Dynamic Tile Spawning & Lifecycle

How the world dynamically expands and contracts based on player distribution. The garbage collection model for tile processors and preemptive neighbor spawning.

Overview

This episode covers tile lifecycle: how the world dynamically grows to accommodate players and shrinks to save resources, all while maintaining consistency at boundaries.

Key Topics

• Reference-counted tile lifecycle: active tiles hold references to neighbors
• Preemptive spawning: adjacent tiles spawn before entities reach boundaries
• Garbage collection: zero references = tile termination
• Density-aware replication: empty tiles aren’t triple-replicated

Tile Lifecycle State Machine

[Inactive] → spawn request → [Spawning] → ready → [Active]
                                            ↓
[Active] → entity count 0 for N ticks → [Quiescent] → ref count 0 → [Terminating]

Timestamps

Preemptive Spawning

When an entity is within 10 cells of a tile boundary:

1. Tile processor checks if neighbor tile exists
2. If not, requests spawn from Tile Manager
3. Tile Manager assigns to node with capacity
4. New tile initializes from DynamoDB or cold start
5. Boundary adjacency table updated

This ensures entities always have somewhere to move.

Kubernetes Integration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tile-processor
spec:
  replicas: 0  # Scaled by custom controller
  template:
    spec:
      containers:
      - name: processor
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "2Gi"
            cpu: "2000m"

Our Tile Manager is essentially a Kubernetes operator:

• Watches for Tile custom resources
• Scales Deployments to match active tiles
• Handles node affinity for latency optimization
• Manages graceful shutdown on tile termination

Next Episode

Episode 6 covers the first half of our optimization journey: protocol design and serialization.