Using EntityComponents for input


If I use EntityComponent for the player input, can I look up this input (and remove it once processed) inside of a for-loop going over the EntitySet.getAddedEntities? I can see there’s a method: EntityData.findEntities - maybe that’s more thread-safe ?

I need more information.

For example: Player input is constant. Why would you remove it?

Like planting a bomb, once you’ve given your input (and maybe succeeded or not) it shouldn’t happen again.

You mean movement in this case?

Then that “input” was not a component. It’s an “event” and you’re probably trying to bring OOP concepts into an ES. At least it feels that way.

Why not just plant the bomb instead of having a game object represent planting the bomb? …and if the “act of planting the bomb” is a game object then it’s its own entity anyway.

Seems like something is weird further back that we don’t understand.

Im not hearing a “no”


I just fancied the idea of leaning more into the ES.

Where do you draw the line between player input (which may or may not be constant) and OOP concepts (out of curiosity) ?

Given: Entity system is on the server. No writeable entities on the client.

How does the client communicate what’s happening to the server?

That answer leads to the next ones.

I didnt mean it like that, I just meant on the server side, taking the input from the client and adding a component with that info and letting the right system pick it up from there.

Client instantiates input entity component - sends to server through session - server adds to entitydata on the right entity - the related system picks up the information.

Yes, that should be fine.



Allright, and then back to my original question…

Is it safe to remove (one of) the component inside of the EntitySet.getAddedEntities ?

For movement, perhaps its continuously inputted (and the component is not removed). But what about input that may be continuous and may not (firing a laser continuously comes to mind). Server sees and processes the input and removes it right away, or … ?

This is a different case, you do not create a “fire laser” event with ES, when the player wants to fire a laser, the client sends a message to the server through RMI session and the server will spawn a laser entity. When the laser gets destroyed you set a decay component on the laser entity then it will be removed automatically by decay system.

Now I’m just stubborn :smiley:

  1. Movement, a continuous “event”, not removed from player entity - the input is sent all the time (per demo at least). Client doesn’t press movement keys all the time.
  2. Fire laser, a continuous “event” as long as the player wants to fire it - input starts when client presses a key, stops when client releases the key.

How are they so different ?

I genuinely want to understand the difference.

Edit: I’m trying to think if I can phrase a question for myself so that I can understand why I’m moving down a wrong path (as I infer from the replies here :slight_smile: )

I mean having a system in ES that listens to entities with a FireLaser component (which represents an event) and then creates a laser entity seems to be an OOP stuff and out of ES scope. Maybe I am wrong.

Anyway, this should be safe to do I think.

Thanks. I think I’ll try it and see how it works.

If it’s continuous then there is no reason to remove it. There is always some state… either laser firing or laser not firing.

The reason movement is done this way is because it’s sent unreliably… so you have to send ‘up’ continuously as well as ‘down’.

“Lasers” may work this way but more likely it’s another continuous ‘pressing fire button’ ‘not pressing fire button’… then the server will decide what to do with that information. For example, if the player has a laser equipped then the server-side game session will create the laser beam entity if the button is pressed and the entity is not already created. It will delete the laser beam entity if the button is released and the entity is not null.

The laser beam will deal continuous damage wherever it’s aimed as long as it exists.

If your ‘laser’ is more like the ‘pew pew pew’ blaster variety then the server side session spawns laser bolt entities while the button is pressed and time has expired since the last bolt based on rate of fire.

Never was there a need to add a component to something just to say to create this other things and add a component to it. Down that path eventually leads to crazy if you aren’t carefull. ("See… there’s a button component and a system that looks up the tool and adds a tool component… then a system that looks up the tool component to see what tool is equipped and add the laser component… and then another system to… etc…)

…when a single factory method called early would have been fine.

1 Like

I think this is whats been nagging me about my design. Thanks