AI structure and finite state machines

I've been working on the structure for Alta's AI system in the last few days. I recently read a blog post by a fellow Xna dev on his issues with structuring AI code (link to follow), and I thought I'd share my approach.

I've created 3 main engine classes to manage AI, 2 of which are base classes designed to be extended in game code.

The two base classes are the AEAIState class and the AEAIBehaviour class. The AEAIState class represents the finite states that a AI can be in, and it has responsibilty for determining whether an AI should change state or not based on the information available to it (flags and variables in the AECharacter class it is owned by).

The AEAIBehaviour class represents a set of responses or actions, to be associated with one or more AEAIStates.

Each of these classes need to be extended by game code to add the logic for changing state (in AEAIState's think() method) and to specify actions (in AEAIBehaviour's act() method).

The third of these classes is the AEIntelligence class. Each AECharacter can have at most one AEIntelligence class associated with it. Each instance of this class holds a list of available states for this AI and a dictionary that associates a behaviour with each state.

The instance also keeps track of the currentState and associated behaviour. Each frame the AECharacter class calls the current syate's think() method to see if the state should change, and then the act() method on the behaviour associated with the current state.

For code organisation, I keep all states associated with a given AI in a single code file, and similarly with behaviours.

This structure should provide a good alternative for the usual massive switch statement without spreading out AI code into hundreds of files. It should also allow for plenty of code reuse, as parent AI states and behaviours with common code could be created in game code, with more specific versions inheriting from then.

I'll be sure to make a note of how this approach works out for me, but thought I'd share it in case it gave anyone else any good ideas

December Progress

I've been quiet on the blog for the last month, but I've been making steady progress. I've gotten to the stage with Mario where he is running around the level, the level scrolls in the usual Mario way, with him unable to go backwards, only forwards. He dies when he falls out of the world and respawns at the last respawn point he passed, and he has lives.

Next up, enemies (who are almost completely animated already), getting them into the level, letting them kill Mario and letting Mario kill them. After that its rewards, points, coins and powerups. That includes headbutting '?' blocks to get coins & powerups (not sure on the implementation details of that yet).

Finally it will be polishing up the whole level, tweaking the movement dynamics (which still aren't right) and adding in Title Screens, Menus etc.

A december finish for Mario is still on the cards, which would give me a full 2 months to work on a DBP entry before the details of the competition are even announced, and hopefully a further 2-3 months after that until the deadline. However, I'll need to spend some of that time upgrading Alta to XNA 4.0, and testing its performance on the Xbox (its completely unoptimised at the moment).

Assuming that takes up my time during January, I'll have 3-4 months in total to complete my DBP entry. I just hope it'll be enough!

Before I go, a note on Farseer Physics. I've been having trouble with Farseer and Mario. The biggest problem is the fact that I'm NOT trying for real world physics. In fact, I'm trying for very artificial physics. This simply isn't what Farseer was designed to do. My DBP entry is also not realistic in its physics. It remains to be seen whether I decide to keep Farseer for my DBP entry or try to write the physics that I need myself.

Until next time...

Content creation

Just a quick update. I've been working hard on content creation for the last week or so, drawing the parts for Mario, and creating animations with them. They're doing pretty well at the moment. Hopefully I'll have some full animations up and running for a video upload this weekend.

I've also finally updated my ToDo list. For the last few months I've been working on things as I come to them, with no real plan. I've now gone through and listed all the things that I need to do to finish Mario. There are A LOT more of them then I thought! Most should be quick, but it all adds up. Still, I need a plan and I need to stick to it, because....

Dream Build Play 2011 has been announced! Registration opens in February, and there'll probably be 2-3 months of the competition, so hopefully I'll have until May - June time to get an entry together.

So the new timeline (seems a long time since I posted the last one!):

Mario - finished by end of the year(!)
Alta Engine fully updated to 4.0 and editors integrated into the engine by end of January.
DBP idea chosen and design document/ concept art completed by end of January.
Playable demo level of game w/ place holder art by end of February.
Full artwork for game completed by end of March.
All levels designed and built by end of April.
Testing - until DBP deadline!!!

Its a very tight schedule, and whatever I create will need to have a very narrow focus to achieve it on time.

I'm a bit disappointed that the competition isn't for WP7, I have an idea that would be perfect, but as it is, I'm considering moving that idea to xbox for DBP. I'll let you know when I've decided!

That's all for now. Onwards!

Content Pipeline extensions

Well I've had some fun so far today. I finally got tired of my firewall sandboxing my application every time I needed to use XmlSerializer to load a map file, meaning that I needed to recompile twice everytime I made a change to the source code.

So I decided to try and use the Content pipeline to load my maps. This would also have the advantage of compiling my maps to the binary xnb format, taking advantage of the format's compression.

It took me a while to get my head around it, but eventually I came up with the following importer:

[ContentImporter(".mm", DefaultProcessor = "", DisplayName = "AETileMapImporter")]
public class AETileMapImporter : XmlImporter
{
      public AETileMapImporter()
           : base()
       {
       }

       public override object Import(string filename, ContentImporterContext context)
       {

           SaveMapStruct retMapStruct = new SaveMapStruct();

           FileStream stream = File.Open(filename, FileMode.Open, FileAccess.Read);
           try
           {
               XmlSerializer serializer = new XmlSerializer(typeof(SaveMapStruct));
               retMapStruct = (SaveMapStruct)serializer.Deserialize(stream);

           }
           finally
           {
               stream.Close();
           }

           XmlWriterSettings settings = new XmlWriterSettings();
           settings.Indent = true;
           filename += "X";
           using (XmlWriter writer = XmlWriter.Create(filename, settings))
           {
               IntermediateSerializer.Serialize(writer, retMapStruct, null);
           }

           return base.Import(filename, context);
       }

}

This code could easily be tweaked by others to use for their own custom importer, allowing them to import xml files serialized with XmlSerializer.

Hope someone finds it useful!

Character physics integrated!

Just a quick progress report. I've adapted the Farseer 3.0 platformer tutorial for Alta, and I've added a AEPhysicsCharacter class, which I've integrated into the AECharacter class alongside AEAvatar. It will now play animations at the same time as moving the character around.

Next up, implementing physics tags to the AETileEngine, automatically creating static physics blocks where indicated.

Sounds like a fun project for this weekend!

Farseer 3.0

Well, progress this weekend was hampered somewhat due to the fact that it took me a lot longer than I thought to get an understanding of how Farseer works. There is a very good tutorial on getting started with Farseer on Sgt. Conker, but unfortunately it was made for Farseer 2.1.3, and the latest version is 3.1.

On the face of it that shouldn't be a challenge, but alas, I'm finding more and more often in the world of game development that things are rarely as simple as they seem.

The biggest issue with applying the 2.1.3 tutorial to 3.0 is the units system. 2.1.3 uses screenspace pixel units, whereas 3.0 (based on Box2D) uses what it calls 'MKS' or meters, kilograms, seconds. This has the unfortunate side effect that a falling block of 50x50 pixels has the physics of a falling building if you just plug the pixel dimensions into the physics engine.

At first, after trying to convert the units manually, I thought this was a deal breaker, and decided to use 2.1.3 instead (when I discovered that it compiles directly under xna 4.0, but that's another story). However I was persuaded by Farseer's creator that 3.0 offered a number of benefits over 2.1.3, I decided to give it another try.

Then I came across the ConvertUnits helper class in one of the samples that ships with Farseer 3.0. This largely solved my unit problems, although I still had some issues with things like magnitudes of forces ir impulses.

So after a couple of hours of playing with the tutorial, including faking a anglular spring (which isn't included in 3.0) with a anglejoint, I finally got the tutorial working. Being the good community member that I am, I will be writing up my adventure later in the week and sending it off to Sgt. Conker as an update to the current tutorial.

Watch this space for a link! Then it'll be back to Alta for an abstraction layer around Farseer 3.0, which among other things, will attempt to convince the developer that they are working in pixel units!

Progress report

Things are picking up now at last. The AEAvatar class is tested and working, I've written a skeleton of the AECharacter class which will fill out as I write the physics and AI engines.

Next up is Farseer integration which means adding a nice wrapper over its API, and integrating its setup code into AEGame.

More soon I hope!

Avatar!

Nope, not blue aliens with plaits that let them talk to alien animals. Nope, not the cutsy Xbox version of Nintendo's Mii's.

I'm talking about the actual meaning of the word, a proxy visual token to represent another object or person in the virtual world.

This weekend I've been working on my animation engine for Alta. As well as various structs and helper classes, I wrote a class called AEAvatar. This is to be a class which will be a component of the upcoming AECharacter class, and manages the visual representations of characters, including playing and queuing animations.

It's finished but untested as yet. I'll be writing the wider character class this week, and putting together a quick sample that plays animations loaded from the editor.

Next up, physics (which will be a wrapper on Farseer), character art and putting animations to use, some tweaking of various systems,  and then finally gameplay.

I'm a long way behind schedule and Mario is taking longer then I'd hoped, but the engine is still progressing.

Once Mario is done I'll be migrating Alta to xna 4.0, and potting Mario to windows phone 7 to test the engine's performance on the phone. Then on to my first commercial game.

I *will* have my first game out by March. Maybe...

PS my wp7 device arrives today. Going to be awesome, can't wait! :)

Animation Editor - finished! (except for bugs...)

So I finally finished the animation editor. There's a few bugs to work out, but above is a quick video of it in action, loading a saved animation, and playing it back in the editor. Now on the animation component for Alta to be able to use them in game!

Something's coming....

Spring/Summer 2011...

Feature creep

Life has got in the way again, and slowed me down, but I'm still plugging away with this animation editor. I would like to find a way to seperate it out from the rest of Alta, so I can share it with the community, but haven't figured out how yet.

The title refers of this post refers to the extra bits I've added to the animation editor and the extra bits I'm planning to add.

I've already added an option to flip parts horizontally when creating frames, and a playback feature in the editor, and I'm planning on including an 'onion skin' effect to overlay frames on each other, and a feature which creates sprite sheets from the frames.

So I'm still hard at work, but it may be another week before I'm finished, we'll see.

Ooops!

Well, best laid plans and all that. Life has once again got in the way the past month or so, but I'm still making progress on Mario, or more precisely, the animation editor for Mario. I've almost finished it, and will stick up some screen shots in the next couple of days, plus maybe a video of the animation preview feature in action.

I've also grabbed the domain name http://www.rabidlion.com/, which now points to this blog. Soon I'll be putting together a propper website for Rabid Lion Games, and then I'll link this blog in from there.

I've realised in the course of making the various tools for Mario, that none of them are actually specific to Mario itself, or even to platformers. As such, once I've completed Mario, I will be integrating the Map and Animation editors into Alta. Mario will also involve me writing in an Animation engine to read the character files created by my animation editor, and a physics engine (which will most likely be a wrapper around Farseer).

So Alta is still growing, and I'm still hopeful that by Xmas I'll have made the first commercial game with Alta. However, it's looking more and more like that will be a Windows Phone 7 game rather than Xbox 360. The more I look at it, the more I believe Windows Phone 7 will take off in a big way, and getting in early on the platform could yield some serious rewards.

Arcade Mayhem (working title), my first xbox game has been shelved for the minute, and a new game (codenamed project Circlevania) is my target. However the temptation to 'cash-in' on a simpler, less imaginative game is very strong.

Anyway, that's it for now, been a bit of a ramble. Hopefully the next update will be more coherent!

And hopefully it will be significantly less than 6 weeks before I post here again!

Long time no post...

Well the inevitable has happened, I've neglected my blog.

A couple of reasons, life has been very hectic recently, so I've had little spare time for blogging, and also progress has been slower on Mario than I'd have liked, so there's been little to show off on here.

That's not to say that nothing has happened though. I've fully adapted my map editor from pacman for Mario, including adding support for a background, allowing the user to add metadata and textures to multiple tiles at once, and even to stretch textures across multiple tiles if they form a rectangle, making it very flexible.

I've also designed a animation system that will allow the user to mix skeletal and traditional animations in the game easily, and an editor which takes in any textures for use in creating a animation frame, and outputs a sprite sheet alongside the character file to minimize texture swapping in game at run time.

Implementing the animation editor is well under way but I don't have any screen shots at the moment, hopefully I will by the weekend.

I have plenty of tips and pitfalls that I want to share that I've come across in the last month, but I'll hold off for now as I could write a blog post on each. (Note to self, write a post soon on tools programming in general!).

Anyway, this has just been to keep this blog alive, because I know if I don't post regularly it'll fall by the wayside, and that'd be a shame, because I hope one day someone out there might be interested in how I started out (even if no one reads thus right now!)

Til next time!

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...

Tile map editor, and James Silva's book

Well, a lot has happened in the week or so since I last posted.

I now have a fully functional Tile editor based on Winforms. I was concerned after learning a bit more about the integration between XNA and Winforms that it wasn't going to be possible to create a comprehensive Editor for Alta using Winforms, as the only method I could see for running the game in the Editor was to hook an update method into the Application.Idle process, which seemed a bit of a hack to me.

A quick query on the XNA forums seemed to suggest that this was fine though, so I'm going to carry on heading in that direction.

James Silva's book (http://www.amazon.co.uk/Building-XNA-2-0-Games-Professionals/dp/1430209798/ref=sr_1_2?ie=UTF8&s=books&qid=1279808646&sr=8-2) arrived late last week, and I've been blasting through it ever since. I'm both impressed and dissappointed by this book.

On the one hand, the content covered include things that you just can't find anywhere else, like a strategy for level editing, basic 2D terrain-type collision detection, a character/ animation editor, and (the most impressive in my opinion) scripting. Also the game created looks the part, and unlike any other game that I've created by following a book, I would actually be proud to sell it (had I come up with it myself obviously!).

So why am I disappointed? Two reasons. First, simply put, the editing is attrocious. Whilst the source code that you can download from the book's website is all correct, the code in the book seems to be a hodge-podge of various itterations, with variable names changing within the same function, and a constant switching between C# properties and manual GetYourVariable and SetYourVariable methods. Its fairly clear that someone has started rewriting the code for the book (to make it more readable perhaps? see below) but hasn't finished the job. This makes it very difficult to follow, and I was constantly flicking between the book and the online source code to see if I could tell what a function was supposed to do, and then make sure that it did it.

Which brings me to my other disappointment with the book: the code itself. Now I'm not the sort of programmer who lifts code wholesale from books/ tutorials and sticks it in my own projects without understanding what it does, but I do like to be able to look at the code I'm working with, and see what each part of it does, so that I can refer back to it if I ever need to do anything similar. With the code in this book, that simply isn't possible. James admits himself that there are a lot of hacks in the code to get something working quickly, and that its not as neat as you would normally like. Unfortunatley this is a contender for the understatement of the year.

Because James uses spritesheets, his code is full of crazy little bits of code to determine the correct source rectangle to use for textures, which I can live with, if they're a little annoying, but the placement of everything in the tools is hard coded (presumably figured out by a lot of trial and error on Jame's part, and fairly complex functions are just copied in, with a single line in the text to explain what purpose they perform. I'm not looking for a line by line explanation, but if you are creating a (fairly good looking) full screen effect, I'd like to know exactly how it achieves it!

/rant

That's probably an unfair assessment of Jame's book, given that I've taken away a LOT of useful tips, tricks, and techniques from it. But that's what I was looking for from the book. If anyone was looking at it with only a limited understanding of XNA then it would only serve to confuse them.

It probably should have a place in the learning path of a budding XNA developer, but I would put it after having cloned a few classic games in full to learn the ins and outs of XNA. Just my 2p...

Anywy, next up for me is creating the Tile map for PacMan, and then trying out some rapid development of the gameplay. The trickiest bit will be the AI, which I've never really had to deal with previously (the AI in pong left much to be desired!).

Until next time...

Graphics!!!

Well, the book I ordered still hasn't arrived. I spoke to the ebay seller last week who said that it had been sent 2nd class, but it still should have arrived by now. Its disappointing as I'm approaching the half-way point in my time off and I really wanted to be ploughing through that book by now.

Still, I've kept going in my XNA endevours. Tetris is now complete, with working high scores, music, and game modes.

I'm starting on PacMan, and I've already abstracted out a simple tile engine from the tile manager code I created for Tetris. I'm now working on creating a basis for my 2D rendering engine.

There is however some other news. Over the weekend I received an email from the Sunburn people offering me a promotional price on the community license for the Sunburn rendering engine for only $150 dollars. For non-creators club members (like me) that license would normally cost a massive $399!

It was too good an opportunity to miss, and so I now own a copy of Sunburn:) I'm still intending on abstracting out my own custom renderer using the Sunburn engine behind the scenes, so that in the future I can write my own rendering engine if I so choose without breaking any of the games that have already been built with Alta.

Sunburn will greatly speed up the process of getting the engine into a finished product. Once that happens I'll be free to tinker with sections of the engine behind the scenes without changing any gameplay code.

As I've said before, ultimately I'd like to be able to replace the XNA underpinnings with C++ and directX, and possibly OpenGL, but that is a number of years in the future at this point. In the meantime, I'm hoping to be able to update you on PacMan later this week.

In what I hope isn't the beginning of feature creep, I've decided to create a level editor with PacMan to alter the 'Maze' that the game is played in. Whereas I made a basic level editor with breakout, I'm planning on creating this editor as a stand alone winforms project, which I'll then build on when it comes to Mario.

I'm really hoping at this point I'll be able to get started on an original game before the end of my holiday, as that should give me the momentum to keep going once I'm back at work...

Finishing touches

I've come to the point in Tetris where I normally move on to the next project: the finishing touches.

I've got the gameplay mechanics sorted, the visuals look passable (I'm not really putting much effort into visuals at the moment as these are just learning games, but I've tried to make sure they don't look too amateur). What's missing are little things like a high scores page, a different game mode that lets you see how many points you can score in a given time period, things like that.

I'm not the kind of person who is driven by finishing every minute detail. Its one of the reasons my code is never very good as far as error handling is concerned. But if I ever want a comercially released game I'm going to have to get better at it, and so I'm persevering with Tetris. By the end of the day I'll have a High scores table, a couple of game modes, and decent 'you won'/ 'you lost' screens.

And then I'll call it a day and move on to the next learning game: PacMan! I'm going to spend some time abstracting out the reusable code from the Tetris tile engine, as both PacMan, and the next game, a Mario clone, will use it in one form or another.

I'm still waiting for James Silva's book to arrive, but when it does I'll be working through that as well, and probably refactoring some of my engine code as a result. I also want to get started on my 2D rendering engine. At the moment all of my different game components use a seperate SpriteBatch to draw to the screen. Its not a big deal now, but if I start having a lot of sprites on the screen (including say some particle effects) the draw calls might start hurting performance.

Anyway, that's it for this update, more soon I hope.

A new (old) book

Two entries in one day, whoa! :-)

Over lunch at work I spotted a book on ebay that I've been meaning to buy for a while and at less than £4.50 with free postage it was a steal. The book is 'Building Xna 2.0 games' by James Silva. I've heard great things about this book, and I'm looking forwards to working through it.

I have a lot of XNA books, some of which are good, some of which are terrible, but mostly what I need to learn isn't how to use Xna, its how to structure and build good games.

James has built some v. successful games so an insight into his way of working should be invaluable.

I also heard about a new iphone games book, which got me itching for the 'buy' button on Amazon but I held off for now. With Xna, UDK, and Unity on the go, starting an MSc in computer science in October and a full time job, iphone games may have to hold on for now.

(Incidentally at some point I'll be starting blogs on UDK and Unity so as to not clutter this one with thoughts not related to the Alta engine. I'll link to them when I get them going).

Code, delete, re-code

One issue with the idea of game driven development is the fact that I find myself spending hours over an issue that has a quick fix FOR THIS GAME but not for other games, and hence is useless for the engine.

I came across an example last night whilst debugging my latest build of Tetris. At the core of my engine is a game state manager. This works by having a stack of 'in use' states, and controlling whether or not those states in use are visible and enabled.

Those states that aren't on the stack are removed from the game's component list and are added to it when they join the stack.

This all worked fine until I created game components that were owned by my game states. If the owner state was removed from the stack, the owned components remained active. Problem.

Now, its a simple enough matter to fix. I don't really need all the objects that are currently 'owned' game components to actually inherit from the GameComponent class, I can just call their update and draw methods from within the owner's update and draw methods.

However that's not a very satisfactory solution, especially in a more complex game where the playing state might have many sub-components.

I have two options that I can see. The first is to add a components list to the base game state and add the components to that, which then adds them to the Game class's component list when the owner state is pushed onto the stack, and removes them again when they're popped or removed from the stack.

The other is to re-evaluate my whole approach to game management, as the game state system isn't as flexible as others I've seen, such as unity's Scene - game object - component hierarchy, or UDK's system where everything is a 'level'.

The second would be more work to implement but might save me from complex work arounds in the future, but the first is simpler to implement now and may turn out just fine...

A note on organisation

Just wanted to mention something I came across last night. I originally had my Utility functions inside a class called AEUtilty.

All of the functions (random number generators etc) were static functions so that I didn't have to have an instance of AEUtility.

Then I came onto creating some simple Timers, which are a class, and I hit a problem. I wanted to group utility functionality together, but obviously nesting the class within the AEUtility class wouldn't be much use.

So I decided to change AEUtility to a namespace, and add a class of AEUtilFunctions to hold the static functions. However intellisense went bonkers, insisting that AEUtility was still a type. So I had to ignore the intellisense and rebuild the library anyway to convince it to behave.

As I'll no doubt be doing plenty of refactoring into namespaces as I go along, I'll have to keep an eye out for this one in the future, as it cost me a good half hour of trying to figure out the problem.

Lesson learnt: just because intellisense says there's an error, doesn't mean the compiler will agree!

Introducing the Alta Engine!

Welcome to my development blog for the Alta Engine.

I'm going to quickly go over what the Alta Engine is (or rather will be), the reasons for it's creation, and a quick outline of it's features.

I'm aiming to update this blog fortnightly, but that will vary depending on how much time I get to spend on this project vs my other gaming projects.

So let's begin.

The Alta Engine is to be a fully featured game engine based on the XNA framework. It will run on both the PC and the Xbox 360 (via XBLIG) and will handle both 2D and 3D games.  I'll talk more about the proposed features later.

Why am I building a game engine? Well the obvious answer is that I want to! But its more than that. Together with a friend of mine (who is very into game design) I am part of a new start up Indie games studio. As we haven't officially launched the studio I won't give any more details here just yet.

Anyway, we were looking around at the game engines available at the moment, and focus fell on Unity and UDK.

Now, we fell over ourselves in amazement at UDK, with how easy it was to use and how incredibly beautiful the results were. We pretty much decided that it was for us and were ready to commit to it. Then I started looking at UnrealScript.

Perhaps I've lead a sheltered coding life, but I've never come across a language/ api with a steeper learning curve than UScript. I will be persevering with it, but it's thrown a real spanner in the works, and there is a risk that it will undo a lot of the dev time savings from using UDK in the first place.

Then we found Unity. Now Unity is an unusual beast. On the one hand its criss platform, very well supported, established, and has a lot of good features. On the other, it has upfront costs associated with it ($1200), the graphics aren't amazing, and its missing some very important features like occulsion culling. Now a lot of this is being addressed in the next update, but there is still the price tag to consider, and the lack of Xbox support (its a damn big market to ignore).

However there is a free version of Unity and its still pretty good if graphically hobbled. In fact we've come to the conclusion that it'll probably be our prototyping engine, and we may make some simple web games using it.

So we were left with no ideal solution, and so I proposed writing an engine based on XNA. Having used XNA before I know that it strikes a good balance between the low level control of directx and the accessibility of something like Unity. My CSharp is pretty good, and I've always been interested in game engine programming.

And so I've embarked on developing the Alta Engine.

And now for its proposed features.

As I said, the Engine will support both 2d and 3d games. For 2d it will feature the usual set of blending and shading techniques e.g. additive blending, parallax scrolling, a tile engine, 2d editor. The 3d features will include options of either forward or deferred rendering, built in occlusion culling, dynamic light and shadows, a full 3d editor, middleware physics, animation support, and many more. Other items on my list of features I want to implement are a 'scene animation' editor like unreal matinee and a visual scripting system like unreal kismet, but in the shorter terms I'll be including the facility for csharp scripting.

Now before anyone goes 'woah, you'll never do all of that' you may be right, but this isn't a short term project.

Ultimately the Alta Engine will be the core of our game studio. My intention is that everything will be abstracted from the xna framework, so that eventually I can port the engine to c++ and both directx and opengl.  The ultimate vision is for almost any game to be created without writing a single line of code. Ambitious, me, never! Deluded perhaps...

I will be developing the engine using 'game driven development' i.e.  I will make a series of games, and each one will develop the engine in some way.

To get me started I have a list of classic games to clone, so that I can start using the core engine in other games. I've already created classics such as pong and Breakout which have given me the core game state machine, and I'm currently cloneing Tetris which will give me the beginnings of the tile engine. I'm also starting work on the input library, which will abstract out input to a map created by the game, allowing the gameplay programmer to just check is the player has pressed 'jump' for example, rather than checking space bar, A key on gamepad etc. It will also allow easy user customised controls.

Okay, that's a massive entry to start, I promise future posts will be shorter.