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 OpenBeOS, 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 OpenBeOS, 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 OpenBeOS, 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.

There is one source of confusion (if I may call it that) about the track we are taking to implement OpenBeOS that comes up quite frequently. And, frankly, it drives me nuts! So let me dispel this misconception as best as I can.

We have, for quite specific and logical reasons, chosen BeOS R5 (the last official release from Be) as our development target. That is, we aim to create for our initial version, an OS that matches, as closely as possible, R5.

This one simple fact, apparently, causes more people to roll their eyes, hyperventilate, and wag fingers than could be possibly imagined. The litany of complaints goes as follows:

R5 is old, several years behind the times!

By the time you implement R5, you'll be several years even further behind!

It's legacy ('90s era) -- do something new and innovative!

R5 is buggy, don't reproduce that!

Worry about adding (insert technology X) that R5 doesn't support, not with recreating (the already inadequate) R5!

Yes, we hear you. We understand. We sympathize. And, most importantly, we agree!

That's what makes it so frustrating to hear these types of comments. These kinds of concerns confuse our pragmatic strategy for implementation with the end goal. We are recreating R5, not because it is the final destination, but rather because it is a logical and straightforward beginning point. We are building a new house, and the first thing it needs is a good foundation.

That foundation is a code base. Once we have the code base for a working (even if not complete) OS, then the world is our oyster (actually, I don't like oysters, but it seemed like the thing to say). Can you imagine the day? What glory to behold the source tree for an honest-to-goodness working OS that can be tweaked, updated, and extended to your heart's content and your imagination's limit.

Those of us who contribute to OpenBeOS are not lacking in vision. We don't have fewer dreams, desires, and pie-in-the-sky fantasies than anyone else. But, in regards to development anyway, we realize that none of this will ever come to pass without getting down to the long, tedious, gritty work of creating the code base.

To get this code base written, we need two basic things: clarity and stability.

Clarity refers to having a specification or goal that is crystal clear. You'll never get anywhere if you don't understand the problem at hand.

Stability refers to having a goal that remains fixed while designing/coding. Without stability, you never finish anything, because the work always stops at 80% completion (or less) in order to switch to the "new" model.

R5 gives us both.

Because it is extensively documented (notice I said "extensively", not "perfectly"), there is no confusion among developers about what the spec is. Everyone knows and agrees on what needs to be done -- implementing the R5 API. You couldn't ask for more clarity than that. This fact alone will probably save us man-years of time and effort. Without it, our project might be nothing more than a think tank where people argued endlessly about "cool" things we could do.

Quite obviously, R5 is not going to change. It was released and stands fixed as stone. This is the stability we need while coding and testing. Naturally, there is nothing magic about R5 itself -- it just happens to be the last official release. If R6 or R7 or R8 had been the last, that would have been our target.

Of course, there are various pieces of what probably would have been R6 floating around the BeOS community. Should we take advantage of those? Absolutely not! Doing so would wreak havoc on both the clarity and stability we have with R5. Any parts that make up what might have been R6 are not fully tested, working, documented, reliable, etc. Interesting to look at, no doubt, but not what you'd base a critical project on.

By having this clarity and stability, we have something solid to push against, we are able to make progress. Would you rather walk across of pit of loose sand (or quicksand) or on solid, hard ground? What some see as lack of flexibility is, in fact, solidity. It allows us to step with confidence and continue moving forward.

What happens then, once we have this sought after code base? We begin to implement the dreams we had put aside momentarily. We begin to implement all those "cool" features that have been suggested. We take an OS that some consider legacy and turn it into the most innovative, cutting edge, downright awesome OS anyone has ever seen. Why not? The source will be available for all to see. Anyone and everyone with an innovative idea could contribute.

It has been mentioned by some that I have been instrumental in researching the blackest of black boxes - the App Server. However, what I (and the rest of the IK Team), now know is already out there. It's just a matter of finding it. There are basically three ways to extract this information: documentation, software tools, and networking.

Documentation

First, BeOS has its well-known books: The Be Book, The BeOS Bible, and Be Advanced Topics, amongst others. Our core knowledge as developers ought to come from there (duh!). Having both electronic and dead-tree formats is the best. Searching for a particular word via 'grep' can be immensely helpful in finding the information, after which one can read it at one's leisure. Also, not exclusively limiting one's expertise and focus to a particular Kit is necessary. I have learned more about the Kernel Kit than I think I ever care to know. :)

Second, Be Inc. published a series of newsletters addressed to developers in earlier (pre-4.5) days. While helping developers with understanding and using the API, the newsletters' authors have made known quite a few things not mentioned elsewhere. It is simply marvelous to find the exact answer to one's question simply by looking it up!

Third, the WWW (World Wide Wait) is a gargantuan beast which contains files and information about BeOS' past in its earlier releases. AltaVista, Google, and other search engines prove to be extremely useful. For example, a search for +beos +app_server on AltaVista returned 108 results. While this is a rather broad search, it implies that someone has written something that somehow involves the BeOS app_server. The reader is encouraged to consider Fravia's Searchlores, which gives a wealth of information on searching and finding via not just the WWW, but also FTP and many other protocols and means.

Software Tools

While sometimes not the most obvious route, it is simply amazing what playing with a few common applications can return. Quite often, someone else has created an app which deals directly with the area that you are concerned with. As a developer, you can create your own tools to tap into this source.

Need to steal messages from a server? Make a mockup which just dumps all messages sent to it. Need something more low-level than that? Steal the server's port and do your own message monitoring! The best inventions were created out of necessity; you see a need, so you fill it with your own solution.

Below is a list of apps that you can glean useful information from. By no means exhaustive, but it's a good start.

Native Utilities (included with the BeOS):

• ps - returns a list of all processes running, along with respective semaphore names, ports, and threads in each team.
• objdump - dumps objects, symbol lists, etc. found in binary files. Very nice for learning about internals. :)
• grep/zgrep - find the occurrence of words in a file or files.

Other Apps:

• BeFileGrep - a graphical interface to grep (written by our own Zenja Solaja). It's simple, effective, and quite useful.
• Be Debugger - Loading an app in the debugger can be extremely useful if you know anything about assembler. There's a bit of bdb documentation from the old R4.5 Release Notes.
• hey - simple scripting language for sending BMessages to running apps. This was the way that information was gathered for the print_server.
• AreaWatch - need to know about areas? This has loads of info on all areas maintained in the system. An old Be newsletter, Issue 25, has more info about this utility.
• MemIt - inspects all running teams for number of threads, RAM usage, and so forth. It's almost like a realtime ps command.

Networking

Thoughts that come to mind when networking mentioned normally include TCP/IP, IPX/SPX, sockets, and a host of other things. But what I'm referring to is a people network.

Some people might say that it's not what one knows but whom one knows. Be employees and developers are a helpful bunch. While NDAs limit what employees and former employees can divulge, they can point in the right direction, give general advice, etc.