I have recently been trying to create a clean, simple baseline framework for game development. Not necessarily for big team commercial game development (that’s my day job @ EA), but for my one-man hobby playing with gamedev. As I experimented with several different designs for the core architecture, it struck me that there was something fundamentally missing in the world of game development that’s been popping up in other development circles.
Unfortunately, I don’t have a good name for it. Something akin to XAML, but for games not apps. Yes, I know XAML can be used to make games, but at the very least it’s .NET and it’s Vista, so it’s not quite ready for what I’m looking for. I’m actually thinking of something more along the lines of the holy trinity of web2.0, XHTML/CSS2/DOM.
I like to dabble in web development. It was my first real job, back in the dotcom days, doing web design (which also meant web programming, and Photoshop, and search engine optimization, and graphic design). I found it to always be an incredibly satisfying toolset — particularly if browser incompatibilities weren’t involved. Now, with browsers like Firefox, and standards like XHTML and CSS2, developing for the web has an incredibly exacting feel to it. Flexible, portable, standard, accessible… lots of satisfying aspects.
In the world of game development, I don’t feel like there’s a good equivalent. Sure, we have common APIs like OpenGL or DirectX, but those are really just implementation details of what I’m looking for. And they’re in a different domain. There’s also the game engines, like Unreal3, but that’s too high-level and would be the web-equivalent of a CMS app or blogging tool: fill with content, turn the crank, out pops a standardized game.
There’s certainly no common API for organizing the process of game development. If you write Windows apps, you’re hopefully using C# .NET which has a load of standardized facilities. Actually, it says so right on the box: .NET Framework. Sure, you can make games with it, but all you’re doing is leveraging the collections and DirectX wrappers; .NET doesn’t provide a games-oriented framework.
What I’m proposing is a framework for games, something similar to the three-pronged approach of web2.0: XHTML/CSS2/DOM. These three technologies represent structure, style (or what I’ll call aesthetics) and behavior. These are three properties inherent to games.
Structure is essential on many levels in games. There’s the obvious visual/spatial, screen-relative structure of the game: high score in the top-left corner, current score in the top-right corner, numbers of lives left in the bottom-left corner, gameplay in the background. There’s also the temporal structure of the game: Title Screen –> Game –> Game Over –> High Scores. Finally, there’s the internal structure of the game’s model, such as the map coordinates of the bad guys, the stats of an RPG character, or the arrangement of tiles in a game of Tetris.
Aesthetics in games is pretty obvious. It’s the property that distinguishes Wolfenstein 3-D from Return to Castle Wolfenstein. Much like in web development, it’s essential to be able to separate the aesthetics of a game from the actual gameplay, if only from the practical perspective of getting to iterate on each independently.
Behavior is fundamental to games. It’s what separates games from narratives. Behavior facilitates the interaction between the user and the game. Behavior also operates internally to the game in the form of a ruleset. Lastly, behavior can be thought of as the simple automation that digital games have over their pen-n-paper cousins: through behavior, I’m able to control hundreds of units in a game that would otherwise be tedious with physical tokens.
To be clear, I’m not trying to speak to the aspects of a game from a gameplay design perspective (though there are some obvious and necessary overlaps and similarities). I’m looking at it more from the actual production process, the tangible development of an executable that I can run on my customer’s machine. (As an aside, this orthogonal decomposition of a game into structure/aesthetics/behavior is very similar to the academic decomposition of game design into mechanics, dynamics and aesthetics, as well as being similar to the software engineering pattern of model/view/controller.)
What devices to web developers have at their disposal to accomplish this tidy decomposition? First, and most fundamentally, they have the web browser. For lack of a better analogy, we could consider this most generically to be our equivalent of a game engine, though it would be a very, very generic game engine, more so than really any engine I’m aware of.
Second, they have the basic food of the web browser, HTML, or it’s more well-formed cousin, XHTML. While logically equivalent tech exists as most every game developer who employs some kind of toolchain, there’s clearly no standard form for describing the structure of a game. As a result, we as developers must discuss things at a nuts-n-bolts programming level, borrowing heavily from that domain’s idioms. Maybe one day XAML will fill this role for us, but it’s certainly not there yet.
Third, web developers have CSS. This adds a critical wrinkle to the mix. With the advent of CSS, web developers were able to cleanly separate the structure and content of their medium from its visual (aesthetic) presentation. The best equivalent we have in game development is the use of placeholder artwork and stock library models. Under poorer development processes, we have a direct coupling that would remind web developers of embedding font tags in the middle of their paragraphs.
Finally, web developers have the DOM (Document Object Model), which is programmatically controlled through JavaScript. Here’s an area that game developers actually have some parity with game scripting engines. Lots of developers have scripting engines these days, lots of them use fairly standard languages (Lua, Python, LISP), and the scripting languages often have what would be the equivalent of DOM-access to the rest of the game engine. The only real difference is that what is defined as the DOM for a game varies pretty widely. Some would argue that it does so necessarily because games are different. But then again, so are websites, so perhaps there is soom room for standardization.
Of course, maybe all of this chatter is crazy talk. Maybe I shoud just shut-up and start using Flash since that sounds vaguely like what I’m asking for. It’s close. In fact, it’s very close to the designs for Flash when we originally put together the (now defunct) OpenSWF group back in 1998 (pre-ActionScript, thank-you-very-much). But there are some limitations to Flash that prevent it from being directly adopted: it’s rendering engine is fairly specific; programmability is only through the interpreted ActionScript; it’s fairly closed and proprietary regardless of what Macromedia may lead you to believe.
Or maybe, just maybe, there’s a better way to make games…