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!