Working Architecture

So, finally now that classes have died down and I'm on the last stretch of my BS degree in Software Engineering, I am going to cover future plans and the system I have been devoting some of my spare time to, the Inferno Game Engine.

I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.

Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.

Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):



The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.



The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.



The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.

My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.

And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.