Hi.
I thinking about how to do an input system.
I am going to use Win32API (anyone got better solution?) to capture the input events (mouse and keyboard, no plan for controllers or joysticks yet).
So from what I understood I should have some array of key states (and mouse state) and every frame I call my input system to check if something is pressed.
Correct me if I'm wrong up to this point.

This works nice for a demo where you don't have different game states. So this brings me to GameStateOperator. GSO (as I call it) is simply a wrapper upon stack DS that holds various GameState objects. The top most GameState in the stack is the current state of the game and the only one who can parse the input events.

Example:
Let there be two GameStates:
1. MainMenuState
2. InGameState

Both states can parse the ESC button press however they acts differently. MainMenuState is the default state that loaded when the game initialized. If current state is InGameState, pressing ESC will pop this state therefore the current state will be MainMenuState and pressing ESC here will quit the application.

This is nice and cool, but lets add entities. Entity (dont yell at me if I define it wrong) as I see it is something that can be present in the scene (be it visible and dynamic like car, visible and static like wall or invisible like trigger). Some entities would like to handle input as well (Player entity for example).

What I tough about is to do an Interface like IKeyboardListener and IMouseListener and everyone who wishes to receive keyboard or mouse events will implements them and registers itself within InputManager.

The same goes for GameState class. It will by default inherit from IKeyboardListener and IMouseListener.
For the input manager to know if the event was parsed withing specific listener, the listener must return either true or false.
Pseudo code:

So if the listener returned true, the InputManager knows that that current state was handled and no more listener needs to be called.

This is a brief of how I see it. Somethings were tough about for a long time, others just came into my head right now. It looks like a flexible system for me but I would you to comment on it and show me were I went wrong, if at all.

Thanks!

Quote:Original post by s.kwee
What I tough about is to do an Interface like IKeyboardListener and IMouseListener and everyone who wishes to receive keyboard or mouse events will implements them and registers itself within InputManager.

Disclaimer: I don't have a lot of experience with this sort of thing.

I don't think entities should really care about the keyboard and the mouse. A player, for example, should be able to move forward, jump, fire his weapon, etc. It shouldn't worry about what caused him to jump or fire.

Game logic should be decoupled from this kind of low-level stuff (like input devices).

Quote:For the input manager to know if the event was parsed withing specific listener, the listener must return either true or false... So if the listener returned true, the InputManager knows that that current state was handled and no more listener needs to be called.

What if several listeners are interested in the input?

Quote:Disclaimer: I don't have a lot of experience with this sort of thing.

I don't think entities should really care about the keyboard and the mouse. A player, for example, should be able to move forward, jump, fire his weapon, etc. It shouldn't worry about what caused him to jump or fire.

Game logic should be decoupled from this kind of low-level stuff (like input devices).

Then who cares about the input? When you press W who knows that your avatar should move forward?

Quote:
What if several listeners are interested in the input?

Hmm right, I didn't think it well enough... I was confused with single event being parsed (like W key down) therefore no listener should parse this event anymore.

Well what I meant was if W was pressed, its passed to the first listener if the listener knows how to handle W it handles it and no other listeners must handle it. This what I meant.

Quote:Original post by s.kwee
Then who cares about the input? When you press W who knows that your avatar should move forward?

I was thinking about something like this (pseudo code, just to demonstrate the idea):



As you can see, the player is completely decoupled from the input handling code. I would probably put this code in the InGameState class.

Yes but in this case every state needs to know about the objects in it. A bit ugly IMHO.

Other suggestions are welcomed.

Hmm sounds logic now. Maybe I need to start coding to see it.
IMHO its a bit violation of encapsulation since State shouldn't know about player entity or etc.

Quote:Just another thought related to the OP: A stack is not the best structure to manage global game state. Game states build a kind of graph with transitions between them. And those transitions are not always mappable to a FIFO structure.

Could you please give an example of a system where FIFO wont work? I can't come up with anything.

chronozphere
It doesn't answer my question: how to handle Entity events? Like player movement? Should player entity implement some interface and register itself as keyboard/mouse listener? Should it be handled inside the current game state?