colemanok.com

Project · Game design · Idea → buildable plan

Ranch-Sim

A study in method: turning a collaborator’s fuzzy vision into a working start for a buildable project. The starting point — no concept, a genre I have no personal investment in, and a collaborator who is exactly the player this kind of game is for: a breeder who builds external spreadsheets when a game’s own tools fall short, and who quits when the demand curve collapses and the output has nowhere to go. Through a structured interview and three rounds of back-and-forth refinement, that frustration profile became a full, buildable game design — competent, coherent design in a genre I don’t personally inhabit, driven by the collaborator’s needs instead of my own taste.

Overview

This was the “doing it for a job, not a passion project” case — design driven by the collaborator’s needs rather than the designer’s enthusiasm. It held up: the process guided coherent design in an unfamiliar genre, and three rounds of collaboration produced three genuine design discoveries rather than just validation.

The differentiator that crystallized was an observation-based recognition system: the world demonstrably notices what the player has built — not through score screens or achievement popups, but through living systems reflecting the player’s work back to them. The emotional promise that the world notices.

How the rounds are tagged. The feedback documents use a consistent triage taxonomy, carried here: ✓ CONFIRMED — validated with the player · ★ INSIGHT — a design discovery made in-session · ⚑ FLAG — an open decision that blocks downstream work.

Intake & interview

The intake turns a fan’s wishlist and frustrations into structured design questions — and coaches for precision: “‘got bored’ is fine, but ‘got bored because I had all the animals and nothing to work toward’ is gold.” The frustrations became architecture, not tuning:

And the wishlist became features by reading the player’s own habits: the external spreadsheets became the in-game journal’s required views; the “?” marks in those spreadsheets became a Known / Suspected / Unknown genetic-certainty system; the habit of naming breeding campaigns became Named Breeding Projects.

Iteration rounds 1–3

Round 1 — confirm the core, find the blocker. One-species focus, three-layer breeding depth, and systems over visual fidelity all confirmed. The round surfaced the single blocking decision — ⚑ FLAG: single-player, multiplayer, or hybrid, “the most important architectural decision in the design” — resolved as Single-Player Core with Social Periphery: a single-player economy plus an optional asynchronous marketplace, because multiplayer NPC processing is “fundamentally different engineering at much higher cost with much less controllable outcomes.”

Round 2 — three structural refinements. Rival reframed to Neighbor — “competitive AI that reacts to the player as a threat creates anxiety, not warmth.” Recognition and demand were unified into one system — a request that arrives as “I heard you breed the most beautiful palominos in the region” makes you feel like a master of the craft; the same request stripped of that feels like a chore. The economy risk was re-diagnosed: “the economy did not fail late. It never launched” — early-game silence, not late-game collapse. And the discovery of the round: departing residents carry the player’s reputation outward.

Round 3 — content pass, still structural. The neighbor breeder as the mentor’s former mentee — a pre-existing social triangle with history before the player arrives. The county fair as an unfilled genre gap. The auction house as a physical location — “pens with animals in them, clipboards on the gates” — solving the “feels like a separate app” problem.

Scope & spec

The buildable spec crystallized as a single validated chain — every system feeding the next:

Genetics Performance stats Training Competition Titles / provenance Auction & NPC demand Journal goals the next generation.

It reached build-ready, not just conceptual — the spec carries an honest “Items Needing Resolution Before Code” table and engineer-facing tags (CRITICAL FOR CODE PERSON: the genetics system must be data-driven, not hardcoded). The same triage rigor runs from fan feedback all the way into the handoff.

One tone rule worth quoting, because it captures the whole design sensibility: planner entries show approximate in-game dates, never countdown timers — “Windmere due: Spring, Week 3,” not “9 days remaining.” One invites planning; the other creates pressure.

Quantitative exhibits

The vision became numeric. Trait inheritance runs on a tiered probability model — the design target being that a player who has bred a rare trait should see it in the majority of foals:

Trait tierVisible parent inheritsSingle carrier passes silentlyTwo carriers express
Common95%
Uncommon85%55%35%
Rare65%40%25%
Very rare45%25%15%
Dual variant12% trigger

Provenance — how a champion’s value flows down its bloodline — runs on a deliberately-tuned generation-decay curve, set more generously than the obvious 100/50/25/10 so that lineage depth beyond two generations stays economically meaningful:

GenerationValue retained
Self100%
Parent100%
Grandparent80%
Great-grandparent55%
Great-great-grandparent30%

Alongside these: a five-stat performance model (Athleticism, Temperament, Rhythm, Suppleness, Collection — each with a genetic ceiling vs. a trained value, and Collection deliberately given no genetic ceiling so any horse can earn it), a judged dressage score composed 60% movement / 25% collective marks / 15% harmony, and a starting-population frequency model with a hidden-carrier seed ladder and marketplace-locked traits — where the first player to list a black-marked horse is a genuine economy event.

This spec is the design basis for a horse-sim built on the VOID engine — one of its target titles.


← All studies