Second Toy Post Mortem

Context

Tim Cain presents his second toy post-mortem, this time for "Dungeons and Dices" — a project he started over two years prior during an insomnia coding session. He distinguishes between a toy (something you play with) and a game (something you play), and notes he hasn't touched this project in over a year. He encourages hobbyist developers to accept that not all toys will become games, and that abandoning projects is perfectly fine.

He also references his previous post-mortems: a larger one for his space fighting game (which actually transitioned from toy to game) and a meta post-mortem covering all his professionally shipped titles.

What Went Right

Dice Physics

The primary motivation for the project was exploring 3D dice physics simulation — modeling bounce, fall speed, friction, and surface interaction. Tim developed an elegant system for detecting which face is up:

• Each die face has a short vector pointing outward from the opposite side
• Each vector is labeled with the number of the opposite face
• When a die stops, whichever vector intersects the table's collision box tells you the upward-facing number
• Example: the vector on the opposite side of the "one" face is labeled "1" — if it intersects the table, the one is facing up

This system was simple and worked beautifully, though it immediately surfaced edge cases. Sometimes dice would lean against each other at an angle where no vector intersected the table (the vectors were kept deliberately short to avoid false positives from leaning dice). Tim's solution: when a die's speed hits zero with no intersecting vector, apply a random force nudge. The die rolls off and settles properly. If it still doesn't resolve, nudge again. This happens so fast the player never sees the pause — visually the die just keeps rolling until it lands cleanly.

The Core Game Concept

The fundamental design combined Yahtzee and poker mechanics with a fantasy dungeon theme:

• Roll dice and match combinations (number of pips, color/texture) to slots on monster cards
• Fill all slots on a card to defeat the monster
• Each roll costs hit points (the monster hits you back), creating time pressure
• The fantasy dungeon theme made the mechanics immediately accessible — players understood "roll dice to fight monsters" intuitively

What Went Wrong

Classes Were a Mistake

Tim added character classes (fighter, thief, mage) with unique abilities — for example, the thief could "backstab" by auto-completing a card with one empty slot. He considers this a mistake and believes the class system needed fundamental rethinking.

Art Quality

The programmer art wasn't cutting it. To progress toward a real game, Tim would need to either buy art assets online or hire an artist — a significant commitment for a project that was still just a toy.

The UI Was a Nightmare

Tim spent roughly five times longer getting the card UI working than the dice physics — despite dice being the whole point of the project. The core problem: dice are 3D objects that must be dragged onto 2D card slots, remain as 3D objects on the card (so you can pick them back up), and transition smoothly between 3D and 2D space. Card textures, borders, and general interface polish consumed enormous time. Tim's verdict: UI work is "an amazing time sink."

Rules Didn't Scale

The biggest blocker was game design itself. Tim experimented with multi-card monsters (a rat = one card, a dragon = three cards) and defense cards that had to be cleared first. The difficulty scaling broke badly:

• One-card monsters were trivial
• Two or three-card monsters became extremely hard
• Adding defense cards made some encounters potentially impossible within the player's hit point budget
• The probability math simply didn't work out

The Mechanics Stall

Tim began exploring solutions — replacing classes with collectible power/ability/item cards with usage limitations (one-use, one-per-monster, one-per-roll). He also considered special dice types:

• Rainbow dice — match any color, but can't be used on "all different colors" cards (since they match everything, they create duplicates)
• Gray dice — no color at all, useful on "all same color" cards but not on rainbow-requirement cards
• Metal dice (gold, silver) — visually appealing but Tim couldn't figure out what mechanical role they should serve

He got stuck at this design stage and couldn't find a satisfying next step, knowing that beyond the design work lay further commitments to art and UI.

Lessons

• Post-mortems on abandoned projects are valuable — they crystallize what worked and what didn't, directly informing your next project
• It's okay to abandon toys — not every idea needs to become a game; some are great ideas but not great game ideas
• Distinguish toys from games early — a toy demonstrates a cool mechanic; a game requires rules, progression, balance, art, and UI
• UI will eat your time — especially when bridging 3D and 2D spaces; budget accordingly
• Edge cases appear immediately — even "simple" systems like dice physics surface surprising problems (leaning dice, force nudges)
• Always do a trademark search — "Dungeons and Dices" was already the name of an existing game and a burger restaurant in Brazil
• Difficulty scaling needs math — intuitive "harder = more cards" can create impossible encounters; validate with probability analysis