Why I Started Building Developer Tools Alongside Games

When I first started putting serious time into HK Lab Studio, I was mainly thinking about games. That was the part that interested me most, and Axirune naturally became the project that forced me to learn a lot of things properly instead of just experimenting with them. Building the actual game was only part of it though. Once I got further into the project, there was artwork to prepare, menus to clean up, sound to test, input behaviour to fix, browser builds to check, store material to prepare and a final release to put together without accidentally breaking something that had already been working a few days earlier.

That was probably the first time I really understood how much work sits around the thing you are actually trying to build. When people look at a finished game, most of that work is invisible, which is understandable because nobody buying or playing a game really cares how many times the developer checked the export folder or whether the same browser build had to be tested on three different screen sizes. From the development side, however, those jobs start to take up quite a lot of time. I kept finding myself checking the same things over and over again, writing down little procedures so I didn’t forget something, and trying to remember what had changed between one build and the next.

At first I just treated that as normal development work. If something needed checking, I checked it. If a build had to be tested again, I tested it again. If I found a mistake, I fixed it and moved on. After doing that enough times, I started noticing that some of the problems weren’t unique to Axirune at all. They were the kind of problems I was probably going to run into on the next project, and then again on the project after that.That was really where the developer tools started coming from.

I wasn’t sitting down and trying to invent software products because I thought the store needed more items. Most of the early ideas came from things I was already doing manually. Release checking is a good example. Once a project gets to the point where you are preparing an actual version for people to download or use, you suddenly become very aware of all the small things that can go wrong. You can have the correct build but the wrong version number somewhere. You can accidentally include files that were never meant to ship. You can test one folder and then upload another. Something can work in the editor and still behave differently once it is exported.None of that is particularly exciting, but it matters, especially when you are working alone and there is nobody else doing a second pass behind you. That kind of work eventually influenced the way I thought about ReleaseVerity and some of the other release and regression tools I started building. I wanted a more structured way of checking things instead of relying on memory every time I got close to publishing something.

Browser testing led me in a similar direction. Getting a project to open successfully in a browser does not automatically mean it is finished. A page can look fine on a desktop and fall apart on a phone. A button can technically work but be awkward to use on touch. An image can look correct on one screen size and get cropped badly on another. You only really notice these things once you start moving between devices and testing the same build under different conditions.That became especially obvious once I started putting more games and tools online. Every project had its own issues, but there was always some amount of checking that had to be repeated. After a while I started thinking that if I already had a decent way of testing something, there was no point rebuilding the process from scratch every time.

The same thing happened in other areas too. Data importing sounds straightforward until somebody sends you a file that is formatted differently from the one you were expecting. Localization also sounds simple when you describe it as “translate the text,” but in practice there is a lot of organising, handing files over, receiving them back and making sure everything still lines up correctly. Input systems can be easy when a game only has a few fixed controls, but they become more complicated when players need to remap keys and the interface still has to display the right prompts afterwards.I started looking at those problems differently. Instead of seeing them as annoying little interruptions during development, I started seeing some of them as reusable problems. That does not automatically mean every solution deserves to become a product, but it does mean that if I have already spent time solving something properly, there is value in asking whether the same solution could help on another project.

A lot of the tools I have built have therefore started with a fairly selfish question: would I use this again myself?

I actually think that is a useful filter. If I wouldn’t want to use something again after the first project, then there is probably not much point trying to turn it into a standalone product. Some internal scripts are useful for one very specific situation and then never get touched again. Other ideas sound clever at first but end up adding more work than they save. I have definitely learned that not every little development shortcut needs a name, an interface and a place in the store.The projects that interest me more are the ones where the same problem keeps coming back. If I find myself thinking, “I really don’t want to do this manually again,” that is usually a better starting point.

At the same time, I have not moved away from games. I still want to make them, and in some ways the game projects are what keep creating the ideas for the tools. Axirune taught me one set of lessons, Memory Grid brought different problems, Meteor Defense forced me to think about other things again, and Forge Rush has its own completely different requirements. Even when projects use the same engine, they can expose completely different weaknesses in the workflow.That is one of the reasons I like keeping the Game Lab active. It gives me somewhere to actually build and test things instead of only thinking about them in theory. There is a big difference between designing a tool because something sounds like a useful feature and designing it because you have personally run into the problem several times and are tired of dealing with it the hard way.

Working on tools has also changed how I approach games. I probably think more about testing now than I did when I started. When I add something new, I am already thinking about what else it might affect, whether it will still work after export, what happens on a smaller screen and whether I am going to regret the way I implemented it once the project becomes bigger.That has also made me much more aware of the difference between something working and something actually being finished. I have had plenty of situations where a feature technically worked, but it still did not feel right. A control can respond and still feel bad. An animation can play and still look wrong. A page can load and still be awkward to use. A build can launch and still not be something I would be comfortable selling.

I think that distinction becomes much clearer the more projects you finish.

Looking at HK Lab Studio now, it has become broader than I originally expected. There are games, developer tools, interface products, assets and browser-based projects sitting next to each other. If I had tried to force the studio to remain exactly what I imagined at the beginning, quite a few of those projects probably would never have existed. I don’t really see that variety as a problem anymore. The products may look different on the surface, but most of them come from the same place. I build something, run into a problem, figure out a better way of dealing with it, and occasionally that solution becomes another project of its own.

That is probably the direction I want to continue with. I do not want to turn every small development issue into another product, and I also do not want the store filled with random utilities that have no real reason to exist. I would rather keep building games and software, keep improving the way I work, and pay attention when I create something that I know I would genuinely use again.Some of those ideas will probably turn into games. Some will become tools. Some will stay as experiments and never go any further than my own development folders.

I am fine with that.

The interesting part for me is that I usually do not know what one project is going to lead to when I start it. Axirune began as a puzzle game, but the process of building, testing and releasing it pushed me into thinking much more seriously about release checks, browser behaviour, packaging and the wider development workflow. Those lessons ended up influencing products that have very little to do with puzzle games.That was never really the plan when I started HK Lab Studio, but at this point I think the mix of games and practical developer tools suits the studio better than the original idea did.