I’ve been trying to learn more and more about web development over the last few months. In part just because there’s a lot to the wider world of software than games, and I think that there’s much that game developers can learn from that wider world ( and vice versa for sure ).

Deliberately unemploying yourself helps a lot I might add. There’s generally so much to do when working on a game, it’s hard to pursue extra-circular activities.

At any rate, there are a lot different UI solutions out there in the world for applications other than games, for lack of better terms let me lump them into the (probably incredibly poor ) categories: DHTML, Flash, and Forms.

Categories Link to heading

Dynamic HTML is typified by HTML w/ embedded JavaScript, CSS, and the DOM. For the uninitiated the DOM is a set of semi-standardized interfaces that allow a browser to present HTML ( and XML ) for parsing/manipulation by JavaScript.

Flash, in this particular context, refers to the more generic concept of a platform for UI development and delivery than necessarily Flash itself, but of course, Flash is the foremost example of this.

Forms, here cover standard windowing applications, dialogs, and the APIs used to create them. To name a few: Java’s AWT and Swing; MacOSX’s Cocoa; Windows Win32, MCF, and .NET Forms; wxWindows; Tkl/Tk.

HTML wasn’t originally designed with much more than simple, single page presentation in mind, but it has grown to the point that, with DHTML, it’s a flexible, if work intensive, way to provide custom user interfaces for all kinds of content.

Unlike HTML, Flash is geared toward content over time. While DHTML has come close to some of Flash’s capabilities, Flash was designed with user input and immediate feedback in mind. Flash also provides a very rich display mechanism, and in this sense becomes a complete platform for delivering user interface.

Forms, like Flash, are usually, though by no means always, part of a larger platform. Unlike both (D)HTML and Flash, Forms are geared towards making a consistent user interface across an entire application, and in some cases, across an entire OS.

These categories aren’t completely rigid of course. The space between strict forms and the web has been blurring as more and more developers seek ways to build web based applications quickly. While there’s “always” been HTML forms: buttons, text input boxes, etc. more recently there’s been full on dialog like support. Among others there’s: Microsoft’s WebForms, and Mozilla’s XUL. Flash likewise has been growing it’s own native form extensions, whereas Windows latest .NET work is heading the direction of Flash.

Link to heading

Game UI Comparisons

User interface for games falls roughly into two categories: front end menus, and in game HUD. I say “front end” but of course there are in game options and inventory screens; I say “in game” but sometimes front end screens are over real time graphics. My phrasing here, like the UI models above, are meant to be more evocative than accurate or scientific.

That said, none of the models above match up really match up well with these two categories.

For instance, while Form-like consistency might be a good thing for a game’s main menu I can’t think of anything less consistent than game HUD. Even within the same game, there’s tons of different elements that all do their own unique things. Further, Forms simply aren’t as dynamic as game UI tends to be. Forms generally, well, just sit there. Game interfaces, even main menus, tend to jump up, blink, spin and turn every which way. MacOSX flying windows don’t really even come close.

Flash, on the other hand while incredibly dynamic, is really, for lack of a better word, an engine for user interface. That may be good for some games, it really does come at a significant cost. Because it’s a closed, proprietary system, extending Flash ( or any other UI system of this model ) to the needs of a particular game, and integrating it well with the rest of a particular game engine is no small feat. Both the editor and the language, for instance, really need to provide facilities for manipulating and displaying game elements, as well as facilities for talking to and interacting with game state.

DHTML is interesting to me precisely because it’s so flexible, so widely used, and so relatively open. Like Flash, there is no model for talking to or displaying game elements, which is a problem. On the other hand, even if somewhat “transaction-oriented”, there are standard ways of talking to, and manipulating, state on servers. All that may be moot however. While there are some web-page based games out there, there are no commercial games that I know of that have ever attempted to replace custom UI with HTML.

Link to heading

Another Take

My simple analysis that no model matches exactly does miss an important point however – a fairly basic theme underlying these models. JavaScript, PHP, and even Flash are popular in a way that Form based programming isn’t. Non-programmers feel free to use both Flash and DHTML. Unlike Form programming, they don’t need compilers, or linkers. They don’t really even need a complex editing environment. Though something like Eclipse does wonders: notepad ( or emacs ) works just fine. The language and the content are intermixable. A single html page can contain: markup, style, and programming all in one place.

The most useful advances in form programming of late, follow this same pattern, namely a tighter integration between form layout tools and the programming environment. This started long ago with the NEXT, but .NET finally has achieved a similar level, as has Java with the NetBeans IDE. ( NetBeans by the way, even though slow is pretty awesome even for those used to Microsoft’s excellent programming IDEs. In fact, I would say it offers a lot of things that Microsoft could learn from. )

Perhaps if game developers are to learn anything from this, it’s that if we really want non-programmers – our designers and artists – to be able to control front end menus and in game HUD, we need to begin to mix-up content, scripting, and presentation. I know this is anathema to good procedural programming but perhaps it’s key to fast, flexible UI development.

A word of warning perhaps though. To be really advantageous to the game development process, I think we have a lot to learn about how to leverage the knowledge of existing user interface creators.

Until we can use the hard won skills (D)HTML designers and Flash developers, we will probably be behind the curve – continuing to spend large amounts of our development time on user interface development.

Link to heading

Final Note

Over the last few years there has been a growth in UI middleware for games. Where previously there was nothing there are now several different efforts. On the commercial front: Anark and Scaleform. On the open source front: Crazy Eddie’s GUI. Microsoft’s DirectX has simple GUI widget support. Shockwave/Director/Flash have always provided a platform for containing mini-games, but Flex may be providing some new steps towards going the other way: embedding Flash into games.

As I have some time I might, out of curiosity, see whether the middleware that’s out there falls into any of my UI categories above, and just briefly, provide an update to this post as to which uses which.