Game logic

How the fuck do they code games so that everything moves smoothly and at a consistent rate regardless of the speed of the machine you run it on, and still have tons of shit interacting with each other somehow?
Maybe I need to find a good open-source candidate to have a look at.

Also, I wish I knew the correct terms to describe what I'm talking about.

>>35
That's the cheapo way: fixed tic rate, render with time interpolation. It's reasonable, the problem is that it adds latency and the only advantage is that the logic can be a bit simpler (however you lose other desirable features such as the ability to do slow-motion properly).

He says the problem with the right solution ("Game Speed dependent on Variable FPS") is numerical instability. Well, so suck it up and design it correctly so huge errors don't pile up on a reasonable range of speeds, and limit times to that. That's what most properly designed games do. For example most recent Valve Source games are limited to 300fps by default. Most iD Tech 3 games come limited to 85fps, most Unreal Tech 3 are limited to 60 (that's a bit too low, but can be increased and increasing it doesn't cause any problems). Practical experimentation suggest that mathematical precision isn't an issue at all in practice.

Of course badly chosen units + shitty timing functions that have low precision and will return 0 regularly (like the GetTickCount() he suggests) = trouble. Big news.