Jump to content
Posted 23 November 2012 - 01:16 PM
Posted 24 November 2012 - 12:28 AM
Posted 24 November 2012 - 04:28 PM
I like that.
Slowly dial up the delay until you can perceive it, and note how long you're buffering your input. Now cut that back by about 25% and you have your target :-)
Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.
Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.
Posted 24 November 2012 - 05:13 PM
Keep in mind that there can be up to several frames of lag between when you hand off your rendered scene to the video drivers and when the player actually "sees" the image.
Also, bear in mind that you cannot escape network latency by hiding it. It is generally measured in dozens of milliseconds - the roundtrip time of even the speediest cross-internet trip is going to be very noticeable. (See also: why "streaming gaming" services have generally failed to catch on.) You need to anticipate network latency and deal with it in a totally different way than just hoping the player can't feel it.
Now - with those caveats out of the way: in my experience, you can generally burn about 30-50ms (depending on the player) before input latency "feels" bad. At 30Hz, that means you can afford one frame of latency or maybe two if you're not expecting twitch reflexes from your gamers. At 60Hz of course you're in a different boat, and can afford a lot more.
Here's a great experiment you really should try: build a simple game like a Snake skeleton or something, just implement the controls and rudimentary rendering and that's it. Put in a configurable delay buffer between when your input is read and when it affects the game simulation. Slowly dial up the delay until you can perceive it, and note how long you're buffering your input. Now cut that back by about 25% and you have your target :-)