First off: I distinguish between (In-game) HUD (UI connected to the gameplay) and UI (main menu, smaller menus, server browser).
Now to the cool stuff: I've written the base for an a bit more sophisticated (and cleaner) HUD system today.
Design is as follows:
The HUD has been split into Infantry, Vehicle and Spawn Screen (for now).
These will all have separate UIElements (official name for Flash files you can load).
A C++ class (CGameHUD) with its ScriptBind (GameHUD) act as the middle man between the UI (Flash) and the gameplay code (either Lua or C++).
Most of the interaction will happen in the UI Flowgraph.
All calls sent from Lua (or other C++) to the GameHUD will be output into the Flowgraph via the CGameHUD class.
All fscommands from Flash will be output into the Flowgraph, too.
Then they all can be connected and interwoven etc.
So no UIElement file (or setup) is hardcoded.
I tried to keep the Lua-to-UI code to a minimum but as Lua IS the main gameplay it will always need to take part a bit.
The CGameHUD class will only be active as long as a map is loaded (which means if we want to have a map as background for the main menu we'd need to handle that as a special case).
Next up today: UI (as in main + sub menus)
That's not very important, it's just a good looking 'overlay' over some CVars/console commands. More knowledge is always better though, and the more planning we do until we get to creating the UI, the better.
For most of the main menu we won't even need code (as in, not-ActionScript code), the server browser will need some though.
Home 
