Antillery Devlog #4

Problem

Before building any gameplay systems in Antillery, I needed a reliable, flexible way to manage the overall structure of the game. This includes switching between scenes like the Main Menu, Match Setup, the active game loop, and Post-Match summary.

Key Challenges

• Prevent tight the tight coupling that would occur if states handled their own transitions.
• Ensure that scene transitions are clean, observable, and modular.
• Allow for easy debugging and extensibility of the application flow.
• Support a flexible architecture that can adapt to future gameplay systems.
• Maintain a clear separation of concerns between state logic and transition management.
• Allow designers to create and modify game flow without needing to write code.
• Ensure that the application flow is version-control friendly and inspector-friendly.

Approach

I designed a modular architecture to provide flexibility and clear separation of concerns between different aspects of the application flow.

Architecture Overview

The implemented application flow architecture uses a modular, ScriptableObject-driven state machine backed by a polymorphic IState interface, enabling clean, observable transitions between game scenes.

Core Systems

• IState.cs - interface contract for all state logic
• State.cs - base SO implementation with lifecycle + scene handling
• StateMachine.cs - tracks active/previous state, handles transitions with safety guards
• AppManager.cs - SO configuration container for initial state and registration
• GameFlowManager.cs - MonoBehaviour that connects state signals to transition logic

Example state and transition flow:

public event Action OnPlaySelected;

public override void Update()
{
    if (Input.GetKeyDown(KeyCode.P))
        OnPlaySelected?.Invoke();
}

mainMenuState.OnPlaySelected += () =>
{
    stateMachine.ChangeState(matchSetupState);
};

Results

The application state system is complete and functional:

Limitations

Centralized Transition Management

One limitation of the current architecture is that the GameFlowManager becomes a central point that must be aware of all systems that could trigger state transitions. As the project grows, this could lead to:

• A bloated GameFlowManager that knows too much about disparate game systems
• Potential tight coupling between the manager and various specialized systems
• Scalability challenges when adding new types of state transitions

Forced Additive Scene Loading

A significant limitation I've discovered is that using a persistent GameFlowManager MonoBehaviour forces all scenes to be loaded additively rather than replacing the current scene:

• This creates performance overhead from maintaining multiple scenes simultaneously (e.g., having the menu scene still loaded while playing)
• Requires complex management to hide/show objects between scenes
• Increases memory usage by keeping multiple scenes resident
• Creates potential conflicts between scene-specific systems and resources
• Complicates object references and scene hierarchy management

Future Improvements

For the next iteration, I'm exploring potential solutions such as:

• A more decentralized event bus system that allows systems to broadcast state change requests
• State transition rules defined in data rather than hardcoded in the GameFlowManager
• Hierarchical state machines that handle domain-specific state changes locally
• A DontDestroyOnLoad-based service locator pattern that persists without requiring additive scenes
• Scene-independent state persistence using ScriptableObjects to maintain state between full scene transitions

For now, the centralized approach is sufficient for the current scope, but future scalability will require addressing these architectural considerations.

Project Impact

This architecture milestone sets the foundation for all gameplay systems in Antillery.

By developing a clean, modular, event-driven app flow with interface-backed flexibility, I've removed friction for future development of in-match logic, input context switching, UI overlays, and more.

The project is now version-control friendly, inspector-friendly, and scalable, ready for iterative solo work but also cleanly extensible for future collaborators.