The XNAMachine

I'm continuing to plug away at my new engine here and there, mainly by jotting ideas down into classes & interfaces, and then shaping them into workable objects. It's kind of like throwing lumps of clay down into the IDE & then shaping them into recognizable things. It's probably the world's most inefficient way to design something but I'm having fun with it.

The XNAMachine (my obvious name for this new engine) has grown into 5 primary categories which I've split into as many Namespaces within the project. The primary namespaces are, in no particular order

• Core - this contains classes such as the base Game class, the VBContentManager, a static math helper class, all the primary singleton stuff


• Objects - the base game object is defined in here along with a base game component for including objects in the XNA Game's components collection. Future items in here will be other common bases; screen, camera, and some sort of base spacial partitioning class either a grid or a quadtree or both


• Augments - a base class + various primitive implementations of game object expansion pieces


• Automations - this is the bit I've been working on the past couple of days, it's a system of rudimentary classes that primarily hold information which can be used to modify various properties of augments. Automations are intended to be Augments, but it's such a big category of "stuff" that it got it's own namespace. An example of an Automation Augment would be, for example, if you have a Transformation augment attached to a game object, the game object gains the ability to be transformed by a matrix. You can then attach an automation augment to that game object, specify which element of the transformation object you want the automate, and this will allow for "scripting" various activities over pre-defined times & destinations. I have a system like this now, it's just not nearly half as elegant as this revision will hopefully be


• Augment Update Services - the way I'm experimenting/planning to update augments is to create a collection of service implementations that perform various tasks, each built to accept a single augment at a time. Every single augment will have a reference to the service it uses to update itself, so when an augment wants to update, it simply passes itself in to it's service reference.

So that's kind of the gist of it so far, and I'm getting reasonably close to finishing up the classes in the Automation Namespace, but my wife is hardcore giving me the stink-eye so I better turn my laptop off before I get busted.