Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When checking for collisions between entities, should you play a collision sound immediately on discovering a collision or queue every collision and process the sounds later?

Similarly for user user input: When the user presses keypad left, should you insert the event in a queue for later processing or immediately update the world?

share|improve this question
Separate questions should be separate questions. Input and sound aren't really related. – Tetrad Nov 23 '11 at 15:12

1) I guess it depends on the capability of your sound-engine and the number of objects/collisions you might have at any given time. If you have lots of collisions, the amount of concurrently playing sounds might exceed the limitations of your sound-engine.

It would be a good idea to have notifications for collisions. Whenever your collision-solver detects a collision, it notifies the entities and maybe also your "sound-manager". There you can decide if this new collision should play a sound or (if it's concurrent with another collision of the same type) you don't need to play a sound at all. You should also make sure that a collision fires a notification just once.

2) It's definitely a good idea to queue user-input. Depending on how your input works, you might get multiple user-inputs during one update and you don't want to miss any of these. But this heavily depends on the input library you use (some do input buffering already or allow you to poll on updates etc.).

Generally it's a good idea to have an intermediate layer that handles/normalizes input. Just imagine you want to allow key-remapping or different control-schemes. You don't want to check if(keyPressed == W_KEY || keyPressed == LEFT_KEY). Rather your input-layer would know about the currently active key-mapping, do the check and return (or broadcast) normalized commands, like left etc.

share|improve this answer
  1. I wouldn't do either. I'd change the state of the object (this sounds fancy - in code I do something like i_collided_with_something = true) and then I'd implement a seperate method in the class which is responsible for playing sounds (which does nothing else than if(i_collided_with_something) playcollisionssound();). This seperates the actual state-logic from playing the sounds (you can change the sound without fiddling around in the collision-management code).

  2. Since I consider the position of the player to be a state, I'd change it immediately. There's no real advantage to be gained from saving all that stuff in a list and doing it all at once later.

share|improve this answer
I really disagree with 2. User input is an additional constraint that should be resolved with all the rest (collisions, other physics). Also, it should really affect acceleration or at least velocity rather than position. – sam hocevar Nov 23 '11 at 10:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.