verekia-architecture

Architecture

The core principle of R3F game development is separating game logic from rendering. React components are views, not the source of truth.

Systems vs Views

Systems contain all game logic:

• Movement, physics, collision detection
• Spawning and destroying entities
• State mutations (health, score, timers)
• AI and behavior
• Syncing Three.js objects with entity state

Views (React components) only render:

• <PlayerEntity>, <EnemyEntity> wrap models with ModelContainer, process any data needed and pass it as props to the model
• <PlayerModel>, <EnemyModel> are dumb and only render meshes via props
• They don't contain core game logic, just visuals logic
• No useFrame in view components unless it is purely visual and should not be part of the core logic

Headless-First Mindset

Games should be capable of running entirely without a renderer:

┌─────────────────────────────────────────┐
│            Game Logic Layer             │
│  (Systems, ECS, World State, Entities)  │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│            View Layer (optional)        │
│   React Three Fiber / DOM / Headless    │
└─────────────────────────────────────────┘

This means:

• All state lives in the world/ECS, not in React components
• Systems iterate over entities and mutate state
• Views subscribe to state and render accordingly
• You could swap R3F for DOM elements or run tests headlessly

Miniplex: What NOT to Use

From miniplex-react:

• ECS.Entity - Don't use this component
• ECS.Component - Don't use this component
• ECS.world - Don't access world through ECS, use direct import
• useEntities hook - Don't use this
• Render props pattern - Don't use this

From miniplex core:

• onEntityAdded / onEntityRemoved - Prefer using data and systems to trigger things (e.g., timers, flags)
• .where() - Don't use predicate-based filtering, prefer iterating over all entities that have the component no matter its value. For example iterate over all entities that have health and filter out entities that have health < 0 in the system rather than querying entities where health < 0 (which would require reindexing).

Miniplex: Preferred Methods

Only use these:

• world.add(entity) - Add a new entity
• world.remove(entity) - Remove an entity
• world.addComponent(entity, 'component', value) - Add component to existing entity
• world.removeComponent(entity, 'component') - Remove component from entity
• world.with('prop1', 'prop2') - Create queries
• createReactAPI(world) - Get Entities component for rendering

Entity Types and Queries

// lib/ecs.ts
import { World } from 'miniplex'
import createReactAPI from 'miniplex-react'

type Entity = {
  position?: { x: number; y: number; z: number }
  velocity?: { x: number; y: number; z: number }
  isCharacter?: true
  isEnemy?: true
  three?: Object3D | null
}

export const world = new World<Entity>()

export const characterQuery = world.with('position', 'isCharacter', 'three')
export type CharacterEntity = (typeof characterQuery)['entities'][number]

// Only destructure Entities from React API
export const { Entities } = createReactAPI(world)

ModelContainer Pattern

Capture Three.js object references on entities using a wrapper component, allowing systems to manipulate objects directly.

Similar to the Redux container/component pattern:

• ***Entity** components are smart wrappers that connect entity data to the view
• ***Model** components are dumb and only responsible for rendering

┌─────────────────────────────────────────┐
│  PlayerEntity (smart)                   │
│  - Wraps with ModelContainer            │
│  - Passes entity data as props          │
│                                         │
│    ┌─────────────────────────────────┐  │
│    │  PlayerModel (dumb)             │  │
│    │  - Pure rendering               │  │
│    │  - Receives props               │  │
│    │  - No knowledge of entities     │  │
│    └─────────────────────────────────┘  │
└─────────────────────────────────────────┘

• Ref callback stores the Three.js object on the entity
• Cleanup function removes the reference when unmounted
• Systems access entity.three directly in useFrame
• Models are reusable and testable in isolation

Entity as Props Pattern

The component passed to <Entities> receives the entity directly as props:

// Dumb component - only renders, no entity knowledge
const CharacterModel = () => (
  <mesh>
    <sphereGeometry />
    <meshBasicMaterial color="blue" />
  </mesh>
)

// Smart wrapper - connects entity to model via ModelContainer
const CharacterEntity = (entity: CharacterEntity) => (
  <ModelContainer entity={entity}>
    <CharacterModel />
  </ModelContainer>
)

// entities/entities.tsx (contains <Entities> for all renderable entities)

const isCharacterQuery = world.with('isCharacter')

export const CharacterEntities = () => <Entities in={isCharacterQuery}>{CharacterEntity}</Entities>

Systems and Queries

Query Placement

Define queries near where they are used (in the system file), not in a central file. But define them outside the loop at module scope:

import { world } from '@/lib/ecs'

// ✅ Query defined at module scope, near where it's used
const movingEntities = world.with('position', 'velocity')
type MovingEntity = (typeof movingEntities)['entities'][number]

One + System Pattern

Split logic into a "One" function (operates on a single entity) and the system (iterates and calls One):

import { world } from '@/lib/ecs'

// Query at module scope
const movingEntities = world.with('position', 'velocity')
type MovingEntity = (typeof movingEntities)['entities'][number]

// "One" function - single entity logic, easy to test
const velocityOne = (e: MovingEntity, dt: number) => {
  e.position.x += e.velocity.x * dt
  e.position.y += e.velocity.y * dt
  e.position.z += e.velocity.z * dt
}

// System - just iteration
export const VelocitySystem = () => {
  useFrame((_, dt) => {
    for (const e of movingEntities) {
      velocityOne(e, dt)
    }
  })

  return null
}

Query by Components, Not Types

Systems must iterate over queries tailored to their specific needs, not over entity types:

// ✅ GOOD - Query targets entities with the components the system needs
const entitiesWithVelocity = world.with('position', 'velocity')

const VelocitySystem = () => {
  useFrame((_, delta) => {
    for (const entity of entitiesWithVelocity) {
      entity.position.x += entity.velocity.x * delta
    }
  })
  return null
}

// ❌ BAD - Iterating over specific entity types
const VelocitySystem = () => {
  useFrame((_, delta) => {
    for (const player of players) {
      /* ... */
    }
    for (const enemy of enemies) {
      /* ... */
    }
    for (const projectile of projectiles) {
      /* ... */
    }
  })
  return null
}

The point of an ECS is that systems operate on a subset of entities matching exactly what they need. A VelocitySystem targets entities with velocity, not "players + enemies + projectiles".

ThreeSystem - Syncing Three.js

const threeEntities = world.with('position', 'three')
type ThreeEntity = (typeof threeEntities)['entities'][number]

const threeOne = (e: ThreeEntity) => {
  e.three.position.set(e.position.x, e.position.y, e.position.z)
}

export const ThreeSystem = () => {
  useFrame(() => {
    for (const e of threeEntities) {
      threeOne(e)
    }
  })

  return null
}

Spawning Entities

const SpawnSystem = () => {
  useEffect(() => {
    world.add({ position: { x: 0, y: 0, z: 0 }, isCharacter: true })
  }, [])

  return null
}

Zustand Store Usage

Zustand stores are for state that doesn't belong in the ECS. Each store has a consistent API pattern:

// In React components (reactive)
co