Multiple MotionControls components

[Marcin Misiurski]

Hello. I finally grasped entity system basics. Now, I started tinkering with the Asteroids example, and as a first thing wanted to add alternative controls using a/d/w. I can't simply add another MotionControls component, because of the entity rules. I've read https://groups.google.com/forum/#!topic/ash-framework/538md_mE_A0 , but it makes no sense to create multiple entities just to get alternate controls. I'm thinking either about changing MotionControls to accept arrays of keys, or lifting the unique component restriction (though I don't know what will happen with node creation process). Which option is better?

[Eric Lund]

If it were me, I would add each MotionControls component to a separate entity. I'd use an AllowMotionInput entity or something like that to tell my InputSystem that it should process input. When it does, it would loop through all the MotionControl entities. I might process the inputs right there, or if I'm worried about double processing, register the inputs in variable like playerFired and playerMovedRight, before resolving those variables. Or I might store those variables as Intent components, to decouple it from the resolution, e.g., FireIntent and TurnIntent(Right, .1), then these could be processed by a separate system, and also would give me the ability to artificially trigger an outcome that normally comes from input. When I know there should be only one of something, I make use of "singletons," looking up entities by name rather than node. My two cents, but there are many ways to do something in an ECS.

[James Wrightson]

Maybe I have miss-understood but it seems to have a simple solution.

Rename MotionControls to "StandardMotionControls", then create a seperate component "AlternativeMotionControls" that hooks onto a seperate system.

As you need to store STATE within the new component (ie what controls to what), it makes sense to me to have a new component.

[Eric Lund]

Hrm. I suppose you could have a super class called MotionControls and then subclass Standard and Alternative, but this seems like an OOP approach to fixing an ECS problem. When two objects store the same type of state, doesn't that suggest they should be a single component?  I mean, do you care if the Z key to jump is a primary control and the SPACE to jump is an alternate? Only your control setting UI cares about that, otherwise the rest of the game just knows they're both valid controls. What if you didn't have control settings UI and you got feedback from your customers from a country with a different keyboard who would appreciate a third control for jump? Are you going to create a KazakhstanMotionControls component now as well? I think this is better treated as a data problem.

[James Wrightson]

Just because both components store similar data, it does not mean they are related.

Technically both solutions are wrong as you can easily generalize "input" -> "action" with a generic component.

You will bind input events to action id's, for example:

input.addMouseAction(MouseEvent.MOUSE_DOWN, "attack");

input.addKeyAction(KeyboardEvent.CLICK, Keyboard.LEFT, "move-left");

etc

Have a system that can read the events (a bit like the polled keyboard/mouse stuff) and then decide what actions are enabled.

Later on you could use this in systems for example:

if(n.input.isLegalAction("attack")){....}

The brilliant part is that now your inputs are abstracted and mapped to actions, you can have even greater inputs:

input.addTouchAction(....);
input.addSwipeAction(...);

etc

[Richard]

Hi

I think your choices depend in part on what user experience you want to present.

1. If you want the user to choose which controls they will use, you can configure the appropriate MotionControls component and add it to the entity. No need for multiple components.

2. If you want all controls to be available all the time, you can use an array of keys for each control effect, so MotionControls has an array of keys that can be used for left, etc.

Note, if you want to add input that isn't keyboard based, you will likely want a different component type for that, such as MouseMotionControl, and you may want another level of separation between the controls and the physics so the input is processed to produce velocity or acceleration, whichever is appropriate, which is stored in another component and then elsewhere the velocity or acceleration is processed to produce movement.

Richard

[Marcin Misiurski]

Hello

Thank you everyone for your input! I'm quite certain I'll use some of those solutions in more complex systems in future, but for learning purpouses I'll just stick with key array. 
(Also sorry for duplicating thread, looks like this discussion already took place in xember github - https://github.com/alecmce/xember/issues/12 )