Data-Driven Architecture

Philosophy

SiliconGhetto is designed to evolve toward a fully data-driven game engine where scenes, entities, and gameplay can be defined through structured data rather than imperative code.

Why Data-Driven?

  1. AI-assisted authoring: Structured specs enable AI tools to generate valid game content.
  2. Tooling: Visual editors, validators, and linters can operate on data.
  3. Hot reloading: Data can be reloaded without recompiling WASM.
  4. Portability: Game definitions transcend implementation language.
  5. Validation: Schemas enforce correctness at the data boundary.

Component Serialization

ECS components in sg_scene are divided into two categories:

Authorable Components (Serializable)

These represent game content that can be authored, saved, and loaded:

  • Transform2D, Transform3D — Position, rotation, scale
  • Sprite — Visual appearance
  • Velocity2D — Movement state
  • CollisionBox — Collision bounds
  • Health — Game state
  • Name — Labels

Runtime Components (Not Serializable)

These are engine internals that exist only during execution:

  • GPU buffer handles
  • Cached computed values
  • Internal scheduling state

Future: Game Specs

The long-term vision is a manifest-driven game definition:

# sg-game.toml
[scene.player]
transform = { position = [400, 300] }
sprite = { width = 24, height = 24, color = [0.2, 0.8, 0.3, 1.0] }
collision_box = { width = 24, height = 24 }
health = { max = 100 }
tags = ["player"]

[scene.enemy.template]
sprite = { width = 20, height = 20, color = [0.9, 0.2, 0.2, 1.0] }
collision_box = { width = 20, height = 20 }
health = { max = 50 }
tags = ["enemy"]

[scene.enemy.instances]
count = 10
spawn_area = { min = [0, 0], max = [1200, 1200] }

This format is not yet implemented but informs architectural decisions today.

Validation Pipeline

Author/AI → Structured Spec → Schema Validation → ECS Instantiation → Runtime

Each step validates the data:

  1. Schema validation: JSON Schema or TOML structure check
  2. Semantic validation: Component compatibility, reference integrity
  3. Runtime validation: Resource availability, capability checks