This project is a Unity case study implementation of an infinite Battle Pass UI with a modular service-based architecture.
The main goal of the project was to build a scalable Battle Pass system that can support a very large number of levels while keeping the UI smooth, reusable, and separated from the core gameplay logic.
The project is organized into three high-level system layers.
A strict assembly definition structure is used throughout the project:
- L0 and L1 systems each have their own dedicated Assembly Definition File (``)
- L2 systems share a single Assembly Definition File
This separation enforces clear dependency boundaries between reusable systems and project-specific implementation code.
L0 contains general-purpose systems that are not specific to the Battle Pass feature and can be reused in other Unity projects.
Each L0 system is isolated in its own assembly definition to maintain strict modularity and dependency control.
A basic logging system with support for normal logging and typed logging using generics.
A global service system based on a Service Locator pattern with IOC container-style logic.
Services can be registered and accessed globally through the main IOC container, allowing different systems to communicate without having direct scene dependencies.
A basic Unit of Work-style repository system used for syncing custom data repositories.
This is mainly used to keep data handling separated from the gameplay systems that consume the data.
A custom update scheduler that allows services and non-MonoBehaviour systems to receive update callbacks without needing their own Update, FixedUpdate, or LateUpdate methods.
It supports:
UpdateFixedUpdateLateUpdate
Each update type also has three execution orders:
PreCurrentPost
This makes it easier to control service update order in a predictable way.
A basic readonly ScriptableObject variable container.
In this project, it is mainly used for editor-safe referencing of integer-based IDs.
L1 contains systems that are more game-specific than L0, but still reusable across different projects.
Like L0, each L1 system is placed in its own assembly definition to preserve modularity and allow independent reuse.
The Finance System handles in-game currencies.
Internally, each currency is identified by an integer-based CurrencyID. For editor-safe referencing and asset-based configuration, these IDs are exposed through IntSO ScriptableObjects.
The system is responsible for:
- Currency validation
- Adding and removing currency
- Checking balances
- Persisting currency data
The Battle Pass System handles the core Battle Pass logic and persistence.
It contains settings for defining free and premium rewards per level. Rewards are currently basic soft and hard currency amounts.
The system is responsible for:
- Battle Pass progression
- Free reward claiming
- Premium reward claiming
- Premium unlock state
- Reward lookup by level
- Current level calculation
- Communicating with the Finance System when rewards are claimed
The Battle Pass System does not directly handle UI. It only manages data and gameplay logic.
The Battle Pass UI is a custom infinite scroll implementation.
Instead of relying on a continuously growing content position, the system recycles UI elements as the user scrolls. This avoids floating point precision problems that can happen when scrolling through a very large number of levels.
The UI only keeps a small number of visible elements active at a time, reuses pooled elements, and keeps their local positions within a small visible range.
This allows the Battle Pass list to support a very large number of levels while keeping the scrolling smooth.
The implementation also exposes events so other systems can react to UI interactions without tightly coupling to the scroll logic.
L2 contains project-specific systems that connect the reusable systems together into the final case study flow.
Unlike L0 and L1, all L2 systems share a single assembly definition.
This reflects their role as project composition code rather than independently reusable modules.
Handles the basic main menu flow and connects menu buttons to the project systems.
Controls the Battle Pass popup screen and connects the Battle Pass UI with the Battle Pass System.
It is responsible for displaying the current Battle Pass state, reacting to button clicks, and updating the UI after rewards are claimed.
The project uses installer and destructor classes to control service creation and cleanup.
This keeps service initialization and teardown explicit instead of relying only on scene object lifecycle order.
- Modular layered architecture
- Strict assembly definition boundaries for reusable systems
- Dedicated
.asmdefper L0 and L1 system - Shared
.asmdeffor all L2 systems - Global service registration and access
- Repository-based data handling
- Custom update scheduler for non-MonoBehaviour systems
- Finance system with persistent currency data
- Integer-based currency IDs with editor-safe
IntSOreferences - Battle Pass system with free and premium rewards
- Infinite Battle Pass UI with element recycling
- Small active UI pool for large level counts
- Floating point precision-safe scrolling approach
- Clear separation between core logic and UI logic
This project was built as a case study, so some systems are intentionally simplified.
The main focus was to demonstrate architecture, separation of concerns, assembly-level modularity, service-based systems, persistence, and a scalable infinite Battle Pass UI implementation.
Some sprites and icons used in this project were provided as part of the case study assignment.
These assets are included only for demonstration and review purposes within the context of this technical case study. They are not original project assets and are not intended for reuse, redistribution, or commercial use.
The source code in this repository is provided for portfolio and review purposes.
Third-party or assignment-provided assets, including sprites and icons, are not covered by this license and should not be reused or redistributed.