Connecting the Backend to the Frontend
I’m incredibly excited about what I did in the past week; I now have a working frontend for the core card battler mechanic! Previously, I had modeled an entire conflict from start to finish, including several mechanics and end states, but it was running in isolation and practically executable only as unit tests. A picture is worth a thousand words, and boy were those logs verbose. There were several challenges in connecting the frontend.
I used the observer pattern for communicating internal updates; for example, the conflict manager will check to see if the game is over if any combatant is destroyed. When I was just working on the backend, the signals were within individual classes, and I didn’t really notice a problem until I started working on the frontend; it wasn’t practical to reach all the way into the backend manager and all its underlying architecture in order to react to specific events. Instead, I refactored to a centralized signal bus using an auto-loaded singleton, with each signal containing enough context for subscribers to act.
Another problem I had was keeping the backend and frontend synchronized. I had this really clean state management system with actions within each state, enter and exit hooks, with clearly managed flows. However, the backend would do something like resolve an effect that would destroy the player and declare game over, while the frontend would be waiting for the player to choose their cards.
The resolution was for the state management system to use await to listen for a signal to indicate that the frontend was ready to move on. There were a lot of edge cases here with transitions; the last one was when the player would win while playing cards - an interactive loop - and the backend would wait for the all clear from the frontend to transition to the final state that would never come because the frontend was still allowing player choice.
Log verbosity was useful in tackling these challenges; while it may seem ironic to look for a linear description of asynchronous operations, it’s a great indicator of whether the two major systems are in the same state. An early indication of a problem was that the game would end, then there’d be a message saying that damage had been inflicted. It was a symptom of one of many race conditions, often resolved with just a little reordering.
Little weirdsies would pop up, like why isn’t my health bar working as expected? Oh, it’s because you need to set the max value before you set the current value; it’s a hidden dependency, but it makes logical sense (you can’t allow a value to be set unless you know it’s boundaries). The logic was sound, but my order wasn’t.
The game now persists preferences; there is a grand total of one, which toggles logging for collision logic. It was very useful in a narrow context, but too chatty for regular use. The configuration singleton is a little overengineered for today, but I’ll need it for a lot more in the very near future.
The game is playable now, but it’s nowhere near a vertical slice; there’s a major mechanic that is missing, which I’ll work on this week. Broadly, it provides the tactical strategy and pressure that will make it a fun challenge. With that, I’ll add some more opponents, [redacted], and cards to flesh out the core game loop. There also needs to be some animations to indicate effects that the frontend should keep track of in order to say it’s ready to move on; that way, you know what phase it is, who is doing what and what the impact was, rather than suddenly you just having less hull.
If I can hit the above, I can make a playtest build to validate that these mechanics make sense and start getting feedback. Want to be the first to play? Join the Discord (link in the menu).
For a vertical slice, I’d need an overworld to facilitate multiple encounters, a [redacted] system, non-combat encounters, a simple dialog during the conflict for flavor, and support for sound and music. Finally, I’ll need make sure the content is localizable even if I’m not planning on translating at this stage; establish the best practices now.
Easy peasy, lemon squeezy. Honestly, this is fun, I now have something tangible.
Last week, I mentioned contributing a soundtrack; it turned into two music cues, and they’re both published now! Costco Fahrenheit is an independent animated series by ToadBurger.
- Costco Fahrenheit: The Costco Killer (2026) - the “Soylent Green” montage beginning with the wrecker to the food court.
- Costco Fahrenheit: When Saving Hostages Goes Wrong (2026 version) - from the window breaking through the credits.
Check out the music page for more information and to listen to the tracks in isolation.