I'm making a soccer simulation game and for that I'm using normal 2DBody nodes for the players and ball. But I would like to be able to speed up the game, without breaking the physics and getting other results.
To speed up the game I found Engine.time_scale and Engine.iterations_per_second that affect the game speed.
So default values for timescale = 1 and for iterations_per_second = 60
By just setting time_scale = 0.5, physics seem to break. At least I can see, that it looks less natural than on normal speed.
When fasting up by setting time_scale = 0.5 and iterations per second = 120,
so physics don't seem to break.
But I can't really tell if this is 100% true. (Also 99% would be okay ;-) )
So does somebody know another way to speed up the game without breaking physics or can confirm, that modified time_scale and iterations per second don't break physics?
First of all, Godot documentation says:
float time_scale - Controls how fast or slow the in-game clock ticks versus the real life one. It defaults to 1.0. A value of 2.0 means the game moves twice as fast as real life, whilst a value of 0.5 means the game moves at half the regular speed.
So if you want to speed up the game time you should increase that value, not decrease. As far as I understand this value will influence how much time delta is passed to _physics_process(delta) methods (and other engines internal physics calculations), and time_scale works as a multiplayer for that value.
Physics engine runs with a fixed time step, so iterations_per_second will influence it as documentation mentions:
int iterations_per_second - The number of fixed iterations per second (for fixed process and physics).
Yes, modifying both values should give better results, because increasing iterations_per_second makes calculations of physics more frequent and that means more precise (let's call it "time detailing"). Could it still "break physics"? Yes, if physics calculations won't be fast enough to keep up with engine iteration frequency. In that case the only solution will be to optimize your game.
Related
For some time now, I've been thinking about how games calculate physics. Take as an example the game TrackMania. There are special routes where you only have to accelerate from the beginning to get to the finish. As an example, I take the following YouTube video (https://www.youtube.com/watch?v=uK7Y7zyP_SY). Unfortunately, I'm not a specialist in game development, but I know roughly how an engine works.
Most engines use a game loop, which means they use the delta value between the last call and the current call. This delta value is used to move objects, detect collisions and so on. The higher the delta value, the farther the object must have moved. The principle works fine with many games, but not with TrackMania.
A PC that can only display 25 FPS would calculate the physics differently than a PC with 120 FPS, because the collision detection is more accurate (impact is detected earlier, speed adjusted accordingly, ...). Now you can assume that the delta value is always the same (as with Super Mario Maker, at least that's my assumption), then this would work. But that would cause problems similar to old games (https://superuser.com/questions/630769/why-do-some-old-games-run-much-to-quickly-on-modern-hardware/).
Now my question, why do such maps work on every PC and why is the physics always exactly the same? Did I miss any aspect of game development / engine development?
The answer is simple, first the physic of the game is predictable, based on the input the result will always be the same.
Then the physic loop is not the same as the render, the game ensure the physic loop will be call with exactly the same period every time during the whole execution. So, yes a delta is needed for the render part, but the physic as a constant time in ms between each iteration.
One last think : you wont find "Press Forward" maps on the multiplayer, these kind of maps will not work correctly, this is directly linked to specificities in the physic to avoid TAS (Tool Assisted Speedrun).
hi i am developing my new game it is like infinite runner. I am using object pooling for instantiate objects. i have lots of character with animation and rag doll.
Physics are very big on my iPad 3 profiler. when i destroy characters everything is good working. Characters have animator,rag doll and simple waypoint.
How can i optimize that ?
Okay, first take into account the maximum number of characters on screen. As far as I can see you also wish to optimize this as much as possible, so I have a few tips.
First thing I would do is look at the triangl er count and get it as low as possible for each model without sacrificing the aesthetics.
Next I would set up an LOD system where as an object moves further away the detail decreases saving triangles. You should repeat tgis with textures animation and some of the ragdolls.
Once that is done. Look at the more expensive functions called in your code and see if you can make an alternative. Like you have done with object pooling.
Good luck.
You can do some things to improved your physic calculation time spent.
1.- The most important is avoid to use MeshCollider, this is much higher performance overhead. Use primitive colliders ever you can or combine few primitives.
2.- Adjust Fixed TimeSteep setting. You can reduce overhead reducing physic accuracy.
I'm writing an application for iphone4 and I'm taking values from the accelerometer to compute the current movement from a known initial position.
I've noticed a very strange behavior: often times when I walk holding the cellphone for a few meters and then I stop, I register a negative peak of overall velocity when the handset decelarates. How is that possible if I keep moving in the same direction?
To compute the variation in velocity I just do this:
delta_v = (acc_previous + acc_now)/2 * (1/(updating_frequency))
Say you are moving at a constant 10 m/s. Your acceleration is zero. Let's say, for the sake of simplicity, you sample every 1 second.
If you decelerate smoothly over a period of 0.1 seconds, you might get a reading of 100 m/s/s or you might not get a reading at all since the deceleration might fall between two windows. Your formula most likely will not detect any deceleration or if it does, you'll get two values of -50 m/s/s: (0 - 100) / 2 and then (-100 + 0) / 2. Either way you'll get the wrong final velocity.
Something similar could happen at almost any scale, All you need is a short period of high acceleration or deceleration that you happen to sample and your figures are screwed.
Numerical integration is hard. Naive numerical integration of a noisy signal will essentially always produce significant errors and drift (like what you're seeing). People have come up with all sorts of clever ways to deal with this problem, most of which require having some source of reference information other than the accelerometer (think of a Wii controller, which has not only an accelerometer, but also the thingy on top of the TV).
Note that any MEMS accelerometer is necessarily limited to reporting only a certain band of accelerations; if acceleration goes outside of that band, then you will absolutely get significant drift unless you have some way to compensate for it. On top of that, there is the fact that the acceleration is reported as a discrete quantity, so there is necessarily some approximation error as well as noise even if you do not go outside of the window. When you add all of those factors together, some amount of drift is inevitable.
Well if you move any object in one direction, there's a force involved which accelerates the object.
To make the object come to a halt again, the same force is needed in the exact opposite direction - or to be more precise, the vector of the acceleration event that happened before needs to be multiplied with -1. That's your negative peak.
Not strictly a programming answer, but then again, your question is not strictly a programming question :)
If it's going a thousand miles per hour, its acceleration is 0. If it's speeding, the acceleration is positive. If it's slowing down, the acceleration is negative.
You can use the absolute number of the velocity to invert any negative acceleration, if that's needed:
fabs(delta_v); // use abs for ints
I am trying to write a simple game, but I'm stuck on what I think is simple physics. I have an object that at point 0,0,0 and is travelling at say 1 unit per second. If I give an instruction, that the object must turn 15 degrees per second , for 6 seconds (so it ends up 90 degrees right of it's starting position), and accelerate at 1 unit per second for 4 seconds (so it's final speed is 5 units per second), how do I calculate it's end point?
I think I know how to answer this for an object that isn't accelerating, because it's just a circle. In the example above, I know that the circumference of the circle is 4 * distance (because it is traversing 1/4 of a circle), and from that I can calculate the radius and angles and use simple trig to solve the answer.
However, because at any given moment in time the object is travelling slightly faster than it was in the previous moment, my end result wouldn't be a circle, it would be some sort of arc. I suppose I could estimate the end point by looping through each step (say 60 steps per second), but this sounds error prone and inefficient.
Could anybody point me in the right direction?
Your notion of stepping through is exactly what you do.
Almost all games operate under what's known as a "game tick". There are actually a number of different ticks that could be going on.
"Game tick" - each game tick, a set of requests are fired, AI is re-evaluated, and overall the game state has changed.
"physics tick" - each physics tick, each physical object is subject to a state change based on its current physical state.
"graphics tick" - also known as a rendering loop, this is simply drawing the game state to the screen.
The game tick and physics tick often, but do not need to, coincide with each other. You could have a physics tick that moves objects at their current speed along their current movement vector, and also applied gravity to it if necessary (altering its speed,) while adding additional acceleration (perhaps via rocket boosters?) in a completely separate loop. With proper multi-threading care, it would fit together nicely. The more de-coupled they are, the easier it will be to swap them out with better implementations later anyway.
Simulating via a time-step is how almost all physics are done in real-time gaming. I even used to do thermal modeling for the department of defense, and that's how we did our physics modelling there too (we just got to use bigger computers :-) )
Also, this allows you to implement complex rotations in your physics engine. The less special cases you have in your physics engine, the less things will break.
What you're asking is actually a Mathematical Rate of change question. Every object that is in motion has position locations of (x,y,z). If you are able to break down the component velocity and accelerations into their individual planes, your final end point would be (x1, y1, z1) which is the respective outcome of your equations in that plane.
Hope it helps (:
In a soccer game, I am computing a steering force using steering behaviors. This part is ok.
However, I am looking for the best way to implement simple 2d human locomotion.
For instance, the players should not "steer" (or simply add acceleration computed from steering force) to its current velocity when the cos(angle) between the steering force and the current velocity or heading vectors is lower than 0.5 because it looks as if the player is a vehicule. A human, when there is an important change of direction, slows down and when it has slowed enough, it starts accelerating in the new direction.
Does anyone have any advice, ideas on how to achieve this behavior? Thanks in advance.
Make it change direction very quickly but without perfect friction. EG super mario
Edit: but feet should not slide - use procedural animation for feet
This is already researched and developed in an initiative called "Robocup". They have a simulation 2D league that should be really similar to what you are trying to accomplish.
Here's a link that should point you to the right direction:
http://wiki.robocup.org/wiki/Main_Page
Maybe you could compute the curvature. If the curvature value is to big, the speed slows down.
http://en.wikipedia.org/wiki/Curvature
At low speed a human can turn on a dime. At high speed only very slight turns require no slowing. The speed and radius of the turn are thus strongly correlated.
How much a human slows down when aiming toward a target is actually a judgment call, not an automatic computation. One human might come to almost a complete stop, turn sharply, and run directly toward the target. Another human might slow only a little and make a wide curving arc—even if this increases the total length to the target. The only caveat is that if the desired target is inside the radius of the curve at the current speed, the only reasonable path is to slow since it would take a wide loop far from the target in order to reach it (rather than circling it endlessly).
Here's how I would go about doing it. I apologize for the Imperial units if you prefer metric.
The fastest human ever recorded traveled just under 28 mph. Each of your human units should be given a personal top speed between 1 and 28 mph.
Create a 29-element table of the maximum acceleration and deceleration rates of a human traveling at each whole mph in a straight line. It doesn't have to be exact--just approximate accel and decel values for each value. Create fast, medium, slow versions of the 29-element table and assign each human to one of these tables. The table chosen may be mapped to the unit's top speed, so a unit with a max of 10mph would be a slow accelerator.
Create a 29-element table of the sharpest radius a human can turn at that mph (0-28).
Now, when animating each human unit, if you have target information and must choose an acceleration from that, the task is harder. If instead you just have a force vector, it is easier. Let's start with the force vector.
If the force vector's net acceleration and resultant angle would exceed the limit of the unit's ability, restrict the unit's new vector to the maximum angle allowed, and also decelerate the unit at its maximum rate for its current linear speed.
During the next clock tick, being slower, it will be able to turn more sharply.
If the force vector can be entirely accommodated, but the unit is traveling slower than its maximum speed for that curvature, apply the maximum acceleration the unit has at that speed.
I know the details are going to be quite difficult, but I think this is a good start.
For the pathing version where you have a target and need to choose a force to apply, the problem is a bit different, and even harder. I'm out of ideas for now--but suffice it to say that, given the example condition of the human already running away from the target at top stpeed, there will be a best-time path that is between on the one hand, slowing enough while turning to complete a perfect arc to the target, and on the other hand stopping completely, rotating completely and running straight to the target.