The current state of crimson
cubed2D
July 23rd, 2007.
Two months ago i last posted about my progress with my game engine, Crimson. Things have changed since then. As I’ve previously mentioned, not done much coding has been done on the engine since because of real life and hardware problems (t minus 10 days till laptop returns!). Because of that, most of the progress has been in design. Here is what my class layout looked like back at that last update (all these classes were coded up when i posted this originally)
Well, as you can see, I’ve crossed off everything that doesn’t exist in my current design. That’s not to say this old functionality is being removed, just that its being moved around and redesigned to be a lot more powerful that it ever was before. I’m also trying to decouple the game simulation from the world view, a trick that i learned from reading Game Coding Complete 
 So, “how does it look now!?!” i hear you shout, well like this.
Each icon represents a different core area of the engine. Authority is the game rules, its where the simulation takes place. This will include a physics engine, the information on the current level, the data structures containing all the current entities in the world and things like that. You could almost think of it as a server (infact, this architecture is very good for extending your game to be multi-player). It also contains the command interpreter, which is very important! (shall all become clear soon)
The view is not a single piece of code like the authority, There is actually loads of em. Im implementing a base view which can be extended for more specialized purposes. They are basically filters on the game state(held in the authority). The most obvious example on one would be the player view. It has all the code in it for drawing the world to the screen, converting button presses in to commands, making music play and stuff like that. You could also make one to command a team of A.I players. It wouldn’t need any drawing code, but it would need to be able to sense whats happening in the area of world-space it can see (filtering everything it cant out)and then sending commands to the authority for the next step in simulation.
That’s where it comes exciting for me. The game I’m designing this engine to build will rely alot on A.I… good A.I that doesnt cheat. This system lets the A.I only get the same information a human player would, and use the exact same methods to interact with the game world a human is. For me, that’s big!
 So whats that last bit all about? have a closer look!
 
Please remember this is still far from done, its in a kind of half way state between class layout and program flow diagram! Whats important is that the class CrimsonEng is the engines entry point, create an instance and throw it a start-up script and the game shall load! Its basically a massive collection on managers which will be available for the other systems to use (via the interfaces and core libs). My current plan is to not use the default game class that xna ships with, as it wont fit very well with my engines design (maby more on this next time). Some interesting things here are things like eventMan and MessengerMan. Messages are going to be from entity to entity, good for A.I characters or triggers. Events will be for wider reaching things, like state changes or button presses. I think its important to separate and specialises these kind of messaging functionalities. Well, Thats it for this installment! Cant wait to get my laptob back to start building this thing!