Show HN: React에서 카드 기반의 섬뜩한 IT 지원 게임을 만들었습니다.

Building a System for the Absurd: Why I.T Never Ends is actually a website I set out to make an existential comedy about the mundane grind of tech support, and seeing people connect with that world has been a massive boost. As a solo developer, you often spend months shouting into a void. It is a strange feeling when the void starts shouting back with ticket suggestions and bug reports. I am immensely grateful for that, but most of all I am so happy to hear from real people in the world who've had a good experience or found joy in this thing. I have very little to offer anybody as a sign of my gratitude for this, but I want to take a moment to look under the hood at how this project actually works and share it with anybody who might be interested.* 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. | Feature | React (useState / useEffect) | Godot / Unity (OOP) | |---|---|---| | State Sync | Automatic: The UI re-renders whenever the state updates. | Manual: You must emit signals or update labels in a script. | | Logic Flow | Functional: Data flows down through the component tree. | Imperative: You tell specific nodes to change their state. | | Side Effects | Hooks: Logic runs only when specific dependencies change. | Lifecycle: Logic usually lives in a broad "Update" 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 ga