GDC - Physics in Half-Life 2

Jay Stelly is a senior engineer at Valve, and on the last day of the conference he kicked off the morning with a discussion on Physics in Half-Life 2 (HL2). The physics simulation, and inventive physics-related puzzles used throughout the game, were complicated elements to implement. He discusses the problems they faced, relates some of the humorous demos they used to flesh out their ideas, and laid out the ways that good engineering can make design that much better.

In 1999, world physics was a new technology that hadn't been integrated into the genre before. That meant that the solutions were not very well understood. There was an obvious visual payoff, with problems both from a technical and design perspective. Just the same, it was an opportunity to integrate gameplay. At the time, everyone was talking about physics, but there was no discussion of incorporating that technology into gameplay.

Their high-level strategy was to invest in gameplay. They decided not to start with a simulator, and to not add features to simulation (until it became necessary). They set out to make HL2 stand apart with the depth and quality of gameplay, as opposed to just 'cool simulation'. This would require a lot of engineering work on tools and design.

A timeline for HL2 Physics:

• They looked into physics demos.
• Demos generated ideas.
• Looked into licensed physics simulators.
• Internalized physics into their design ideas.
• Built a bunch of prototypes and tools.
• Gameplay mechanics experiments.
• Solved technical issues.
• Focused design and tech.
• Solved more problems on the technical side.
• Incremented to deliver a stable system (with valuable features at each deliverable goal).
• A long polish stage before shipping the game.

Some physics prototypes:

• Zombie basketball -Satchel charge, trying to explode zombies into nets.
• Watermelon skeet shooting - Watermelons loaded up into an ejector, tossed into the air to be shot.
• Glue Gun - Trying out 'building things' within the game. A gun that placed glue on objects, glue attracted itself to make constructs.
• Danger Ted playset - Glue a model of a designer to a car, glue propane canisters to the car, launch the designer strapped to the car into the air.
• Toilet Crossing - Build a zipline construct with junk to cross a chasm, extra points if you rode on the toilet during the experience.

New technology can be intimidating; To fully understand this, they needed to create their own point of reference. Led to really cool things like Garry's Mod.

So, how can they make the gameplay more focused? What ideas are good? How many ideas do they need? How can they measure the difficulty of the gameplay? And, of course, how are the prototypes going to be turned into shippable gameplay?

They reduced design to 'training and testing'. Game design is a set of player experiences that trains the player, allows them to demonstrate a learned skill, and is presented with style. With this criteria, they had an easy way to judge ideas for merit.

Design is also engineering. Defining success, identifying constraints, generating ideas, analyzing solutions, building prototypes, testing results, measuring success, and then re-examining your constraints. Distill out the elements of game design, be creative, but you want a way to analyze your solutions and measure your progress.

This allows you to reverse engineer your experiences. I want them to do 'X'. Okay, what do they need to know before they can do X? Training skills in isolation allows the player to be prepared for future gameplay elements. When something went badly in playtesting, they could look back and see if they'd prepared the player adequately for the experience. If something isn't eventually used, or isn't working, it becomes obvious and can be cut.

Training can have obstacles, though. If the player is in combat or in peril, they're probably not learning. To improve the training experience, you make it clear it's okay to experiment. Sell forced choices tot he player with style. Suggest experiments with the the gameworld. Story should not be an obstacle to training, it should enhance the experience. It's also not distracting like combat. Players can play attention to both. (He uses the example of the sawblades in Ravenholme to chop Zombies in half.) Player value as a metric for skills and knowledge. Each piece of skill must have value, or it gets cut from the game. There is a limit to the total number of things you can teach in a game. You want to cull skills down to the fewest required. Having skills interact makes them both more valuable. Requiring skill from a player makes the skill more valuable to the player. These relationships form a sort of economy, which they refer to as 'design economy'. Allowed a framework for discussion about the process.

Of course, every design has constraints. Objects have to be breakable, with the quintessential crowbar. Physics have to interact with the core combat gameplay. Collisions should cause damage, objects should be used as cover. Physics need to extend the core puzzle gameplay.

Integrating physics turned out to be kind of difficult. Physics are kind of intuitive, but it doesn't "just work". Most designers don't completely understand the technology. Taking the design to the fullest required understanding the simulation. Game logic may place impossible requirements on the simulation. Some elements have to be one part physics and one part game design, fudging the edges.

So, they took on the design interface for the physics. They need to teach the designers about the system (decomposing machines into physics blocks). They needed to become proficient with unfamiliar units and tuning parameters, dealing with a complex set of variables that imply calculations. So, to deal with this they delivered technology incrementally (ramping up the learning curve). They needed a physics expert to support designers.

Some other problems came up, especially in the early days. Many physics engines interact with the game in discrete steps of time. Changes to the state of the system are often queued. Game rules are often discontinuities in state. They also needed to reserve space for 'inventory items' (grenades, etc.) Motion planning is a problem as well (will I hit anything when I go over there?). Collision detection without physics was a required - especially for AI. They ended up building a collision speculator for themselves so the AI would behave intelligently.

This then becomes an over-determined systems, with simulation variables, design variables, and design criteria. The 'Superman problem' - Beating people to death with tin cans. They fixed this by making the mass of gravity gun held items very low, so that you couldn't destroy a car with scrap metal.

Simulation failure also was a problem. Objects get stuck in each other, they don't settle, something that is valid for physics becomes invalid for the design. Simulator 'explosion', game design constraints that can't be satisfied, and creating objects in solid space. Plan for the simulator to fail, and be flexible with your expectations. realize you're going to need to fudge.

To sum up: Engineer to solve gameplay mechanics. Use analysis and design economy to intentionally improve the design. Tech problems remain with phsyics. Some can be solved with design, put plan on investing in the technology. Plan for failure cases and be sure to ask "is this failing as a result of bad design?"

I ranted about this

[Shadow Wrought]

In my Jounral [slashdot.org] already, but how is it that just about every write-up from the GDC is long and expansive except for the Iwata's keynote? Am I alone in thinking that that was far more important to the gaming industry than what the producer of Battlestar Galactica had to say?

Re:HL2 Physics

[Anonymous Coward]

To put it simply, Half-Life 2 is a moderately well rendered city, that feels vaguely real. Doom 3 is ten thousand miles of beautifully rendered corridor.

Re:HL2 Physics

[Jorkapp]

I would assume the years leading up to the licensing of the Havoc engine were spent on developing other aspects of the game.

* Audio work does not require the game engine.
* Modelling the objects and maps does not require the game engine per-se.
* Aspects of the engine can be coded without the physics engine - AI, weapons, Player->NPC interaction, etc
* Other things were going on behind the scenes at Valve besides HL2 - Steam, Creating DOD:S, CS:S, HL:S, etc

Of course, we can't deny that they probably took a day or two here or there just to duke it out in an office Counter-Strike tournament.

Re:Motion and path simulation

[rentedflowers]

Also object weights tended to be too light IMO. I really felt that objects' fall rates and throw trajectories reflected not enough weight.

You realize the fall rates are largely independent of the weight, right Gallileo?

You can't own it

[Anonymous Coward]

You can't own Half Life 2.

You can only rent it, using Steam to grant you permission to play it.

Steam sucks.