Toy Update

tim-cain game-design prototyping toys star-raiders star-control-2 rpg scope-management system-mechanics

Abstract

Problem: How do game developers transition from mechanical prototypes ("toys") to full games, and what's the value of maintaining a library of small experimental projects?

Approach: Tim Cain gives a one-year progress update on his hobby projects — particularly a Star Raiders-inspired space combat simulator — walking through the features he's added, ideas he's considering, and why he deliberately keeps calling it a "toy" rather than a "game."

Findings: Toys become games when they acquire setting, story, and purpose — not just more mechanics. Cain's space combat toy has grown significantly but remains a prototype because he's exploring systems without grounding them in narrative. He also highlights Star Control 2 as proof that RPGs don't need bipedal characters, suggesting vast unexplored design space.

Key insight: Building toys — small mechanical prototypes with no story obligation — creates a personal library of implemented ideas you can pull from when a real game concept emerges. The toy-to-game transition requires setting → story → mechanics, and skipping that pipeline means you're still prototyping no matter how polished the systems are.

Source: https://www.youtube.com/watch?v=CA7gIg5b6_8

Context

This is a follow-up to an earlier video where Tim discussed small hobby projects he calls "toys" — not games, but mechanical experiments. A year later, he revisits his space combat simulator and reflects on the toy-to-game boundary.

Space Combat Simulator Progress

Tim's primary toy is a space combat game inspired by Star Raiders (1979), one of his all-time favorite games. Since the original video, he has:

  • Extracted and integrated authentic Star Raiders sound effects
  • Added varied starting scenarios: planetary systems, space stations, asteroid fields
  • Continued iterating on the core combat feel

Planned Weapon Systems

Tim has a backlog of torpedo variants he wants to implement, all building on the projectile-based combat model (deliberately avoiding instant-hit phasers to preserve the skill element):

  • Gravity torpedoes — push ships away or pull them in
  • Disabling torpedoes — temporarily knock a ship out of combat (sparkle and spin), enabling crowd-control tactics against larger fleets
  • Virus torpedoes — convert enemy ships to fight on your side temporarily

Shield System Redesign

Rather than simple on/off shield visibility, Tim envisions a multi-layered visual feedback system:

  • Shields start transparent, become translucent as they absorb damage
  • They expand in size to increase surface area for energy dissipation
  • Color shifts from deep red → bright blue → violet, representing higher-energy radiation as the shield works harder
  • All of these properties are quantizable — shield capacity, dissipation rate, expansion factor — making them suitable for RPG-style upgrades

The Ship-as-Character RPG Model

Citing Star Control 2 as a key inspiration, Tim notes that RPGs don't require a humanoid protagonist — the ship itself can be the character. His upgrade loop:

  • Destroy enemy ships → collect wreckage → analyze debris → unlock upgrades
  • Built-in difficulty scaling: better loot comes from tougher enemies, so progression naturally demands harder fights
  • Planetary exploration via shuttlecraft on procedurally generated terrain, scavenging ruins for analyzable artifacts
  • Surface combat with a different model than space combat

Scope Awareness

Tim explicitly catches himself expanding scope and pulls back. When planetary exploration ideas led to thoughts about animated characters and first/third-person gameplay, he recognized this would blow up the project and defaulted to simpler shuttle-based exploration with procedural terrain — a scope-conscious decision even in a hobby project.

Why This Is Still a Toy

Tim's core framework for game development is: setting → story → mechanics. His space combat project inverts this — he's building mechanics first with no setting or story. By his own definition, this makes it a toy or at best a prototype, regardless of how many systems it contains.

He emphasizes this distinction not to diminish the work, but to be honest about what stage the project is at. A game needs narrative purpose; a toy is pure mechanical exploration.

The Value of Toys

Tim's closing argument for maintaining hobby prototypes:

  • You learn coding and engine architecture
  • You build a personal library of implemented mechanics ready to be pulled into future projects
  • When a real game idea arrives (setting + story), you already have tested systems that might support it
  • Star Control 2 proved decades ago that unexplored RPG design space exists — yet most RPGs still default to bipedal characters collecting loot. There's room for something different.

References