Toy Post Mortem

Why a "Toy" Post Mortem

Tim explains he won't do post-mortems of other people's games because they inherently include harsh criticism. He has written private post-mortems for all his own professional games, and even for Fallout 3 and 4 (which he sent to Bethesda), but won't publish those because they involve other people's work. Instead, he applies the post-mortem format to his personal space game — a project his YouTube audience watched him build across five update videos — calling it a "toy" or "game shell" rather than a finished game.

What Went Well

Faithful Recreation of Star Raiders

Tim was obsessed with Star Raiders on the Atari 800 in the late 1970s — so obsessed that he figured out how to copy the cartridge to disc solely to decompile and read the code. He believes his Unity project recognizably recreates that childhood game. Anyone who played Star Raiders would look at it and say "I see what you did there."

Modernizing a Retro Game

While staying faithful, he found ways to make it feel more modern — particle effects, smoke trails on ships — that give it a retro aesthetic through contemporary techniques. The game looks newer but still feels retro.

Learning New Engine Skills

Having worked on Pillars of Eternity and Tyranny on large teams, Tim never touched many parts of the Unity engine. Building this toy taught him particle effects, render trails, and other systems he'd never used. Several of his update videos were essentially him excitedly showing off what he'd just learned.

The Joy of Making It

Tim considers this the biggest pro. He had a ton of fun making the toy, and he's a firm believer that joy in development shows up in the final product. He points to Troika's three games (including Temple of Elemental Evil, his worst-reviewed game) — all now considered classics despite poor sales or reviews — and attributes this partly to the genuine fun the team had making them, despite the stress, long hours, and crunch. He contrasts this with modern games that launch, exist for a few weeks, and disappear: "There's no joy in them."

What Went Wrong

Broke His Own Rule: Setting → Story → Mechanics

Tim's cardinal rule for game development is: create the setting first, then the story, then the mechanics. Because he was replicating a childhood game, he jumped straight to mechanics. The result: an undeveloped setting ("roughly sci-fi with spaceships"), no story whatsoever, and no answer to "what is the player supposed to be doing beyond flying around and upgrading?"

Inconsistent Art and Weak UI

Without a defined setting, the art style is incoherent — free assets from the internet and the Unity store that don't necessarily belong together. The UI is functional but ugly. Tim acknowledges he can't do art and doesn't enjoy doing UI work. Both shortcomings trace back to the same root: no joy in those tasks, and it shows in the result.

Feature Suggestions That Violate Design Pillars

Many viewer suggestions (and some of his own ideas) would bolt an entirely different game onto the project — getting out of your ship to explore space stations, landing on planets, talking to NPCs on foot. These fundamentally break the game's identity where "you are the ship." Tim traces this problem back to the first con: without a clear setting and story, there were no design pillars to guide expansion, so suggestions came from every direction.

Ideas for Turning the Shell into a Game

Tim ends on a constructive note, outlining how he'd advance the project:

Distinct Alien Races

Inspired by Star Control 2, he wants truly distinct races — not Star Trek's "humanoid with a funny forehead who acts like a human." Examples: a race with an enormous sense of humor ("everyone is Robin Williams"), a race that communicates entirely through song (tone reflects emotional state — dirges when upset, bright melodies when happy, and they call you "the monotone race"), and a hyper-logical race that literally cannot parse emotional speech rather than simply choosing to suppress emotion.

Subspace Radio

A ship radio system that opens up gameplay: receiving SOS signals, picking up chatter, hearing about distant battles. This becomes the primary quest-delivery mechanism and keeps the player "in the ship" rather than breaking the core design.

Ship AI Companion

An AI with a distinctive personality that narrates events — shields down, hull damage, incoming enemies — so the player doesn't rely solely on UI bars. Tim emphasizes he'd work hard to avoid clichés: no snarky AI, no silly AI, no HAL 9000. Something genuinely original.

Setting and Story First

The most critical next step: define the setting and write a storyline. Everything else — races, radio, AI — becomes coherent only once the foundation exists. This circles back to the lesson from the cons: skipping fundamentals always catches up with you.

The Fallout Vector

Tim shares a revealing framework from his Fallout post-mortems. He liked Fallout 3 and liked Fallout 4, but liked 3 better — meaning the vector from Fallout 3 → Fallout 4 points in a direction he wouldn't have gone. The vector from Fallout 3 → Fallout: New Vegas, however, is exactly the direction he would have taken: New Vegas was "a really good evolutionary step" that took Bethesda's engine and made a game that was "very Fallouty in the sense of the first two."