One game was only the start

The last post was about understanding one game’s result. A season made that job considerably bigger. The same players had to come back next week, and the previous result had to stay put.

I wanted a football management game, after all. A button that produced an interesting score wasn’t going to keep anyone managing a team for very long.

What changed since the last post

The work expanded from a matchup to a schedule. I started working out what had to follow the same team from one game to the next.
Keeping results became part of the job. Earlier games needed their own history instead of disappearing once the next matchup ran.
Roster continuity needed clearer handling. Changing today’s team couldn’t quietly change who had played in an earlier game.
I worked on the boundaries between players, games and season history. They were related, but treating them as one growing pile of information was making later changes harder.
Season results started giving the management side a purpose. I could think about the team’s next decision with its earlier games in mind.

Keeping what happened

Two prototype views for the history I wanted the game to keep.

Franchise record book showing historical and dynasty records with career and season tabs. — The record book separates the franchise’s historical record from what happened during the dynasty.Open full screenshot

Draft results list showing a recorded pick, portrait, ratings and salary. — A saved draft board gives me a way to find a pick again, with the player and contract information still attached.Open full screenshot

The boring bits were doing useful work

It’s easy to get excited about championships, records and a long coaching career. I certainly did. The job in front of me was much less glamorous: keep the roster and its results together properly, then see what broke when I moved on.

I was mentally designing the trophy cabinet while the game still needed help remembering last week’s team. Very sensible sequencing on my part.

I was getting better at splitting up a problem. Early on, I would often try to solve several layers of the game at once. By this point I could usually find one smaller piece to work through. The project felt a bit less like a room where every drawer was open.

There was still plenty I couldn’t judge from engine output alone. I could talk about making a lineup, but I hadn’t yet given anyone a sensible screen to make one on.

That was the next step: work out what this data needed to look like as a game.