Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Basics questions on ECS and jobs

Discussion in 'Entity Component System' started by sixolar, Apr 18, 2018.

  1. sixolar

    sixolar

    Joined:
    Jan 8, 2014
    Posts:
    37
    Hi, I'm really excited about these new features, I've been watching GDC talks and read about it for the past week and what I understood is that it's not quite ready yet for pure ECS as there is some important features missing like physics and animations. But I would like to jump in as soon as it has everything I need for the game I'm working on, and I'm a slow learner so better understand the concept in advance !

    There is some things I'm not sure of :
    1. Do really any game benefit from ECS, or DoD in general?
    From what I saw, this is best in cases of large scale games with a lot of reused, or similar, entities, what about a game like Super Meat Boy, where there is almost nothing else than the player and a few (moving or not) deadly colliders? What about low scale online games like an online 1v1 versus fighting game?

    2. Is the ECS system meant to be used without scene change?

    3. Can jobs be used only for handling operations like db requests asynchronously? Or is there something simpler/more performant for that?

    Thanks !
     
    Last edited: Apr 19, 2018
  2. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    1. In theory ECS code and data should be faster and smaller, as you break down big kitchen sink objects like MonoBehaviour and use tiny data structs and Systems that use/manage/update those structs. So you should see reduced memory footprint and higher speeds or lower CPU usage that decreases power usage for mobile platforms.
    In addition even with low number of unit scales you can do more effects and have higher quality settings and still hit your target fps.

    2. Interesting question? Scene changes are often there to clear the old data and load in new, mostly as the name implies these are Scenery items e.g. new level. However you will need to restart or clear out old data and re-launch ECS systems that are used in the next scene.

    3. [Not Sure (Anyone?)] As the Jobs system will be compiled by the Burst compiler to native SIMD code I'm guessing that DB access might not be a thing it is designed to do. However it is a multi-threaded system so it hopefully will provide some asynchronous file/DB operations. .Net 4.6 does have parallel and threaded API's that could probably work well with DB access.
     
  3. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    Any game that can benefit from a performance gain can benefit from the ECS (unless you are GPU-bound). And any game that runs under 144 fps is in need of a performance gain :D

    Aside from performance, ECS is also a very good way of making good, well-organised code that won't end up crumbling under its own complexity and incoherences. It kinda forces you to do things right. In the context of working with a team, this is extremely useful
     
    Last edited: Apr 18, 2018
    RaL, teutonicus, Krajca and 1 other person like this.
  4. sixolar

    sixolar

    Joined:
    Jan 8, 2014
    Posts:
    37
    Thanks both of you, seems the ECS is good in any case indeed.

    The third question is still giving me hard time though, I've read from Joachim that having a secondary multithreaded system is bad because then it fights with the JobSystem for CPU usage... But I've also read that the JobSystem can very well schedule jobs on the main thread, effectively stalling it. That would not be a problem for most operations, but for DB requests I can't afford to freeze the game while waiting for the request to execute.. I just can't find a solution/good answer anywhere...
     
    Last edited: Apr 19, 2018
  5. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Can I ask why you are using a database as it sounds like it's central to your game/app and how much data will you need from it per a frame?

    Look at it this way with ECS you should be able to set up the game to run lightly across a number of threads reducing it's impact on DB access. Also hopefully you will be able to allocate threads to ECS and others to your DB queries.

    For more technical discussion knowing more about what type of database and how it is accessed would be needed along with someone with more in depth knowledge of managing ECS than me.
     
  6. sixolar

    sixolar

    Joined:
    Jan 8, 2014
    Posts:
    37
    DB access was just an example, I'm using API that can do DB queries among other things like communications with services. All these API call are synchronous, the thread calling is waiting for the response, for now there are called from the main thread and therefor freeze the game for something like 30ms, that's not that much but it can be more.
    There is no call 'per frame' these calls are mostly results of user actions like fetching a leaderboard, registering to matchmaking, etc.

    I was thinking of having a dedicated thread for these calls and maybe even use a queue system, but I'd like to be sure that if I do that in parallel of the JobSystem the former will not get a performance hit by having (sometimes) a blocked thread. I'm afraid that it could stall the main thread if a job is schedule in a thread, this thread is blocked for let's say 100ms by a DB request and I call job.Complete() on the main thread, but maybe I'm totally wrong...
     
  7. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    I think this should not be an issue, try it if it is get in the way, contact Unity support. As the ECS ideally should work with available threads and have some kind of thread management/allocation built in.
     
    Last edited: Apr 19, 2018
  8. andywatts

    andywatts

    Joined:
    Sep 19, 2015
    Posts:
    110
    I use Unity.Jobs just for CPU bound jobs.
    For IO bound jobs like database or web, I think coroutines are probably still the way to go.

    Having said that, you likely could use the job system.
    Just know you're occupying a hyperthread for the duration and use jobHandle.IsComplete to check for completion in your Update.