What would you want the input system > ECS interfacing to look like?

Unity Engine
,
1

Naively I think when you touch it will generate an entity with touch IComponentData into a world you specified. Then any system you have can inject on the touch and read data.

But then there has to be someone that have to destroy “used” touch or the data would remain there across frame.

We could use things like EndFrameBarrier to destroy touches, but then if the input system is able to be frame-independent and these touch entities can appear at any time in a frame, it might be right before the destroy touch system and no one would be able to use it in the next frame.

So I would like to ask what is the ideal interfacing that you would like to work with? It is because I am considering adding this function to my own touch plugin I want to know what user want.

Currently I am towards making the touch entities and never destroy them. It is up to the user to destroy or keep it for other system to use the touch next. Each system can add its own ISystemStateComponentData to indicate “handled by this system” state and subtractive component would prevent it from being injected again. Not sure if I leave all these “handled” touch in the world it would cause performance impact for the next subtractive inject or not?

2

I think that makes sense. I would also say input in ecs should be fully typed IComponentData

For a first person shooter I would probably have this:

struct FPSInput : IComponentData
{
     float2 Move;
     float2 Look;
     bool PrimaryWeapon;
     bool SecondaryWeapon;
}

So in that sense. It should be quite easy to wrap your Input needs based on current input system into this format. And then at least all game code is isolated from any changes to input system. And also you have moved input to a higher level more game specific data format, that you are fully in control of.

Advantages of this:

  • Access FPSInput on any job
  • Replay feature just needs to replicate FPSInput entities into the world in the right frame
  • Networking it, becomes tagging the right components to send.
  • Everything is simple
  • Static Typing / Auto-complete for all game code using the input. Following 100% same approach of all other code.

So for starters, i would just make a system that runs first in the frame, and simply produces / updates an entity with that struct on it by reading Input API and transforming it into the above.

2 Likes
3

Yeah, bools would be nice :wink:

2 Likes