19
Mar

For many long months, I have been the only source of Sims 3 information on the internet. Totally crazy, I know, but I saw a talk at an AI conference and apparently they weren’t really ready for that info to go to the press. I’m not really the press, so there you go, my info was out there for some of you to find.

Sims3

Today the news embargo was lifted and the official site went live. In addition there are previews at 1up, IGN, and a little bit on Gamespot. I’m sure there’s more info out there but I saw enough to know that it looks kinda interesting and that it’s not coming out for a good long while. One of the sites has the date as 12/15/2009. I can’t even begin to think that far into the future of my game purchasing plans!

I never really played the Sims 2. I got it when it first came out and it blue-screened my PC. I tried it about 3 times then gave up forever. I was kinda busy at the time. When the first Sims came out I actually played it a lot. I got really really into it for a few weeks. Maybe months even. Then I realized I was dirty and neglecting my real friends in favor of keeping my sim clean and happy. That was the end of that.

Back in 2001 I had the experience of doing some work on the path finding system for the Sims 2. I don’t know if the code I wrote for Maxis ever ended up in the shipping project but it was a great learning experience. I got to work on getting the Sims to navigate around their houses better and to deal with imminent collisions with each other as well. It was quite challenging but rather cool. But that was way early in development and I’m sure that they changed things a lot before actually shipping it out the door.

Anyways, we’ll see what more info they reveal. For now I guess everyone will have many other outlets for their Sims 3 curiosity!

27
Feb

Having just recently finished Assassin’s Creed, I was quite looking forward to the talk on crowd AI in Assassin’s Creed. The talk was mostly given by Sylvain Bernard, the Animation Director for NPC & Cinematics. James Therien, the Technical Lead for crowd gameplay, chimed in with technical details here in there, but it was a mostly high level talk. Which was good, talking about their goals and design for the crowd, with a little of how they accomplished it.

They started out talking about measuring their expectations. Sylvain joined the company 3 1/2 years ago. At the time, they were looking at GTA since they were doing an open world game. But their focus would be much more on the crowds. The new consoles weren’t out yet so they didn’t know what they were capable of. They recalled watching the trailer for Dead Rising and using that as a benchmark for how many rendered characters the Xbox 360 was capable of that the player could interact with in some way. They also got reference from movies about how people interact with crowds. Some key ideas they took were that in a dense crowd, people form two aisles of traffic, looked at how the crowd reacts to threats, ways the crowd can be an obstacle for the player (showed some footage from Indiana Jones, yeah!) and can make the player trip and fall. They really wanted to incorporate the crowd into gameplay.

High level goals
Rich NPCs: There is no actual notion of a crowd in Assassin’s Creed. Every NPC is an individual. The crowd is emergent from the behaviors of the individuals.
Realistic Art Direction: The art direction was going for a realistic style, which meant they needed to give the player character realistic capabilities. Compared to the Prince of Persia, where the player could run 10 meters along a wall, the assassin can only run a short distance along a wall. They do cheat where needed, however, to make gameplay more fun. The player can survive a 20 meter fall, for instance.
Animation Style: Tried to make it more realistic. They showed the Prince and the Assassin’s wall climb animations side by side and there was much more movement in the assassin’s animation. Ultimately, they felt their animation style was “stylized realistic.”
Shared Skeleton: All NPCs share the same skeleton. Some characters are just scaled down or scaled up. It was a bit of a challenge to fit all the meshes onto that same skeleton, but ultimately it was worth it because any character could play any animation.

They then went on to talk about some of the specifics of bone count and their animation system. One point I found really interesting was that they said they started with an animation system that was more realistic but the controls weren’t responsive. The player would let go of the stick and his character would take a few steps to stop, sometimes running off a roof. NPCs couldn’t stop on a point. They ultimately went back to a more traditional system to allow for more precise control. This was really interesting to me because we run into the same question, trying to balance really smooth locomotion animations with really precise player control.

Unlike in Uncharted: Drake’s Fortune, NPCs and the Assassin share the same animation system. In fact, you could control every character as the player. They would just switch to using Assassin animations if you tried to do something that character didn’t have the capability of doing.

There are two layers to the AI. The first is the behavior layer, and this is shared with the assassin. These are fine-grained environment interactions. The other layer is for the decisions. There is behavior environment data that acts as guidance for runtime interpretation. These guidelines are used only in specific cases, like when the assassin is climbing. NPCs following him in a chase behavior use the exact same code as the player and do the same environment detection tests to achieve their goals.

The AI decision environment data consists of a navmesh. On top of that they generate a waypoint network for A* pathplanning. On top of that they have metalinks. The waypoint links are simple connectivity info, the metalinks encode complex connectivity such as jumps, ladders and beams. They use steering to move the NPCs and communicate with the decision layer when they’re in trouble (something is blocking it should they stop and wait or what).

Since the game is about crowds, they want the designers to be able to specify in general where they want the crowds to go. Level design placed road segments down in the level. Then the NPCs only had to make decisions about which branch to take as they wandered. This made wandering very cheap. They also used this system when NPCs decided to flee from the player - it was just a different decision on which branch to take.

They specifically called out their lack of a technology like Euphoria (something I know a bit about given the project I’m working on), meaning they had to make a ton of different animations. They only wanted to activate rag doll at the last possible moment because they wanted the limbs to have weight to them. So they then showed an example of a character running into a wall. Many many times. All different heights of walls, running into it forwards, backwards, all every which way. That’s how you get to 15,000 animations, they said. 15,000! That’s a lot, wow.

Next they discussed how the spawned in the crowds. They wanted the city to feel like it was full of people but they had I think 120 NPCs at a time. They first tried just spawning them in a radius around the player, but they ended up wasting spawns in places you couldn’t see. They tried changing the radius of the circle, but if they made it too big they just ended up with a sparse smattering of NPCs in any one place. They called their solution “the blob.” They’d pick the closest triangle to the player on a 2d mesh and then do a flood fill outwards to all the connected places the player could go. They’d spawn NPCs on random triangles within that blob out of sight. They didn’t try to bias the blob in any one direction because the player is so mobile, they couldn’t guess where he was going. They just made sure all the connected streets were full of NPCs.

They had a cool system for creating variety on the NPCs. They could vary the head structure, facial texture, skin color, body texture, gender, height, accessories, AI category, reactions, voice and more on spawn. Beyond just looking different, the crowd was composed of people with different duties. First, there was the base walking crowd, which was made up of bench sitters, monks, beggars, military patrols, trouble makers, etc. Then they had people with specific duties, of which they only ended up with the kiosk workers and the orators. These were to give structure to the flow of the crowd. They had wanted more, like people sweeping or drinking from fountains but ultimately these were all really just aesthetic and didn’t make it in.

At one point they had a big system to do simulation and have people change tasks, but they realized they didn’t need it. The lifespan of an NPC is very short, you don’t care if someone just walks off and despawns.

The reaction system was how the crowd would respond to the player. They talked about how it important it was for design to communicate what they wanted to the programmers. They made some animated videos (what we call pre-visualizations) of what they wanted. Showed us a few, they conveyed the basics of how the crowd should move.

They showed some in-game footage of a player hanging on to a world. NPCs that wander close enough and are facing the player will stop and ask what he’s doing. If more than one stops next to each other they’ll start a fake conversation. Reactions are composed of an individual reaction, the sound that actually comes out of that NPC, and over 100 possible body gestures.

Reactions are much more than a visual system. They have “reaction packs” designed by the level designer so they can have special responses to specific events in the level. Alert was a reaction used to draw guards into a fight. Guard awareness levels were done by switching out the current reaction pack based on when a guard saw a body.

How do you get lots of NPCs at 30 frames per second? They didn’t want to have a level of detail system on the decision or behavior layers because they wanted reactions to be consistent. They do get a little bit simpler as the NPCs get farther from the player though - they don’t do much when they are out of sight of the player. But they did a lot of LOD on animation. The bone counts drop quickly, there’s no more IK, simpler look at, simpler procedural rigs. They focused on making common NPCs as cheap as possible - cheap pathfinding, environment tests, steering, etc. They also made use of multi-threading to take advantage of the X360 and PS3 platforms.

Ultimately, they felt they met their goals of creating a believable crowd. They had a quality focused team with good support from management. They felt they fell somewhat short in incorporating the crowd into gameplay. Blocking the player and reacting to the player was there, but they player couldn’t really use the crowd in interesting ways.

Their team size was around 150-180 people, 1/3 programmers, 1/3 animators, and 1/3 artists. Well, I think that’s what he said, but then were are the designers? Must have took that down wrong.

27
Feb

Christian Gyrling’s talk on the AI/animation system used for Uncharted: Drake’s Fortune was easily the most anticipated talk at GDC 2008 for me. I am currently working on AI for a console action title and this is a subject near and dear to my heart. Hearing how other people have made this system work is fascinating and helps me think about how I can learn from other’s work.

They were facing many problems going into this project. It was a new codebase, a new franchise and a new console. The goal was to make everything bigger! They were expecting 10-20 times the number of animations for each character compared to the last generation of console games. But they still were only planning on having one programmer and one animator for every two characters. You cannot put 20 times the content in with the same number of people.

They decided to figure out which things they could address. First was gameplay scope - they couldn’t make everything better, so what parts should they make better? Next was asset creation - how could they create all these animations? How could they decrease iteration time? Finally, the issue was programming. How should they organize all the animations? With all those anims, how will they choose which ones to play? Do they need complex selection logic?

Their approach was to get something working very rapidly. They got a very bare bones version of the AI up and running. It could stay and shoot, go to cover, get hit, and die. Christian and a designer played with it and took notes on what they saw as a player. When they were having fun what were they seeing on the screen? The average lifetime of an enemy in Drake’s Fortune is 15 seconds. Enemy hit reacts and death were fun. The rest of the time the enemy was in cover or shooting at you. The goal became to make these interactions as interesting as possible.

Problems to solve were that they had a lot of animation files. It was slow for an animator to open them all in Maya. With so many anims, they had mismatching keyframes, especially with transition animations where they go from one state to another. The start and end frame need to be the same, but to check this they had to open another Maya file. To solve this they decided to have fewer actual files and keep all related animations in the same Maya file. For example, all cover animations were in one Maya file that the game extracted the needed frames out of. This solution only works if you have one animator per character, since you cannot share the Maya file. But they found that the animator really took things to heart and felt a sense of ownership when they did own a character like this.

Another problem was that the animator shouldn’t have to go through a programmer to fiddle with his animations. They should be able to tune their anim blends without having to restart the game. They created a tool called the In-Game Character Animation Test Bed. Instead of having the AI contol things, they map all possible AI actions to a controller. Then the animator can run the character around and move it to cover to see all the anims. Time to go from animation creation in Maya to controlling an NPC was around a minute. They also let you reload animation scripts at run-time. They only have a PS3 build of the game, there is no PC build. So letting the animator tweak the blends on the fly on the devkit was really critical.

Next Christian got into a lot of specifics on how they structured their AI and animation layers. I think the most important things to take away were how separate they kept the two layers. The AI would tell the character to move to cover and just trust that it would get done. The animation scripting took care of which animation would play to make it happen. They could have many different enter cover animations and the AI logic would never need to know about any of them.

The other big thing that was fascinating was the technique of Additive Animation (or Delta/Diff Animation). We are all using technology to blend multiple animations together to ease the load on animators. For example, playing a walk animation on the legs at the same time layering on an aim anim with the upper body. But this idea takes it one further. If an animator makes a run animation, then makes a tired run animation, you can basically subtract the run from the tired run to get something that equals “tired”. Then you can add that “tired” bit on to any animation to make the character look fatigued. Add it to the idle, the walk, the run or more and you create a lot of animations without any new work. Awesome.

They also use something he called animation layers. Each of these layers is independent of the others for purposes of deciding when they start and stop. So on one layer you may be playing a run animation that is 30 frames. On another you have an additive run-noise anim that is 300 frames. On the final layer you have some facial animation that’s 160 frames. As the one starting these anims, you don’t worry about syncing them up. Each layer is responsible for itself only, so the run-noise layer isn’t worrying about if the run layer is going to loop, it just plays.

Other interesting bits - they using additive animations for their aiming and look ats. They tried using IK but it caused skinning problems when the character was lying down in low poses. They tried partial animations where they only animated the neck/spine but it made the character look very stiff, and you’d need lots of unique head idle anims. Ultimately they used additive anims that contain the difference in aiming with the neck, back, spine and preserve the base animation motion. Using additive anims gave the animator the power to control the look and feel. Animators will always make things look better than your tech. If not, find better animators.

This was all running on SPUs so had very good performance. 9 clips and 9 blends in normal battle took about 10 microseconds. 2 or 3 times that if the character was changing direction. Memory footprint was about 1 Kb per animation.

He gave some guidelines on what they learned from this technique as dos and don’ts.
no y-translation on hip joints in base anim
little to no hip rotation (use rotated base anims)
high and low poses worked great

He summed up with these parting points.

- choose wisely where to spend your time
- hide animation complexity form the AI through some kind of action interface
- animation states are autonomous
each contains not just an animation but the blend tree
can be tested/verified in isolation
no surprises
- additive animations
cheap - so much bang for the buck
more power to the animators - better visual quality

08
Jul

By popular demand (well, one request), I’m writing up my notes on Richard Evans’ talk from AIIDE. Richard Evans is currently working at EA/Maxis on the Sims 3. He talked about how the work they’re doing to make each Sim unique and distinct. They’re goal is to make them more individual and more social at the same time.

They have a large pool of discrete traits. Each Sim gets a selection of about five from the pool of traits. Some traits are mutually exclusive, for example, a Sim can be modest or have a big ego. A Sim can hate TV or love TV.

They’re doing their work on the game mechanics in a 2D prototype. It’s a simple sprite world with box graphics, but the simulation it’s running is complete. Richard showed us several demos of the topics he was discussing in action. He had a Sim that hated TV and one that loved TV. It resulted in a funny setup where one Sim would turn on the TV and the other would promptly turn it off.

Read the rest of this entry »

18
Jun

It’s been taking me a bit longer than planned to get around to writing up my notes from AIIDE. I’ll just list out who spoke and see if I can’t get around to filling in the ones people are most interested in hearing about. So leave a comment if you want to know what someone talked about! And probably do it soon before I forget everything I heard. Hehe. Kidding! I took notes!

Wednesday:

  • Richard Evans from EA/Maxis talking about Sims 3
  • Quinn Dunki from Pandemic talking about pathfinding in Saboteur
  • Chris Williams, Nick Pavis, Matthew Best and Steve Dykes talking about Euphoria technology from LucasArts (I won’t write this one up since it’s where I work! Conflict of interest and all)
  • Ken Perlin talking about all sorts of interesting stuff

Thursday:

  • Matthew Wiggins from Lionhead talking about character and emotion in Fable 2
  • Wolff Dobson from AiLive talking about their LiveMove and LiveCombat products
  • Peter Gorniak from Mad Doc Software talking about Squad planning in a tactical shooter (yes, I used to work at Mad Doc, but I’ll talk about this one if people are curious)
  • Chris Hecker from EA/Maxis talking about approaching hard problems - not really about Spore

Friday:

  • Neil Young from EALA talking about various AI in different games, including the Spielberg titles
  • Soren Johnson talking about Civilization IV (he was at Firaxis but is now at EA/Maxis)

Just about all my notes are from invited talks. The only one I could really write up that was from a paper submission is Peter’s talk, above. I have a few notes on some work done at the University of Alberta on memory efficient pathfinding that is being used in Bioware’s Dragon Age, but the most interesting thing about my notes is really the fact that the game is still in development, since there’s been nothing about it released in quite some time.

The final item at the conference was a presentation about this annual RTS competition. If you’re interested in RTS AI problems then I recommend checking out their webpage since it’s all open source and you can download their engine and all the competitors to try to build your own solution.