Search Unity

Decision Tree for FPS Sample and Jobs (or lack thereof?)

Discussion in 'FPS.Sample Game' started by drhodor, Nov 1, 2018.

  1. drhodor

    drhodor

    Joined:
    Aug 18, 2013
    Posts:
    39
    This is a post about high level decisions made for the architecture of a game created as the FPS Sample.

    tl;dr - Wondering how Jobs fit into a project of this type and scope (server authoritative, snapshot based, client side prediction, server side rollback). In general, are jobs (which are concurrent in nature) a bad idea for a snapshot based entity replication procedure? Or did the FPSSample team choose not to use Jobs based on the exigencies of bring as much of the ECS system into their own project as possible and not relying on the Jobs team's work?

    From what I've looked at so far, this project didn't seem to be Jobified at all!

    Here's what I saw: the systems derive from ComponentSystem (or a custom FPSSample subclass, <name of subclass -- think it's BaseComponentSystem). Instead of a Job System calling an Execute method, all of these Component Systems are manually created as managers and then their Update methods are called in one of the game loops which deserialize and and propagate the snapshots to the components that make up the world state.

    Now it's my understanding that this is a non-concurrent, Burst compiled way to go. Even if it does have immediate benefits from being Data Oriented and friendly to a non-allocating native app via IL2CPP at the end of the day.

    I was wondering what the design decision tree to go in this route was. Obviously it makes some sense to have all of the tickets for the loop go down on the main thread, however there seems to be a lot left on the table given that even the transport layer project has examples that use the Job System. Given that SceneEntity.cs instead of GameObjectEntity's (a facet of the Hybrid system) I wonder if there just wasn't enough time to do a version of the FPS Sample with all of the latest and greatest going into the Jobs system or if it truly is the vision to keep it working like this. Are burst / jobs a bad idea in a system that pumps snapshots through the main loop like this? I know that the transport layer sample projects have job-ified networking that waits until after FixedUpdate...

    I know that (custom written, non-Unity ECS) Jobs are used in big multiplayer Unity games -- so it at least seems feasible.
     
    drhodor, Nov 1, 2018
    #1

  2. Mogens_H

    Mogens_H

    Unity Technologies

    Joined:
    Mar 7, 2017
    Posts:
    20
    The primary reason we only have a few jobs is because we wanted to limit our depencencies to systems being developed. We try to structure our code in a way where it is possible to change systems to jobs and we will start "jobifying" more in the future. Currently our main concern is the general structure of the game code and adding core features needed for an FPS - but in that process we also try to make as much as possible "pure" ECS so it is ready for jobs and burst at some point.
    The abilities are already pure ECS (on my machine - you will get it soon) and could be updated by jobs and I really want to change the HitCollision code to not use Unity physics system, but rather something "burstable".

    There will be areas that will stay "hybrid" for a while, like client side presentation stuff (like UI) and the network systems and ReplicatedEntityModule (while more work is being done on the new networking stack).

    Regarding SceneEntity.cs - it is a leacy thing and will be removed at some point.

    But now that you mention it ... maybe it is time to add some more jobs
     
    Mogens_H, Nov 1, 2018
    #2