Comments on: Programming Responsiveness

By: Interesting Reading… – The Blogs at HowStuffWorks

Interesting Reading… – The Blogs at HowStuffWorks — Mon, 11 Jan 2010 17:54:23 +0000

[...] Programming Responsiveness – “Responsiveness is something that can make or break a game at first impression. This is especially true in reviews where a game with poor responsiveness will be described as being “sluggish”, “unresponsive”, “floaty” or “sloppy”. A better game might be referred to as “tight” or “responsive”. There are several factors that contribute to perceived responsiveness. This article looks at some of them from a programmer’s perspective, and offers some routes to making your game more responsive…” [...]

By: EvaUnit02

EvaUnit02 — Wed, 23 Sep 2009 21:49:55 +0000

The phrase, “in actual fact” made me giggle.

Great article, Mick.

By: Understanding Lag « c# to javascript, actionscript

Understanding Lag « c# to javascript, actionscript — Mon, 20 Jul 2009 07:27:01 +0000

[...] lag in order to defeat it. While browsing I found this great article to explain all of it. To understand why lag occurs, you need to understand the sequence of events that occur [...] Mick [...]

By: Simfoony » Blog Archive » A propósito de OnLive

Simfoony » Blog Archive » A propósito de OnLive — Tue, 31 Mar 2009 22:02:05 +0000

[...] OnLive tiene que solventar es el lag entre que pulsas una tecla y ves la reacción. En el blog de Mick West hay un diagrama que muestra la secuencia de eventos que transcurre entre que pulsas el boton [...]

By: Mick West

Mick West — Mon, 01 Dec 2008 05:17:23 +0000

I’ve been mostly a console programmer, so framerates are generally fixed at 30 or 60. Decoupling is not generally a good thing in that situation. Especially if it can introduce extra latency. If you have a fixed framerate, it’s generally better to run the physics in lockstep or a fixed multiple (or fraction) of the display frame rate.

By: Ape-Inago

Ape-Inago — Mon, 01 Dec 2008 02:55:32 +0000

Wow, this is really neat. I’ve thought a lot about this type of thing myself, when writing out a simple display engine… It would always seem that the external console would display “button pressed” a few moments before the game responded. After much trial an error, it turned out to be similar to one of the approaches you’ve written about above.

Have you put any thought into decoupling the input management from the framerate? I did something like that with the physics of the thing I was using, and it gave a much more responsive feeling game. http://gafferongames.wordpress.com/game-physics/fix-your-timestep/ (an article about physics timesteps.)

The only step further would be to do input handling in a thread, but that gets a bit complicated.

By: Cowboy Programming » Measuring Responsiveness in Video Games

Cowboy Programming » Measuring Responsiveness in Video Games — Fri, 30 May 2008 17:59:44 +0000

[...] Programming Responsiveness [...]

By: Mick West

Mick West — Wed, 28 May 2008 14:39:33 +0000

There’s a lot of room for tweaking – basically changing things based on context. Always be asking “what is the player’s intent here”, and try to accommodate that as quickly as possible.

Take the immediate past button pressing history into account when deciding what to do. If they press left, then it can do a different style of velocity modification if they were pressing right withing the last 0.5 seconds.

By: SteveC

SteveC — Wed, 28 May 2008 04:41:34 +0000

“I’m assuming you are not talking about the standard key-repeat rate here…”

No, I figured that much out (not on the first try, but the 2nd try.)

“For example if you are moving and change direction, then you use a different acceleration than if you are stationary and start moving.”

I think I did something along those lines (will have to go back and look and see what I did.)

“You’ll also want some hard limits on velocity in addition to friction.”

Yeah, got that. Somewhat arbitrarily chosen values, hard to figure, except by trial and error, I guess.

My suspicion is that that the keyboard can never be as good as the joystick, simply because it provides less information. What few testers I’ve had have told me I’ve made improvements in the keyboard, but it’s hard to know if you’ve maxed out the “goodness” of the keyboard response.

By: Mick West

Mick West — Wed, 28 May 2008 04:35:25 +0000

I’m assuming you are not talking about the standard key-repeat rate here – if so, you are reading the keyboard wrong, and should look at, for example, my “Pushing Buttons” code.

http://cowboyprogramming.com/2007/01/02/pushhing-buttons/

Basically, you have a key that is either pressed or not. When it is pressed, you accelerate in some manner, and when it is not pressed, you decelerate in some other manner.

Remember all the great games that came out before analog sticks were around? They were all basically button pressing games – no different from keyboard input. It’s all in how you handle the acceleration.

It’s not a simple thing to get right. There are several cases you have to handle. For example if you are moving and change direction, then you use a different acceleration than if you are stationary and start moving. You’ll also want some hard limits on velocity in addition to friction.

Look at some existing games, and try to duplicate their behavior.