Search Unity

Manually assigning systems to Entities?

Discussion in 'Entity Component System' started by Vectrex, Jun 1, 2020.

  1. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    267
    This might be a dumb question, but why can't we tell an Entity directly what systems should operate on it? I don't understand why everything is this weird Entities.ForEach filtering mechanism. With no representation in the inspector at all (even in the mostly working and nice Tiny editor)

    For example, I couldn't find anyway to enable/disable a system operating on my entity for testing. I can't disable Data components also.

    I also came across multiple times where a system matches my components that I DON'T want it to. So I have to make a fake empty Entity or use string based "ByName" stuff. This seems hacky and clumsy and I've noticed this in multiple tutorials.
    Also wouldn't this cause large games to turn into spagetti? eg when some other programmer makes a new system that accidently matches your data components, then suddenly your Entity is going nuts? Or worse, an Entity that rarely gets used, so when you add new functionality to the game, you don't easily know what it's going to affect? How do I *know* my new system will *never* affect an unrelated part of a big project?

    Isn't every single system ForEaching through entities inefficient? Even for a single object like the Player?
    I would have thought being able to manually assign systems would be faster? Then the code wouldn't need the foreach stuff and could instead use the familiar 'RequiresComponent' attributes that Mono components use. In fact, everything would feel more similar to Mono.
     
    Last edited: Jun 1, 2020
  2. WAYNGames

    WAYNGames

    Joined:
    Mar 16, 2019
    Posts:
    992
    IMO, if you make your system to have a single responsibility you should not run into big issues.
    The querying of entities is the most efficient way to select what entity should be affected by the system as it is based on the archetype chunks and allow for the data layout to be perfect for iterating through.

    If making a new system changes the behaviour of an entity and mess up antoher system, you should propbaly rethink those systems, eihter they need to be merged or you are actually operating on 2 set of different entity archetype that need to be distinguish a diferrent component (enven tag component if necessary).
    Exemple you can have a several move system (on for walking/runing, one for flying, one for swimming, one for driving and so on). In that case you either make one system that manage every posible mobement 'mode' or one system per mode with a tag/state component that will tell the ssytem wich entity to affect.

    In future versions of entities, the enable/disable of component without affecting the actual archetype chunk memory, will probably make me use tag components more.
     
    Last edited: Jun 6, 2020
    Orimay likes this.