Quote:Original post by shuwo
My real question is: If I have a few sprites and such, how can 'MyGameInputHandler' access them to change their movement direction etc?
Well, you typically wouldn't change the movement of
sprites, but rather you'd give your
game objects specific instructions. The code that's responsible for visualizing them should take care of updating sprite positions (as a reaction to the game object having changed it's position). Keep in mind that game objects are not sprites, they're just visualized with sprites (or particle effects, or 3D models, or whatever you want).
So, when the user presses the up key, you'd call the jump() function on your player object, rather than setting the velocity of a player sprite. You'd then have some code that checks the players state and that draws a sprite (or sprites) accordingly.
Quote:Do you mean that every sprite/graphic should implement these methods? Please elaborate.
Well, no. Only things that need to react to user input need to implement this interface, as only they need to be registered with the input code to listen for input events.
Well, it's possible to have to game react to input and, depending on the game state, perform certain actions, but it's also possible to let individual objects listen for input. I think the latter is a bit too low-level, though. For example, if the player object itself was listening for input directly, it would explicitly need to be paused or disabled when pausing the game.
So I tend to prefer a 'screen-based' approach, e.g. only menus and game-screens handle input directly, and only one screen can be active (visible, or on top of another screen) at the same time. Pausing the game would simply push a pause menu on top of the game-screen, preventing the game-screen from reacting to input.
