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.

A quick screen shot

Just wanted to post a quick screen shot of my tile editor in action, with the grid for PacMan. Hopefully I'll have some video and screen shots of the game that I've made by following James Silva's book later on.

2010 Roadmap

Ok, so I've decided that if I'm going to make some serious progress with this engine then I need some sort of roadmap with milestones to try and hit, otherwise it'll never happen.

I've decided to focus on the 2D aspects of the engine initially and then build up into 3d from there.

As I mentioned in the beginning, the development of the engine is going to be game driven. I'm working on the basic framework of the 2d rendering engine, which will basically be an abstraction of the layering, batching and culling of the various sprites that make up a scene. I also need to work out the interaction with shader based effects.

So, the roadmap. I'll start short term. This week I'm still on holiday, so I should be able to get the whole of PacMan completed this week. This will include a first draft of the 2d rendered, and possibly a base Ai class as part of the engine.

After that I'll be back at work, but I'll be able to move onto my last clone, Mario. That will involve an expansion of the Tile editor that I've made for PacMan to include parallax backgrounds/ foregrounds, and collision surfaces (ledges) to allow for more complex levels. I also want to refactor the editor into the engine code, and work on a way of allowing the designer to 'plug in' gameplay code and then run the game within the editor, to allow for quick testing of levels.

I'm currently envisaging Mario (and the supporting work on the editor) taking up the whole of August.

In the longer term, I want to have my team's first original game ready for playtest by Christmas.

We have 3 different concepts that we're toying with. I don't want to talk about them too much at the moment, but we have one arcade type game, one room based platformer/ puzzler, and one 2d scroller/ platformer shooter. The first requires basically zero graphics assets, but seems to be the least likely be successful, the middle concept requires the most in the way of artwork, and may be out of our reach at the moment, but equally is the most refined of the concepts. The third will probably have the broadest appeal, will need some, but not too much in the way of artwork, but is the least well fleshed out of the three.

I might say more once we've decided on which to go with, and once development is in process.

Anyway, that's a bit of a rough, rambling roadmap for the remainder of 2010. Hopefully by the end of the year the Alta engine will be in a state where it can comfortably provide the functionality for most 2D games we want to develop...