Body
The Framework
If one is to believe the books and magazine articles, websites, and game developers one talks to these days, there seems to be a general consensus that the bare-metal, code-it-from-scratch mentality just doesn't cut it any longer when developing games. Software engineering practices long appreciated elsewhere in the software development world are finally making an appearance in the last bastion of the garage-hacking, caffeine-swilling coder.
This is for a lot of reasons. For instance, game publishing schedules ("If it doesn't ship in time for Christmas, we're gonna lose our shirts!"), lack of in-house expertise ("Sure I can write that, just let me brush up on my number theory first."), egg-on-the-face from having shipped buggy products (let's not name names), improved tools and the general enlightenment of the coding community, amongst many other factors, are all changing the way games are made.
So what does this mean from a practical perspective? It means that libraries that provide a framework in which to build a game are increasingly de rigeur. Adopting a clean API (GPI?), preferably portable, frees developers from having to deal with all the minutiae of writing a game. They're then able to focus on creating novel technology to differentiate their game (not that this happens often enough, but that's another rant - see the Scratchware Manifesto), spend more time on design, make the architecture more flexible, squash bugs, etc.
It turns out that there are a lot of these libraries out there, from the completely closed and de facto standard DirectX, to the various completely open ones infrequently used for commercial projects (most of the Unix-based APIs). They are written with different goals in mind, and often from one person's perspective as to what would constitute the ideal game development platform -- hence the proliferation.
The Design
The fun part, and the challenge, of working on the Game Kit for Haiku, is that the Game Kit is currently sparse. Be was presumably working on correcting that, what with OpenGL being re-written and the necessary changes to the Game Kit that would entail, but if we don't get any of that code, perhaps that's just as well. We get to spend some time thinking about how best to build an amazing Game Kit almost from the ground up, and do it in a way that meshes nicely with the existing API that we've come to know and love as BeOS developers.
Which isn't to say that we won't be source compatible with programs that use the existing Game Kit, but there really isn't all that much code to be compatible with, relatively speaking. The small size of the Kit means that, although it'll be tricky to implement because of how tightly knit it is with other parts of the OS, it still shouldn't be all that much work (at least, not for the people working on the game kit). A lot of other stuff has to be in place, e.g. graphics support, before it makes sense to worry about getting a BDirectWindow happening.
In the interim my approach has been to peruse the other libraries available, particularly those with source available, and try to determine what's good and worth keeping, and where we can improve on existing designs. Some examples you might want to look at are SDL, Clanlib, PTC, Allegro, CrystalSpace, and DirectX - the list goes on.
Another pair of technologies we'd be well off having are OpenGL and OpenAL, because they're standard or becoming so, well-known and supported, and having them automatically lends us a certain air of legitimacy. There is also an increasing body of knowledge accruing on the net, at places like gamedev.net, gamasutra.com, and flipcode.com pertaining to what was once one of the more secretive branches of the software industry. Go ahead and have a look. You'll thank me you did.
The Implementation
As far as the actual classes, systems, and whatnot that will compose the Game Kit, here are some ideas:
- display surfaces.
- n-Buffered display, i.e. back-buffering.
- resource compression, (en|de)cryption, loading and translation.
- network game support, including game finding, negotiation, etc.
- BMessage transport across networks.
- OpenGL support. Perhaps a native 3D engine that wraps OpenGL.
- OpenAL support. Perhaps a native 3D audio system that wraps OpenAL.
- multichannel and positional audio, including audio convolution.
- generic implementations of commonly used game algorithms, e.g. A*.
- a logical game framework based on an extension of BApplication.
- a decoupled, multithreaded graphics and game state framework, i.e. game state and "drawing" happen independently; a drawing thread can take a "snapshot" of the current game state for rendering while game logic proceeds.
- a generic save game framework, usable by all games.
- hardware queries that determine the capabilities of the current machine. Some standard benchmarks might be useful to scale game features according to the capability of the hardware.
- force feedback, general haptic support.
- classes for uniquitous game elements like menus, consoles, splash screens, scrolling credits, bitmap fonts, etc.
- support for playback of multimedia (courtesy of the Media Kit).
- automated music generation
- multilingual support (good 'ol UTF8, multiple resource files, etc.)
- serial debugging, message console debugging, etc.
- math stuff, e.g. vectors, matrices, quaternions, splines, compression, etc.
- low-level stuff, e.g. bit-fields.
- insert your favourite feature here.
If half of the code you need to write for your game is written before you first sit down with a design document in hand, chances are you'll be a happy developer. Our mission with the game kit is to spread such joy throughout the land.
The Future
Since it's you (yes, you!) that we expect will one day be writing the video games we intend to be playing on Haiku, the Game Kit people would love to get some feedback from you: feature requests, design suggestions, recipes, whatever. Send it to Robert Medeiros or Vitaliy Mikitchenko.
Of course, nothing I've said here is set in stone - at least not yet. My personal milestones are to have an unoptimized alpha version of the new Game Kit released with the first alphas of Haiku, profiled and somewhat optimized betas accompanying the beta OS versions, and massively tweaked cycle-squeezing code shipping with the 1.0 release, whenever that might be.
Chances are the Kit will be available and usable long before then (I've already written, and re-written, moderate sized chunks of the library in an effort to grok the design), but I don't want to promise that the API won't change, or that things won't break horribly up until that magical moment when my sweaty hands are cradling our collective love child -- a golden master of Haiku v1.0.