Question about design

Question

Two fast questions about two design decisions:

1. Suppose that you are checking collisions between game elements. When you find a collision between object 1 and object 2, do you play immediately a sound effect or do you insert it in a list and, in a later a stage, do you process all sound effects?
2. Same question as above for user input. When the user presses key 'keypad left' do you insert the event in a queue and process it later or do you update character position immediately?

Thx

Answer 1

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.

Answer 2

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.