Creating a Better Game Development Framework: Or What Games Can Learn From Web 2.0
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…
Hehehe… I like you.
You’re talking directly into my brain. That’s hard to relate I guess. I guess I’m a wannabe game developer/designer. But I’ve had some ideas akin to what you’re talking about. I’m looking for web design work as I write this cause I don’t have the portfolio mustard to get into professional game design yet. I’d been neglecting my web development skills the past while so I’ve been doing alot of reading about Web 2.0 recently (currently learning Ruby on Rails and AJAX and what not)… which I guess is what I mean about “speaking directly into my brain”. I sort of have a constant background noise about game design running and since I’ve been doing so much web development reading I’m completely on the same page.
My own work has been more looking towards a higher level framework… but that fundamentally relates back to the groundwork it is based on… which at this point meant I was thinking from scratch because there isn’t a solid framework standard. As such I’d been pondering your points myself, but you’ve definitely woven them together (at least for me).
I think the meat of it is an absolute lack of standards. There just aren’t any. There’s no WC3 of game development languages that aren’t for the web. Standardization is a multisided die. You end up with benefits as well as restrictions in standards.
I think higher-level tools is where the empowerment comes from, but again what is a higher-level tool without a common set of standards to be built off of? Something very restrictive and not as useful. Flash can do some nice things for the web but it’s far from open. Sure I know how to use it, yes I can write basic actionscript, but most stuff doesn’t need it and it’s not ideal for all web development.
I think the problem is systemic. If we look at games from the base level: Hardware. We immediately run into a problem. Different hardware manufacturers start to support advanced features but don’t make those features commonly availible. They stick them in propietary API’s versus the painfully in need of updating OpenGL standard. Obviously graphics hardware doesn’t sport the actual gameplay, but it’s an example of part of the issue. If we move beyond hardware we get to platforms. Game consoles, computers (mac and PC), cellphones, handhelds. So many platforms!
Going back to the web comparison, now I’m only 22, but my impression was that the web was originally only intended for landbound computers and eventually home computers. So it originally only had to support a few operating systems. And even then it’s not untill recently that webbrowsers have actually started to HAVE standards that were reliable… even as short as 5-10 years ago that wasn’t the case at all. And then cellphones and other platforms now have to confrom to the established standards… but they came later. Now I’ve not followed game development for too many years, but I’ve never been aware of too much of a push to standardize much of anything in games. I feel it kind of stems from the same attitude that permeates most games traditionally: “I’m a teenage boy, and what’s mine is mine! Fuck the rest of you! Our’s is way better and bigger!”
There’s a handfull of dominant engines in the market and they’re all so proprietary. For example, I grew up modding HL, so I know HL’s tools… Hammer, a smidgeon of 3DSMax, proprietary scripting for their engince, and Photoshop (fortunately Photoshop is a nice standard). But Hammer and their scripting language aren’t useful elsewhere… and even 3DSMax to a certain extent… sure if you know them… you can apply CONCEPTS to other tools but it can be a bitch to learn the new tools because they’re the same…. but different… and sometimes COMPLETELY different. The tools that make content for games are even becoming propietary (at least in aligences: Valve and XSI for example) Games have their own engines for everything… and sometimes you need that… but what they make doesn’t contribute to the whole. There just aren’t enough people like us saying, “Wait guys! All this stuff is great and all but we’re specializing instead of standardizing!”. Some of that is obviously some of my person frustration, but I can only use my own expereinces as examples.
Getting back to my previous point, as the web was struggling for standardization… it doesn’t feel like gaming has tried to do that so much. There have been different efforts at different points and time, but it’s definitely not an industry trend. People have been building engines (as you poigniently noted - “browsers”) for a long time but the similarity ends there because as you duely noted there is no actual equivalent in games.
I think you’ve basically outlined a grocery list for the industry:
1) A standard upon which to base Games (”Browsers”) - DOM
2) A standard markup to relate the functional mechanical bits to the engine - XHTML
3) A standard markup to relate the aesthetic parts to the engine - CSS2
Whatever the DOM equivalent for gaming - Let’s do what the tech industry does best - MAKE AN ACRONYM - G.O.M. The Game Object Model needs to be flexible to allow the various languages out there to interact with it. We need to start to see more open engines based on a GOM. Frankly game mechanisms are standard and need to be standardized. You touched on this and this has been where my own research and development has been… the stanard mechanics of games. Games have common elements - UI Bits, Common Statistics, Common Controllers. The industry has spent a long, long, long, long time (all of it’s history) rewriting alot of the same code instead of building a standard framework of game mechanisms that can be expounded up and overridden for specific uses.
XHTML and CSS - They’re standard for web, but I agree that the lack of standard base prevents even the practical discussion of a game equivalent untill such a standard starts to take shape.
Anyways… alot of that is regurgitation mixed with fresh food… which I guess doesn’t always taste so great… but it helps me digest what you’re saying. Again… definitely on the same page.
Gonna keep this going upstairs in a “spin cycle”…
-C. Richardson
[...] Register « Creating a Better Game Development Framework: Or What Games Can Learn From Web 2.0 [...]
We are trying to create a integrated development and deployment framework for games using a variety of standards and psuedo standards including XAML , XNA , HLA , Jabber , Grid Services. The high level standards aspect seems to be the key but the problem is finding a viable sustainability strategy. Our current solution is to link into DOD sponsored initiatives such as BOM, X3D, and SEDRIS . We would love to hear from anyone actually interested in creating high level standards for games.
duncan@magnetargames.com
I totally like the way you are thinking. I’m coming at the problem from the other side. I’m an HTML/Javascript developer who wants to build games, but trying to approach it from the HTML/DOM/CSS side. It would be so amazing cool to have like a “games markup language” that allowed you to define stages, levels, genre, collision detection, etc. etc. I hope you continue to persue this idea. Have you looked at Laszlo? It’s a platform that allows you to develop web applications and output them to either Flash or DHTML. If that could be adapted for games (you can create your own tags, etc.) that would be perfect for what you might be looking for. http://www.openlaszlo.org
Hey,
You have a great idea! We’ve started a game development framework similar in design to ruby on rails. We call the framework ’shattered’.
[...] Not too long ago I posted about my desire for a game framework that was as useful as the frameworks enjoyed by the whole “web 2.0″ crowd. Call it envy, if you will. Those web 2.0 geeks have great toys to play with. The concluding paragraph of my post pondered, “Maybe I shoud just shut-up and start using Flash…” Well, I did. [...]
[...] You know, kinda like exactly what I said would be the perfect game development environment back in March 2006. I sung the praises of the mindshift in software development brought on my “web 2.0″ where production-quality development truly is agile: they divide the problem into structure, behavior and styling. Of course. The Holy Trinity of Interaction. You find it time and time again when you dissect anything one would describe as interactive: model-view-controller, input-process-output, listen-think-speak… structure, behavior and styling. [...]
Sounds like MVC for game dev. Nice, I like it.