Nextbots: Sandbox

Overview

Nextbots: Sandbox is an AI-heavy sandbox project focused on pursuit gameplay, reactive environments, and scalable runtime systems across WebGL, mobile, and PC targets.

The project originally started as an early production prototype, but rapid content growth exposed architectural scalability and maintenance problems that later required major runtime refactoring.

The long-term focus shifted toward runtime stability, async streaming, memory management, and scalable gameplay system ownership under production constraints.

Real Constraints

High AI density: large enemy counts active simultaneously during sandbox gameplay
WebGL limitations: strict browser memory constraints and unstable loading behavior
Low-end device targets: optimized for Android devices with ~2 GB RAM budgets
Scalable live updates: runtime content expansion without full scene rewrites
Stable frame pacing: maintaining responsive gameplay during enemy-heavy scenarios

Role & Ownership

Full gameplay and runtime architecture ownership
Refactored legacy systems into modular isolated runtime modules
Designed scalable async scene loading pipeline
Implemented AI scheduling and optimization systems
Maintained production updates and live runtime stability
Optimized gameplay systems against real player sessions and runtime load

Engineering Approach

Chunk-based async Addressables streaming
Strict modular gameplay runtime separation
Profiling-driven optimization workflow
AI update throttling and staggered scheduling
Object pooling across gameplay-heavy systems
Event-driven gameplay communication architecture

Key Technical Problems

Architecture scalability issues — gameplay systems became difficult to extend after multiple content updates due to tight coupling
GC spikes during async transitions — Task-based initialization pipeline generated unnecessary allocations during runtime loading
AI CPU scaling problems — per-frame navigation and targeting updates scaled poorly with enemy density

Optimization and refactoring work was continuously validated against production-scale gameplay sessions rather than synthetic benchmarks.

Postmortems (Key Fixes)

Gameplay Architecture Refactor

Issue: Architecture became increasingly difficult to extend after multiple production updates.

Root cause: Tight coupling between gameplay systems and scene-specific logic.

Fix: Refactored gameplay systems into isolated runtime modules with explicit ownership boundaries.

Result: Feature integration time reduced from ~6–10 hours to ~1–2 hours for medium-sized gameplay changes.

GC Spikes During Runtime Initialization

Issue: Noticeable GC spikes during async gameplay transitions.

Root cause: Task-based async flow generated avoidable allocations during initialization.

Fix: Migrated async runtime systems from Task to UniTask.

Result: Reduced allocations from ~1.2–2.5 KB/frame to ~0.2–0.4 KB/frame during transitions.

AI Update Scheduling

Issue: AI update cost scaled poorly with large enemy counts.

Root cause: Per-frame navigation and targeting evaluation for all active entities.

Fix: Introduced staggered AI update scheduling and throttled recalculation cycles.

Result: Reduced CPU spikes from ~5-10 ms to ~2-3 ms during high-density gameplay scenarios.

Systems Design

Chunk-based Addressables streaming pipeline
Modular gameplay runtime architecture
AI update scheduler for large enemy counts
Event-driven gameplay communication system
Async scene initialization pipeline
Object pooling across gameplay-heavy systems
Data-driven balancing and spawn configuration

Results

Stable runtime behavior across WebGL, mobile, and PC targets
Significant reduction of loading spikes on low-end devices
Reduced async transition allocations after UniTask migration
Improved scalability under high AI density scenarios
Faster iteration speed after architecture modularization

Scale & Usage

Total plays: ~1.8M
MAU: ~30K
Session length: 5–10 minutes
Platforms: WebGL, mobile

Tech Stack

Unity C# UniTask Object Pooling Modular Architecture