The UI System

I decided to take a break from the rendering/physics side of things and work on the UI system. The UI system is based on a custom scripting system – embedded in the project as data files which cannot be downloaded or modified in the final game to avoid issues with Apple. Anyway all the UI in the game – both 2D and 3D – will use this data driven system.

I’ve also implemented the text system, which uses a bitmap font for fast rendering, to enable text to be properly layered with the UI and to allow the text to be rendered onto 3D UI surfaces. You’ll be able to freely interact with both 2D and 3D UI’s, allowing you to interact with panels directly in the 3D world. These panels can cause things to occur in the world (doors opening, platforms moving, etc.) and will be a primary means of interacting with the world.

Here are some examples screenshots showing the UI system with both 2D and 3D UI’s.

These shots are taken directly from the iPad. Notice the button color on the bottom buttons changing as I press them, which also changes the text. The first screenshot is in the default state, then I press the left, middle and right buttons.

This screenshot simply shows the 3D UI from a different angle, so you can see that it is really the UI being properly rendered in the 3D world, on the wall.

And finally the same level and UI on the iPhone. Everything works seamlessly between the iPad and iPhone versions.

The UI scripts are exactly the same for 2D and 3D, in fact they are interchangeable. When a UI is created, the instance running is created as a 2D UI (such as the game HUD) or by a model in the world as a 3D UI. Unlike, games like Doom3, the UI is setup with iPhone/iPad control in mind – essentially as touch interfaces. This means that you’ll be able to drag around elements (if enabled by the script), use multi-touch where appropriate, use iPhone like scrolling instead of scroll bars and so on.

Finally the UI panels and game systems will be able to communicate, allowing things like the UI scripts affecting game-state, game-state affecting UI, and having data saved in one level be accessible by any other level. An simple example would be using one panel in a level to turn on one in another level, or all panels in an area to be disabled if the power is off.


~ by xlcontrol on July 2, 2010.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: