Final straight...

Well, 6 months ago when I started learning XNA properly, I thought, very optimistically, that by now I'd have released my first game and be working on my second. Even taking into account the month I spent learning UDK (before realizing how horrendous Unrealscript is), its been slow progress.

From starting work on the tools for Pacman to completion took about a month, and that's only for a single level version. However, it has not been in vain...

My engine is coming along more with each game. And what's more all of the mechanics from the games I've made so far will appear in my first release, currently code named 'Arcade Mayhem'.

In fact I'm now in a position to start work on my first real game. Almost.

The engine still needs work, and so does the design of AM. So instead I'm going to make one last 'learning game': Mario.

Now, the gameplay code from Mario won't help much in my first release, but it will be vital for the subsequent two games that I have planned (both platformers).  It will also give me a chance to update Alta so that it's ready for AM, and let me nail down the design Bible for AM to prevent feature creep.

So, here I go, embarking on my last project before I start 'for real'. Let's get started...

Pacman complete!

Well, after a month of development (mostly in my spare time), Pacman is complete. It was never meant to be an amazing game, just a tool to develop Alta further, but I may as well upload the video, just to prove I did it! The quality is fairly pure due to using CamStudio, but I'm limited to free capture software at the mo.

Logo update

Just thought I'd post a slightly refined version of the logo. Its still just a draft at the moment. Eventually I'll probably get a real artist to have a go, but this will do for the minute.

A draft of a logo

As I'm away on business and so can't work on Alta, I've had a play with the image manipulation package GIMP to make a quick draft of our studio's logo. Its just an idea at this point, but I thought I'd post it.

Good progress

Well, I'm back at my day job now, so progress is slower, but at least its steady.

I've had a fair bit of work to do in the last couple of weeks on Alta, mostly around the RenderManager2D class. Its essentially a scene manager that keeps track of all of the sprites to be drawn, each of which is assigned to a 'layer' to make depth sorting easier.

The interface for the RenderManager2D is based around a heavily overloaded function called AddToScene(), which is fairly flexible about what parameters it can take. I've also tried to integrate the layering system into the gameState system, by creating

int backgroundLayer, mainLayer, foregroundLayer, textLayer;

in AEGameState (base class for all game states).

I then altered the game state manager to change the value of these variables based on where the state is in the gameState stack. This has made it easier to know what layer to add sprites to, but its not particularly flexible, and will probably end up being cumbersome in the long term.

I've also set up a SVN repository on Assembla for Alta. The reason being I'm considering branching the engine at some point in the near future so that I can rewrite a lot of the base gameState management code.

I'm considering a new hierarchy along these lines:

Scene: equivalent to my gameState, essentially a discrete section of the game, e.g. a menu screen, titlescreen, level of the game etc. The management of the scene will essentially be the same as the current management of game states, with some tweaking to make it a bit less clunky.

GameObject: This will represent an element of the scene, and will be arranged into a tree structure, so that GameObjects can own other game objects, e.g. a menu might own a submenu, or a player object might own a weapon object. Changes to the parent object will filter down to the child objects, so if the player is destroyed in an explosion and removed from the scene, the players weapon will also be removed from the scene, for example.

Components: Each game object will be able to have a collection of components. These will be the bits of the object that actually change its state and react to stimuli. For example, a gameObject could have a physicsBody component which would allow the gameObject to be manipulated by the physics simulation. It could also have a mover component which checks the game's InputManager to see if a button has been pressed, and responds by moving the object in a certain way.

The idea of all of this is to allow as much flexibility for the developer as possible, whilst enforcing a strict OO design to the game. However, I would need to create some sort of prefab or archetype, which would allow the designer to create multiple instances of the same object with tweaked properties, or else it could be very tiresome creating every tree and bush on a piece of terrain!

I also picked up a cheap copy of Game Coding Complete this week.

Whilst its a C++ book it deals a lot with engine structure. The author advocates a model which separates out the Game logic (essentially the simulation of the game world, a lot of which would be game specific), from the 'Game view' i.e. the inputs and outputs of the game logic, so user input, graphics, audio, network code, AI (I'll get onto this in a second) etc. and then has two communicate via 'commands' with 'listeners' that then act on those commands.

The point behind this is to create a clear dividing line between the game logic and the rest of the engine, rather than make direct API calls. However, it sounds awfully like events and delegates to me, which can seriously cripple the xbox 360 when using C#. I'll have to look further into how the authors suggests implementing this structure, but I'm not sure its one I'll be able to adopt with Alta.

Right that's enough for now.

Hopefully next weekend I'll be able to upload some footage of PacMan running, along with the game from James Silva's book.