I wrote about it at length. I shipped it. I was pleased with it.

It never appeared on screen. Not once. Not for anyone.

Structurally incapable

I want to be precise about this, because "it was buggy" would be letting myself off easy. The coaching report was not intermittently broken. It could not draw, on any snap, under any conditions, for any player. Every single frame of its existence was spent returning early from a guard clause.

Here's the shape of it. The report grades the call you made, so it runs after the play resolves — you want to read the grade against the result you just watched. But the function that commits a play result also clears your pending call, because the call has been spent; it's not pending any more. The report was reading that cleared value.

var called = HumanOnOffense ? PendingPlayCall : PendingSchemeCall;
if (called is null || !called.IsTactic) return;

called was always null. The guard always tripped. The function always returned. The panel was built, styled, animated, tuned, and never given anything to render.

The part that stings: two lines above the call site, the code already knew. There's a comment sitting right there in the resolution path — "Capture pending state before ApplyPlayResult clears it" — and a set of local variables doing exactly that, feeding the play-by-play log. Somebody (me) had hit this exact hazard before, understood it, wrote it down, solved it, and then wired a new feature straight past the solution.

The knowledge was in the file. It just wasn't in my head at the moment I needed it.

What the tests were doing instead

Here is what makes this worth writing about rather than just fixing quietly.

The build was green. The tests passed. And the tests were good tests — the coaching report has a suite that pins genuinely subtle properties. That the grade never reads the play's outcome, so it can't secretly become a scoreboard. That the bands are quantized into five states so repeated observation can't be inverted into a probability table. That no number or percentage ever leaks into the text.

Every one of those tests calls the grader directly. Not one of them asked whether anything ever called the grader.

That's the gap, and it isn't a gap you can close by writing more of the same tests. I had thorough coverage of a component and zero coverage of its wiring. The component was flawless. It was also unreachable, which made its flawlessness worth precisely nothing.

I don't have a clean answer for this. The honest version is: unit tests verify that a thing works, and nothing I own verifies that the thing runs. In a game, the only real integration test is playing it, and I hadn't played a snap and consciously looked for the grade panel — I'd looked at the code for the grade panel, which is a completely different activity that feels identical from the inside.

The one that shipped

While we're being honest, the coaching report wasn't even the worst one.

Update 1 failed Steam review three times. Same report each time: no cards, no players, unable to progress. Field renders, scoreboard renders, menus work. Just an empty stadium and no way to play.

I could not reproduce it. Not once, not on any machine I had.

The cause was capitalization. The player models load from res://assets/models/... and the folder on disk is Assets/Models. On Windows that's the same path — the filesystem doesn't care about case. But once the game is packed into its distributable archive, lookups inside that archive are case-sensitive. The load returns nothing. The scene instantiation throws. And it throws inside the routine that populates the field, which runs before the cards are dealt — so everything built earlier survives and everything after it never happens. Which is exactly, precisely the symptom three different reviewers wrote down.

The reason I couldn't reproduce it is the whole lesson. I always played from the project folder, where the loose Assets\Models\ directory still sits next to the executable, so Godot's filesystem fallback quietly resolved my wrong-case path against the real one. My development environment was more forgiving than the shipping one, in a way that made a fatal bug invisible right up until it reached a stranger.

I now smoke-test the staged build folder, not the project folder. It cost me three review cycles to learn a rule that takes one sentence to state.

The panel that argued with itself

Once the report could actually draw, I got to find out what I'd designed.

The first thing it did was appear for about a second and a half in the middle of the screen, over the field, while the touchdown banner and the yardage numbers fired over the same real estate. The grade is three meters and a sentence. You cannot read three meters and a sentence in a second and a half while a "+42 YDS" is exploding across it.

That's a design error I could only have found by looking at it, and it's a good argument for shipping the ugly version early. I'd tuned the animation curve on that popup. Punch-in scale, settle, hold, drift up and fade. I had opinions about the easing. All of that was work spent on a thing whose fundamental problem was that it was temporary and in the wrong place.

Then the banners. It turned out the touchdown and first-down banners opened at 12 pixels below the scoreboard with a 150-pixel-tall zone, and the last-play strip lives at 6 to 44 pixels below the scoreboard. The banners didn't overlap the strip so much as contain it — they started six pixels inside it and ran a hundred and eighteen pixels past its bottom edge. Every touchdown buried the thing telling you what just happened.

And then the sentence itself. When the two rosters were even and neither scheme had an edge, the report said "this one came down to the dice." Reasonable. Except it decided that by looking only at the roster and scheme meters and never at the call meter — so on a snap where you'd clearly out-called the opponent, the panel showed you a full green CALL bar and a sentence telling you the play was random. It was contradicting itself on screen, in two elements six pixels apart.

That one bothered me more than the crash. A crash is a mistake. A system confidently reporting something its own display disproves is a credibility problem — and the entire pitch of this feature is "trust me, I'll tell you whether that was skill or luck."

Saying something true

So the report names the call now. And I had to be careful about how.

It would be easy to write forty lines of football-sounding flavor. "Screens beat blitzes." "Slants are good on the goal line." Some of it would even be right. But this game has a simulation engine underneath it that has actual opinions about which concepts profit against which shells, expressed as a table of numbers, and there is nothing worse than a game that explains itself in a way its own rules contradict. Players notice. They should notice; noticing is the game.

So the sentences are generated from the same table the resolver scores with. When the report says "a screen into their blitz — the pressure ran itself straight out of the play," that's the same 1.3 multiplier the engine applied. When it says "you ran at a light box," that's the 1.4 the engine applied for a run against a dime front. If I retune those numbers tomorrow, the sentences follow, because they read the same source. The report cannot tell you something the game disagreed with — not because I was careful, but because there's only one place the answer lives.

The situational lines work the same way, off the tags on the cards themselves: "nothing in your hand fit third-and-long better than that call." That's not flavor. That's the actual ranking the grade was computed from, said out loud.

Taking it away again

The last change to the report was removing it.

At the highest fluency setting — Certified Ball Knower, the mode for people who see "P22" and picture the box count — the explanation sentence doesn't appear. You get the letter and the three meters and nothing else.

This is the same call I made last update with the TIP line on the cards, and I think it's the most important design principle in the whole game: reading the situation is the player's skill. The door I built for newcomers cannot become a set of training wheels bolted onto the expert experience. An expert doesn't need to be told the matchup was even and the schemes cancelled — they can see both meters. Telling them anyway is noise, and worse, it does the interesting part of the thinking for them.

Meeting people where they are has to include the people who are already there.

The guard that cried wolf

One more, because it's the one I'd have dismissed as trivial a month ago.

There's a script that uploads builds to Steam, and it has a guard: if the source has changed since the last packaged export, warn me, because otherwise I'll upload a stale build. Good guard. It saved a stale build from shipping at least once.

It compared file modification times. And git checkout rewrites modification times without changing a single byte, so switching branches made it fire on a build that was demonstrably correct. It cried wolf, and I typed "yes" past it, and typing "yes" past a safety check is a habit you only have to form once.

It hashes file contents now. It's silent on an unchanged tree and it names the exact files when something really moved.

I mention it because a guard you've learned to ignore is worse than no guard at all. No guard means you stay nervous. A guard you dismiss reflexively gives you the feeling of safety while functioning as a speed bump. That's how a stale build reaches review — not because nothing was watching, but because the thing watching had taught me it was usually wrong.

(It caught something real while I was writing these very notes, incidentally. A stash-and-restore had rewritten a source file's line endings, so its content genuinely differed from what the last package was built from. Behaviorally identical, completely harmless — and I re-exported anyway, because the entire value of the guard is that I don't get to decide which of its warnings are the boring kind.)

Where this leaves it

This patch adds almost nothing. One new sentence generator, some tooltip styling, a panel that used to be two panels. By the measure I'd have used a year ago it's a nothing update.

By the measure I care about now, it's the update where the last one actually started working.

The coaching report exists. It sits in the corner in a panel that waits as long as you need instead of flashing past in a second and a half. It tells you what decided the snap and it can't lie to you about it, because it reads the same numbers the engine does. It shuts up at the highest difficulty because that's the point.

The players show up on the field, which they did not do in the build I was proud of.

I've been writing software long enough to know the difference between "done" and "shipped," and I keep relearning that there's a third state past both of them: observed working, by someone, in the form they'll actually receive it. Everything short of that is a hypothesis. My tests were a hypothesis. My playtests from the project folder were a hypothesis. Three review rejections and a feature that never drew a single pixel are what a falsified hypothesis looks like.

The build folder is the game now. Not the project. That's the whole lesson, and it cost more than it should have.

Next up: the crowd bed, which is currently disabled because it sounds less like eighty thousand people and more like an untuned radio. I know why. It's a synthesis problem, not a mixing problem, and it deserves its own pass rather than one more attempt to EQ my way out of it.

Turning something off until it's right is also a form of shipping.

What this is

xvorogue is a roguelike deckbuilder built on football. You pick a team, draft a roster and a playbook, and coach a season under a contract. Win and you push the same build deeper. Lose enough and the franchise fires you mid-season, and that is the run.

It is not a management sim and it is not Madden. You do not move a stick, and you do not set a depth chart forty players deep. On every snap you call a play from a hand of cards, pick the player you want featured, and optionally spend a trick. Then the simulation settles the down and tells you what happened. The decision is your job. The execution is not.

The shape of a run: 32 teams, each with its own legacy that rewards a different style. 154 cards across tactics and tricks. A seven-round draft, a weekly waiver wire, a coaching skill tree, and a handful of mid-week actions you never have enough of. Contracts of one, four, or seven seasons, or infinite. Nine-game or seventeen-game seasons. Quarters of four, six, or eight minutes. Five difficulties from Rookie to GOAT, and GOAT stays locked until you win a run on Elite.

How you actually win a run

There is exactly one way, and it is worth stating plainly because it changes how you should plan.

You win a run by winning the Omega Bowl in the final season of your contract. Nothing else closes a run out in the black. Sign for seven seasons and the only result that counts as a win is a ring in season seven.

Titles you win before then are not nothing, and I want to be careful not to undersell them. A championship season is the largest single swing in job security the game offers, which is frequently the difference between reaching your final season and getting fired in year four. It stacks in your run score. It unlocks the legacy of the team you beat. A run with three interim titles is in a far better position than a run with none.

But it is position, not victory. Win the Omega Bowl in season two of a seven-season deal and the confetti falls, the season summary comes up, and then you go back to work with five years left on the contract. If season seven ends without a ring, the run is recorded as a contract that expired, however many banners are hanging. Interim championships buy you the runway to win the run. They do not win it for you.

On an infinite contract there is no final season, so there is no win condition at all. You coach until the franchise fires you, and the only question is how long and how high.

The simulation is the reason the game exists

Every snap is settled by our football simulation, built on more than 18 trillion simulated plays and 56 years of real NFL data: actual player ratings, formations, and play-calling. It is not a dice roll with a football skin on it.

The practical consequence is the thing I care about most. Football knowledge transfers. Personnel packages matter. Down and distance matter. Calling 22 personnel on third and two against a dime front is a good idea in xvorogue for exactly the reason it is a good idea on a Sunday, and the sim will pay you for noticing. If you know the sport, you already know most of how to play this.

Here is the honest cost, and you should know it before you buy. The sim is right on average and completely indifferent to your feelings in the moment. If you engineer a 78 percent look, it will fail roughly one time in four, and it does not know or care that the one time was the fourth quarter of your final-season Omega Bowl. There is no rubber band that notices you are having a bad night and quietly helps. Some players are going to read that as the game being unfair. It is the price of any of the results meaning anything, and I decided to pay it.

One related note: if the main menu says SIM ENGINE (native engine not found), the full simulation did not load on your machine and you are running the lightweight built-in fallback, which resolves plays differently. That is a bug report, and a high-priority one.

The play that was never thrown

The progression fantasy in xvorogue is super soldiers. Stats are deliberately uncapped above 99. You concentrate practice, card evolution, and legacy bonuses onto two or three players until they tower over everyone on the field while the rest of your roster stays ordinary on purpose. Focus is how you cash that in: you pick a play, then you pick the player who should get the ball.

Building a monster is worthless if you cannot get him the ball. Focus is not a convenience feature, it is the spine of the entire progression loop.

The game layer and the simulation talk across a narrow contract that I designed, and I had never verified that the sim honored the half of that contract focus depends on. On 13 June I stopped reasoning about it and drove the shipped simulation directly with controlled requests, 400 to 500 iterations per configuration, because the sim has its own randomness and a single run tells you nothing. The test was a mesh concept in 11 personnel with three receivers given identical stats.

Baseline, no overrides: 100 percent of completions went to the receiver in slot 0. I gave receiver 2 guaranteed separation, the override whose entire job is to get him open. 100 percent to slot 0. I blocked slot 0 with the override whose entire job is to forbid completions to him. 100 percent to slot 0. I blocked every receiver except number 2 and force-fed number 2 as hard as the request format allows. 100 percent to slot 0. I made receiver 2 statistically the best player on the field, and then the worst. Slot 0, both times.

The sim resolves each concept around a fixed slot, always. Every override the focus feature was built on did nothing whatsoever.

Two details made it worse. The separation override works by setting the stat to 99, so on a player already above 99 it is a downgrade: a receiver with a 170 route-running rating averaged 3.37 yards without it and 3.27 with it. I had shipped a button that made your best player slightly worse.

Then I replayed the last request a real session had actually produced, 400 times. It was a play-action card. The game layer treated it as a pass, attached focus boosts to a tight end, and then sent it to be resolved as a counter run. The ball went to the running back on every single snap. The focused tight end touched it zero times, and the box score said he caught it, because my own resolver renamed the ball carrier after the fact.

That last part is the piece I got wrong twice. The first mistake was trusting a mechanism I had never tested end to end. The second was worse: when the attribution looked wrong, I wrote a post-hoc relabel so the box score would agree with the player's intent. It made the feature look like it worked. Your monster was never touching the ball, the stat line was fiction, and my own cosmetic patch is what kept me from finding out for months. The lesson I would pay money to have learned earlier is that a display fix layered over a suspicious result is not a fix, it is a blindfold.

What shipped is embarrassingly simple. Before the roster is handed to the sim, the focused player is swapped into slot 0, so the player it resolves around is the player you picked. Attribution then names him honestly, because now he really did carry it.

The honest limit: aggregate pass concepts such as mesh resolve around the whole route combination rather than one receiver, so focus on those plays narrows your options rather than guaranteeing a target. That is how the sim reads those concepts today and I have not beaten it yet.

The second time the same fantasy broke

Fixing targeting immediately exposed the next layer. A 140-overall team was resolving like a 99 team.

The response curves flattened out near 99: a cap on big plays, completion probability clamped at 0.90, a floor under sacks, no interception term on the offensive side at all, and the outcome tree's upper stages missing outright. First Contact, Second Level, and Breakaway, the three stages where a genuinely fast player turns a six-yard gain into a long one, were not in the build. You could stack a back to 140 and there was no stage left to produce the yards.

The Dominance Pass restores those stages after resolution, so it behaves the same way whether the full sim or the fallback produced the result. It is dead-zoned: matchups in the ordinary 65 to 95 band resolve byte for byte identically to before, so it only fires where the old curves were lying. 1,277 tests green when it landed.

If your 140-overall running back breaks a long one now, that is not a bug. This is the first build where it was possible.

What is not in there

• Windows only at launch. Other platforms are a question for after I see how this one goes.
• Injuries are cut. The toggle is hidden in the run setup screen and the plumbing behind it is still wired, so it can return. I would rather ship without them than ship a system that deletes the super soldier you spent six weeks building on a coin flip. It comes back when I am confident it makes runs more interesting rather than just more annoying.
• No onside kicks and no two-point conversions. A touchdown is seven points and the extra point is automatic. Both are on the list.
• No multiplayer. The architecture allows for it. That is not the same as it existing.
• 154 cards against roughly 190 planned. Several team identities are noticeably thin.
• Team balance is uneven, and I know which direction. 19 of the 32 teams use a parameterized roster generator tuned into a tight 72 to 79 band. The other 13 were built by hand, and several of those are materially stronger. I have not decided whether to tighten the 13 or accept that the signature teams are simply better, and I would rather hear from players before I pick.

What happens next

Patch notes for every update land on this devlog. Dev diaries when there is something real to say, not on a schedule. The first patch will be fast, because launch day always finds things no amount of solo testing does, and I would rather ship a small fix in days than a tidy one in a month. There is an RSS feed at /devlog/feed.xml.

The Discord

discord.gg/PPvXdCzWWZ is where the fast loop happens. Post a repro there and there is a real chance it is fixed before I have finished writing it down, and it is the best place to argue with me about balance.

Use the contact form for anything that does not belong in a public channel: purchase problems, or a save file you would rather not post where everyone can see it.

What I need you to break

This is the part I actually care about on day one. In priority order, because scattered reports help less than aimed ones.

1. The first hour on a fresh profile. This is where my testing is thinnest by a wide margin, and the reason is boring: I have been playing the same save for months and I already know what every screen means. I cannot see this game the way you will see it. If the tutorial skips something load-bearing, if a phase begins and you cannot tell what the game wants from you, if you lost a down because you did not know a timer was running, that is a real bug and I want it reported like one.

2. Balance across the 32 team legacies. I have a spreadsheet saying they are close. A spreadsheet is not a hundred real games, and it never has been. If a legacy feels like a free win, or like an empty slot you forget you have, that is the single most useful report you can send me right now.

3. Infinite mode at depth. I have tested it and I have not lived in it. Season 8, season 15, season 30. Since an infinite run has no win condition and ends only when you are fired, the whole mode rests on the late seasons staying interesting, and that is precisely the part I have the least real evidence about.

4. Anything where the sim result feels wrong rather than merely painful. This distinction matters more than any other on this list, so let me be precise. Painful is your 78 percent look failing at the worst possible moment, or a fumble that ends a perfect season. That is the sim doing its job, and I am not going to change it. Wrong is a result that could not have happened: a player who was not on the field, a stat line that contradicts what the animation showed, yardage inconsistent with the down and distance, a punt outcome with no physical sense to it. Painful means the game is working. Wrong means I have a bug. Report the second kind loudly, and do not soften it because you are not certain which one you saw. I would rather sort through fifty painful reports to find one wrong one.

5. Anything that ends a run for the wrong reason. A crash, a save that does not resume where you left it, a down that gets eaten. Pressing Escape while a play is mid-resolve is a genuinely untested edge. Losing a seven-season run to a software fault rather than to a bad fourth-down call is the worst thing this game can do to you, so those reports jump the queue.

A report I can act on the same day looks like this:

That last line matters more than it looks. If the full simulation did not load, everything else you saw came from the fallback, and I need to know that before I chase the wrong bug.

Break it and tell me what broke.

— aerbuf