Building a Game

Over the past week and a half, I’ve started coding again. As part of my unemployment, I was hoping to rediscover building—getting that muscle working again and learning to build new things.

Since I like board games, I started to build a board game: Hive. It’s an strategic two-player game, with a bit more depth than first meets than eye.

I now have a (rough) prototype ready. It’s been fun building it, and there’s been a lot of interesting things along the way.


Stack: TypeScript + Kotlin/JS

A lot of my initial difficulty here was just getting things working, though that’s partially my fault. A library I’m using is written in TypeScript, so I spent ~1 day getting a crash course (I read the TypeScript handbook). In general, TypeScript seems pretty neat. If I was just exploring languages, it would be fun to learn more.

With that said, I’m not actually coding in TypeScript. I’m a fan of Kotlin, and I decided (half on a whim) to use Kotlin/JS.

One big draw is interop: you can pull JS libraries into Kotlin and use them as if they were written in Kotlin. The benefit of this is that you get to write in Kotlin, which includes type safety (though that might not be an improvement over TS).

I spent quite a bit of time trying to understand how things fit together. How do you actually pull in the TS library? How are TS modules declared? How do I get the imports right in Kotlin? How do I get the typing to work?

There were also some fun times where I didn’t understand the errors I was getting. It was quite confusing to get an error about how equals did not exist.

It was quite frustrating at first, but eventually I got things working. The abstraction unfortunately breaks down a bit—you have to keep in mind how your Kotlin code will end up running as JS. Once I figured out the quirks, however, things started going pretty smoothly.

Builds and Deploys

I’ve tried to make a Kotlin project before, but in the past I tried to get it working with Bazel. This is doable if you’re doing Kotlin/JVM, but beyond that the support seemed too early.

Knowing that I’d run into this, I decided follow the standard—I used Gradle. At this point in the project it likely doesn’t matter, and being able to find examples is incredibly helpful.

My deploys are still incredibly simplistic. I’m using Netlify, as I’ve had a good experience with it for this blog. However, I’m manually triggering deploys (to conserve my free tier use).

Things are also simpler because I haven’t actually set up a domain or webserver—everything is statically served at the moment.

Game Logic

This was actually pretty easy to implement. Partially because backend/systems are more of my strength, and partially because what I wanted to do fit in well with the external library I was using.

A few things stood out to me while doing this implementation.

One, tests are nice. This is standard practice, but it was cool to catch a few bugs. Writing tests is a bit more challenging for me just cause it requires more discipline. This is especially true with regression tests—it’s way easier to fix a bug and keep going.

Two, functional programming is neat. I broke down all the movement rules into more atomic pieces. From there, it’s easy to combine them into the appropriate rules for each bug.

Unfortunately, functional isn’t always efficient. Part of my game logic involves move generation: from a given game state, I compute all available moves to a player. Functional makes this require very little effort—you just generate moves and see if they satisfy your rules. In practice, this was too slow.

Front End

I will confess: front end is not an area I’m strong in. I know some extreme basics, but I’m not up to speed with modern practices. Outside of vanilla HTML/CSS/JS, I know some React philosophy.

Despite this, the game today is fully functional and defined in client-side JS, using React. That’s pretty nuts, considering how little experience I have with these things.

This is mostly a testament to good frameworks. Kotlin allowed me to focus on code and not syntax. React let me more easily put together all my pieces.


An interesting thing with all of this—I had to recalibrate on when coding standards matter vs. when they don’t.

In general, I tried to keep my abstractions reasonable. Code is formatted. Once I understand what I’m doing, I’ll clean things up a bit to make it clearer how things fit together.

Other things, however, are messier. I don’t have any stylesheets (and at one point I was duplicating identical <style> blocks). Sometimes I lump a bunch of classes/functions together. Package organization is minimal (and not thought out).

Based on this, I think a good heuristic for code quality is mental organization. Can future you, or someone else, come into your code base and get a sense of where things are as well as what belongs where?

If yes, that’s good enough. Things can be a bit sloppier within those larger divisions.

In other words, try to keep sloppiness to places where it has minimal impact on future coding.


Actually launching games to anyone online involves more than just building. I’m a novice here, and already I’ve made some mistakes.

The biggest one is probably overvaluing building. I neglected (and am neglecting!) some things that I should probably look into more.

The most obvious example of this is with Hive. I reached out the designer asking about licensing and was told that I wouldn’t be able to license the game. So, I can’t actually finish it and let others play it. While the process was still valuable, this is also a bit of a bummer.

In general, licensing is an obstacle to building online board games. I thought it would be simpler (since there are a lot of implementations of games online), but it seems more complicated than I first thought.

The other main mistake I’m making is not understanding enough what people want. For example: publishers aren’t necessarily looking to profit off of digital games! For some, they view as a way to grow the community and brand around that game.

Next Steps

Since I can’t launch Hive, polishing it isn’t very important. I want to spend some of my time building general features, such as multiplayer support. I’ll also be looking for a game I can license and launch.

Outside of that, my other main priority is finding a niche I can best fill. This means understanding more of what people want, and figuring out how I can deliver on that.

One avenue that seems interesting: it is surprisingly expensive to build and launch a decent game across multiple platforms (Steam, iOS, Android). From the single data point I have, existing development studios estimate this to cost $100k. Additionally, it can take years to develop.

I might be naive, but this seems way more than it should be. I’m sure there are a lot more costs I’m unaware of, but based on my initial experimentation I’m hoping that I can shave this down a lot.