I've been working on a simple game in JS using canvas, and I've been looping a certain function every 16 milliseconds (1000/60 = 16.67) and it works fine, but I was just wondering why games don't aim for 25/50/100 FPS instead of 30/60/120 since they can divide into 1 (second) without anything left over?
It may be that what I'm doing has nothing to do with FPS, and real games work in a completely different way. If that's the case I would love to be proven wrong and be pointed in the right direction
Thanks
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).
I'm working on this game engine which plays some board game, I implemented minimax with alpha beta pruning, and move ordering. Now when I play with other existing engines, everything looks fine. However, I found two subtle problems which I don't know what causes them, maybe I have some gap in my knowledge.
The first issue:
When I increase the depth of the search, intuitively I should get better results even if consumes more time, but in my case moving from depth 8 (winning) to depth 9 causes me to lose all the time, now if I increase it to 10 I suddenly win again. Keep in mind that I keep everything constant except the depth. At first I thought that maybe its because at depth 9 we find a promising move at first which the opponent can refute it easily, but then this could happen at every depth. So my question is what causes this weird behaviour? Is there an optimal depth, which if we go beyond could backfires?
The second issue:
Its similar to move ordering but done to get the values of the next play to pick what to play. For example:
For every possible move starting from weakest move do:
minimax(move)
Now since we have to go through all possible moves why having the strong moves first wins the game but if I started with the weakest moves loses the game. It doesn't make since we have to evaluate all possible moves anyway. What causes this behaviour?
When I increase the depth of the search, intuitively I should get
better results even if consumes more time, but in my case moving from
depth 8 (winning) to depth 9 causes me to lose all the time, now if I
increase it to 10 I suddenly win again.
Certainly sounds like a bug to me.
For every possible move starting from weakest move do:
minimax(move)
You should always start from the strongest move in order to benefit from alpha-beta pruning
Now since we have to go through all possible moves
What about alpha-beta pruning? You do not have to go through all possible moves.
In a game I've created Negamax works well for low depth searches but larger depth increases causes it to freeze. I thought about changing depth to type 'long' instead of 'integer' but not sure what else I can do. I know computation will take longer so it is possible it is calculating behind the scenes and I'm interpreting as freeze up. Any advice would be appreciated. In the game a player can only make 1 of 3 possible moves in a position and it is not like chess where there are large numbers of moves possible in anyone position and terminal position is difficult to reach.
Thanks
Daz
What counts as larger depth?
Remember that these trees grow exponentially, so if you have 3 options on the first choice, you have 9 when you're 2 deep, 59049 options to check when you're 10 deep, and so on. Another possible reason for things to slow down drastically is if you start using the page file; that is if you're storing your whole tree and suddenly run out of Ram once you get to a "larger" depth. You can probably hear that, or see the blinking hard drive light, if that's contributing.
Your best bet is to get some feedback; get it to print out a new number every x thousand options it checks, so that you can find out instead of guessing at whether it's still trying and how far it has to go. Once you know what it's doing and assuming it is just munching through, look into something like alpha-beta pruning to prevent the tree from growing as quickly.
I'm developing a game, as a tutorial, learning experience
Specs summary:
imagine something like icehockey, but with static obstacles on the field ( thumbtacks ).
turn based, each players shoots by dragging ball and applying linear impulse on opposite direction
all of this is MULTI-PLAYER
Basically, after you shoot, you tell the other player's app that it must apply "this" force to the ball. Considering it's the same engine, I imagined I would get the same result on both devices, therefore the only communication will envolve sending the force params when the time is right. This is correct AS LONG AS THEY HAVE THE SAME RESOLUTION. If I shoot a straight line, no obstacles, then everything seems fine ( I can't really see if there's a very small offset ), but with obstacles, collision etc. the motion is not the same ( not the same trajectory ) on different resolutions ( devices )
I need to know if there is some way I can make this work the same on all devices. I need to find a way so I can replicate in minute detail a movement ( complex, not straight line ) on different screen/resolution.
Some technical details:
I'm using the letterbox scale
1200w 800h resolution ( don't really know why I chose this :) ... it seems really dumb now ... but you get the picture, I'm using basically a resolution bigger than most of the devices I test on )
physics.setScale( 100 ) = this seemed important on some point.
PS: This is meant to be a tutorial; I'm aware that I can send the trajectory lines then compose the movement OR find another way to replicate the motion, but I need to understand EXACTLY this issue, since I'll have to confront it in future games.
I'm not sure if it works but you can try this:
( forceVariable / 1200 ) * display.contentWidth
( Assuming, your width is still 1200 px
It worked with images for me
I have a moving mars lander which I want to detect when it hits the top of a refuelling station in a game I'm making. I want to know the best way to know exactly when they hit.
What I am doing at the moment is I have 3 timers controlling horizontal, vertical and gravitational movement. Each timer makes the mars lander move a bit so I put the crash detection code at the top and bottom of each of these but since each one is fireing every 50 milliseconds a) it wont detect exactly when it collides and b) it will call the crash detection code a lot of times.
This is what one of the timers looks like and its pretty much the same for all 3 (I am making the game in vb 2008, this is just some pseudo-code):
gravity timer:
detectCrash()
Move ship
detectCrash()
End timer
what would be a more accurate way to see if they are colliding in terms of response time from the collide to the code which that calls.
how would I call the detection a lower amount of times?
I could possibly make another timer that fires every 10 milliseconds or so and check the collision but then this will run the code an awful lot of times (100 times a second) wont it?
I am also curious as to how large games would handle something like this which most likely happens many times a second.
Thanks.
One thing you could do is just use one timer to control all movement at 16 or 17 milliseconds (roughly 60 fps), but even that may be too fast, you should be fine with maybe 40 milliseconds (25 fps). In this timer event, calculate the new position of your object before moving, see if there is going to be a collision on the new position, and if not move the object.
At least that is how I would do it in vb.net. I would probably go with XNA however.
You don't want to have separate timers for moving the object and for detecting collisions. This approach has a couple of obvious problems:
It doesn't scale at all; imagine adding more objects. Would you have two timers for each (one each for the X and Y planes)? Would you add yet another timer to detect collisions for each object?
It's possible for the timers to get out of sync - imagine your code for moving your ship in the X plane takes much longer to run than the code for the Y plane. Suddenly your ship is moving vertically more often than it's moving horizontally.
'Real' games have a single loop, which eliminates most of your problems. In pseudo-code:
Check for user input
Work out new X and Y position of ship
Check for collisions
Draw result on screen
Goto 1
Obviously, there's more to it than that for anything more than a simple game! But this is the approach you want, rather than trying to have separate loops for everything you've got going on.