Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

ECS player control best practice - distinguishing between player and NPC?

Discussion in 'Entity Component System' started by timothy_j, Jun 5, 2020.

  1. timothy_j

    timothy_j

    Joined:
    Apr 11, 2020
    Posts:
    12
    What kind of ECS organisation is best for ‘injecting’ player control into a generic prefab that is also used for NPCs?

    This is easy if the prefab is rigid - you can just add an ‘IsPlayer’ tag component and create movement systems that filter for that component.

    However, if the prefab has physics joints and the affected entity is not the prefab root, the entity gets decoupled from prefab root and I can’t think of an easy way to either tag it when spawning, or filter for ‘associated prefab root has IsPlayer’.

    Considering this, what is the best way of creating a (spawn?) system that can tag any ‘driven’ entities on a prefab so control systems can distinguish between Player and NPC? Or a better way of getting the same distinction?

    A real world example:
    • A car game where player and NPCs can choose any of a selection of car prefabs
    • All prefabs have a 'TorqueControl' component on each wheel, but the wheels could be anywhere in the prefab hierarchy, connected to the car entity by physics joints.
    • A PlayerSystem using player input controls wheel rotation using the TorqueControl on the player car
    • An NPCSystem controls wheel rotation on all other cars
    How do I distinguish between the Player and NPC wheels?
     
  2. JooleanLogic

    JooleanLogic

    Joined:
    Mar 1, 2018
    Posts:
    447
    This sounds similar to mine but I don't understand your problem with adding a tag to the root entity so I don't know if this addresses your issue or not.

    In my setup, I have a spaceship with many parts attached through joints. All ships have an Input component on the root containing properties for engine power, landing gear, weapons etc.
    The ship can only be controlled via this Input component, whether human or ai.
    The root ship contains reference components for all the parts attached to it.
    From there, systems copy information from the Input component to the rest of the ships components using CDFE's.
    None of the attached ship parts care whether they're controlled by a human or ai.

    Don't know whether that's the best or correct ecs approach or not but that's how I'm doing it.
     
    timothy_j likes this.
  3. timothy_j

    timothy_j

    Joined:
    Apr 11, 2020
    Posts:
    12
    That certainly looks as though it would work for me. Thanks!
    My mistake was trying to control all of the movable entities directly rather than going through references in the prefab root entity.
     
  4. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    3,993
    This is a pretty bread-and-butter approach to modular systems in ECS. I named this component ShipDesiredActions rather than Input in my project so as not to confuse it with actual input handling.
     
  5. timothy_j

    timothy_j

    Joined:
    Apr 11, 2020
    Posts:
    12
    Unfortunately I can't get the CDFE's to write data to the other components - my current code is in this post. Any pointers would be appreciated!