Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

GDC - Physics in Half-Life 2 93

Posted by Zonk from the super-gravity-gun-ftw dept.
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?"

This discussion has been archived. No new comments can be posted.

GDC - Physics in Half-Life 2 More

GDC - Physics in Half-Life 2

Comments Filter:
  • 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:I ranted about this (Score:5, Funny)

      by jdgeorge ( 18767 ) on Friday March 24, 2006 @04:22PM (#14990416)
      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?

      No, but you are alone in thinking that someone might read your Slashdot journal (which I imagine is very interesting, insightful, informative, funny, and unread.)
      • (which I imagine is very interesting, insightful, informative, funny, and unread.)

        Or at least two of them ;-) Mianly I was lazy and didn't want to spend a lot of time posting something that I had already written, but on the off chance that someone cared, well, maybe they'd share their lottery winnings with me, too. Same odds and all that.

    • I was there... (Score:3, Interesting)

      by djohnsto ( 133220 )
      To be honest, Nintendo's keynote was light on any real info. He spent more than half of the keynote going over how the game Brain Age for the DS came about, how they convinced stores to carry it, and had a live demo / showdown of the game with some "friends". The most popular part of this was when he announced that everyone in attendance would be getting a copy of the game (which turned out to be a demo).

      He then talked about Metroid Prime: Hunters, and again had a live deathmatch between some of the devel
      • Well its nice to know we didn't miss much, but a simple line to the effect that nothing much was said would have been, IMHO, much preferred to making it look like Iwata's speech was simply glossed over.
  • Sort of off topic, but we had a *HUGE* turnout of GDC folks at my bar last night. Had a nice chat with the art director for zipper interactive, few other folks. Replay video from last night will be playing till 5pm today, then again on sunday.

    Winamp compatible stream here [205.188.215.229]

    --toq
  • I was somewhat disappointed that the physics in HL2 fails realism testing in at least one respect; on the "bridge" level, I had the idea to run a little experiment: I jumped off the bridge, and then used the "toss" fire for a grenade to see if the grenade and "I" would fall at the same rate. That grenade shot up in the air like a balloon, relative to my descent. I wanted SPLAT-->BANG! and all I got was SPLAT. What's up with that? :)
    • Maybe they just give items weight and calculate fall rates based on that, rather than giving them both weight and some number to define the level of air resistance that they encounter when falling.

      A five-pound chunk of styrofoam should shoot up above you if you release it while falling. A 5-pound grenade should not.
    • I tried the same thing, but toss still puts force behind the grenade, it doesn't just let it go. grap a small object like the bucket in the small shack half way through the bridge and repeat. The secondary fire key (or primary, I forget which) will just drop the object. I forget what happens...

    • Re:Failing the leaning tower test (Score:5, Interesting)

      by syphoon ( 619506 ) on Friday March 24, 2006 @08:42PM (#14991985)
      I can't speak for other objects, but I do recall reading that they deliberately lessened the gravity for grenades to let them arc higher for a better visual effect.
    • The game doesn't take place in a vacuum.

      Air resistance, anyone?
    • It's funny, because this feature is in Quake III.
      Projectiles will spawn with the same speed and direction you have when firing them.
      It's not on by default though, and I don't think people enable it because it seriously messes up aiming with the rocket launcher.

  • Things like this... (Score:3, Interesting)

    by TheNoxx ( 412624 ) on Friday March 24, 2006 @05:12PM (#14990799) Homepage Journal
    Make me wish, if only a little bit, that I'd gone into programming instead of art/3d modelling/graphic work/etc.

    Oh, what a good game programmer could do with an easily scriptable physics engine. Imagine WoW when the spells have effects on the physics, or interact with each other based on their level and element and alignment... I dream of a combination of Mage: the Ascension and Dungeons & Dragons... tell me I'm not the only one.
    • Your not:

      http://physx.ageia.com/titles.html [ageia.com]

      "Warhammer MMORPG"

      Its got the MMORPG part, but if you want the magical part you want:

      http://www.mightandmagic.com/us/darkmessiah/teaser / [mightandmagic.com]

      FPSRPG Might and Magic game powered by an enhanced version of source, anyone?
    • An engine like this? http://www.unity3d.com [unity3d.com]

    • Imagine WoW when the spells have effects on the physics, or interact with each other based on their level and element and alignment

      There's a reason why the "physics" of WoW, and MMORPGs in general, are very simplistic; synchronizing complex HL2-class (full rigid-body simulation) between several computers in an ordinary multiplayer game is NOT simple... Now try to do it in a game like WoW, where thousands of clients need to have their physics synchronized. It's a daunting task to say the least. The thing

      • That not necessarily true. A script can be applied both localy and remotely and the communication overhead is still minimum. For example, you could send a 'chest thump' as a script or you can send the positions for all the body parts individually. In the first case you have a processing overhead that is handled at the client (receiving) side, but since the engine is already there it might be invisible to the user. In the second case you have a communication overhead which might make your game latency-depend
  • FTFA:

    Motion planning is a problem as well (will I hit anything when I go over there?).

    Getting around tended to be more difficult than I'd like to see in a FPS. Part of it was overambition in striving for a truly 3D physical environment, replete with small ventilation ducts and bizarrely slanted ceilings, but I rather frequently found that I needed to jump to get over a 1" ledge or duck to get under a certain threshold, and sometimes both, sadly.
    Hopefully this is still a work in process in game physic

    • 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?
      • Also object weights tended to be too light IMO. I really felt that objects' fall rates and throw trajectories reflected not enough weight.

        If motion in free flight looks wrong, that's probably intentional.

        But if big objects bounce as if they're very light, that's a fundamental limitation of impulse-constraint physics engines. All bounces occur instantaneously in such systems. (That's what an "impulse" means; an infinite force applied for zero time with finite energy, leading to an instantaneous chang

        • When our ragdolls fall down, it looks like they're hurting.

          "main: no suitable decoder module for fourcc `IV50'. VLC probably does not support this sound or video format."

        • Interesting. So (speaking as a physics illiterate), what is it that's not being modelled by impulse-constraint engines? Compression?

          I've seen this in movie CGI as well as games, so it can't be just down to realtime computational constraints. Most recently in Serenity (the docking clamp on Beaumonde and the final crash sequence both made the ship look far too light).
          • Most recently in Serenity (the docking clamp on Beaumonde and the final crash sequence both made the ship look far too light.)

            Yes, and you can also see a helicopter bounce badly in Charley's Angels.

            Interesting. So (speaking as a physics illiterate), what is it that's not being modelled by impulse-constraint engines? Compression?

            Yes. If you do strict rigid-body physics, bounces take zero time. That's not realistic. There's always some compression. To look right, some compression needs to be simu

            • Couldn't you just hack in the deformation by adding a slight time delay to the bounce? Kind of an 'on contact, wait so-many-ticks-dependant-on-object, then resume bounce' with a different delay per object. I know it doesn't simulate reality per-se, but it seems that it would a computationaly-cheap hack to enhance realism. Or is something like that too obviously not real?
  • Valve licensed a Popular physics engine [ign.com] right off the shelf. Many companies do write their own Physics engine from scratch, but Valve didn't, so I find it funny they talked about this, shouldn't Havok have spoken instead?
    • Read you own link, it says Havok worked with Valve for 3 years to bring about Havok 2. Kind of similar to how Half-Life's engine was built off a licensed Quake engine, no?
      • It's not the Havok physics engine itself that made HL2 stand above the rest. In fact, a dozen more companies license this ridiculously expensive engine. However, it is how they utilize the engine that made them stand out. Many games limit the implementation of the physics engine to how the character will jump, how will the grenade fly, how will the particles of an explosion go and how will the car fly when an explosive is placed under it - of course there are more areas but they are generally limited. HL2
      • Being part of the testing process of Physics engine someone else is making is not the same as creating one... sorry.
  • I loved the physics in HL2. My favorite part of the game was shooting down this flying thing (I don't think it was a helicoptor) in the middle of a mud flat. I fired off the last shoot to put the thing out of commission right above me and I enjoyed the moment of a victory of seeing it come back down. Until I realized that the damn thing was going to crash on me! Fortunately, I was able to get out of the way. That was a fine moment when I realized I nearly lost the game because I was rubbernecking the kill.
  • # 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.

    These remind me of a map I made years ago for the HL1 community project called 'The Spirit of Half-Life'. The map had a number of different 'sport' type activities, including a basketball and skeetshooting games using snarks. Heck I even made it keep score correctly...Ahhh those were the days...

  • I'm trying to construct a Rube Goldberg device (see http://www.rubegoldberg.com/html/gallery.htm [rubegoldberg.com]) in Hammer, which is Half-Life's level designer, but I'm running into one major problem. The HL2 physics engine does whatever the heck it wants! I'll load up a map, and the entire device will work fine, but then I'll load up the SAME map again and, for example, all the dominoes will immediately fall over, as though hit by a sudden gust of wind! Even more oddly, objects affected by a trigger will respond varia
  • My only complaints about half life 2 are the total time spent playing, and the forced puzzel solving. There was one point in the game where I was not allowed to progress due to an invisible wall until I solved the puzzel the "proper" way (as in blow up a storage bin and race up a ramp, vs jumping over the baricades and racing up a ramp.)

    If you're going to have an environment where physics are supposed to play into the game, you shouldn't prevent the level completion with invisable walls. If they get there t
  • "In 1999, world physics was a new technology that hadn't been integrated into the genre before."

    That's odd, given that Trespasser was released in 1998.

    http://en.wikipedia.org/wiki/Trespasser_(game) [wikipedia.org]

    Sadly, about all it was used for was naff box-stacking puzzles, with an interface that made stacking boxes extremely hard.

Slashdot Top Deals

Scientists will study your brain to learn more about your distant cousin, Man.

Close