Breed Classic

Raise, race, and improve generations of horses in a management simulation that explains why each race was won or lost—and what to change next.

Comment

Inspiration

As an independent developer, I wanted to build a game that could offer years of depth without depending on servers, live operations, or recurring infrastructure costs. Horse-racing simulation was a natural fit: breeding, training, race selection, and competition can produce an enormous amount of content from a deterministic offline system.

I also see an underserved position in the Japanese market. Many current horse-racing games sit at one of two extremes: mobile titles designed around ongoing purchases, or expensive console titles with increasingly complex systems. What I missed was the faster sandbox experience I grew up with—one where the player can spend generations building a personal bloodline, move through routine management decisions quickly, and still feel genuine anticipation when an exceptional horse finally appears.

My initial audience is adults who played Japanese horse-racing games during the Super Famicom era. Those games made long-term breeding approachable without removing its depth. Breed Classic is intended to recover that rhythm for modern mobile play: quick sessions, no forced purchases, and a bloodline that becomes uniquely yours over time. In the longer term, this foundation could also support optional online competition, but the core game must remain complete and enjoyable offline.

There was another problem I wanted to solve. Race results in management games often feel opaque. A player may lose without understanding whether the cause was ability, distance suitability, growth stage, race position, pace, track condition, temperament, or timing. Breed Classic is designed not only to show where a horse finished, but to turn every race into useful information for the player's next decision.

What it does

Breed Classic is a horse-breeding and racing management simulation built with Godot.

Players can:

  • Build a stable and develop horses over multiple generations
  • Select breeding combinations and inherit bloodline characteristics
  • Compare five-generation pedigrees, compatibility, inbreeding effects, and risk
  • Train horses while managing condition, fatigue, growth, and suitability
  • Choose races from a seasonal program
  • Watch races with changing positions, packs, corners, stretch battles, and visible finishing gaps
  • Review evidence-based explanations of why a horse won or lost
  • Use trainer, jockey, result, and newspaper perspectives to plan the next race

The post-race explanation system is deterministic and grounded in the race simulation. It does not invent a convenient story after the result. It converts validated race events and performance factors into player-facing explanations.

What I built during OpenAI Build Week

Breed Classic existed before the submission period. The underlying breeding, training, weekly progression, race simulation, save system, and initial mobile interface were already in development. This submission focuses on the meaningful extensions I completed during Build Week.

The largest addition was an explainable race-result system. I implemented a pipeline that:

  1. Records an authoritative trace of what happened during the race
  2. Separates actual causes from comparisons and observations
  3. Validates whether each fact is safe to show
  4. Produces distinct trainer, jockey, newspaper, and result-screen explanations
  5. Preserves each explanation with the race history so it remains consistent after loading a save
  6. Connects supported causes to practical hints for the player's next decision

I also improved the race presentation with better home-stretch camera tracking, canonical finishing gaps, clearer sequential finishes, and stronger consistency between the simulation result and what the player sees.

How I built it

The game is developed in Godot 4.6 using GDScript. Core simulation logic is separated from platform-specific interfaces so the same breeding, training, progression, saving, and racing systems can support mobile and web builds.

OpenAI Codex using the GPT-5.6 model family was my primary development environment for almost all Build Week work. I used Codex to:

  • Analyze the existing race simulation before changing its behavior
  • Design the evidence and publication contracts for race explanations
  • Implement new services and mobile result surfaces
  • Trace inconsistencies across simulation, presentation, and saved results
  • Build regression tests and release gates
  • Review implementation decisions and tighten unsafe edge cases
  • Iterate on camera behavior and finishing-gap accuracy using captured race frames

The product direction remained human-led. I decided what the game should feel like, which information should be visible to players, which explanations must be withheld without sufficient evidence, and how much complexity belongs on a mobile screen. Codex accelerated implementation and review, but it did not replace those decisions.

Challenges I ran into

1. Establishing a race-simulation foundation

Because the game was built from scratch, creating a complete race flow took substantial time. I originally considered reproducing each racecourse in full 3D, but that approach did not fit the scope or the fast management experience I wanted. I instead built a 2D presentation around four phases—start, middle stages, final corner, and home stretch—while applying course-specific configuration to the underlying simulation.

Translating a sensory request such as “make this pack movement feel natural” into measurable rules was difficult. GPT-5.6 made repository-wide iteration much more effective, but the system still required extensive debugging, captured-frame review, and regression testing.

2. Making the home stretch feel believable

The final straight has been one of the hardest presentation problems. Horses must retain a natural formation while some accelerate, others tire, and the entire field crosses the line in the exact order and gaps produced by the simulation. I rebuilt this sequence several times because a mathematically correct result can still look wrong on screen. The current version is much closer to the intended experience, although this remains an area I will continue refining.

3. Explaining defeat without inventing a story

I wanted players to understand a horse's limitations and future potential naturally through trainer feedback, jockey comments, result screens, and race history. The difficult part was not writing fluent text; it was collecting the right race events and deciding which conclusions those events genuinely support.

I therefore designed an evidence pipeline that distinguishes recorded facts, comparisons, inferred causes, and publishable feedback. A GPT-5.6-based Codex workflow contributed heavily to implementing and reviewing this system. Unsupported explanations are withheld rather than presented as plausible-sounding advice.

4. Building breeding logic with both depth and uncertainty

Breeding is the long-term core of the game, so it could not be reduced to simply averaging the parents' abilities. The system analyzes five-generation pedigrees, sire-line and broodmare-sire compatibility, shared ancestors, inbreeding patterns, outcrosses, inherited tendencies, maternal latent traits, and risks to temperament or soundness. It also considers contributions from the sire, dam, and broodmare sire while allowing rare strengths to reappear across generations.

The hardest balance was making pedigree decisions meaningful without making outcomes deterministic. Strong parents should improve the odds, but they should not guarantee a champion; an unfashionable family should still be capable of producing a breakthrough horse. I also had to prevent the recommendation system from presenting combinations with excessive temperament or soundness risk as automatically “best.” Distribution benchmarks, controlled breeding tests, pedigree audits, and repeated multi-generation simulations were essential to tuning this system.

5. Fitting a deep simulation onto a portrait mobile screen

Horse management involves dense information: condition, training, suitability, race history, pedigrees, and breeding effects. Showing everything at once would make the game unreadable. I used progressive disclosure, dedicated detail views, and a shared gameplay facade so the mobile interface can remain approachable without simplifying the underlying simulation.

6. Maintaining one consistent truth

The hardest overall engineering challenge was keeping simulation logic, visual presentation, saved history, and player-facing language consistent. A race can be mathematically correct while the animation looks wrong. An explanation can sound convincing while being unsupported. A saved result can also change meaning if commentary is regenerated after the game logic evolves.

To solve this, I treated the authoritative race trace as the source of truth. Public explanations must pass evidence and publication checks, and race presentation must use canonical simulation data instead of independently estimating the outcome.

Accomplishments that I'm proud of

  • Meaningful post-race explanations grounded in actual simulation evidence
  • Different perspectives for trainers, jockeys, results, and newspapers
  • Persisted explanations that remain stable across save and load
  • Race animation that respects canonical finishing order and gaps
  • A deep multi-generation breeding system with visible rewards and risks
  • Reusable test fixtures and regression suites for explanation and breeding consistency
  • A complete offline management loop without requiring a server or API key at runtime
  • A mobile-first interface built on the same underlying simulation as the desktop version

What I learned

Explainability is not simply a text-generation problem. The difficult part is establishing which facts are authoritative, which conclusions are justified, and which information should not be shown.

I also learned that simulation logic, visual presentation, and player-facing language must be tested together. Improving only one layer can make the overall experience less trustworthy.

Codex was especially effective when the work required understanding a large existing codebase, following evidence across multiple services, implementing a coordinated change, and then testing the result from several perspectives. At the same time, turning a subjective game-design intention into reliable behavior still required clear human direction and many rounds of observation.

What's next for Breed Classic

Next, I plan to:

  • Complete submission-ready web and iOS builds
  • Improve onboarding for players unfamiliar with horse breeding
  • Expand the visual presentation of breeding and bloodline inheritance
  • Add more actionable race-history comparisons
  • Continue mobile usability and accessibility testing
  • Further tune the home-stretch presentation and breeding distributions
  • Explore optional online competition without compromising the offline core
  • Extend the simulation while preserving deterministic, evidence-based explanations

Built With

Share this project:

Updates