Full Force Physics (No Simply Following Ground, etc)
One day I hope to go into programming physics engines (right now I am only a high school senior getting ready to go to college as a physics major). I''m curious though as to the extent physics is used in games so far.
It seems that generally the physics engine is kept out of many of the everyday interactions that are due to physics in the first place. For example, when you walk down a slope you do not simply "follow" the ground. Instead, you lift your foot up and move itforward, then gravity pulls it down.
Do any games right now actually use gravity to pull down objects constantly, and then use the ground to apply a normal force?
I know that this sounds pretty wasteful, but it seems like it could be a good step to coming up with more realistic looking games by having everything interacting correctly. For example, it always looks a little odd to see a character running down a hill with as much strength in its step as when the ground is flat, yet not slightly jumping off the hill with each step. Beyond that, actually taking into account the normal force off the ground allows realistic modeling of the effect of torque on an objects rotation instead of gross approximations.
So, is this possible today? Has anyone doing it? Am I the only one who thinks full physics simulation would be useful/benificial?
I don''t really know how this issue is implemented in these-days-games, but actually I have finished the physics part for our game engine and it does work like you stated.
All moving objects are affected by gravity, and the only way to move them is to apply a force on them. This way a character walking down a hill will be faster than a character trying to climb this hill up.
But no, there is no rotation of objects implemented (yet). Maybe this will be done in the future... (when all other is running smooth)
All moving objects are affected by gravity, and the only way to move them is to apply a force on them. This way a character walking down a hill will be faster than a character trying to climb this hill up.
But no, there is no rotation of objects implemented (yet). Maybe this will be done in the future... (when all other is running smooth)
it''s not done to the extent you described. It''s rigid bodies usually. which means, the character is taken as a whole. The gravity pulls everything down, and the character animated idnependently (well, sort off, he he is falling, the animation changes to a falling animation, ect...).
If you switch back to ragdolls when the character dies, then each limbs are physically different bodies, and the character (hopefully) falls to the ground realistically), and it''s more what you are looking for. And as you must know, ragdolls are expensive to process due to that. It''s a lot more work on the CPU to get the physical interactions between limbs, and limbs and the environment, than to do a simple rigid box around the whole player.
Also, there are complications if you try to integrate physics into the animation. The animations are done by artists, and they are pretty much set in stone. It''s forward kinematics (play an anim regardless of the environment around).
Games that try to push the envelope in animations use inverse kinematics. So when on a slope, the foot lands exactly on where the floor is, and the foot can follow the slope of the terrain as well. The knees bend at the right angle, the hips rotate, the body arches, the shoulders drop, ect...
Mechwarrior does this, but it''s also quite expensive. Hitman use a mix of ragdolls and set animations to flinch the characters when they get hit by bullets, but that''s about it.
But for a beat them up, like Tekken or Virtual fighters, it''s quite possible to push the physics a lot further towards the realism you describes, since there are only two characters to process. Then it''s a start, when you can do 2 characters, then you can possibly do 10, then 20, then 100....
For a more complex game, like say, Prince of persia, you can do some pretty advance physics on the controlled character. I''m not sure if Prince Of persia does this kind of stuff, though.
If you switch back to ragdolls when the character dies, then each limbs are physically different bodies, and the character (hopefully) falls to the ground realistically), and it''s more what you are looking for. And as you must know, ragdolls are expensive to process due to that. It''s a lot more work on the CPU to get the physical interactions between limbs, and limbs and the environment, than to do a simple rigid box around the whole player.
Also, there are complications if you try to integrate physics into the animation. The animations are done by artists, and they are pretty much set in stone. It''s forward kinematics (play an anim regardless of the environment around).
Games that try to push the envelope in animations use inverse kinematics. So when on a slope, the foot lands exactly on where the floor is, and the foot can follow the slope of the terrain as well. The knees bend at the right angle, the hips rotate, the body arches, the shoulders drop, ect...
Mechwarrior does this, but it''s also quite expensive. Hitman use a mix of ragdolls and set animations to flinch the characters when they get hit by bullets, but that''s about it.
But for a beat them up, like Tekken or Virtual fighters, it''s quite possible to push the physics a lot further towards the realism you describes, since there are only two characters to process. Then it''s a start, when you can do 2 characters, then you can possibly do 10, then 20, then 100....
For a more complex game, like say, Prince of persia, you can do some pretty advance physics on the controlled character. I''m not sure if Prince Of persia does this kind of stuff, though.
It seems that physics is a good place to look for taking games to the next level. Our graphics abilities allow us to make very jaw dropping stills, but when they are animated the results are not always as impressive. A lot of time things just don''t look right.
The one item that really made 3D rendering possible without taxing the CPU was the graphics card. I think it would be really interesting to see something along the lines of a physics card so that you could run hardware assisted physics.
I guess it would only be useful to gamers though, unless the hardware was highly accurate and could be used in the scientific and commercial community.
The one item that really made 3D rendering possible without taxing the CPU was the graphics card. I think it would be really interesting to see something along the lines of a physics card so that you could run hardware assisted physics.
I guess it would only be useful to gamers though, unless the hardware was highly accurate and could be used in the scientific and commercial community.
I was just thinking about Homeworld (a game), Homeworld: Cataclysm (a expansion/stand-alone game), and Homeworld 2 (yet another game). I was thinking about how they ruined Homeworld 2 by allowing everyone to kick everyone else in online games (It really sucks!). So I considered whiping out one of the older versions of the game, and quickly ruled out Cataclysm because - like so many other expansions - it''s just not as good. I decided I liked the original Homewrold best.
Now before you delete this post for being off topc there admin...
The reason I decided I liked Homeworld (original) better was because, the gameplay is just as good as it is in HW2 (and without kicking problems), and it has great physics.
I think this series contrasts perfectly the different ways to use physics.
(You need to know Homeworld is a RTS that takes place in space.)
Homeworld - The pysics in this game seemed to be the basis of the game and not even the AI could escape them. This was evident in massive fighter battles where you would have 50 vs 50 fighters swarming and they would occasionally crash into each other and both would blow up. they would also at times bump into larger ships they were fighting, the fighter would blow up, and damage the bigger ship a appropriate amount (yes, there was a kamakazi command in the game). It really sucked when you had several large capital ships in close proximity and they would bump and kill each other, particularly when your own fleet was so tighly cramped the AI couldn''t figure out where to go. You could also be crusing though a astroid beld and have a ship go up in flames because it scraped half its hull off on a near by rock. It even went as far as to allow gravity wells (a unit you could build) to attract stuff around it. One strategy (that rarely worked, but could) involved cloaking a gravity well and placing it in the enemies base then they would soon have to deal with astroids moving through the middle of their operation. It was a great game with great physics.
Homeworld: Cataclysm - Similar to Homeworld in many aspects. Ruined much of the fun because a stupid fighter bumping into a capital ship would just bounce off. Your ships would never be destroyed by touching another ship, either friend or foe. (Failed to mention there was explosion damage in Homeworld.) They also removed explosive damage, so you would see the tiniest scout survive a point-blank explosion that lit up half the map.
Homeworld 2 - Same flaws as Cataclysm, although better game play (except kick issues). Adding to the problem the AI control of the ships seems to be able to stop a ship in the what would be about a milimeter if it were real life. So instead of bouncing off a ship it just stops and turns on a dime right before it hits, much better.
Physics made the first one the most fun, mainly because they were a core part of the game, not just a novelty.
I would like to see more games like it.
Now before you delete this post for being off topc there admin...
The reason I decided I liked Homeworld (original) better was because, the gameplay is just as good as it is in HW2 (and without kicking problems), and it has great physics.
I think this series contrasts perfectly the different ways to use physics.
(You need to know Homeworld is a RTS that takes place in space.)
Homeworld - The pysics in this game seemed to be the basis of the game and not even the AI could escape them. This was evident in massive fighter battles where you would have 50 vs 50 fighters swarming and they would occasionally crash into each other and both would blow up. they would also at times bump into larger ships they were fighting, the fighter would blow up, and damage the bigger ship a appropriate amount (yes, there was a kamakazi command in the game). It really sucked when you had several large capital ships in close proximity and they would bump and kill each other, particularly when your own fleet was so tighly cramped the AI couldn''t figure out where to go. You could also be crusing though a astroid beld and have a ship go up in flames because it scraped half its hull off on a near by rock. It even went as far as to allow gravity wells (a unit you could build) to attract stuff around it. One strategy (that rarely worked, but could) involved cloaking a gravity well and placing it in the enemies base then they would soon have to deal with astroids moving through the middle of their operation. It was a great game with great physics.
Homeworld: Cataclysm - Similar to Homeworld in many aspects. Ruined much of the fun because a stupid fighter bumping into a capital ship would just bounce off. Your ships would never be destroyed by touching another ship, either friend or foe. (Failed to mention there was explosion damage in Homeworld.) They also removed explosive damage, so you would see the tiniest scout survive a point-blank explosion that lit up half the map.
Homeworld 2 - Same flaws as Cataclysm, although better game play (except kick issues). Adding to the problem the AI control of the ships seems to be able to stop a ship in the what would be about a milimeter if it were real life. So instead of bouncing off a ship it just stops and turns on a dime right before it hits, much better.
Physics made the first one the most fun, mainly because they were a core part of the game, not just a novelty.
I would like to see more games like it.
One problem with adding advanced physics to a game (i.e. making huge numbers of objects interactive etc) is that every target platform needs to be able to run the physics simulation at the same level. With flash graphics, you can just turn the eye-candy down and it doesn't really change the game much (though maybe that's not so true with games where you hide in foliage... which seem to be getting popular). With a racing game where you have to navigate through streets containing cars/debris then changing the physics (either quantity or quality) actually changes the game. Basically, the whole physics for the game is determined by the lowest spec target platform.
Another problem with adding more realistic physics to the game is that it doesn't necessarily make it more fun - in fact it can make it harder to interact with the environment (and consequently less fun). The reason for this is that little quirks of the physical environment (e.g. a slightly sloping floor) can have a significant effect on the physics (e.g. how far you jump), yet it may be totally unreasonable to expect the player to be able to see this. The player's experience will then be that the behaviour has a significant degree of randomness, which isn't good.
Another reason to be careful about constructing a game based heavily on physics is that the artists and designers, in their infinite wisdom (ha!), will want it to conform to THEIR perception of physics, not yours, even though you have the PhD etc! So your pure elegant vehicle physics code will gradually turn into a series of "if (this hack)" and "if (that fudge)" until, at the end of the project, you'll stand back and wonder why the behaviour wasn't done around a series of animation set pieces anyway - at least it would be honest!
Just some thoughts... I really enjoy seeing (and coding!) decent physics in games, but ultimately the emphasis has got to be on making the game enjoyable to play, not just an ego trip for the physics coder
[edited by - MrRowl on March 25, 2004 4:09:18 PM]
Another problem with adding more realistic physics to the game is that it doesn't necessarily make it more fun - in fact it can make it harder to interact with the environment (and consequently less fun). The reason for this is that little quirks of the physical environment (e.g. a slightly sloping floor) can have a significant effect on the physics (e.g. how far you jump), yet it may be totally unreasonable to expect the player to be able to see this. The player's experience will then be that the behaviour has a significant degree of randomness, which isn't good.
Another reason to be careful about constructing a game based heavily on physics is that the artists and designers, in their infinite wisdom (ha!), will want it to conform to THEIR perception of physics, not yours, even though you have the PhD etc! So your pure elegant vehicle physics code will gradually turn into a series of "if (this hack)" and "if (that fudge)" until, at the end of the project, you'll stand back and wonder why the behaviour wasn't done around a series of animation set pieces anyway - at least it would be honest!
Just some thoughts... I really enjoy seeing (and coding!) decent physics in games, but ultimately the emphasis has got to be on making the game enjoyable to play, not just an ego trip for the physics coder
[edited by - MrRowl on March 25, 2004 4:09:18 PM]
The key to figuring out how far to take the physics for your particular game is to figure out likely situations where a better physics engine would actually make the game better OR make programming the game easier.
Example:
I want to have floating platforms in my game. When a player jumps onto the platform, I''d like the platform to react to the impact by dropping suddenly and then floating back up to its resting position.
Platform::onTouch(GameObject toucher) {
// by the time the platform gets this callback,
// the physics engine has already noted the force
// and whatever reaction is done here merely counteracts
// that force.
hoverJet.setForce(Force(0.0f, toucher.mass * toucher.velocity.y));
}
If the jet includes a mechanism that limits the rate of change of power, then the platform can drop simply because its jets take time to produce enough upforce to counteract the extra weight.
Ok, so what if we wanted Donkey Kong to land on the platform and we did not want it to be able to float with him on it. If the jet that was used for this particular platform was given a maximum amount of upforce that it could produce, then without ever changing the platform code, the platform would fall downwards when the maximum jet power was not enough to support it and donkey kong.
Notice that the above code says nothing about the horizontal motion of the player or the effects of torque that the player gives the platform by landing off center. With the above code, if a player landed on the platform with horizontal speed, the platform would start floating horizontally, carrying the player on it. Torque calculations would require the platform to either use two jets, or for a jet to be able to apply torque to whatever object it is attached to.
By using physics to model object behavior instead of hacking the behavior specifically for each object, we have a robust and full featured set of behaviors available for everything!
Example:
I want to have floating platforms in my game. When a player jumps onto the platform, I''d like the platform to react to the impact by dropping suddenly and then floating back up to its resting position.
Platform::onTouch(GameObject toucher) {
// by the time the platform gets this callback,
// the physics engine has already noted the force
// and whatever reaction is done here merely counteracts
// that force.
hoverJet.setForce(Force(0.0f, toucher.mass * toucher.velocity.y));
}
If the jet includes a mechanism that limits the rate of change of power, then the platform can drop simply because its jets take time to produce enough upforce to counteract the extra weight.
Ok, so what if we wanted Donkey Kong to land on the platform and we did not want it to be able to float with him on it. If the jet that was used for this particular platform was given a maximum amount of upforce that it could produce, then without ever changing the platform code, the platform would fall downwards when the maximum jet power was not enough to support it and donkey kong.
Notice that the above code says nothing about the horizontal motion of the player or the effects of torque that the player gives the platform by landing off center. With the above code, if a player landed on the platform with horizontal speed, the platform would start floating horizontally, carrying the player on it. Torque calculations would require the platform to either use two jets, or for a jet to be able to apply torque to whatever object it is attached to.
By using physics to model object behavior instead of hacking the behavior specifically for each object, we have a robust and full featured set of behaviors available for everything!
quote:Original post by MrRowl
One problem with adding advanced physics to a game (i.e. making huge numbers of objects interactive etc) is that every target platform needs to be able to run the physics simulation at the same level. With flash graphics, you can just turn the eye-candy down and it doesn't really change the game much (though maybe that's not so true with games where you hide in foliage... which seem to be getting popular). With a racing game where you have to navigate through streets containing cars/debris then changing the physics (either quantity or quality) actually changes the game. Basically, the whole physics for the game is determined by the lowest spec target platform.
Another problem with adding more realistic physics to the game is that it doesn't necessarily make it more fun - in fact it can make it harder to interact with the environment (and consequently less fun). The reason for this is that little quirks of the physical environment (e.g. a slightly sloping floor) can have a significant effect on the physics (e.g. how far you jump), yet it may be totally unreasonable to expect the player to be able to see this. The player's experience will then be that the behaviour has a significant degree of randomness, which isn't good.
Another reason to be careful about constructing a game based heavily on physics is that the artists and designers, in their infinite wisdom (ha!), will want it to conform to THEIR perception of physics, not yours, even though you have the PhD etc! So your pure elegant vehicle physics code will gradually turn into a series of "if (this hack)" and "if (that fudge)" until, at the end of the project, you'll stand back and wonder why the behaviour wasn't done around a series of animation set pieces anyway - at least it would be honest!
Just some thoughts... I really enjoy seeing (and coding!) decent physics in games, but ultimately the emphasis has got to be on making the game enjoyable to play, not just an ego trip for the physics coder
[edited by - MrRowl on March 25, 2004 4:09:18 PM]
Well said.
My only arguement would be sience were talking more about theory we could be talking about a time in the futer where everyones monitor has such a high resolution, frame rate, processing power, that such things will become irelevent considerations.
Wouldn't it be awsome to see game with physics on the molecular level. :o Although it would take 25 years to develop, but once completed it would never go out of date. One day when we have frame rates of like 10000 fps with a 1000000 X 1000000 resolutions graphic upgrades will be a think of the past; a eye upgrade my help though. (Although there are people that will boast "I bough a new card and went from 300 FPS to 500 FPS" just like their are now. All I say is "WOW, your eye can only perceive about 100 FPS though, but good job!")
[edited by - Cyber-Ace on March 26, 2004 4:23:13 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement