Migration Guide¶
Migration Strategy¶
- It's a gradual refactoring.
- Individual developer will perform small changes while doing other game-feature tasks.
- Everyone is aware of the Target Architecture that this migration want to achieve.
- Many Refactoring Patterns will be added to this document to help developer identify these quick and small changes.
- These changes are optional, developers should decide to do them on their own.
- Even though the changes are small, it should bring immediate benefits.
Refactoring Patterns¶
Each pattern consists of four sections: what, why, how and progress.
- What: show what needs to be refactored. This helps how to identify which part of the current code belong to the pattern
- Why: explain why do we need this refactoring and what is its immediate benefits as well as its final function in the Target Architecture (if they differ).
- How: how to perform the refactoring.
- Progress: how to measure progress. For example, reference counting. Not all pattern has this section nor is it relevant.
Content:¶
- SystemBase to ISystem
- Reverse One-To-Many Relationship
- Jobify Entities Creation
- Jobify Add Component
- Generic Container to Native Container
- Inheritance to Generic Struct
- Avoiding Command Buffer
- Split DOTS code out of UI
- Moving queries to the Bridge layer (Pull Data from DOTS Layer)
- Hybrid Baker to SubScene Baker and Baking System
- Move managed components out of DOTS code
- Use Tag components to publish changes to the Bridge layer (Push Data to Managed Layer)
- Move strings out of DOTS code
- Make MonoBehaviour components accessible in the Bridge layer
- Emulate C# features using struct