Tales of the Rampant Coyote
Adventures in Indie Gaming!


(  RSS Feed! | Games! | Forums! )

Sunday, June 11, 2006
 
Ways to Fake More Believable AI
And now moving 180 degrees from the original post of complex simulation of an ecosystem and characters in a world... here's a bunch of ideas on how to fake it. Some of these were taken from a CGDC lecture from many years ago about using Deception in Game Design. Sorry, I haven't found proceedings for that lecture or anything else other than my decade-old notes, so any resemblance to what the forgotten lecturer spoke on is purely coincidental.

#1 - Swap Cause and Effect
Our brains are wired to recognize causality. It's critical to our survival. We experience pain when touching a hot stove, and our brains hastily lay in the neural pathways that equate the stove to dangerous pain. In fact, if no causality exists, we'll often make up our own in a vain effort to order the universe and make it more predictable than it is. That is the foundation of superstition.

So one powerful trick is to swap cause and effect. This is well-used (and often sloppily implemented) in computer role-playing games. For example, an NPC might apparently perceive danger, and warn the player. From the player's perspective (the only one that matters), the NPC was being smart (and believable) by recognizing that there was danger approaching. But really, the causality was backwards - the warning effectively triggered the danger to appear.

#2 - Limit Interaction
Interactive Games have everything that movies, books, recorded audio, and comics have all rolled into one package. So if games have all the power of these other artistic media, why are we still struggling with cardboard characters?

It's because it is interactive. Once you let the player poke around your carefully crafted world, the illusion comes apart. TV sets only resembles a real world when carefully lit and filmed at very specific angles, edited to make it contiguous. The characters don't have to be subjected to random interruptions from the audience and unscripted things happening on the set. But that's what games are all about.

One way to work around this is to limit interactions. You see this in the almost stereotypical "conversation trees" in RPGs and adventure games - the player has a very limited palette of things he can say to the AI characters. The player may not even have the option of attacking a "friendly" character, thereby preventing some game-destroying events from taking place.

Face it, the game is going to have limitations one way or the other. You may as well put it on the UI side where players can ignore it.

#3 - Interweave Scripted and Random Behaviors
One of the clearest signs that a character is computer controlled is purely deterministic behavior. Throwing a little bit of unpredictability into their behaviors will keep the player on his toes.

When we did Twisted Metal, the little bit of randomness that I through into the AI attacks convinced some players that the AI cars were actually attacking each other. They weren't, really (though at one point they were), but it created a more compelling illusion for the players. They loved the feeling that they were in a true free-for-all.

#4 - Force Decisions
If you are going to use this, use it sparingly, because there's a good chance players WILL figure it out. With this technique, you pretend to offer multiple paths, but they both converge on the same path. Players WILL figure this out, though, and it will annoy them.

#5 False Causality
This is a little trickier than #1 - but basically you hint that some event occuring now is somehow linked to some past event or decision... where really none exist.

For an example - take the "Arch Enemy" scenario from Daggerfall. Now imagine if this random event hinted about something like, "You killed my brother in the dungeon X," pulling X from a random list of dungeons the player has visited. The player may be wracking his brain trying to remember what he killed in that dungeon and how it could have led to this turn of events. It's a nasty little trick, but it could work.

#6 - Interweave a Non-Interactive Storyline With the Interactive One
This is usually implemented by the old "doling out the backstory" trick - as the player goes through the game, he encounters bits of a secondary story (usually one occuring in the past) that he has no influence over. But through this, certain characters come alive - which helps make up for their robotic reactions when the player finally encounters them in-game (if he ever does: In the System Shock games, the characters are long dead when the player encounters pieces of their stories).

Labels:



Did you enjoy this post? Feel free to share it: del.icio.us | Digg it | Furl | reddit | Yahoo MyWeb

Comments:
One trick we used rather extensively in Jet Moto 2 and Streak was to have one of the testers (Mike Snow, I think?) lay down a track by recording him doing a lap. We took position samples every frame as he ran the lap. He was the best in the office at the game due to spending hundreds of hours at it, so these tracks were pretty close to ideal.

Then the trick was that the AI would not (couldn't actually) follow the tracks exactly, but used the tracks as hints of where they should be. That allowed the players and AI to bump against each other and realistically alter paths. It also gave the AI really organic-looking paths because you were, in fact, racing against a close approximation of Mike.
 
I tried to do something like that with the AI in Jet Moto 1. I actually tried using a genetic algorithm to calculate the optimal path. But I had a few other problems:

#1 - I couldn't use the same physics engine as the player bike, because the player bike was taking between 4.5 and 6.5 milliseconds to process. I was given about 7.5 milliseconds total to process Physics, AI, and Collision Detection for all of the other NINETEEN bikes. (The physics were optimized for JM2, which allowed the NINE - not nineteen - bikes in that game to use the same physics as the player).

#2 - The AI physics (which was never very good, because it had to be dirt simple but still somehow resemble what the player bike was doing) was constantly in flux, almost up until the first RC. So the "best path" kept radically changing.

#3 - The tracks (when I implemented the algoirthm) were also in flux in a bad way, screwing up the G.A. --- in fact, the algorithm provded to be much better at finding collision holes and bugs (to exploit) than the optimal path.

#4 - After some experimentation, I didn't have enough confidence in that technique to stick with it. It was cool though.
 
Post a Comment

Links to this post:

Create a Link



<< Home

Powered by Blogger