Live data from Hacker News

Doing Game Gravity Right

niksula.hut.fi

51–60 of 86 posts

Re: Doing Game Gravity Right

#51
post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

Correct me if I'm wrong, there is no reason to numerically integrate this. This is not a differential equation. The integral solution is a simple function that can just be evaluated.

remember this is a game. gravity is only one of the forces present.

Re: Doing Game Gravity Right

#52
post #21

Earlier quoted context omitted.

If the game is so bogged down that the fixed timestep cycle is slowing down the game is broken for so many other reasons. Objects will start tunneling through other objects.

Changing the discussion from conceptual to technical making assumptions in the latter just to win an argument. I like that.

No I am just being realistic as an actual game developer. This is not a conceptual discussion. It doesn't make any sense to implement this change because if your fixed timestep for the physics system is breaking down then gravity not calculating correctly is the least of your problems. The controls would be unresponsive if the dt became large anyway. You are talking about more than doubling the number of operations for all acceleration based movement which is just about every movement and applied force in the game. If you thought the framerate was hurting before because too many objects were on screen doubling the physics calculations is not going to help you out. It might not hurt that bad but it really depends, you would need to profile it. It doesn't matter though because the tunneling would be another bigger issue that you would also have to address for this to even matter, and that would definitely hurt bad to check for.

During the far majority of use cases the timestep is fine, and you are just creating deadweight by doing this. Plus I guess you are now doing tunneling checks as well to create further deadweight for the rare occasion when someone has framerate issues.

I am looking at this in the sense that I would actually implement this in a game I make, and I would not because the upside of doing this is basically "if the game is already fucked I want it to be maybe not as fucked but still having many other big issues with pretty much every other component of the game logic", vs a bunch of deadweight when the game is running correctly, which should be 99.5% of use cases.

Am I adding assumptions here? I guess so but they are real ones for real game developers. Unless you are doing something very unusual these would be your concerns.

This is not an academic exercise for me like it maybe is for you and most of the commenters it seems like.

Re: Doing Game Gravity Right

#53
post #4

Why does this even matter? If you have a large delta time then your game is fucked anyway. Collision detection will likely also be broken and the game is unplayably choppy anyway so it doesn't even matter.

I remember a car trick (do a barrel roll) in GTA San Andreas that for the life of me I could not accomplish. I found out that this variable physics was likely the problem - I dropped the graphics settings to minimum, and I was able to do the trick. This is on a quad core, 8GB ram, 1GB video card machine - it's no slouch - but the subtle difference was enough to make my task impossible.

Is this worth making the whole game run slower all the time for everyone? That is what you are talking about here.

Re: Doing Game Gravity Right

#54
post #20

Udacity has a course, "Differential Equations in Action", that's about numerical solutions of equations of motion and other differential equations from physics, biology, and so on. http://www.udacity.com/overview/Course/cs222/CourseRev/1

I'm between doing that course or doing this one: http://ocw.mit.edu/courses/mathematics/18-03sc-differential-... Anyone has any insight into the strenghts and weaknesses of each one? I've been unable to find any comprehensive review online about them. I don't have time to do both simultaneously, but can do one first and the other later or alternate between them. I don't have a strong calculus background though I'm ab…

The Python necessary for the Udacity one is a bit of a pig if you've never coded in Python before. They help out a lot by essentially presenting complete programmes with you needing only to fill out some extra calculations, so you can concentrate on the important bit, but nonetheless if you're used to being able to identify the type of an object by looking at its creation point it's a bit of a mystery to begin with, especially since the first module uses 2D arrays to represent location and velocity - there are some handy Python functions to turn them into distances/vectors from various points, but if you're not familiar with them you'll spend too much time wrestling with Python instead of thinking about the DEs.

There's also the occasional big gap here and there between the video lecture and what you're expected to do (indeed, sometimes it's actually quite tricky to just work out what you're expected to do, despite the helpful comments in the code - I've found that the hardest aspect is not solving the problem, but getting a clear picture of the question being asked and translating the solution into python). For language reference, I am an experienced coder in C and C-related languages (C++ and non-Cocoa Obj-C).

Still, it's early days and I expect these things will be ironed out over time.

Re: Doing Game Gravity Right

#55

This same thing is used in molecular dynamics simulations. For instance, there is an algorithm called RESPA that is used to break integrations of different types of particle interactions into appropriate timestep intervals. Bond vibrations must be calculated much more frequently than non-bonded interactions. The algorithm (reversible RESPA) is formally derived from the Liouville operator (which governs the time evolu…

This was also colloquially known as the "leapfrog" algorithm and is the simplest of a class of integrators that are symmetric (in simulation time) and symplectic which are crucial properties for some simulations. I take it that RESPA is the partitioning of the time evolution operator into components with different force gradients, and the application of different integration schemes to those components. One can also generalise leapfrog to integrate the momentum (or some part) with n steps of dt/n.

The metric used to describe their accuracy is the degree to which they violate the conservation of energy, which can be shown to be an odd integral power of the timestep dt per step [0]. The error in leapfrog goes like the 3rd power.

Higher order integration schemes can be derived e.g. [1]. They may not be useful in practice, depending on the cost of computing the individual terms and the accumulation of finite precision errors. But the known scaling behaviour provides a nice way of verifying the calculation of the evolution operators. Another nice thing to do is to compute the "round trip", i.e. integrate forwards in time, and then backwards. With a symmetric integrator you should end up where you started in terms of position, momentum and energy, regardless of step size, so computing a suitable difference and seeing how it scales with trajectory length can be informative. (e.g. one can compute a Lyapunov exponent from such round-trips to see if the underlying dynamics are chaotic).

[0] McLachlan and Atela, Nonlinearity 5 (1992) http://www.massey.ac.nz/~rmclachl/si.ps (PS) [1] M. Creutz, A. Gocksch; Phys. Rev. Lett. 63 (1989) http://thy.phy.bnl.gov/~creutz/mypubs/pub106.pdf (PDF)

Re: Doing Game Gravity Right

#56

you are still doing it wrong. dt should not be affected by framerate. http://gafferongames.com/game-physics/fix-your-timestep/ use an accumulator to have a fixed dt no matter the framerate. With a variable step size you risk all kinds of weird bugs linked to the hard to debug rendering context. The size of dt should be consider a system parameter, tuned for your game and fixed in concrete .

This problem involves performance, precision, code stability and player perception, so there are no hard and fast rules applicable everywhere, and certainly do not need always to be fixed in concrete. A game can mix variable dt and fixed dt in different subsystems (render, logic, physics, user input, network, ...).

I have even managed to dynamically change these settings and parameters on the fly: which subsystems use which method, the lower and upper limit for variable dt, number of iterations per render frame, and even value to use for fixed dt, all adjusting depending on framerate and state of the game.

A classic example of this is, during a big explosion you may need maximum precision on physics (fixed dt with low value), can afford variable dt on behaviour and interface (since stuff is just blowing up in the air), and can benefit from a low maximum dt that causes a bit of slow-motion (John Woo style!).

When you're doing multiplayer there's a lot less you can afford to change, because you need to keep timing sane and synced across clients & server. Everything depends on the game, the engine, the platform, and the dynamics of what the player is seeing.

Re: Doing Game Gravity Right

#57
post #52

Earlier quoted context omitted.

Changing the discussion from conceptual to technical making assumptions in the latter just to win an argument. I like that.

No I am just being realistic as an actual game developer. This is not a conceptual discussion. It doesn't make any sense to implement this change because if your fixed timestep for the physics system is breaking down then gravity not calculating correctly is the least of your problems. The controls would be unresponsive if the dt became large anyway. You are talking about more than doubling the number of operations f…

> the game is unplayably choppy anyway so it doesn't even matter.

My point originally was about this statement of yours, that is purely conceptual and you skew the discussion to address the other part of your comment (or you through that was the point but didn't explain so in your answers)

But anyway, one assumption is that every game should have a fixed gamestep, in many single player games (real single player games) you don't want to do that, because is preferable that the user can see the ball coming to the player than to magically appear behind the player even if that is "timely correct"; the ball/interface going slow is a lot less frustrating that losing without realizing why. Platformers for PC with (virtual) high speed movements come to mind as a common example of this.

Even multiplayer games suffer of this; in most online FPS if the server suddenly slows down all the players start experiencing lag and everyone looks like they are "teleporting"; with a not-fixed-timestep you could slow everyone down so the problem becomes a lot less frustrating because the player still have complete control and understanding of their in-game character; just a bit slow-mo until the server speeds up to normal. The teleporting should be used only to sync with the server when the client connection is the one with problems updating.

Re: Doing Game Gravity Right

#58

You can cut down the amount of error even further by not iterating. Instead of iteratively updating the height, just store the initial position, velocity and time. You still compute the current position as pi + vi * dt - a * dt * dt/2, but intermediate results are discarded to avoid compounding floating point errors. Of course, you will need to update the initial position/velocity/time whenever the jump is interrupte…

That assumes that there are no other forces. Your solution doesn't handle momentum changes (throwing an object, or taking a bullet, or being close to an explosion) while in the air, and it assumes that there's no maximum or terminal velocity in the game. It also becomes trickier to compute when your objects hit other objects.

You say that "you will need to update the initial [state vector] whenever the jump is interrupted or modified" - that's exactly what numerical integration does. So your solution seems like it would use a closed-form solution for some cases, and numerical integration for others, which would make the dynamics code easily twice as complicated.

While switching from Euler to leapfrog integration is a couple of lines of change, for a better approximation.

Re: Doing Game Gravity Right

#59
post #46
post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

> This is still Euler integration, which has poor accuracy whenever the derivative varies with time. Which is why decoupling the physics delta from the rendering framerate is important. The author mentions Quake (id Tech 1, 2 or 3 ?), and I seem to recall id Tech 4 (Doom 3) was the first id Tech engine that implemented that.

I have a vague recollection that it was fixed or mostly eliminated in Quake 3. It was definitely still an issue in Quake 2, and one relatively well-known cheap trick was leading people towards particularly architecturally dense parts of the map and using a weapon such as the hyper-blaster, which was a high rate of fire laser gun for some unfortunate reason was implemented as a discrete particle/projectile for each shot. This would sometimes slow down the opponent(s) significantly enough to make a difference.

There were also special moves, especially rocket jumps, and double-jumps that were impossible <60fps, and got easier towards 100+ (This being in the days of 200MHz pentiums and software rendering, "Monster 3D 4MB", and intense envy of those who could afford 2x 12MB Voodoo II cards.

Re: Doing Game Gravity Right

#60
post #49
post #39

Can someone explain the jumping parabola graphs? I can't make sense of the description.

X is time, Y is height. So something like, X time after hitting the jump button, the guy is Y above the ground. (Or you can pretend that the guy is moving towards the right at constant speed, and jumping, and the points in the graphs are the different positions he'll be at :) (Edit: I'm not very sure about the pictures to the left though. Maybe higher jumps/longer time or somethingsomething.)

Yeah, I don't get the difference between the left and right sides of the two graphs either.
Post reply on HN