5 ms·

I don't know what kind of CPU bugs or float point behaviour deviations you think modern cpus have that will effect a game.. such things would cause most online

I don't know what kind of CPU bugs or float point behaviour deviations you think modern cpus have that will effect a game.. such things would cause most online games to immediately go out-of-sync, and in practice they don't, and while latency might effect player's enjoyment, it won't effect how fast they run / how high they jump. The hardest part is the curved motions -- and also collision detection. Without ticks it's extremely hard to make collision detection repeatable. I'm unaware of any recent notable multi-player game which don't run on a tick-based physics engine (I'd be interested if you could point me to some) -- that suggests to me that tick-based is necessary. Sure, you can get things "closer" in tickless physics, but I've never seen anything non-trivial which can produce exactly the same results, for reasons of floating point: when (A+B)+C isn't the same as A+(B+C), it's very hard to make your game produce exactly the same results. As you say, with a lot of work, you can get a 95% repeatable result with a tickless engine, but you can easily get 100% repeatable with a fixed time-step engine, and in practice it seems to make things work well enough, and is VASTLY easier.

wareya 10y ago
Online games avoid that problem by having an authoritative networking architecture, not by avoiding minor deviations in CPU behavior between players. Games that use synchronized lockstep that use floating point math always desync, because floating point math differs slightly between different processors. Curved motions are easy as long as you have simple polygons and only one of them is accelerating and is accelerating in a simple way. You remove the acceleration by skewing the polygon you're going to collide with and then you have a linear path of motion again. (if the acceleration is not constant for the duration of that frame, then skewing doesn't give the right result; as long as you have a closed form representation, though, it's entirely possible to get it right) "Don't run on a tick-based physics engine" is a misconception. Interactions are the borders between ticks. It's just dynamic. As long as your tick doesn't contain interaction changes inside it, you can simulate that tick with 100% tickrate independence with 100% certainty. Floating point differences between cpus are Much Larger, especially if your code uses hardware-accelerated trig at all. Games networking is authoritative for this reason. You can get a 100% repeatable result with a tickless engine. Fixed timestep doesn't solve the problem. If the user can't run the simulation at 60 ticks per second, they're still going to slow down, period. All you're doing is separating simulation from rendering, which basically every modern FPS under the sun already tries to do in a different way than fixed timestep does. If you run the simulation slow enough that nobody will have performance problems with it, you just added tons of input latency. Thanks a lot, sincerely, someone with dysgraphia.
- CJefferson 10y ago
  > because floating point math differs slightly between different processors. I don't know why you keep saying this. If I compile a program which uses floating point for (say) x64, it will produce the same results on every machine. Can you give any example where the same executable will produce different results on different machines? Now, you may get different answers on ARM, or 32-bit, but almost no games (I'm having trouble thinking of any) try to do cross-CPU networking, so the (extremely) minor differences doesn't make any difference. Most games don't sync between users, they trust each user to run the game engine -- you can't afford to send the total state of the world to users, it would take far too much network traffic. Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't.
  - wareya 10y ago
    >I don't know why you keep saying this. Because it's true. The same operation on the same data may give different results on different CPUs, even if you're operating at the machine code level (no implementation-specific optimizations). https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ https://randomascii.wordpress.com/2014/10/09/intel-underesti... >Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't. box2d is sufficiently low level that it gives programmers the tools necessary to do this. Most notably, box2d provides the following: >Continuous physics with time of impact solver This directly allows developers to create a "tickless" physics simulation by breaking up the simulation into the timespans between interactions, as long as pathological situations aren't introduced (like the quake 3 ledge climbing bug). That doesn't mean that the developer will actually do so, and if the gameplay logic interacts with physics in framerate-dependent ways the result will still be wrong. It just means that the possibility is there. Of course, this doesn't solve game logic issues with things happening only at the moment that a frame happens. That's entirely on the developer, even if they use an ideal physics engine. At the end of this, I'll repeat that fixed timestep doesn't actually solve the problem, all it does is allow you to output higher graphical framerates than the physics simulation is running at. If the physics simulation itself can't run at full speed, you still need a way to adapt to longer frametimes, and you have to do so correctly. And if you run the physics simulation so slowly that it won't slow down on any reasonable PC, you either have a very simple game or you just added tons of input latency.
Jare 10y ago
During development of the game [Prototype] I experimented with a number of game logic update scenarios, including variable timesteps, fixed (potentially multiple per frame) and limited fixed (potentially leading to slow motion), in combination with factors like enabling and disabling vsync, taking into account camera movement (speed, mostly horizontal or mostly vertical?), amount of explosions and debris going off, etc. To try and find the best experience for the player at each moment. But we always had physics running at a fixed update rate (always receiving a constant delta time) regardless of any of the above. Trying variable rates there will ruin the stability of your movement, collisions, platforming, etc in any system that is complex or requires precision and predictability.
- LoSboccacc 10y ago
  yeah, 5 minutes playing with Kerbal Space Program really highlight the fuckery that variable delta updates cause to physic based games
buzzybee 10y ago
To add to this statement: Input latency is a much broader issue than collision latency - a large scale of collision latency is produced simply by being an online game, regardless of how you're trying to represent the events. So the collision being subject to a tickrate is hardly a dealbreaker. Variable timesteps can be a little bit better at performance or responsiveness, but it comes at the expense of flooding additional concerns about consistency throughout the main loop. The modern fixed timestep treats a tick rate as delta times being partitioned into quantities of ticks, but also passes the time each tick represents into each update as a way to ensure that timers and time-centric physics can exhibit perceptually similar behaviors if the tickrate, and thus the duration of each tick, changes. Input latency, OTOH, is something that has challenged developers from the earliest days since it has to do with how fast you propagate new input through the main loop to the output device, and the timestep's interaction with input is not straightforward. Arcade games could drastically improve their feel just by capturing and debouncing input multiple times a frame, even with the simple screen-refresh timesteps that were the common practice.

wareya 10y ago

Online games avoid that problem by having an authoritative networking architecture, not by avoiding minor deviations in CPU behavior between players. Games that use synchronized lockstep that use floating point math always desync, because floating point math differs slightly between different processors. Curved motions are easy as long as you have simple polygons and only one of them is accelerating and is accelerating in a simple way. You remove the acceleration by skewing the polygon you're going to collide with and then you have a linear path of motion again. (if the acceleration is not constant for the duration of that frame, then skewing doesn't give the right result; as long as you have a closed form representation, though, it's entirely possible to get it right) "Don't run on a tick-based physics engine" is a misconception. Interactions are the borders between ticks. It's just dynamic. As long as your tick doesn't contain interaction changes inside it, you can simulate that tick with 100% tickrate independence with 100% certainty. Floating point differences between cpus are Much Larger, especially if your code uses hardware-accelerated trig at all. Games networking is authoritative for this reason. You can get a 100% repeatable result with a tickless engine. Fixed timestep doesn't solve the problem. If the user can't run the simulation at 60 ticks per second, they're still going to slow down, period. All you're doing is separating simulation from rendering, which basically every modern FPS under the sun already tries to do in a different way than fixed timestep does. If you run the simulation slow enough that nobody will have performance problems with it, you just added tons of input latency. Thanks a lot, sincerely, someone with dysgraphia.

CJefferson 10y ago
> because floating point math differs slightly between different processors. I don't know why you keep saying this. If I compile a program which uses floating point for (say) x64, it will produce the same results on every machine. Can you give any example where the same executable will produce different results on different machines? Now, you may get different answers on ARM, or 32-bit, but almost no games (I'm having trouble thinking of any) try to do cross-CPU networking, so the (extremely) minor differences doesn't make any difference. Most games don't sync between users, they trust each user to run the game engine -- you can't afford to send the total state of the world to users, it would take far too much network traffic. Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't.
- wareya 10y ago
  >I don't know why you keep saying this. Because it's true. The same operation on the same data may give different results on different CPUs, even if you're operating at the machine code level (no implementation-specific optimizations). https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ https://randomascii.wordpress.com/2014/10/09/intel-underesti... >Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't. box2d is sufficiently low level that it gives programmers the tools necessary to do this. Most notably, box2d provides the following: >Continuous physics with time of impact solver This directly allows developers to create a "tickless" physics simulation by breaking up the simulation into the timespans between interactions, as long as pathological situations aren't introduced (like the quake 3 ledge climbing bug). That doesn't mean that the developer will actually do so, and if the gameplay logic interacts with physics in framerate-dependent ways the result will still be wrong. It just means that the possibility is there. Of course, this doesn't solve game logic issues with things happening only at the moment that a frame happens. That's entirely on the developer, even if they use an ideal physics engine. At the end of this, I'll repeat that fixed timestep doesn't actually solve the problem, all it does is allow you to output higher graphical framerates than the physics simulation is running at. If the physics simulation itself can't run at full speed, you still need a way to adapt to longer frametimes, and you have to do so correctly. And if you run the physics simulation so slowly that it won't slow down on any reasonable PC, you either have a very simple game or you just added tons of input latency.

Jare 10y ago

During development of the game [Prototype] I experimented with a number of game logic update scenarios, including variable timesteps, fixed (potentially multiple per frame) and limited fixed (potentially leading to slow motion), in combination with factors like enabling and disabling vsync, taking into account camera movement (speed, mostly horizontal or mostly vertical?), amount of explosions and debris going off, etc. To try and find the best experience for the player at each moment. But we always had physics running at a fixed update rate (always receiving a constant delta time) regardless of any of the above. Trying variable rates there will ruin the stability of your movement, collisions, platforming, etc in any system that is complex or requires precision and predictability.

LoSboccacc 10y ago
yeah, 5 minutes playing with Kerbal Space Program really highlight the fuckery that variable delta updates cause to physic based games

buzzybee 10y ago

To add to this statement: Input latency is a much broader issue than collision latency - a large scale of collision latency is produced simply by being an online game, regardless of how you're trying to represent the events. So the collision being subject to a tickrate is hardly a dealbreaker. Variable timesteps can be a little bit better at performance or responsiveness, but it comes at the expense of flooding additional concerns about consistency throughout the main loop. The modern fixed timestep treats a tick rate as delta times being partitioned into quantities of ticks, but also passes the time each tick represents into each update as a way to ensure that timers and time-centric physics can exhibit perceptually similar behaviors if the tickrate, and thus the duration of each tick, changes. Input latency, OTOH, is something that has challenged developers from the earliest days since it has to do with how fast you propagate new input through the main loop to the output device, and the timestep's interaction with input is not straightforward. Arcade games could drastically improve their feel just by capturing and debouncing input multiple times a frame, even with the simple screen-refresh timesteps that were the common practice.