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.

>>32
You also can (and in fact, should) interpolate if the system is slower.

T = game tick; R = rendered frame

T    T    T    T    T    T
R      R      R      R

Here the ticrate is 30Hz and the rendering is ~20fps for example. If you pick up the nearest (well, previous) tick instead of interpolating, it won't look very good.

However this adds latency, so please make it variable tick (parametric) instead. It's not that hard. For continuous stuff you just multiply velocity by time. For periodic stuff (weapon firing), you have an accumulator where you add the time every frame. If the accumulator's value is larger than the period, you subtract as many whole periods as possible and perform the action that many times, keeping the remaining time in the accumulator.

There are some other fine details but on the whole I don't see how not being parametric would save a lot of work.

Also, read http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization for an example of a decent design for network replication that doesn't use fixed tics anywhere, presents perfectly smooth motion at any framerate, gives the illusion of no latency, and hides network imperfections (packet loss, timing jitter) rather effectively.