← Back to the dev blog

DEV BLOG / 27

A clearer Inbox—and what comes next

The newest mail interface, and an honest look at the work still in front of me.

Game screenshots
Development post 27: A clearer Inbox—and what comes next. Artwork and captured details from Idleball.
Interface details from Idleball.

I’ve spent this week working on the Inbox. Yesterday’s changes give the messages a clearer list and a proper reader, which is a relief when three different parts of the franchise want something from me at once.

The Inbox was keeping the messages, but using it still took too much hunting around. I wanted to see who sent something, what it concerned and whether I needed to act, without opening half the mail to find out.

The Inbox before this week’s changes

These are actual game captures from September 30. The older notification list worked, but it made finding and reading a message harder than it needed to be.

The notification listWindows · Build 283 · Sep 30, 2026
Idleball’s actual notification list, with the mailbox unread count, saved injury reports and their in-game receipt times.
That is 2,648 unread messages in this long-running development save. Apparently I have managed to give myself another inbox to neglect.Open full screenshot
Opening an injury reportWindows · Build 283 · Sep 30, 2026
An opened injury notification for Hiroshi Diku Suzuki showing its message, Mark read action and Player Details link.
Opening an injury report shows the recovery estimate and a link to the player. This is the older expanding-message layout that I’m replacing with a separate reader.Open full screenshot

What changed since the shared-interface checkpoint

  • Mail rows show their actual source. Sender, subject, preview and timestamp give a message some context before it opens.
  • Unread, resolved and urgent states are distinct. A new message and an outstanding decision aren’t interchangeable.
  • The selected message has a proper reader. Wide layouts use measured columns; narrow layouts use an overlay.
  • The list stays with the relevant team. Team filtering keeps correspondence attached to the franchise being viewed.
  • Messages are paged in groups of thirty. A long archive doesn’t need to be loaded into one oversized list.
  • Reading is an explicit action. Opening or resizing a view shouldn’t quietly change unrelated message state.
  • Original destinations still work. A contract or report link needs to retain its actual callback.
  • Selection, focus and scroll survive resize and Back. Returning to the list should bring me back to the message I was using.
  • Yesterday’s isolated run compiled and passed 39 native checks. The Inbox cases passed; the packaged game still needs its own review.
  • Portrait motion and settings are restored. The interface changes need to keep the existing animation controls working.

Still testing

The 39 checks are useful. They don’t cover every interaction in the packaged game or on an actual device, and the run still had shutdown leak warnings. I need to keep those details on the list instead of rounding the whole thing up to “finished.”

I’m on build 318 now. The matching packages still need their own checks. Getting the focused tests through is encouraging, but I need to use the game at the sizes people will actually play it.

Still in front of me

Startup needs to reach responsive controls reliably. Windows docking, scaling and the title bar still need work. Phone profiles and the expanded workspace need to remain understandable at the sizes people actually use.

Quick Play, Apple parity and some proposed companion changes remain unfinished or unverified. Private-league convergence, deployed notification delivery, background behavior and long-run economic testing also need their own results.

I’m a lot more comfortable with the code than I was when I started. I’m still a dad changing careers and trying to make his first original game. There’s a difference between having built a lot of systems and having a game ready for somebody else to trust.

Football is scheduled for February 1, 2027. The rest of Idleball follows in order: baseball, hockey, then basketball. My job now is to keep improving the football game in front of me, rather than use the next idea as an excuse to leave this one half done.

Next I’m concentrating on startup and the companion window. I want the game to open cleanly, keep its place when I resize it and let me get on with managing the team. A working Inbox is a good step. It hasn’t shortened the rest of my list quite as much as I’d hoped.

The prototype on screen

Here are a few more views of the game: the roster, front office, player creator and football itself. The older and newer layouts are from different saves.

Open the prototype screenshot gallery

Following a game and planning the next season

Screens from development saves on Windows and Android.

Following a gameAndroid · Build 286 · Sep 30, 2026
Live playoff screen with a scoreboard, game clock and play commentary.
A playoff game running in the prototype. This is the sort of screen I had been trying to get the engine underneath.Open full screenshot
Planning the next seasonAndroid · Build 286 · Sep 30, 2026
Front-office budget review ahead of Season 3 with projected costs and funds.
Finishing one year brings me back to the front office to plan the next one.Open full screenshot

The season-opening bill and earlier lineup view

Screens from development saves on Windows and Android.

The season-opening billAndroid · Build 286 · Sep 30, 2026
Season-start confirmation listing the Season 3 costs and projected remaining funds.
The confirmation screen lays out the next season’s bill before I commit to it.Open full screenshot
Earlier lineup viewDevelopment fixture · Sep 15, 2026
Earlier lineup screen with starter, bench and salary-cap information.
The earlier lineup squeezed the team into the main game shell.Open full screenshot

Recent roster capture and archived desktop layout

Screens from development saves on Windows and Android.

Recent roster captureAndroid · Build 315 · Oct 4, 2026
Build 315 Baltimore roster with starter and bench capacity and next-season salary cap.
The recent roster view. There is finally a team to manage, with plenty still to tidy up.Open full screenshot
Archived desktop layoutDesktop · archival capture · date unconfirmed
An archived desktop front-office budget view with accounts and projected funds.
The archived desktop layout. The capture date is unconfirmed, and this is a different save from the phone example.Open full screenshot

The season dashboard and covering an injury

Screens from development saves on Windows and Android.

The season dashboardAndroid · Build 286 · Sep 30, 2026
Season dashboard showing the Chicago franchise, its record and team information.
The season dashboard. A fairly long way from the text files I started with.Open full screenshot
Covering an injuryAndroid · Build 286 · Sep 30, 2026
Injury-cover decision screen showing players and reserve options before confirmation.
Reviewing reserve cover before confirming the choice. The decision needs to be clear before I make it.Open full screenshot

Before kickoff and looking for a replacement

Screens from development saves on Windows and Android.

Before kickoffDevelopment fixture · Sep 15, 2026
Earlier pregame view showing the matchup, team emblems and coach portraits.
The earlier pregame screen. Two teams, two coaches, and a game waiting to start.Open full screenshot
Looking for a replacementDevelopment fixture · Sep 15, 2026
Free-agent player list with a portrait, estimated salary and signing control.
A free agent might fill the gap. The salary is there to make sure I don’t forget the other half of the decision.Open full screenshot

Recent budget view and earlier results layout

Screens from development saves on Windows and Android.

Recent budget viewAndroid · Build 315 · Oct 4, 2026
Build 315 front-office budget with the season-opening bill, payment timing and projected funds.
The budget view, because apparently building a football game also involves doing the books.Open full screenshot
Earlier results layoutDevelopment fixture · Sep 15, 2026
Earlier game results view in the development fixture.
An earlier results layout in a separate development save.Open full screenshot

Creating a player and earlier roster capture

Screens from development saves on Windows and Android.

Creating a playerDevelopment fixture · Sep 15, 2026
Earlier player-creation screen with body measurements and appearance controls.
An early player-creation form. Plenty of information to squeeze onto a small screen; I was still finding room for it all.Open full screenshot
Earlier roster captureAndroid · Build 286 · Sep 30, 2026
Build 286 Chicago roster with lineup places, bench and salary-cap summary.
The roster in an earlier Android build. Useful to keep around when I’m checking whether a change really made things clearer.Open full screenshot

Recent desktop and phone views

These are development captures. The images are from different development saves.

The desktop game todayWindows · Build 318 · Oct 5, 2026
Build 318 Windows home screen with the Arizona Teapots franchise, its pixel stadium and the companion navigation panel.
The Arizona Teapots home screen, with the stadium and companion panel.Open full screenshot
Recent results viewAndroid · Build 315 · Oct 4, 2026
Build 315 game-results screen with league scores and schedule paging.
The results view. Seeing the league produce scores still makes me stop and look for a minute.Open full screenshot
All blog posts