User interface coming along

Development recently has been focused on the user interface. This effected several changes in other systems like the renderer and platform also. I really want to get on with the fun part (developing the actual game) but as I've mentioned my approach is to have as many other components in place as possible first. It shouldn't really matter what order you write your code in though, if your design is modular and clean.

Developing a user interface is easy whilst developing a good user interface is very hard. With the user interface for PhysTank (as with most games) easy is taken over functional. A fully fledged UI API would contain a richly featured widget system, incorporating buttons, sliders, dialog boxes etc no dissimilar to the java swing libraries, developed entirely in a blackbox fashion and probably farmed out to a seperate library. There are C++ API's that exist which contain this and deciding whether to use one of these or roll your own is often a tough choice. For PhysTank the UI doesn't have to be particularly complex, I probably won't be using that many floating dialog boxes or slider controls, so where appropriate will fashion my own thrown together widgets. In a game that does require a more complex UI I would definitely recommend using an API like GTK. Using common API's like this rather than rolling your own will not only save you lots of time but since most UI API's are designed around making sure users have a certain degree of familiarity you won't be confusing your players with weird and wonderful designs. I will probably be using one of these API's when it comes to writing the level editor.

The User Interface still has a long way to come, and I probably won't polish it off until (very) late in development, but as long as there's something in place that gives the player reasonable feedback about what's going on in the game it'll do. Next up on my check list is to implement a basic main menu for the game, also further down the line colour schemes. One problem I'm having is deciding how screen elements (pictures, text etc.) should be placed and scaled on screen. If the user ups the resolution from 800x600 to 1024x768 for example, or higher, then icons and text will appear too small on the screen. In order to fix this these things have to be scaled dynamically based on some "ideal" resolution (i.e if the ideal resolution was 800x600 then on a 1024x768 display that would be a scale factor of 1.28 for the on screen elements). Doing this in an elegant manner isn't easy, and I may just have to resort to having the renderer scale things automatically and all positions given in the range 0-1 and maybe implement scaling functions for text (GetFontSizeScaled() for example).