As a developer, I want to be able to have a seperate dev room to perform tests in

[jChicote]

Description

The only playable and testable area is the MAINSCENE (production level). This can make it challenging as any work and testing is being done in the main production scene.

Acceptance Criteria

• When setting up a test scene, there are prepacked assets ready to be just dragged and dropped.
• Test scenes can be created and fully self contained and configurable.
• The scenes can operate without needing to setup extensive objects

Implementation

1. Investigate the extent of the damage and devise an execution plan
2. Perform fixes and necessary changes to the scripts
3. Package all the required prefabs into a test-ready package
4. Test with empty scene.

[jChicote]

Blocked

Managing the existing services to exist in its own environment will require extensive rework of the management, singletons and services due to both tight coupling and object intimacy

[jChicote]

New Approach

Instead of trying to convert the existing behavior to manage on their own, they can exist within a boot scene and be handled from there. Additionally seperate classes will be used to handle the dependencies of the different objects within the scene.

Additionally there needs to be a partition of objects that are persistent, objects that are scoped to the scene and those that are transient

[jChicote]

Changes to the approach:

• The GameManager will be tailored to have executive functions to the game such as: Running the GameSetup, Possessing persistent references to persistent non-singleton Services.
• No ServiceContainer equivalent will be needed. Instead the singleton pattern will be used extensively
• The DebugGameSetupHandler setup and DebugSceneSetupHandler will work hand in hand to run the debug scene with all the required services and logic by ensuring they are prepared before the developer interacts with the runtime scene.
• GameSetupHandler and SceneSetupHandler will be used to handle the setup and initialisation of scenes in a predictable manner. This ensures that there are very little race conditions to contend with when using the Unity lifecycle
• High level objects will require initialisation and setup through the GameSetup or SceneSetupHandler
• SceneSetupHandler will be used in official scenes being developered. Normal test environments can instead use a customised debug scene setup handler that executes setup commands in sequence for passed in objects

  • This will not be the same with the production scene, it will rely on hard-coded setup handling to ensure immutability from the designer / inspector.

Direction with development of components and their seperation of concerns:

• Need to avoid extensively using the singletons from low level components or nested components. This becomes harder to untangle when it comes to fixes. Instead should be reserved for higher level object where their scope injects their dependencies into these related sub-components
• The word 'Manager' needs to be reserved for persistent high-level objects instead. This becomes confusing as objects that are named Manager are only responsible for a small collection of behaviors that are tied to the active gamescene. Instead its lower level alternatives instead 'Controller', 'Handler', etc.
• Dependencies especially those of components not belonging to the same GameObject should be injected instead of globally located from the component. Introduces coupling as Unity's service locations cannot resolve the signatures of interfaces.

[jChicote]

Next Actions

• [ ] Sort out the scope of the different high-level components (whether the beloing globally or locally)
• [ ] If start method is data reliant, change to be invoked from seperate methods
• [ ] Propose better folder structure that will be more verbose for future changes

With seperate local debug scene

Acceptance Criteria:

• Only the player object should exist
• The input is properly possessed
• The UI can optionally appear
• Player's dependencies are handled

Implementation:

• [ ] Move a player prefab to a debug scene
• [ ] Identify the ends needing to be connected.
• [ ] Create a DebugDependencyResolver for the player

  • Internally resolves the Players dependencies without adding extensive mutating behavior

• [ ] Create a DebugStartupHandler
• [ ] Hookup the player dependency resolver to the startup handler