Building a System for the Absurd: Why I.T Never Ends is actually a website

The Path from Godot to React

Before this project, I built a game called Bearzerk. I used Godot for that project because it was a dynamic action game. Godot relies on a traditional Object-Oriented Programming approach that uses inheritance and a scene tree. For a game where physics and character movement are the priority, that system is excellent. However, I found one consistent source of frustration in Godot and Unity: the sheer amount of manual labor required to wire the game state to the UI.

In those engines, you spend a lot of time writing glue code. If a player's health changes, you have to manually find the health bar node and update its value, or set up a signal-and-slot system to handle the communication. My background is in full stack development, and I have spent years working with React. In the web world, state propagation is an elegantly solved problem. I felt spoiled by that efficiency and wanted to bring that same logic into game development.

The React Mental Model: State as Truth

The fundamental shift in this project was moving away from "telling the UI what to do" and toward "describing what the UI looks like based on the data." In React, you use two primary tools to manage this: useState and useEffect (and yes, react purists I know this is barely scratching the surface, but we're doing a thing here ) This declarative approach changes the entire development loop.

The Game as a Continuous State Machine

At its core, I.T. Never Ends functions as one massive, continuous state machine. You are processing tickets, managing your relationship with your coworker Riley, and trying to keep the office from falling apart. Because the game is driven by logic and text rather than physics and collisions, React is an ideal tool for the job.

Below is a comically simplified Fisher Price diagram sort of outlining the state machine that is I.T Never Ends. Building everything in React essentially means that this entire state machine is baked into a single webpage, running one huge blob of javascript, and that is the literal game.

This approach has allowed me to move at a very fast pace in terms of development. My OOP is rusty and - to be honest - pretty damn bad. I make a lot of mistakes, end up in a lot of tangled code and spaghetti solutions and things get bogged down. React and the whole fullstack web/application developer ecosystem is something I'm much more used to and have been working with professionally for about a decade at this point.
Because I am not fighting with UI wiring or custom layout engines, I can spend almost all of my time on the actual content. The project has already grown to include thousands of tickets worth of text and story, which would have been a nightmare to manage in a traditional engine. Or probably - to a better developer than myself - it would have been eminently doable in both Unity and Godot. But I'm only human and I'm doing the best I can with the skillset available to me.

The Build Challenge: Web, Windows, and Linux

While developing the game in React is fast, shipping it is a different story. If you use a tool like Godot, the process of exporting to Windows, Linux, or the Web is a trivial task. It is a one-click process that most developers do not even have to think about. That luxury does not exist when your game is essentially a website that needs to run in a native window. The challenge encompassed the entire build process alongside the need for robust save data persistence.

I had to build my own infrastructure to make a web application behave like a professional desktop game. This meant solving the problem of how a "website" talks to a user's actual hard drive without compromising performance or security.

The Persistence Bridge and the Rust Sidecar

A game that cannot save your progress is a failure. Since I wanted a single codebase, I had to find a way to handle saving data that worked in a browser, on a Windows PC, and on the Steam Deck. I built a Persistence Bridge to make these different environments look identical to my game logic.

The game calls a single "save" function, and a strategy pattern handles the rest based on the platform:

• Web (itch.io): The bridge targets localStorage. This is the standard for browser-based games.
• Windows (Tauri): The bridge utilizes the Tauri Store to write to the local AppData folder.
• Linux and Steam Deck: I moved to Electron for stability on Linux, but I wanted to avoid using heavy Node.js filesystem modules.

To solve this, I wrote a small "sidecar" binary in Rust. This is a standalone binary that manages the file system operations. The Electron frontend talks to this sidecar via JSON-RPC over a local port. When you save your game on a Steam Deck, the React app sends the data to the Rust sidecar, which then performs an atomic write to the disk. 

This architecture keeps the game fast and ensures the save data is robust. It allows the game to run at a smooth 60fps on the Steam Deck by offloading the I/O work.

Final Thoughts on Stability

Moving to Electron for the Linux build was a pragmatic choice. It results in a larger file size than a Tauri build, but it guarantees a consistent Chromium environment. I prioritized the player's experience over my own desire for a tiny binary. For a solo developer, the goal is to ship a game that works. If the underlying vessel is a bit heavier than originally planned, that is a compromise I am willing to make. Getting the controller setup wrapped up also means that the demo runs as smoothly on the deck as it does on the desktop and in the browser. That's a good thing, to me. File sizes be damned. 

Join the System

The energy in the community has been a massive boost. We now have a thriving Discord where players share their most absurd ticket encounters. It is a great place to suggest a new way for a printer to ruin someone's life or to help me track down bugs.

Join the Discord: https://discord.gg/wwpeAMzMRa

If you want to support this project, adding the game to your Steam wishlist is the single most helpful thing you can do. It helps the algorithm recognize that there is an audience for the comedy of the void.

Wishlist I.T. Never Ends on Steam

Thank you for being part of this journey. The fact that this project resonates with so many of you makes the long hours of solo coding entirely worth it. I am excited to show you the thousands of tickets and story branches I am working on.

— Stefan