Search Unity

Will ECS Make Unity Dev The New Wild West Or Will In Built ECS Systems Save The Day?

Discussion in 'Entity Component System' started by Arowx, Oct 23, 2018.

  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    ECS allows small reusable systems to do simple game tasks, and be re-used for all game objects that need those tasks to be done.

    The thing is once this is live everyone from the asset store to youtube tutorials will be writing their own move, collision, raycast systems then the problems become integration issues with duplicated ECS systems or competing ECS systems that react to the same data filtered pattern...

    So will Unity need to provide a base set of common ECS systems that can be utilised (hint: do not run automagically) and provide a common framework for assets/tutorials and the community to work with?

    Imagine how easy it would be to make a game in Unity if developers just need to create some entities in the Editor and drag and drop the systems they need then let them run with a bit of setup data and game mechanics/logic specific to their game?
     
    Sylmerria likes this.
  2. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    559
    this is the key

    currently, a default world is created and populated with everything found in every assembly.
    I would prefer an asset-based setup approach, similar to how PostFX profiles / HDRP volumes work:
    - you create a World asset
    - you add your systems to it (bonus: you can set configuration data via inspector here instead of pulling a
    GameObject.Find("SystemXxxSettings")
    as the samples do)
    - [optional] you have a "world runner" script in the scene that creates the world and setup the player loop in OnEnable, and disposes in OnDisable. this would link worlds to scenes (you can
    DontDestroyOnLoad
    if you want to persist for the whole app lifetime)
    - [optional #2]
    GameObjectEntity
    -- or the equivalent "put the entities in the scene/hierarchy at editor time" mechanism -- that are children of a World / world runner, will operate in that world instead of World.Active

    ps: the whole World.Active thing needs to disappear, it's too easy to get it wrong (i.e. when having multiworld, a system is doing
    World.Active.GetOrCreateManager<EntityManager>()....
    , and nothing prevents that)
     
    e199 likes this.