Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Input handling in ECS system


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Dominik2000   Members   -  Reputation: 279

Like
0Likes
Like

Posted 06 March 2014 - 03:17 AM

I ask me the question how the input managment is best implemented in an ecs system. Especially how to stop the program, when ESC is pressed.

 

The architecture is like this:

A core game class, which initializes the renderer, different systems (placement system, physics system, ...) and the entity manager, which only stores many maps of components, with an entity id. All systems take their components from the system manager, so every system has access to all components it needs. The input low level class will be initialized by the input system. On the update cycle of the input system  if an ESC click occurs, the input system, sets the game isRunning property to false.

 

Or should I initialize the input low level also in the game class and then message direct from the low level input to the game class? I don't think so because I break the layers in this way.

 

Are there any advantages in the second method? Or is my first approach ok?



Sponsor:

#2 Dominik2000   Members   -  Reputation: 279

Like
0Likes
Like

Posted 06 March 2014 - 03:28 AM

And what is if I want to move the camera on the W key forward? The input manager holds a queue of key presses, the input system translates the key press to a move foreward message. Should I implement a MoveComponent, where I only store the MOVE_FORWARD message, and the placement system, moves the appropriate entity forward?

 

Or should this be a great queue in the game class? Don't think so, because the game class should have nothing to do with input handling or messaging. Maybe an own event messaging class?



#3 haegarr   Crossbones+   -  Reputation: 5605

Like
3Likes
Like

Posted 06 March 2014 - 03:58 AM

Using low level sub-systems by high level sub-systems is okay because it is the natural order when layering. Input is a low level system. So I don't see a restriction in using it by e.g. your core game sub-system.

 

The solution I'm fine with so far is that Input as a sub-system just gathers and maintains low level input and provides a plug-in mechanism to allow other sub-systems to investigate the queued input. A sub-system that is interested in input generates an InputHandler. An InputHandler is responsible to detect situations from queued input and usually to translate it into commands (as a form of high level input) accordingly to the input configuration (i.e. a mapping that defines which input situation should generate which command).

 

At least higher level sub-systems need to be processed in a defined order anyway. I do not propagate input by messaging but let the sub-systems run their InputHandler as needed inside their respective update method.



#4 Dominik2000   Members   -  Reputation: 279

Like
0Likes
Like

Posted 06 March 2014 - 07:08 AM

Your InputHandler works in the update method of the system in the handleInput phase. Do you get the translated commands from the InputHandler? Do you say the InputHandler, in which commands you system is interested in, at initializing?



#5 haegarr   Crossbones+   -  Reputation: 5605

Like
0Likes
Like

Posted 06 March 2014 - 07:58 AM

When you look at it, there are not many different kinds of abstract input. There is an action to be taken (a command), a transient binary state (on or off), or a value on a continuous axis. If you wish you could also express the binary state by using the extremes of an axis. You may have a look at the Unity 3D input system or the USB HID specification for such abstracted input. Any sub-system has a defined set of needs w.r.t. such input. E.g. your core game system has the need to shut down, obviously best presented by an action input. Sub-systems may derive their needs for input from components, like e.g. the controller for the player character.

 

So what I actually do (although it need not be done this way) is that sub-systems export instances of abstract input. Such instances provide a type as described above (e.g. action), a variable appropriate for the type, a display name if needed, and a flag that indicates whether the input is configurable. If so, then they are also binding points for input configurations. When a sub-system's needs can be described this way, then it just needs a standard InputHandler that translates from raw input to abstract input using said input configuration. If it needs more pre-processing, then it could install a derived InputHandler.



#6 BeerNutts   Crossbones+   -  Reputation: 3459

Like
0Likes
Like

Posted 10 March 2014 - 09:31 AM

Another option would be, your input system simply updates all the Input Components.  So, your player entity could have an input component, your camrea entity could have an input component, and you could have the main game/menu system have an input component.

 

The menu system would look for ESCAPE_KEY (probablymapped to Esc) in the Input Component, the Camera would look for CAMERA_MOVE_FORWARD_KEY (possibly mapped to 'w') from the Input Component, and the player would look for WEAPON_FIRE_KEY, PLAYER_MOVE_FORWARD_KEY, etc. from the input component.


My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#7 Dominik2000   Members   -  Reputation: 279

Like
0Likes
Like

Posted 10 March 2014 - 10:37 AM

Good thought, but who stores in which key mappings the system is interested? The system or the component. The component would be perfect if it delivers only the keys in which the parent system is interested.

 

The system could search for every mapping every frame, if it exists, if yes -> do it if no -> do nothing. I don't like this...



#8 BeerNutts   Crossbones+   -  Reputation: 3459

Like
0Likes
Like

Posted 10 March 2014 - 11:29 AM

Good thought, but who stores in which key mappings the system is interested? The system or the component. The component would be perfect if it delivers only the keys in which the parent system is interested.

 

The system could search for every mapping every frame, if it exists, if yes -> do it if no -> do nothing. I don't like this...

Sure, part of the InputComponent could be a list of keys the specific entity is interested in, and, the InputSystem would only add keys the Input Components want to store.

 

So, the Camera Entity just wants CAMERA_MOVE_<direction>_KEY keys, and when it creates it's InputComponent, it gives it that list.

 

When the Input System runs, if a key mapped to CAMERA_MOVE_LEFT_KEY is pressed, then it is added to the Camera's InputComponent only.

 

The next time the Camera System runs, it see it's InputComponent has a key being pressed, and it uses it.


My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS