Data-Driven Content
JSON guests, Resources, roster, SpriteFrames paths, tradeoffs for jam size.
On this page
What we implemented
Each NPC is one JSON file under resources/guests/. A roster lists who can spawn:
{
"spawn_cooldown_seconds": 8,
"default_spawn_position": [378, 605],
"guests": ["beth", "kane", "..."]
}GuestLoader parses JSON into GuestData / GuestSchedule / GuestDialog resources at runtime (FileAccess + JSON.parse_string).
Why JSON (for this project)
- Writers can edit dialog without the Godot inspector.
- Adding an NPC is “new file + roster entry + art paths”.
- Diff-friendly in git.
Tradeoffs
| Approach | Pros | Cons |
|---|---|---|
| JSON → Resources | Easy edits, no .tres sprawl | Parser code; path typos fail at runtime |
Pure .tres in inspector | Native, typed | Painful for long dialog |
@export arrays on scenes | Fast prototype | Does not scale to 10 NPCs |
Recommendation at jam size: JSON (or a spreadsheet export) for dialog/schedules; keep engine wiring in a single guest scene. We already deleted the per-guest .tres dialog chain.
Resources still useful
SpriteFrames stays a .tres (animation editor). JSON only stores the path string.
Typed data after parse
Loader turns station name strings into Station.Id via Station.Id.has(name). Invalid names should error loudly — silent wrong stations waste playtest time.
What not to data-drive yet
Navmesh polygons, camera Room rects, and wall generation stayed in hotel_layout.gd as measured rectangles — content that is inherently spatial/code-owned.