Collision and Animation Systems in Games

Jani KajalaLead Programmer / Chief Technology Officer, Pixelgene Ltd.

Jani.Kajala@pixelgene.com+358 (0)45 6343767

(Other) Uses for Collision Systems

Finding contacts between objects (surprise!) Visibility culling / probing

‒ Shadows (“What objects/polygons are inside this frustum?”)‒ AI (“Are any enemies visible from this point?”)‒ Camera (“Are there any walls nearby?”)

Triggering events‒ IF player_collides_this_dummy_box THEN alert_enemy‒ IF player_collides_another_box THEN show_cutscene

Simplify Problem (As Always)

Usually first idea is too complex Simplify collision scenario as much as possible

‒ Simpler to implement‒ Better performance (likely)‒ More robust at the end‒ Etc. etc…

Best if you can avoid collision checks totally! Examples follow…

Minimize Number of Checks Needed

Usually many collision types can be ignored, e.g. Camera collides usually only against level geometry

(either static or dynamic), but not against e.g. player Character doesn’t collide against Camera either Bullets don’t collide against each other! Bullets don’t collide with the shooter or the weapon Only Player Character can collide cut scene triggers Car tires might collide only with ground, but not other

cars (unless cars can drive over each other) Etc.

Implementation: Classification & Filter

Simple solution, you select category bit for each object group, e.g. level=1, camera=2, character=4, etc.

Then you define, for each object, ‒ A bit flags marking the groups which the object belongs to

(e.g. PLAYERCHARACTER=PLAYER+CHARACTER)‒ A bit mask saying which objects can be collided against

Check if the objects have common bits in their masks / flags or they can be ignored right away:‒ IF (A.bits&B.category)==0 AND (B.category&B.bits)==0

SKIP A vs. B check

Simplify Shapes

Use simpler 3D shapes:‒ Character = capped cylinder‒ Car = box + 4 spheres‒ Camera = sphere‒ Bullet = Point (or line segment)

Use 2D if possible:‒ Do characters need to be able to jump on top of each? If not

then use 2D‒ Can cars drive over each other? If not then use 2D

Character Collisions

Capped cylinder (capsule) works well for characters‒ Turning/moving always ok

due to symmetry of capsule‒ Doesn’t get stuck on stairs as

sphere on bottom ‘slides up’ the character over small obstacles

‒ Efficient to compute, also character vs. character collisions could be handled with 2D circle vs. circle test!

Collisions Against Level Geometry

Polygon detail level cannot be avoided (usually)‒ Action happens inside the level so hard to approximate‒ Counter-example: Racing game with collisions & ‘grass

slowdown’ done based on distance to race track center line When checking collisions against level polygons

make object vs. single polygon check robust first!‒ Everything else (BSP etc.) is just optimization (important)

Use your favorite tree structure etc. to optimize number of collision checks so you don’t need to check every single polygon in level‒ BSP-tree, Octree, OBB-tree, AABB-tree, hash tables, or any

combination of those and many others…

Integrating Animations to Game

Very much game specific tasks, e.g.‒ When a character aims with firearm, we need position of the

character’s hand, then place the weapon on the hand and aim the weapon to the target…

‒ We might need to find out velocity vector of a foot based on key frame data to avoid feet slipping when walking…

‒ Character can walk and aim simultaneously…‒ Car might have different textures on tires based on speed

(smoother textures to provide sense of motion blur) Note that a single game object can have many

animations and a single animation can be used by many objects

Generic Requirements

Support for hierarchy‒ Characters can have more than 80 bones...

Support for low level transformation access‒ Needed for aiming, turning tires, etc.

Manual (=by code) selection of‒ Which (part of) animation to apply‒ To which objects animation is applied‒ When the animation is applied (or is it applied at all)‒ How animations are blended‒ What is done to object before animation‒ What is done to object after animation

So simple scene playback is not enough (or is too much!)

Example: Character Walking

Simple state-based system: IDLE, WALKING, etc. First, assume that character is in idle state Next character blends to walking animation

‒ We can’t instantly change to another animation so we can either use transition animation or blend between two animations. This time blending is fine since standing is quite similar pose as walking

When character is in walking state, we need to move the character in game world‒ We could use linear speed (as many games do), but we can do

better by extracting movement speed from key frame data When character stops we blend back to standing

‒ Remember to blend down the movement speed as well By rejecting animation state changes between transition/blends

we make sure character doesn’t jerk based on user input

Demo: Character Walking

(character_tutorial-divx.avi)

Aiming and Shooting

We simplify the situation by assuming that the character aims and shoots ‘quite much’ forward‒ Makes potentially complex aiming really simple!

Now we need only to blend between aiming-up, aiming-forward and aiming-down poses based on tilt angle‒ Simple linear blend between two animations will do‒ Note that we apply this animation to upper body only

Finally we rotate weapon direction to match actual target direction (to give that last touch!)

Demo: Aiming and Shooting

(zaxdemo-0.5-divx.avi)

Summary

Simplify collisions (and everything else) before implementing

Don’t bother making too fancy animation systems, you need relatively low level access anyway

And last… BUY MY BOOK when it hits the shelves!!! ;)‒ Making Game Demo, by Chad & Eric

Walker and me, published by Wordware Publishing Inc.

‒ It has EVERYTHING… And MORE!!! Another plug: Looking for game-dev job?

Drop email at jobs@pixelgene.com Thanks,

Jani.Kajala@pixelgene.com