Game Kit

First of all, apologize me for my English, I know it not quite good but Im improving. I have posted before but they have been deleted (I dont know why).

Quality / Stability, Kernel

I wish that Haiku before have been or sooner if possible BeOS clone. Have some security and quality features, i propose that this OS have a memory execution protection, just to make the life easier and secure, just to enforce to make best programming practices. The thing is like this:

*proteccion to dont allow execution of code if its in a "not code" memory section/page. So to prevent STACK and HEAP/DATA execution. So the application could fail, but OS remain stable.

*proteccion agaist stack underflow and data/buffer/heap overflow. So bad programmed applications could not damage the Operating system in that way and compromise it.

*independant memory position aplication execution.

with all this open techonlogies (even could be implemented by software) not only could make the user life easier but the developer life too, becouse it could be much more easier too detect some common bugs without crash our system. I guess some BeOS application are not too good programmed so they used that bad techniques, so at first place we could use a COMPATIBILITY user allowed method (or even a listed application allowment for compatibility mode with old and bad BeOS bad programmed apps).

at last
*portable devices compatibility and support, like those that could be plugued inot usb port, ex: Mp3 players, video players, memory cards/sticks, IRDa, WiFi, Routers/Hub/..., external storage.

Network Interface

I wish a well firewall, powerful but yet easy to configure, with an advanced mode for experimented users. Preconfigurated with the common and best settings to do every day work.

*Here we could add, a good network interoperability with all Unix open standards royalty free (SCO, BSD, Linux), to make a good neighborhood this OS in a network.

User Inteface, Game Kit

In this part I really wish a powerful GUI with a simple interface, capable to do good 2D/3D work. With advanced features to made easy programming great games using that GUI-API. I must be easy to extend, but the User Interface must keep standard, with the option if you wish to make it customizable with something like skins disigned by users, but with out let it modify the kernel/drivers of the OS. I made enphasis on standard because it hard work to bring support when the GUI its so different, and even the final user (common user) dont even know it at all its features and diferent options positions.

What its important too bring success to this OS its make powerful and yet simple, but with some easy advanced features for that know how to use it. To bring applications for: word proccesing, calc sheet, slide presentation, a good photo processing ex.linux:GIMP, a good vector drwaing ex.linux:InkScape, good Developing tools, like IDEs, .NET power and simplicity; and not less important a good 2D/3D engine (integrated API) so they (open and close developers) could bring great games. With all this we could attract much more users and industry.

-Morthozz

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.