We’ve been through the game design process three times now, and something that has come up each time is the real time vs turn based paradigm. I’m writing this post to articulate some of our reasoning for our competitors and for future AI game designers.
Why real time? True real time strategy games are more fun to watch. They reward faster / better performing players – with human players, we may not necessarily want to reward the fastest player; but with an AI, we want to encourage the development of efficient AI. Real time games map into our brains easily because we live in a real time world – we don’t determine how far we can move in a turn, then determine how many actions we can perform during a turn, etc. We think of things in terms of rates. I can move 2 meters/second, I can type 60 words / minute.
Unfortunately, creating a real time game API for an AI is hard. It’s not just technically hard – it’s also conceptually hard to introduce to someone and expect them to make something cool with it within 24 hours. We considered a few ways of providing an API for a real time game: setting up Qt-like signals or giving each unit its own thread were a couple. Unfortunately, giving each unit a thread doesn’t scale well (and it forces all of the concurrency issues upon the API user). The signal method sounds nice, but we haven’t investigated it yet.
The downside of a turn based game is that it’s harder to reward faster and more efficient AI’s. Since the other AI doesn’t get to move while your AI is thinking, you can take all the time you want. There is no reward for thinking and acting quickly, so as game designers we have to come up with a penalty for underperforming AIs. What this usually means is that if your AI is taking 5 minutes to complete a turn, you forfeit. When we finish the implementation of the current Zombie Survival game, we’ll probably spend some more time on this problem and see if we can find a way to fairly reward faster AI.
In a turn based game, we can convert the rates of a real time game so they all use a common time unit – in one hour I can type 3600 words or I can move 7200 meters. The problem is that in the games we have created, we let all actions draw from an action pool – each turn, a unit gets X actions. Some actions may cost more than others, but the unit never has more than X actions, ever (if units accumulate actions, then it would be possible to perform a low-cost action hundreds of times in one turn – since we’re in favor of keeping a simple API, we’ve avoided making fixes to this particular problem by adding more limits). The problem with sharing a common time unit then is that it’s hard to include some more complicated game mechanics or long term actions into the game.
To solve this, we have created what we call a fine grain turn based game. Say we want to build a boat. In a turn based game, we might wait until we have enough actions, then tell our unit to build the boat. If our fine grain turn based game, we tell the unit to build the boat each turn. Each turn, a little progress is made on the construction of the boat. By doing this, we’ve captured the “fun to watch” part of the real time game, but we still get the simplified API of a turn based game (which is necessary since we only run our tournament for 24 hours).