To best understand the AI of v1.1 one must first understand the nature of threads.

In a normal game, the players all function in a single thread. There is a while loop in which various components of the game are given the opportunity to to do their part – draw something to the screen, look for player input, update the game state and of course, move the computer AI.

In most games, including v1.0, the AI does all their work at the end of a turn.  This is why in most games you hit the turn and there is a delay, the AI is having to think about and plan what they do.

The challenge, of course, is making sure players aren’t waiting too long between turns, especially if the game locks them out of the UI (which is the norm).

But there is another way: Threads.  Threads allow you to have different things computing concurrently. Even on a single-core machine, threads can make a huge difference. Threads are the reason why Stardock games have historically had such a strong reputation for good AI.  The AI can be calculating strategies while the player moves. There can even be background threads that do nothing but look at the game state and set various flags for the AI to act on when the time is right.

Threads are the reason why Galactic Civilizations II was able to have some of its most infamous diplomatic moments such as “So, I see you’re building up quite a fleet there, so let me guess, you’re going to mass up for an attack, take my planet and then sue for peace? Well, sorry but in the meantime, I’ve been putting ships around your ships..”

In the OS/2 version of GalCiv (back in the 90s) that had cloaked ships, players were greeted with the horrific realization that the AI had surrounded them with cloaked ships and preemptively wiped out their massed fleet.  And this was back when the game was made with 486’s in mind.

Threads rule.

So why not threads?

Why do games (including Elemental v1.0 and other major strategy games of 2010) not use multithreaded AI? Debugging. If multiple things are touching bits of memory, modifying variables, creating or deleting objects it can be a real pain to coordinate.  The bigger the team, ironically, the harder it is to do. 

Plus, truth be told, most people just aren’t that comfortable juggling many threads. It requires a different way of solving a problem. It’s a bit like recursion, they can be hard to envision if you’re not used to it. 

On Elemental, I didn’t have the opportunity to go into that.  On our other games, the only coding part I was responsible for was the AI (except our earliest games).  On Elemental, things went somewhat..differently. By the end of the project I had added lead developer, producer, and design implementer to my hats so the AI had to be done in the more traditional way.

Now that we have Kael to take charge of production, Toby as design implementer and CariElf back as lead developer, I can do for Elemental what I do best: Multithreaded AI development.

Threads: Breaking a problem up into components

When you play a game, what are the things you do? What are the mistakes typical in computerized opponents?

The most obvious is that you’re looking and thinking about your strategy all the time.  So let’s look at the threads we should have in Elemental:

1. Global Strategic AI thread. This is little more than one big while loop that sits in a thread. It’s very low priority and all it does is look at the map and see what sorts of pre-designed situations have been triggered.  Think of it as pattern recognition. If it recognizes a pattern, it sets a flag and the AI in question then begins to deal with it.  This is where players can have the most impact by telling me what sorts of cheese they do to thwart the AI.

If I were writing the Starcraft AI, for instance, this thread would be the one seeing if I’m about to get baneling rushed or if photon canon rushed and deal with it. 

It also sets flags on known items as to whether they should be targeted for control, imbued, recruited, killed, etc.

This is NOT like an expert system or a neural net because the AI is not learning. It is adapting to player strategies but its choice of adaptations is limited to what we (the Elemental community and I) come up with.  Eventually I hope to export this as a C++ DLL for others to play with or better yet make it available in Python but that’s aways off.

2. Player Strategic AI thread. This is the thread that handles deciding what should be built, what strategies it should employ, where it should send its soldiers, what spells it should cast, what type of unit it should design, what technology it should research, what city improvement should be built.

3. Tactical Strategic AI.  The tactical battles are the one part of the game I’m not involved in yet. We have two capable developers handling that.  I won’t be taking that over until the expansion pack.  But that will become another AI thread down the line as a background thread looks at every army group and sets what types of strategies they should employ generally as well as potentially against any enemies that are near by.

Testing the AI

This is my AI map for v1.1 Beta 1. The goal with this map is to teach the AI how to play the game effectively using the v1.1 game mechanics. 

This battle will be the subject of my  next journal entry.