Hi,

I am working on a real-time strategy game. I have come to a point where I'd like to draw some UI graphics on the screen. I have already made the UI in Photoshop and I'm about to implement it in the game.

A couple of questions I have in my mind:

1) What is the general approach to draw game UI that is interaction-able? For example, if the user hovers a certain image, it should display a hover image instead. Obviously I need some kind of coordinate and detection system that plays well the the UI. Also I would not want to recompile the whole game to change the UI a bit.

2) Should I be using some scripting languages such as Lua or Python?

3) Is there any popular and good layout engine just like there is HTML layout engine for the web?

Making a complete GUI system can be quite hard, if you've never done at least a button before then maybe you should google for some gui libraries, it will save you a lot of trouble.

Drawing the gui is not a big deal, just a bunch of sprites drawn over the scene. The update should take events from mouse (and keyboard if you want to use hotkeys for the menus) and detect what gui item can respond to that event. The easiest way is to define a rectangle for each gui item and check the mouse against it.

Setting the gui from script is indeed the best way to do it, but you don't really need a scripting library unless you will use some complex menus. You could just put informations about each gui item in a text file, something like this:

window, background.jpg, x1, y1, x2, y2, "somewindow", null
button, normal.jpg, hover.jpg, pressed.jpg, x1, y1, x2, y2, "NEW", "somewindow" (somewindow will be the boss for this button)
button, normal.jpg, hover.jpg, pressed.jpg, x1, y1, x2, y2, "SAVE", "somewindow"

Kaitsuh,



While I can't answer your questions, and I'm not sure anyone can give you a "correct way" given there are so many different variations and paths to take while creating a GUI. However if you want to create your own (ironically I am doing that now at the moment myself) I found this very helpful in assisting.



http://archive.gamedev.net/reference/programming/features/gui/





Good luck

I am also kind of interested in this subject. I am thinking about using a class which encapsulate a single sprite, it can have animation, send messages on click, etc. Then use a std:vector to push down all sprite obecjts, then loop through each one and draw them. The best thing here is that the closer to the top the sprite is the higher it is prioritzed. So if a new window (popup) is made it will take priority for mouse events(buttons behind it will not react).

Depending on how complicated you want it to be, you will need a list of windows arranged by Z-order, a way to identify foreground window, focus window (receives keyboard events), captured window (receives mouse events exclusively until reset), active window, etc. Also a way to specify hidden windows, windows that can't receive focus (disabled), can't be activated, can't be (or can be) dragged, are always on top or bottom of Z-order (topmost/bottommost) or windows that are modal (receive both keyboard and mouse events exclusively). Then there is an issue of passing focus around, tab order, events that cause windows to become active or inactive, gain or loose focus. You may also have to look at clipping, windows with buffers, and parent-child relationships. You will probably need a way to subclass the UI windows to handle events as well, which I've done with dynamically created classes and virtual functions. There is a lot involved, in other words - if you want to do it yourself for learning purposes you should look at examples first.

Here are a few things I hadn't integrated into my GUI from day one and wished I did:

* Make sure the format is easy to understand if you are going to be loading from file. Text format like XML works well. If you decide to create everything by code, use scripting or separate dll so you don't have to recompile the whole game. My first GUI format was binary, so I ended up having to create it by code and then save to binary file, since I didn't have time to make an editor.
* Integrate an automatic layout system into positioning and sizing of your whole GUI. Even if you use text format to position and size different controls in your gui it still takes forever to layout stuff by hand. The alternative is to write a GUI editor, but most people will not want to take the time to write tools when they want to work on the game. A simple layout engine that works like HTML page layout by specifying margins, padding, breaks, alignment and attachment will make this considerably faster.
* Use a styling mechanism to specify graphics. I started off specifying texture file names and coordinates on texture atlas for every control. So if I had four buttons that use the same textures for all four states (normal, hover, pushed, disabled), the source texture coordinates and the texture path would be duplicated for each. I switched to styling mechanism where I have a style file (like CSS) and the definition for each GUI control specifies the name of style it uses. Then it reads texture path and coordinates from appropriate entry in the style file when loading. This also has the advantage of having switchable themes on your GUI, that making it more reusable for your other games.

Since you mention HTML - you could actually use HTML/Javascript/CSS in your game if you wanted to. I have been playing around with the concept recently and am pretty happy with the results so far - although admittedly I haven't tried making a full game using it yet. For my stuff I have been using Chromium Embedded Framework, but there is also the Awesomium and Berkelium projects available to use. They all end up wrapping chromium in one way or another.

Interesting approaches guys.

For the record, I am using C# so some of the projects/libraries do not fit well in my situation. Do you happen to know C# HTML, CSS, JavaScript libraries? I wonder what commercial games do?

Going off memory, I believe Awesomium at least should have C# wrappers.
As for commercial games, there was a talk at GDC about using HTML for UI, talking about wrapping Gecko (Firefox). EA has also open sourced their implementation of WebKit for PS3/X360/PC. But in all I'd say most games are probably not following this approach and are using some other UI system (custom in-house or some other middleware).