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! :)

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.

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

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.