One of the most important milestones in a game's development is called First Playable. First Playable means proof of concept - The technology works, the game design is coherent and a realistic release date is within sight. The Publisher's Marketing teams draw up plans based on the assumption that the game will be released X months from First Playable.

Eidos held an internal marketing day to present their forthcoming games to sales and marketing teams from around the world. This allows them to plan their Marketing strategy for all forthcoming games. It also allows the developer to schedule in essential marketing materials like demos, screenshots and AVIs. This is particularly important for the US where lead times on magazines are three months or longer. Ideally you want synchronised marketing and development schedules to avoid running adverts before the game is complete. This happens a lot - The game finally comes out and no-one knows it's out because you've blown your marketing budget six months before release.

Many developers aren't interested in this sort of thing but we bend over backwards to help as these are the people who will sell your game. If they don't understand it or have little enthusiasm for it, you can't expect them to do a good job. We do everything in our power to help them as our attitude is that our job isn't done until someone's walked out of the shop with our game.

As ever, Eidos was full of amazingly good looking women but as I spend most days surrounded by hairy-arsed developers, these days I find myself dazzled by anyone who isn't wearing scruffy jeans and three days worth of bumfluff. We presented the game throughout the day and people seemed pleased with what they saw.

We went down to Eidos a couple of days later for the Milestone meeting and it went very well for us. The experimental stuff, particularly the engine and the AI, the stuff people said we couldn't do, we've now done. Ian Livingstone, Eidos's Chairman wrote about the demo on his newly launched website: "This week I saw the first playable version of Republic and I was amazed by Elixir's achievement thus far. I sent my character to the town square to listen to an opposing faction's supporter giving his all on a soap box. His audience was enthusiastic. Action was necessary. After setting up a time to meet this supporter, I had to decide how to get him to change his allegiance. Argue with him, bribe him or give him a right good hiding? Now what would best suit my personality?"

Whilst it's been our graphics engine that has attracted most attention to Republic: The Revolution, what we're trying to do with the artificial intelligence, in creating an entire country, is every bit as impressive as the engine. Over the last few months we've made excellent progress in this area. Alex Whitaker recently joined us from Psygnosis as a Senior AI Programmer. Here he discusses some of the challenges of designing the simulation for the game:

"For its first thirty years the pursuit of artificial intelligence promised much and offered little, but then exactly ten years ago with a paper entitled Intelligence without Reason, Rodney Brooks offered a different view of what it takes to make an artefact intelligent. Through Brooks' tenure at MIT he has built and refined an increasingly intelligent dynasty of robots using behavioural rather than deliberative architectures.

Behavioural AI systems work from the bottom up - the agent perceives certain features of its environment and responds directly to them, with careful design an intelligent behaviour emerges. Deliberative systems allow the agent to build an internal model of its environment, and use rules to extend that model and make assumptions based upon it. The big problem is that, in general, for deliberative systems computing power requirements are exponential, whereas for behavioural systems they are linear.

Needless to say, for driving many thousands of agents exponential computing requirements are not attractive. One of a number of technologies we use to drive agent behaviour in Republic: The Revolution relies on the same augmented transition networks (ATN) on which Brooks bases his subsumption architecture. The ATN system that we use extends the simpler finite state architectures characterised by computer games such as Half-Life and is far more concise.

The agent behaviour is held in a database that describes the relationships between what the agent sees (its percepts) and what it does (its effects). We have created an editor that allows a designer to manipulate that database, now the task of creating all of the behaviours begins. This starts with networks describing the simplest level of behaviour - for example, how the agent will enter or leave a vehicle. We then build these into ever more complex networks - drive to location, go to work etc. Finally we create the highest-level networks describing the complex actions that drive gameplay such as bribe official or call general strike.

This family of algorithms have been shown to have very low processor overhead but allow the description of very complex behaviours. Because the code driving the networks is isolated from the data describing the behaviour, the designers are able to realise their vision without constantly referring to the programmers, and the programmers are able to refine the engine without being constantly disturbed by the designers.

Given the ever-increasing expectations of Joe Public, the ability to design convincing and realistic behaviour skills are going to become essential and I have no doubt that Behavioural Designer is going to be appearing on the games CVs of the future."