Design Patterns for Interactive Physics David Wu Director

Design Patterns for Interactive Physics David Wu, Director of Technology, Pseudo Interactive Inc. Richard Hilmer, Development Lead, Pseudo Interactive Inc. GDC 2001

Abstract A well-designed game built on a solid physical simulator has the potential to achieve an intense level of interactive quality resulting in an innovative and highly entertaining title. The goal of this presentation is to communicate knowledge, techniques, and insight into the design and implementation of games built on the paradigm of kinetics. The format for the presentation is that of a pattern language. A suite of patterns, antipatterns, and pseudo-patterns is presented; each describes a problem in context followed by a proven solution.

Who are we? Introductions

Key Takeaways An indication of the kinds of problems that you will run into in the development of an interactive physics title. Insight into possible solutions to those problems. Do we want to put physics in our game after all?

Why use physics in a game? universal rules that are intuitive – everyone “knows” physics animators try to “re-invent” physics with each model – that is what they are mimicking, so do it once interactivity – since each object does not have to be explicitly programmed, more objects are innately handled and hence more interactive

Why use physics in a game? (cont’d) Emergent Behavior n n things that you did not expect or explicitly program become possible e. g. dragging that barrel from the other side of the level over and using it to prop up a ramp to jump to a different area Used traditionally in simulations n car racing, flight sims

What is a Pattern? A pattern is a solution to a problem in a context. Our patterns are loosely broken down into: n n n Problem Context Forces Solution Force Resolution Rationale

Collision Representation Context: Modeling the physical properties of entities Problem: What sort of representation should be sent to the collision detection engine?

Forces n n n Technology Constraint: Many collision detection systems require geometric primitives that describe an explicit volume Technology Constraint: Many collision detection systems require convex geometric primitives Robustness: Model should be able to represent all entities within the scope of the game with reasonable accuracy

Forces Efficiency: Minimize memory required by models Developer Time: Minimize time and complexity of model construction

Pattern: Union of Convex Hulls Describe the geometric properties of a physical entity as a union of convex hulls.

Implementation n n Each entity has 0 or more Convex hulls Each convex hull is described by 1 or more points Hulls are typically generated from a reduced level of detail representation of the source mesh (i. e. choose an appropriate LOD from meshes used to draw the entity) Spherical extrusion may be used to model smooth surfaces

Force Resolution: n n n Programming the necessary tools and framework is complex and moderately time consuming Designer and Artist time required to generate collision representation’s from meshes is low Efficient and robust collision detection routines may be used such as Lin-Canny or GJK Effective across a wide variety of models with varying topology Models may be represented with arbitrary accuracy

n n Models may be represented compactly with minimal memory requirements Automating the construction of convex hulls is moderately complex

Context: You are using convex hulls to model the collision representation of your entities Problem: How do you construct these convex hulls?

Pattern: Divide (manually) and Conquer (algorithmically) n n n Designer select convex parts of the mesh i. e. Cactus has 3 convex parts Generate convex hulls enclosing these parts add each vertex to the hull and remove degenerate points use available software such as qhull

Pattern: Use that BSP Tree generator you built back when Doom after reading Michael Abrash's papers on Quake n n n Generate a BSP tree from the mesh The resulting volumes are convex Generates many convex hulls

Pattern: Bottom Up Computational Geometry n n Perform a constrained Delaunay Triangulation of the mesh Pray that there is a solution Add vertices if there is not Merge tetrahedra into convex hulls

Pattern: Top Down Computational Geometry n n n Select a arbitrary triangle Build a three point convex hull from its vertices Incrementally add the vertex of “valid” neighboring triangles to this hull - “valid” is a user defined heuristic metric When no more triangles may be added, start a new hull Repeat until all triangles are part of at least one hull

Pattern: Union of Spheres n n Model physical entities as a collection of overlapping spheres. Best when used in a hybrid system (i. e. union of convex hulls and spheres)

Pattern: Union of Spheres Constructing the spheres 1 n Voxelize the volume interior to the mesh n Find a minimal set of spheres that covers each voxel subject to an error threshold Constructing the spheres 2 n Designers add the spheres manually

Rationale n n n Certain models are handled very efficiently (i. e. spheres) Modeling flat surfaces is not that important Spheres are highly intuitive to everyone Collision detection systems required only to handle spheres are typically robust and trivial to implement Manual construction may be highly time consuming

Rationale n n n Automating the construction process using known methods is trivial, but the results are typically poor Some programmers like the RISC style nature of only using spheres They typically like particle/spring systems as well

Pattern: Quadratics and CSG Model physical entities using quadratic primitives bounded by planes Sphere Ellipse Cone bounded by planes Paraboloid bounded by planes Cylinder bounded by planes

Pattern: Quadratics and CSG Rationale n n Quadratic Primitives are fairly intuitive Automating the construction process is non -trivial

Pattern: Use the Mesh

Pattern: Use the Mesh Collision Rep

Pattern: Use the Mesh Rationale n n You already have LOD’s, no developer time is required If you do not require a sophisticated collision detection system this may be you best bet If you do require a sophisticated collision detection system, you can solve that problem later Smooth surfaces are not all that important

Pattern: Alternative Collision Representations Subdivision surfaces Boxes Bezier or Spline Surfaces Higher order implicit functions 2 d representations Connected tetrahedral

Pattern: Alternative Collision Representations Voxels Height fields K-dops

Pattern: What do you mean– ‘only spheres’? Problem n How do you deal with an engine that “does everything” but just not how you would expect, and in a manner that affects design?

Pattern: What do you mean--’only spheres’? Context Your programmer tells you that this engine handles everything. What she doesn’t tell you is that it handles everything as long as it is spherical, or less than 10 kilograms, or connected together with springs. It may in fact handle everything but require certain constraints on the implementation and design that the design needs to take into account. This is distinct from It’s Not Perfect, because the problem lies in side effects of an otherwise correct implementation.

Pattern: What do you mean--’only spheres’? Forces Fun n You need to design a fun game. Physics Engine n You need to use the existing physics engine, most likely because it cost a ton to develop or license and your boss says so.

Pattern: What do you mean--’only spheres’? Forces Intuitive n Your design must be simple and intuitive using the technology as it is, and not require the player to jump through hurdles that the design could not. Design Time n Games take time to design.

Pattern: What do you mean--’only spheres’? Solution To satisfy the requirement that you use the existing engine, the best course is to prototype your current design with the “limited” engine and determine how effective the design can be with the technology as it is. Otherwise, re-design.

Pattern: What do you mean--’only spheres’? Rationale Fun is the most important aspect, not what you wanted to do Make something that works with the given technology In some ways this type of design is easier because you actually have some boundaries to channel your ideas In the end, the product will be better because you will have based it on something that you know works and will have more time to hone and tweak.

Dynamics Representation Context: Modeling the physical properties of entities Problem: What sort of representation should be used to describe the dynamics and degrees of freedom of physical entities

Dynamics Representation Forces: n n n Versatility: Support the dynamics of entities within the score of the game. i. e. cars, people, cacti, cloth, ponytails, jello Efficiency: How difficult is it to solve the DAE’s that result when deriving the forward dynamics of the system? Coupled vs. sparse Ill conditioned vs. well conditioned How many DOF are required?

Dynamics Representation Forces: n n n How many constraints are required? Intuitiveness: Does anyone understand that the DOF describe? Design Time: How easily can the dynamics of a system be described? Can the process be automated?

Pattern: 6 DOF Rigid Bodies n n n Entities are represented using one or more joined rigid bodies Rigid bodies have 3 linear DOF (translation) and 3 Angular DOF (rotation) The orientation of a rigid body may be represented using:

Pattern: 6 DOF Rigid Bodies n n Direction Cosines (a 3 x 3 matrix rotation matrix) Euler Angles A normalized Quaternion (Euler Parameters) a 3 D vector describing the axis and angle of rotation (Exponential Map)

Pattern: 6 DOF Rigid Bodies Rationale n n n Just about everyone uses this representation Highly intuitive Articulated entities can be built with constraints This is what the rendering engine expects The dynamics of 6 dof rigid bodies are well known and trivial to implement

Pattern: Mass Spring Networks n n n Entities are presented using 1 or more 3 DOF particles Particles are connected to one another using various potentials and constraints such as linear springs When used to model rigid bodies they have been referred to as “Natural Cartesian Coordinates”

Pattern: Mass Spring Networks Rationale n n Highly Intuitive Trivial to implement Efficient w Everything is linear, none of those angular issues to deal with w Models cloth, bullets and Jell-O well 3 constrained Particles can describe a 6 DOF rigid body

Pattern: N DOF Articulated Rigid Bodies n n Entities are described as a tree structure. Each node describes the relative transformation between a parent and its child. Commonly referred to as a skeleton, or “Bones”

Pattern: N DOF Articulated Rigid Bodies Rationale n n n There are modeling tools supporting bones Excellent for modeling rigid humans Efficiently handles high DOF open loop articulated bodies

Pattern: Finite Elements • • Models are represented using a connected volume consisting of primitive elements Elements commonly used are tetrahedra and hexahedra State within each primitive is defined by its tri-variate shape function Typically a lower order polynomial • i. e. linear, quadratic, cubic

Pattern: Finite Elements Rationale n n n Effectively handles deformable objects Effectively handles fracture Extremely versatile w Finite Elements can model just about anything n Computers are fast

Pattern: Free Form Deformations • • • A special case of finite elements Elements are uniform hexahedra Shape functions are typically cubic

Pattern: Free Form Deformations Rationale • More commonly known to artists and designers than Finite Element models • Manually constructing the dynamic model of an entity is trivial • Supported by most tools

Pattern: It’s Not Perfect Problem n Your engine doesn’t handle X very well. This is a problem that occurs in various ways in all aspects of development, not just with a physics engine; however, it occurs very frequently when using a physics engine, and is worthy of notice.

Context You have developed or licensed a robust physical simulator with all the bells and whistles, except it turns out X isn’t quite working, and you are trying to use it in the creation of your game.

Forces Stability – X needs to be stable throughout the range of possible inputs, e. g. its use does not blow up in certain cases. Consistency – X needs to work all the time and in the same manner (deterministic).

Forces Developer Time – It will take a large amount of developer time to find and fix the cause of the problem. X may be a bug, or more often (and worse) a limitation in the scope of the engine (“The way I handled that doesn’t work in that case”). Design Time – Certain assumptions have been made about the capabilities of the engine. Re-designing the feature that makes use of X may be prohibitive due to coupling in other areas.

Forces Design Complexity – Certain assumptions have been made about the capabilities of the engine. Designing around X may make the desired game mechanic too complex. Efficiency – Sometimes X can be handled in a more robust and stable way with a less efficient algorithm. That is not desirable.

Solution Unlike a regular “bug”, detecting It’s Not Perfect can be difficult and may only happen far into regular development. Like any problem with “flexible” time based Forces, the solution is a series of questions. In our experience, the order of the questions matters a great deal, and this is where the value lies:

Solution (cont’d) 1. Estimate of Developer Time – Does the programmer know immediately what the problem is? – What is the best estimate to repair the problem? – If the estimate is reasonably short, you may just want to proceed without further consideration. – If the estimate is extremely long, you at least know you have ruled out a programming solution.

Solution (cont’d) 2. Implementation Workaround: – How necessary is it to use X for this feature? Often there are many ways within the existing functionality of the physics engine to perform the same thing. 3. Estimate of Design Time: – Can the feature that makes use of X be removed? – Do other features depend on this too much? Sometimes this is a no-brainer (e. g. yes, we need the wheels on the cars to spin), other times it is desirable feature that may have to be cut based on where you are in the production cycle.

Solution (cont’d) – How long will it take to re-design? If there is little to no coupling between this feature and others, often this is very short. 4. Balance the estimates: Not just the joy of scheduling, but actually comparing schedules.

Rationale This is slightly general for a pattern in that no exact solution can be given. Its solution is similar to handling any relatively unknown entity or cutting edge technology. That is, the emphasis is placed on re-design to minimize risk of re-programming.

Pattern: Play With Your Tool Problem n How can I avoid finding out It’s Not Perfect late in the production cycle?

Pattern: Play With Your Tool Context You have developed or licensed a robust physical simulator with all the bells and whistles, and its time to get down to making the game Your design makes assumptions about the capabilities of the engine You want to find out just how good your physics programmer is.

Pattern: Play With Your Tool Forces Developer Time n The physics programmer’s time is very valuable. Design Time n The designer’s time is better spent not learning everything about the engine. Stability n It is important that all aspects of the engine that are necessary to the design are stable.

Pattern: Play With Your Tool Forces (cont’d) Engine Complexity n The physics programmer is the only one that understands the entire complexity of the engine. It is difficult for others to use or even test without her involvement. Feedback Efficiency n It is important that test cases can be constructed, tested, reworked and retested quickly.

Pattern: Play With Your Tool Forces (cont’d) Consistency n The engine must be deterministic with respect to the tests to ensure reproducibility. Intuitiveness n A means for testing the engine in an intuitive manner is necessary for designers and testers.

Pattern: Play With Your Tool Solution Create a tool that is the interface to your engine. n n programmer may have done this already for herself, but may have also used a suite of small testing programs. one tool that provides access to the complete functionality of the engine is what is needed

Pattern: Play With Your Tool Solution (cont’d) n n not necessarily where content is created it may otherwise be the “game editor” or the game plus a standard GUI, or minimally the engine plus a standard GUI interface does not require a large amount of refinement absolutely must be easy to update so that it is always consistent with the game should not require programming knowledge to use the tool

Pattern: Play With Your Tool Solution (cont’d) The tool helps find out It’s Not Perfect early because it allows the designer to accurately and repeatedly test the engine functionality against her designs.

Pattern: Play With Your Tool Example Mod 2 k - PI’s editor n n n drag and drop object handling intuitive tree structure for components (based on DOF hierarchy, including meshes, collision reps. , functionals) right-click access to all parameters simulation in editor full game engine is actually a subset of the editor code

Pattern: Play With Your Tool Rationale n n n Developing a physics engine requires a large commitment and a great deal of focus by a developer It is a waste of resources (and probably not possible) to teach several people the subtleties of the engine In the long run the time spent is recouped several times over

Time Context: Designing the Physics Pipeline Problem: How do you deal with that time integral? Forces: n n Efficiency: Numerical integration can become a bottleneck Robustness: Do designers have to perform a singular value decomposition on the dynamics equations of their models to ensure stability?

Time Forces: n n Efficiency: Numerical integration can become a bottleneck Robustness: Do designers have to perform a singular value decomposition on the dynamics equations of their models to ensure stability?

Time Forces: n n Deterministic simulation is a plus Code Complexity: Writing a general purpose DAE solver is non-trivial

Pattern: Fixed Time Stepping n n Time is descretized into fixed size timesteps (i. e. 1/60 seconds) The physics and rendering loop might look like this: game. Time = real. Time; for(; ; ) { // Step to present While(game. Time < real. Time) { Step. Physics(1/60); game. Time += 1/60; } Draw. Scene(); }

Pattern: Fixed Time Stepping Rationale: n n Trivial to implement Performance is less variable with a fixed vs. variable time step w Degrades gracefully in the worst case n Deterministic

Pattern: Variable Time Stepping n n n Time is discretized into variable size time steps A time step is chosen such that certain criteria are met in the face of present system dynamics Criteria might include: w Stability w Accuracy w Processor load Rationale n n n Adaptive LOD for physics Potentially more efficient that fixed time stepping This is what we learn in Academia

Pattern: Variable Time Stepping Rationale n n n Adaptive LOD for physics Potentially more efficient that fixed time stepping This is the technique that we have all learned in academia

Pattern: Euler isn’t that bad n n Derivatives are computed at the beginning of the time step. The results are extrapolated across the time step, acceleration is assumed to be constant.

Pattern: Euler isn’t that bad Rationale n n n Intuitive: If you have never read a book on numerical integration you will likely end up with the Forward Euler method Efficient if accuracy and stability are not required Trivial to Implement Encourages Designers to construct stable systems Numerical integration is just a hack to approximate the analytical solution, so why waste time on a fancy scheme?

Pattern: 4 th order Runge Kutta n n 4 Derivative calculations are performed to construct a cubic polynomial approximation of the acceleration over a time step A pseudo Taylor Series approximation

Pattern: 4 th order Runge Kutta Rationale n Highly accurate when compared to alternate techniques commonly used in games w Exceptions to this rule include systems developed by Chris Hecker and Eric Larson n Relatively trivial to implement w well sort of n Adaptive step sizes can be used to promote stability

Pattern: A-Stability Use a numerical integration scheme that is asymptotically stable such as: n n n Implicit Euler (backwards Euler) Moderate order Implicit Runge Kutta schemes Lower order Multi-step methods using the Backward Differentiation Formulae (Gears Method)

Pattern: A-Stability Rationale n n n Performance is fairly predictable Allows you to use a large, constant time step Enables designers to work with very large numbers w Without having their objects disappear

Pattern: A-Stability Rationale n n n Provides a great opportunity for you to use the conjugate gradient method Unstable systems are not conductive to enjoyable game play I sleep better at night knowing that my integrator is asymptotically stable

Pattern: Artists Don’t Know Physics Problem: n Playing With Your Tool allows designers and artists to set physical properties that have no meaning to them.

Pattern: Artists Don’t Know Physics Context you have developed a single tool that gives artists and level builders access to the engine objects are visiting NAN too often for your liking

Pattern: Artists Don’t Know Physics Forces Developer Time n A great deal of programming time has been invested already into creating the engine and the tool Stability n unreasonable physical parameters can create instability

Pattern: Artists Don’t Know Physics Forces (cont’d) Artists Don’t Know Physics n The tool asks the content creators questions they can’t answer

Pattern: Artists Don’t Know Physics Solution 1. Normalize parameters • internally convert to appropriate physical values 2. Automate common cases 3. Education 4. Built-in help

Pattern: Artists Don’t Know Physics Examples map 0 to none, 0. 5 to normal, 1 to max sliders in GUI compute moments of inertia based on extents of mesh adjust center of mass automatically based on mesh

Pattern: Artists Don’t Know Physics Rationale While it is great to improve the knowledge of the entire team, explaining moments of inertia and other things to artists sometimes just ain’t worth it Help files are great, but realistically do not get updated as regularly as the functionality (its hard enough to get comments in the code)

Controllers Context: Implementing Game Logic, controllers and Animation Problem: How do you control a physical entity without deriving a continuous potential energy metric whose gradient applies forces to actuate the entity along your desired trajectory?

Controllers Forces: n n n Intuitive: Controlling characters should be as obvious as directing a puppet show Robustness: Provide mechanisms to control all entities within the scope of your game Quality and Style: Characters should animate with style that is consistent with their personality and your game

Controllers Context: You are controlling an articulated character Problem: How do you find the joint angles required to position part of your character at a certain place in world space?

Pattern: Inverse Kinematics Inverse kinematics is the problem of providing a map from an arbitrary coordinate system into the coordinates describing the kinematics of your mechanism Mechanism

Pattern: Inverse Kinematics n For example you might say: I want Skullina’s hand to grab the sheep located at (128, 64, 32) in world coordinates. Your Inverse Kinematics solver will provide you with a set of joint angles that will position her hand to the specified location w if a solution exists

Pattern: Inverse Kinematics n n Inverse Kinematics is often used to map world space constraints into joint space constraints For Example: “Ensure that Skullina’s heel touches the XY plane at Z = 2”

Pattern: Inverse Kinematics Rationale n n Designers should not need to waste their time solving non-linear systems of equations in their head in real time. Inverse Kinematics provides a level of abstraction between skeleton configurations w you might apply the same world space constraints to two different characters and have your IK solver deal with their underlying differences

Pattern: PD Controller Context: You are controlling an articulated character Problem: How do I compute an appropriate acceleration from the joint angles that my IK solution derived?

Pattern: PD Controller n n n Proportional Derivative (PD) controller’s are commonly used and trivial to implement Given a desired position and velocity, they provide you will an acceleration to apply in order to reach that position and velocity. The trajectory taken may be specified by frequency and damping settings.

Pattern: PD Controller n Intuitively, a PD controller may be thought of attaching a spring+damper to the degrees of freedom that you wish to actuate. The springs rest position is where you want the end effector to be.

Pattern: PD Controller n n i. e. I would like Skullina’s hand to reach the teapot in 0. 5 seconds (frequency = 2. 0) following a smooth ease-in/ease-out trajectory (critically damped, damp ratio = 1. 0) i. e. I would like Skullina to swing a baseball bat quickly (frequency = 32) with a slight overshoot (under damped, damp ratio = 0. 5)

Pattern: PD Controller Rationale n n Generally more robust than other techniques such as Hermite splines Provides intuitive trajectory settings Can produces physically viable accelerations with smooth ease-in/ease-out properties Simple, general interface

Context n You are controlling an articulated character Problem n How do map from an acceleration to a force? w Should I just evaluate Fc=M*A+Fx?

Pattern: Inverse Dynamics n n n Inverse dynamics is a mechanism for determining a force required to produce a given acceleration The solution to Fc=M*A+Fx is not as trivial as it looks M and Fx may be functions of time and Fc w i. e. Fc=M(t, Fc)*A+Fx(t, Fc) n M may be non-sparse

Inverse Dynamics Gotchas n Coupling between degrees of freedom w i. e. accelerating Megan’s thigh will effect her knee n n Constraints Skullina leaning against a wall External forces Gravity

Inverse Dynamics Gotchas n n n Auxiliary Inertia coupling Skullina is carrying an Axe Controller Stability 256 kg w Forward Euler approximation n Force Clamping 64 kg

Inverse Dynamics Rationale n n More robust than tweaking force gains and spring constants Effectively automates a challenging derivation and computation Provides a level of abstraction between difference shapes and sizes (enables politically correct controllers) Designers should not need to know the mass and moments of inertia of Megan’s limbs

Context n You are controlling an articulated character, your artist gives you a key-framed animation Problem n How do you actuate your character to follow this animation and simultaneously respond to external forces such as those resulting from a collision with a convex tennis ball?

Pattern: Physical Keyframer n n Use your PD controller together with your Inverse Dynamics solver to compute forces required to follow the trajectory of the key frames Limit the magnitude of forces applied to ensure that your character does not knock over a Tank that got in the way of her walk cycle Deal with believable reactions to external forces later Deal with the possibility of your character losing her balance later

Pattern: Physical Keyframer Rationale n n n In the absence of external forces your character will perform the animation that your artist provided you with Your character will handle many unforeseen evens in a robust manner (ideally recovering and continuing their animation) You have lots of motion capture lying around, why not use it?

Optimization Hacks Context n Your physics pipeline is complete Problem n Computers are not as fast as you thought

Pattern: Sleep Zzzz Exploit temporal coherency by putting objects to sleep

Pattern: Decoupling Artificially decouple high DOF systems Similar to Baraff’s “Partitioned Dynamics” However, Goal is not model abstraction Goal is to split one O(N 3) solve into multiple O(Ni 3) solves where Ni are smaller than N

Pattern: Kinematics Model objects with known trajectories kinematically Switch to dynamics when necessary

Pattern: Kinematic DOF Model certain DOF kinematically n n Turret of tank Car wheel rotations Spinning barrel of Gattling Gun Skullina’s 3 DOF Ankle

Pattern: Incremental Solver Reduce error tolerance of iterative solvers Improve solution over time n Exploiting temporal coherency

Pattern: The Real World Is Not Fun Problem n You need to create a highly realistic video game that is enormously enjoyable, using a physics engine.

Pattern: The Real World Is Not Fun Forces Realism n n n For many games this is of prime concern Everything in the game world should react as they would in real life For example, the reaction of characters when they are struck by objects, how objects fly through the air, and the behavior of a car in a turn at high speed.

Pattern: The Real World Is Not Fun Forces Fun n n The game needs to be fun and engaging, and this often includes doing things you cannot normally do, which directly opposes the Realism Force. For example, a human cannot run around carrying 600 lbs. of weapons and ammo, and still leap vertically 48”; however, when playing a gun-totin’ sci-fi space marine, its fun to do that.

Pattern: The Real World Is Not Fun Forces (cont’d) Expectation/Extrapolation n Many of the extreme circumstances that are depicted in games are unfamiliar to players in real life (a major reason for their inclusion) Howeveryone has an idea of what should happen in a given circumstance based on their innate understanding of the physical world. Sometimes the natural extrapolations made are not actually consistent with reality.

Pattern: The Real World Is Not Fun Forces (cont’d) Expectation/Extrapolation example Tennis Ball Huge Boulder Falls 4 x its diameter (30 cm) in about 0. 25 s Falls 4 x its diameter (20 m) in about 1. 5 s Because player is not used to seeing such large objects thrown around, the boulder looks slow (falls 6 x slower).

Pattern: The Real World Is Not Fun Solution For decisions that depend heavily on the Forces, prioritize your decisions based on: 1. 2. 3. Fun, Expectation/Extrapolation, and Realism.

Pattern: The Real World Is Not Fun Examples When creating the controller for the avatar, allow for abnormally large inputs so they can jump extremely high. Make the weapons that the player carries unusually light. In a driving game, double the acceleration of gravity to counter the apparently slow falling of correctly scaled vehicles. Increase the friction between tires and the road, perhaps beyond what is possible.

Pattern: The Real World Is Not Fun Rationale The long-term success (lifetime) of the product depends more on Fun There are short-term negative effects to not meeting Expectation/Extrapolation, possibly enough to deter a casual purchase Realism is often more effectively portrayed with visual and audio content, rather than gameplay n i. e. make it look more real and sound more real, but still make the player feel like superman

Thank you! When we get back to the office, we will make this presentation available on our website, n www. pseudointeractive. com