Things to Think About … when using a physics engine

1. Things to Think About…when using a physics engine Brian Sharp Ageia

2. Who am I? • Engine programmer • graphics • sound • physics • file i/o & data mgmt • CogniToy, 3dfx, Ion Storm, now Ageia • (Not actually a lead programmer)

3. What is this? • I’m talking here about the considerations a lead programmer must undergo when using a physics engine • Obviously quite a few

4. 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...

5. 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?”)

6. 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

7. 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”

8. Onward • (Hopefully) helpful framing: 3 axes to each issue • technical component • programmer/programmer communication component • programmer/designer communication component • Survey some issues

9. 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.

10. 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?

11. 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.

12. 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

13. 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...

14. 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

15. 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…

16. 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.

17. 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

18. 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

19. 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…

20. 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 veryproactive, perhaps more so than any other engine programmer.

21. 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.

22. 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...