Using EntityComponents for input

asser_fahrenholz · July 7, 2020, 6:25pm

Hey

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 ?

pspeed · July 7, 2020, 6:47pm

I need more information.

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

asser_fahrenholz · July 7, 2020, 6:48pm

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

asser_fahrenholz · July 7, 2020, 6:49pm

You mean movement in this case?

pspeed · July 7, 2020, 6:52pm

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.

asser_fahrenholz · July 7, 2020, 7:00pm

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) ?

pspeed · July 7, 2020, 8:21pm

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.

asser_fahrenholz · July 8, 2020, 6:31am

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.

Ali_RS · July 8, 2020, 6:45am

Yes, that should be fine.
See

github.com

Simsilica/SiO2/blob/86f3bdbe81f10ca5a85c7fab9265280167aee922/demos/bullet-char/src/main/java/com/simsilica/demo/bullet/CharInput.java#L47


      
          package com.simsilica.demo.bullet;

          

          import com.simsilica.mathd.*;

          import com.simsilica.es.EntityComponent;

          

          /**

           *  Component providing character input information about a mob.

           *

           *  @author    Paul Speed

           */

          public class CharInput implements EntityComponent {

          

              public static final byte NONE = 0x0;

              public static final byte JUMP = 0x1;

          

              private Vec3d move; 

              private Quatd facing;

              private byte flags;

              

              private CharInput() {

              }

and

github.com

Simsilica/SiO2/blob/86f3bdbe81f10ca5a85c7fab9265280167aee922/demos/bullet-char/src/main/java/com/simsilica/demo/bullet/CharInputSystem.java#L50


      
          import com.simsilica.sim.*;

          

          import com.simsilica.bullet.*;

          

          /**

           *  A system that makes entities with the CharInput component

           *  move.

           *

           *  @author    Paul Speed

           */

          public class CharInputSystem extends AbstractGameSystem {

          

              private EntityData ed;

              private BulletSystem bullet;

          

              private CharInputContainer characters;

          

              // Right now there is only one for all characters... which 

              // is generally only players anyway.

              private CharPhysics charPhysics = new CharPhysics();

              private boolean refreshSettings = false;

and

github.com

Simsilica/Examples/blob/6ccd7a138fd948ac472793106780935b57e42657/sim-eth-es/src/main/java/example/net/GameSession.java#L69


      
               *  Returns the ID of the player entity.

               */

              public EntityId getPlayer();

           

              /**

               *  Sends information to the game back end about the current

               *  movement state of the player from user input.  Because this

               *  state is continuous, it doesn't need to be reliable.  

               */

              @Asynchronous(reliable=false)

              public void move( Quaternion rotation, Vector3f thrust );   

          }

asser_fahrenholz · July 8, 2020, 6:53am

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 … ?

Ali_RS · July 8, 2020, 7:16am

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.

asser_fahrenholz · July 8, 2020, 7:23am

Now I’m just stubborn

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.
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 ?

asser_fahrenholz · July 8, 2020, 7:27am

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 )

Ali_RS · July 8, 2020, 7:49am

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.

Ali_RS · July 8, 2020, 7:55am

Anyway, this should be safe to do I think.

asser_fahrenholz · July 8, 2020, 8:03am

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

pspeed · July 8, 2020, 9:12am

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.

asser_fahrenholz · July 9, 2020, 7:00am

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