Things to Think About…when using a physics engine

Brian SharpAgeia

Who am I?

• Engine programmer– graphics– sound– physics– file i/o & data mgmt

• CogniToy, 3dfx, Ion Storm, now Ageia

• (Not actually a lead programmer)

What is this?

• I’m talking here about the considerations a lead programmer must undergo when using a physics engine

• Obviously quite a few

Why Physics?

• Single-system hypothetical development walkthrough

• Physics seemed like a good candidate– and not just because that’s what I have been

most recently working on...

Why Physics?

• Physics is a newcomer to engines– earlier “physics” hard to compare to full 3d rigid-body

simulations

• Physics inherently more challenging to development than other engine systems (in some ways)– very in/out as opposed to output-only like graphics &

sound– still tweaky and unpredictable, relatively– still unexplored (i.e. what is “physics gameplay?”)

Why Physics?

• Game engine subsystems can fall into 2 categories: platform & world simulation– platform: networking, file i/o

• the glue between hardware & game world

– world simulation: graphics, sound, physics, AI• the metaphysical systems of the game world

• As world simulation systems gain complexity:– platform systems must scale to accommodate– other world sims must scale dramatically to maintain

consistency

Why Physics?

• By which I mean:– complex physics complex sound– complex physics complex graphics– complex physics complex AI– etc.

• Generally: we want consistent worlds, so world sim systems must be “sympathetically complex”

Onward

• (Hopefully) helpful framing: 3 axes to each issue– technical component– programmer/programmer communication

component– programmer/designer communication

component

• Survey some issues

Issues: Engine Evaluation• Evaluating 3rd party code could be a GDC 2-day tutorial• Ask as many friends as you know who’ve used various

engines at other companies• Get your design requirements as solid as you can…

– know what things are tentative / flexible– know what things are less flexible (i.e. really important to design)

• Be clear on how the engine integrates– data: how do you hand stuff to the engine?

• how much data will you need to copy• how many world reps will you need?

– code: what domain do you need the engine to serve?• what kinds of query support does it have?• what kind of scope of things do you expect out of it?

• Evaluate API, flexibility, performance, memory usage, cost, platform availability, source access, tools, anything that is important to you.

TechProg/ProgProg/Design

Issues: Asynchronicity

• Physics can chow down on CPU, often contending with AI if not graphics for biggest millisecond pig

• Next-gen consoles with multiple CPUs: having graphics and physics on separate CPUs seems like a potentially good choice for parallelism– but that’s hard.– how to get data back and forth?– what latency is acceptable?– what performance concessions are you willing to

make for more prompt / spur-of-the-moment data access?

TechProg/ProgProg/Design

Issues: Networking

• Generally people do authoritative server-side and broadcast corrections– (I have no first-hand experience with this)

• When client receives corrections, some tricky decisions involved– ignore?– warp?– lerp?– makes everything vaguely kinematic.

TechProg/ProgProg/Design

Issues: Memory Usage

• Many physics engines are not well-bounded, theoretically, in memory usage.

• Can be a problem (especially on consoles.)

• Ion Storm example: elaborate fallbacks– disable ragdoll self-collisions– start stealing memory from other systems

TechProg/ProgProg/Design

Issues: Impl. Risk & SchedulingNew Features on Your Side

• Prototype to make sure you have the support you need from the engine.– is it possible?– if it’s possible, how stable will it be?– if it’s going to be unstable, do you have a

workaround?– in bad cases may fall onto next slide...

TechProg/ProgProg/Design

Issues: Impl. Risk & SchedulingNew Features from Engine Provider

• Communication is key– (like with everything else)

• Be clear with engine provider what your expectations are for features and what their position is on adding them– realistically, also depends on who you are

and who else they’re supporting

• Your needs may not always align– be prepared to argue sometimes– plan for workarounds when at all possible– discuss ramifications of cutting it with design

TechProg/ProgProg/Design

Issues: Interactions with Other Engine Systems

• Make sure you think about how data handed back by physics will be rendered by graphics, sound, etc.

– Graphics: • separate geometric reps; hovering or interpenetration• need hyper-accurate raycasts? need to cast against graphics rep?

– Sound:• physics-sound: no licensable engine has a built-in solution for this• common solution: lots of heuristic parsing of collision data• plan for who’s gonna implement this

– AI:• pathfinding through dynamic objects• if player can throw objects, how to respond to impact? • if player knocks over stuff and makes noise, should AIs respond?

– Yes: or else it looks dorky– No: player control is very coarse, so knocking stuff over is often too easy.– Ion Storm: AIs would respond, but sluggishly and with a high threshold

• keep design in the loop on this one…

TechProg/ProgProg/Design

Issues: Drawing LinesEngine Provider / Physics Programmer

• Player controller– Ion Storm example:

• used licensed player controller• saved us time in implementation?• but small changes could incur much tumult

– Valve rolled their own• spent more time on implementation, • when things didn’t work they had absolute control

• Source access? Do you really want it? – Pandora’s box… but also very powerful to have.– Requires evaluation of how fast turnaround is with

your provider (see “engine evaluation”)• Worry a lot about any part of this line that is

not crisply defined.

TechProg/ProgProg/Design

Issues: Drawing LinesPhysics Programmer / Game Programmers

• Communication is key– Ion Storm example: doors

• Processing of data on game side– damage infliction, etc.– whose responsibility? make sure it’s clear.

• Critical to monitor stuff to make sure you know who’s doing what.– Ion Storm: game-side programmer wrote particle

physics simulation that used raycasts for flinders & grenades

– became critical game system. Then needs support, new features, etc.

• Worry about any part of this line that is not crisply defined

TechProg/ProgProg/Design

Issues: Kinematic Objects

• High concept is obvious• Details are devilish

– Ion Storm example: elevators• game-critical objects• crushing• etc.

• Often hard to make blanket rules– how much force to exert, etc.

• Lots of designer collaboration & special-casing capabilities

TechProg/ProgProg/Design

Issues: Player Controller

• Easily among the most time-intensive parts of using physics.– Wants to be very non-physical, usually…

but play nice with physical objects.

• Maybe the licensed one is great for you... awesome!

• But you’ll probably want custom stuff.– Needs design, coding, management, good

communication, playtesting, lather, rinse, repeat…

TechProg/ProgProg/Design

Issues: Your Physics Programmer

• Is liaison to engine provider• Is liaison to other programmers who

need physics support• Is liaison to designers who need

physics functionality & tools• Must be very proactive, perhaps more

so than any other engine programmer.

TechProg/ProgProg/Design

Issues: DWIM vs. realism

• When a designer wants something to behave in a physically absurd way for game reasons, does the engine already support that? If not, who adds it?

• Can it even be done? Often boils down to the “kinematic objects are hard” problem.

TechProg/ProgProg/Design

In Closing...

• Don’t worry, you’ll find many more issues than just those!

• Hopefully get you started thinking about the issues– or nodding (off – ha ha!) as you remember already

running into this stuff.

• Q&A...