A blog doesn’t really work for me. I always feel obliged to write some elaborated, polished article, when all I want to to dump some quick thoughts. Perhaps a wiki works better – time will tell…

So here it is: The Wiki. Note that this is not an open wiki; edit privileges are reserved to your humble host. In the unlikely case that you want to keep up with my updates, you can subscribe to the Recent Changes feed. It’ll be noisier than the usual blog feed, and its delta format needs a bit getting-used-to.

This blog will live on for the occasional ‘meta’ news, like this one.

So let me describe two other approaches

Simulation

I add this just for completeness. I don’t think that this is really reasonable or even feasible approach, but let’s check it out for the fun of it.

Instead of generating a world as it is now, simulate its development over time. For the landscape that would mean, you start off with a rocky planet, hurl meteorites at it, simulate tectonics, erosion, and all that stuff and let it run for a few billion (simulated) years. Add in plants at some point along the way – which of course have an effect on erosion – and let them spread around. You might get away without evolution, just add or remove different species at various times. Same thing for animals. And finally you pop some settlers into the world and watch them build villages, cities and kingdoms.

You even get history for free by recording it. So you do not only get a Kingdom of Blafasel, but also the fact that it is in war with the neighboring Kingdom of Bruhala – a stupid conflict about a small island, because that’s what they were always fighting about.

This biggest advantage of this approach is that it would not produce the inconsistencies which are inevitable with other approaches – especially when only local knowledge is used.

Of course this is pretty much nonsense and using this to build a game world would be a huge waste of CPU time.

Intelligent Design

No, I’m not a fundamentalist priest. But nobody claims that games work by the same rules as reality.

Instead of using dump algorithms to crunch numbers, let’s try to simulate what a human game designer does when (s)he creates a game world. The most important thing is that the world serves a purpose. Things link “there is a mountain range here that the player has to cross to reach the other kingdom.” Random methods can still be used to fill in the gaps, but they are heavily constraint by a list of story or gameplay driven objectives.

I have no clear vision of how such a beast would look like. It might start off with an empty world (say an endless ocean without any land), a set of rules and the objectives (the purpose that this world should serve). Then it starts to shape the world according to the rules, directed by the objectives.

Shaping means

• Raise some land from the sea.
• Put a mountain range here as a border between two kingdoms.
• Level this area to make room for a mountain village.
• Place river here to give this wealthy city a big trading route.

What are those rules?

• The world consists of continents which are big blobs of rock surrounded by salt water.
• These plants grows along the coast, those in swamps.
• This animal lives in forest, that in open plains.
• A village needs a well or other fresh water supply.
• A village needs some food sources, and the population is constrained by the supply.
• Fishermen, Hunters, Farmers, … are food sources.
• In a religions culture settlements are centered around a shrine or temple.

And objectives?

• The world should be interesting. Otherwise the design process could terminate after raising a continent of rock from the sea, without anything of interest on it.
• The world should be playable. In a randomly generated world, the player might start in a small village in a mountain valley – only to realize that it is surrounded by impassable walls of mountains.
• The world should allow a certain story to take place. If the game is about an epic war which is going to destroy all of the world, make sure there is someone worth defending, someone, coming from somewhere, who is attacking and a place where the great battle can take place.

And of course a gazillion more items in each list.

How to implement a program that can do this is left as an exercise to the reader.

The process of creating such a world would then be similar to declarative programming. The designer would distill her/his knowledge into rules and set up the objectives that implicitly describe a story.

[Update 2010-01-10: Fixed links. GameDev.net got a new site and broke some URLs]

My dear readership probably noticed that I made a few “Links YYYY-MM-DD” entries, featuring stuff on the web that I read or just thought to be useful or interesting. I do read a lot (I have about one hour commute time every day and a phone that it good enough to read feeds and websites), but manually preparing these entries proved to be way to much work for a lazy person as your humble host. So I just started to “share” these links in Google Reader and in the unlikely event that you care about this, you can find and subscribe to them at http://www.google.com/reader/shared/odahoda.

For example with three entities A, B and C, Copycat might first create the group G1={A, B}. Another sequence of Codelets might build up the conflicting (because each entity can only be direct member of one group) group G2={A, B, C}. In order to establish G2 the group G1 has to be torn down, but G2 can coexist with G1 as long as it is in proposed state.

This way Copycat can explore alternatives that conflict with the current view, but might turn out to be better. But the conflicting structures have to compete at a very low level. In the simple case above can easily measure that group G2 is superior to G1 and thus decide to tear down G1 in favor of G2. But in more complicated scenarios an alternative group G2' could seem less promising at first, but once it has been constructed it opens the possibility for a very complex structure which could not be built with G1. This makes Copycat kind of shortsighted, i.e. the presence of G1 suppresses groups which are scored lower than G1 if compared directly to it, but might act as a first part of a more complex structure.

Tabletop seems to have the ability to remember structures and when it explores an alternative that turns out to be a dead end, it can go back to the remembered structure. This way it can be more open to alternatives than Copycat. But I don’t know how this was implemented in Tabletop, because I have not yet read anything more detailed about it.

Last night, while lying in bed waiting for the sandman to come around, my brain was spinning around this and looking for ways to improve the situation. One possible option could be the introduction of “Branches” in the Workspace, which would be a generalization of the “snapshot” feature that Tabletop seems to have. Each Branch is a Workspace in the Copycat sense, but now the Workspace can contain multiple “sub Workspaces.” Each time a Codelet wants to establish a conflicting structure in a Branch, this Branch is forked and the alternative can be explored without interfering with the existing Branch. Now Branches would compete against each other instead of lower level structures. Each Branch gets a score and if one Branch falls behind too much, it is discarded.

There a various ways how this could be implemented. All Branches could be active at any time, which means that the processing capacity has to be shared by all Branches. This makes branching very expensive, so a mechanism that limits the number of Branches is required. The expected value of a proposed structure has to greater than a threshold value before it can be established – this is a mechanism that already exists in Copycat as it is now. If the structure now conflicts with other structures, a penalty is added to this value which is based on the number of existing branches, so it become very unlikely that a new Branch is created when already many Branches exist.

Another option would be to have only one Branch active at a time and every once in a while the system decides if it should switch to another Branch. Or it might shard its attention to all Branches based on the Branch’s scores, with a very large skew towards the highest score – but still leaving some attention to lower scored Branches.

Just an idea…

In Copycat the Slipnet is a network of nodes that is not unlike other networks, i.e. typical neural network implementations. Nodes have activation levels and this activation spreads to connected nodes. But unlike a pure neural network “brain,” the Slipnet is not the place where the main action happens. Instead the nodes and their connections capture the (abstract) knowledge that the system has about the domain and the activation levels reflect what Copycat currently considers as important. Highly activated nodes can spawn Codelets, e.g. if the node “successor” is activated, it may spawn Codelets that actively search for more successor groups. Information flows in the other direction by Codelets that do discovers certain structures and then add some activation to the corresponding node (some generic search Codelets are constantly spawned and if they find something they activate a node – which then triggers more targeted Codelets looking for things like that).

The Slipnet in Copycat is (apart from the activation levels) completely static. So it’s not really “memorized memories,” because it has no way to learn, but more “a priory knowledge.”

The workspace is the place where Copycat builds up the structures and representations of its domain. It is a highly dynamic network of nodes, which is constantly modified by the Codelets. It also has some properties that make it very different from the network of the Slipnet (or neural networks). Connections are built up in several stages, i.e. they are first “proposed” and only later (if they survive long enough) “established.” And while two nodes can only be connected by one established connections, there might exist other, contradicting connections at the same time, which are still in the proposed state. That means that Copycat can build up and evaluate an alternate view of the domain without replacing the current view right away, but only when the new view seems better that the old.

The Workspace is also able to build up hierarchic structures of groups and treat those groups as nodes to operate on.

Both of these components need some changes to be used in a NPC brain. There definitely needs to be some notion of learning and memory. The lack of memory is one of the biggest issues I see in current Game AI (it is somewhat emulated by scripting, but in a very limited way). The Slipnet in Copycat only contains very abstract knowledge, e.g. characteristics of platonic letters and such things (instantiations of letters only exist in the Workspace). So putting knowledge like “Fred has red hair and owes me 20 bucks” in there is a very different thing.

The Workspace will also need some adaptions for my use of it. For example spatial information is one important domain that needs to be represented, so a character can find its way around the world and correctly react to its environment. And there are many other things that need modeling, e.g. relations with other characters, dialogs, etc.

I will have to spend much more time thinking about these things. But I’ll leave that for another day (not implying that I could even scratch the surface on a single day).

I forgot to write about one important characteristic of the Copycat architecture. In traditional Game AI randomness is used to make the character behave less predictable and thus look more human. But this randomness is applied at a very high level, for example upon an encounter there is a 80% chance that the character reacts hostile to the player and 20% chance that he is not. While this might be fine in many cases, there might be situations where such “dumb” randomness leads to quite absurd behaviors. So the random weights would need to be adjusted to the situation, which in itself is a very hard job.

Copycat also makes extensive use of randomness, i.e. every time it picks the next Codelet to execute it will do so randomly – weighted but still random. But this randomness happens at a very low level. As can be seen in Copycat the top level behavior is much more stable – if there is one obvious behavior, it will pick that quite deterministically. Only if there are multiple conflicting behaviors which are valid reactions to the situation, each one will have a certain probability to win (if you repeat the decision making process multiple times with the same input, it will pick decision A_i with probability p_i). But these probabilities are highly dynamic, depending on the input, and will (hopefully) always lead to decisions that “make sense” in the given situation. And the probabilities are not defined in advance by the programmer but a result of the interactions of the different Codelets as the system comes to a conclusion.

Consider are fairly typical but complex situation that a good Game AI should be able to handle: a group of warriors that does an ambush on a bandit’s lair. As the battle evolves each character AI has to perform a number of tasks (in no specific order):

• Path finding: don’t run into trees or get trapped in a dead end.
• Group movement: the group should stay in formation, warriors should not get singled out and become easy prey for the enemy, and gaps in the formation should quickly be closed so the enemy cannot break through and split the group.
• Battle: well, fight for you life or you’ll be dead.
• Communicate: listen to orders and adjust behavior, or react to a comrade’s call for help.
• Situation assessment: where are the enemies, who should I attack?

The biggest challenge is to make these tasks interact properly. For realistic behavior the fact must be acknowledged that each character has just a limited “cognitive capacity.” Let’s look at an example:

A character that is busily defending himself against two enemy fighters will not turn around to help a comrade, he might not even hear (or better: have the mental capacity to process) his call. His movement is mostly determined by the battle and his enemies, so his path finding is reduced to hold position or retreat – and he has no time to look around to realize that the direction is he moving to is a deadly dead end. Once his enemies are defeated the character is able to spend more cycles on other actions, like looking where the battle has taken him, reassessing the situation, regrouping, looking for new enemies to attack or noticing the archer hiding on a roof.

These are just the most obvious tasks which are directly related to a combat situation. Characters have much more behaviors which – on first sight – are not related to combat. For example taking shelter when it is raining, because getting wet is somewhat unpleasant. This is of course a behavior that should be suppressed while fighting. But what if it is a pitch black night and the torch in his hand is the only source of light? Letting the torch get extinguished would be suicide, so in some circumstances seeking shelter from rain can make sense even in the middle of a fight.

And a combat situation is one of the easiest things to handle, because of its nature only short term and tactical decisions have to be made. Dialogs or strategic decisions are much harder because they can be influenced by all previous player actions. Traditional system quickly reach their limits here, for example I encountered several situations in games like Oblivion or Fallout 3 where I completed quests in an order that was not anticipated by the designers and the dialogs conflicted with my previous interactions with certain characters.

Many, many rules will not apply or get activated in any situation, but there’s no a priori way to sort out unneeded rules. At any given point the whole repertory of behaviors as well as the full range of sensory input the character gets from his environment has to be considered by the AI engine. Selecting a subset in an “intelligent” way just moves the problem to another layer without reducing the complexity. And just applying some simple heuristics to cut down the complexity leads to strange and nonsensical actions and discontinuities in behavior (which can often be seen is current titles).

The point is that the complexity of the problem growth exponentially with the wealth of rules and behaviors that the characters have. And for more realistically behavior of characters you want a lot of rules. The current state-of-the-art AI architectures, which build on rather rigid algorithms (finite state machines, decision trees, etc.), become very hard to maintain and their runtime characteristics go down the drain when faced with this combinatorial explosion.

After this short exploration of what is problem is, let me try to explain why I think the Copycat architecture could solve these issues.