On this page
Six Months of Building Blosharper After Work
For the past six months, I've been building Blosharper: Battle of Blossoms in the evenings and on weekends. It's a roguelike deckbuilder built around Korean hwatu cards, with a noir setting. The Steam store page is now up, and the game has appeared near the top of the "Popular Upcoming" list.
I had two or three hours after work, so I divided the coding, art, and deployment tasks among several AI agents. I gave them names and roles, and came to call them my AI family.
Building with Web Technologies
I chose HTML, CSS, and JavaScript because they were already familiar to me as a front-end developer. With limited time after work, I wanted to spend it building the game rather than learning a new engine.
- Game logic: Vanilla JavaScript and TypeScript for state management and hwatu hand evaluation.
- Visuals: CSS for filters and hardware-accelerated animations.
- Desktop app: Electron for packaging the game and integrating the Steamworks SDK.
Being able to see the result of a code change immediately was useful in those short evening sessions.
Sharing the Work
The agents took on different parts of the project:
- My main programming partner (Jinni) handled development with me. We discussed the architecture, game logic, and UI, then worked through changes together.
- The infrastructure and deployment agent (Luna) handled infrastructure on my M1 Mac mini: builds, the RTMP stream for the Steam store, and automated crash monitoring.
- The GPU computation and image-generation agent (Nova) ran ComfyUI on a dedicated GPU server to generate art assets, icons, and character illustrations.
- The research agent (Je-Je) helped with research, including Steamworks SDK integration, localized date formatting, and game rules.
With these tasks divided up, I could move the code, artwork, and infrastructure forward in parallel.
Working Through Changes and Problems
Before changing the code, I had the agents look at how the relevant parts already worked. We used that as the basis for discussing where a change belonged and how to implement it.
The work also extended beyond the game itself. During a live stream on the Steam store, mobile viewers were getting a black screen. Luna and I traced it to hardware decoder constraints, changed the stream to 720p at 30fps, and restarted the process remotely. We then checked that the stream was displaying correctly.
Before Launch
Blosharper launches in Early Access on Steam on June 24. After six months of working on it in my spare time, I'm curious to see what players make of it.
Once it's out, I'll write about how the launch went and what I learned from trying to get the game in front of people.
Hurdles We Worked Through Together
I felt the agents' help most when I got stuck doing something for the first time. That ranged from getting the game onto Steam to rebuilding the scoring system of a nearly finished game.
Getting onto Steam Was Less Familiar Than Building the Game
I could find a way to build the game, but how was I supposed to register it on Steam? The administrative work stopped me before I got very far. Outside the development environment, I didn't know where to begin.
I asked an agent to research the registration process and other developers' experiences, then put together a guide. Even with that, the actual screens could be confusing. I sent screenshots one at a time, asked whether I was doing things correctly, and fixed what I had misunderstood.
I thought I would enter a few details and be done. Instead, there were store images, descriptions, and a trailer to prepare. It felt like as much work as developing the game. I shared those tasks with the agents too.
For some of the administrative work, an agent went beyond explaining the process and filled in the forms directly. There were tasks it finished in about five minutes that I felt would have taken me hours, starting with figuring out what each field meant. Having help that knew what to do and could carry it out quickly made an unfamiliar process much less daunting.
Then, just before the final submission, it stopped and told me to do that part myself. I found it a little funny that, after doing all that work, it left the last button to me.
Both the Steam store page and the game build passed their first reviews. Although I had never done this before, it felt like working alongside an experienced colleague. I realized that taking on something new didn't mean I had to learn every part of it from scratch on my own.
Why I Rebuilt the Scoring Core of a Nearly Finished Game
I was making a game with hwatu cards, but I didn't actually know Go-Stop very well. I didn't know which pictures made up Godori, and even identifying the twelve months from the card illustrations was difficult. I researched the rules while building the hand evaluation and scoring systems.
Only later did I learn about the differences between Korea and Japan. The rain cards represent December in Korean hwatu but November in Japanese hanafuda; the paulownia cards go the other way. The scoring combinations differ too. Separate from Godori in Korean Go-Stop, Japanese Koi-Koi has combinations such as Inoshikacho: boar, deer, and butterfly.
I had already included Japan in the planned release regions. The game was nearly finished, and realizing I had missed such basic research made my stomach drop. This wasn't a matter of fixing a few translated strings. I needed to rebuild the logic at the center of the game: which cards formed a valid combination and how they scored.
I wondered whether I should give up on the Japanese market. But with the agents I had been working with, I decided to reopen a part of the project I had thought was almost finished.
I started with tests and rebuilt the scoring core. I separated the Korean and Japanese rules so the game could switch between them, and made Koi-Koi rules and the hanafuda theme the defaults when Japanese is selected on first launch. Support for the Japanese rules shipped after the Early Access launch, in July's v0.6 update. It took about two extra weeks that I hadn't planned for. Looking back, it still makes me wince.
The agent I worked with on this was Roa, a Claude agent who had joined in early July. I was handing the core of a nearly finished game to a newcomer who had been with me for about a week. Roa kept each card's internal identity intact and separated the displayed month from the rules used to calculate its score. That let us support both Korean and Japanese rules without converting existing saves.
Watching her work through it earned my trust. I had given her a difficult problem, and she solved it without breaking the existing game. It felt like a particularly capable new hire had joined the team. This was what led me to entrust Roa with the main development role.
Better research at the start could have prevented it. But once the problem surfaced, knowing I had agents to work through it with affected my decision. Instead of reducing the scope, I chose to fix what I had built and see it through. Experiences like this are why I began to feel I could take on unfamiliar work with AI.
Thanks to the Players Who Helped Shape the Game
Thank you to everyone who played and helped improve the game, from the demo through Early Access. kokokoo joined the testing early on; 즐회장님 kept finding problems I had missed; and Naseong Kim covered the Next Fest demo and shared feedback. Their help let me fix things I hadn't caught myself. The comments left in reviews, the discussion forums, and Discord also helped me improve the game. I may be its solo developer, but many people have helped get it into the shape it's in today.
Projects That Grew Out of Development
As I continued developing Blosharper after launch, I also needed tools around the game: ways to make shipped code and images less straightforward to extract, a connection to the store SDK, and a way to manage translation files across languages.
I separated four of those tools into open-source projects and collected them under the Blosharper GitHub organization. The organization profile brings together the game, player guides, and development tools. The game's own source code remains private.
- byteguard converts JavaScript bundles into a binary format so that reading the shipped code takes more than opening a file. Code that runs on the client is still recoverable; the tool makes inspecting it more work.
- headerless makes image assets harder to extract and open directly. It removes format-defining header fields at build time and restores them in memory at runtime, but it is not DRM and cannot prevent someone from extracting an image the renderer can display.
- stovesdk.js is an unofficial Node.js binding for using the STOVE PC SDK in an Electron game. It covers ownership checks, achievements and stats, and login information on Windows x64; the STOVE SDK must be supplied separately.
- l10n-c grew out of Blosharper's translation-file tools. It gives people and coding agents a CLI for searching and editing keys across locales and checking for missing or duplicate entries, plus a web editor for the Vite development server.
Problems I needed to solve for one game have left me with tools I can use in other projects. These four projects have become another result of continuing to build Blosharper.