I spent several hours yesterday staring at my laptop, trying to get the first broad strokes of a game framework down. I would head in one direction, sketch out a few classes, work out a few use cases with those classes, then toss it away. Nothing was very satisfying. What do I mean by a game framework? Well, I'm not necessarily looking for a 3D API (I'm fine using OpenGL or D3D), nor am I looking for a high-level Game Object system (not quite to the designing gameplay stage). I'm trying to develop a "harness" so-to-speak that I can use as a baseline for experimenting with a lot of different gamedev stuff. Something along the lines of DXUT or GLUT or SDL... but those don't quite fit. They're either tech-specific (DXUT/GLUT) or showing their age (SDL). To me, those APIs are really *implementation* APIs, not frameworks for gamedev. I also don't want to go the other direction and grab something like Torque or OGRE or some of those other "complete" solutions, as I'm not looking for a all-purpose 3D engine. I'm really looking for the "skeleton" of my application: a way of organizing the game loop, startup/shutdown, init'ing the various hardware systems, managing resources and gamestate, etc... things that have nothing to do with OpenGL or DirectX or Windows or Mac or Linux or 2D or 3D at the design-level. I'm tempted to just rip-off some APIs that I like (DXUT, for example, or SDL). But in doing that, I was left fairly unsatisfied as those APIs had aspects that were pushing me to write my own in the first place... I'm just having trouble putting my finger on it. Anyone have any pointers to some articles discussing this aspect of gamedev? Anyone have any suggestions of their own, or advice for getting past this "programmer's block"?

I designed a micro-kernel-esque architecture that i now use in my applications.

- I have a kernel that loops through 3 or so states, STATE_INIT, STATE_FRAME and STATE_END
- Have a base class called 'process'. When you want something to run on the kernel you have to write a class that implements the 'process' interface. You have to implement void Init(), void Frame() and void End() functions for your class.
- You add the process to the kernel bia void AddProcess( process* P ).
- The kernel loops through them all once for initialisation, continually for the frame and once for the end.
- There is a get process method for the kernel that a process to get a pointer to any other process. For example if your texture manager process wants the device, i t can ask for the D3DInit process, or the like.
- It has built in logging, so any process can call kernel->SafeLog(). You can either provide your own logger or use the default one.

I have found that although my core code has loop holes, it is very practical. Hope you can get some ideas for this.

Dave

You should take a look at the enginuity article which is posted on gamedev. Just type in enginuity into the search bar. I learned a lot from reading it :)

I didn't find Enginuity that helpful personally.

There's another thread going on that touches on some of the same thoughts I'm hashing out here, What gamedev can learn from the web.

The reason I started both of these threads almost simultaneously as they're two sides to the same coin. The framework I'm looking for, I'm wondering if perhaps I should be modelling it off of something like the web's DOM (Document Object Model). I guess that's not exactly what I'm looking for, as part of what I'm wanting in a framework is a bit of the structure used for supporting everything that uses/implements the DOM.

But, reviewing that other thread would probably give a bit of insight into what I'm thinking about. I've not seen any good "Game Object Models." I've seen engines, I've seen libraries and toolkits. I've read over Scott Bilas' work on Dungeon Siege, and read some stuff on Halo's engine, and lots of other GDC presentations. But none of these seem to propose a more flexible Game Object Model.

And it's not just the object model, it's the process of defining the initial state of the model (like XAML does for an application) and defining the model's behavior (like &#106avascript on the web).

But, beyond that, and more to the point of this thread, is the framework for the actual application that would support the gamedev model proposed in the other thread (one that mirrors, somewhat, the web 2.0 model).

Dave, I like your suggestion of micro-kernel. It reminds me of a colleague's suggestion of treating the game as a mini operating system with a bunch of processes. He actually expanded on the idea to include a command parser, file system and network stack. Hence, you could "telnet" into the game engine, peruse the "file system" (a representation of the in-game resource tree), issue commands and launch processes (similar to what you described), etc. Considering the modern target hardware for games, a mini real-time OS would be a shockingly small chunk of memory overhead (heck, Xbox/Xbox360 are running OS kernels already) compared to the rest of the game. And the nice benefit is that it's a metaphor that people (developers) are intimately familiar with.

I'm glad you like my idea.

Your comments in the bottom paragraph have given me ideas about how i can make my framework more suitable ffor game applications in general.

Dave