Development Log Week 82

While I spent a big part of the week traveling and in meetings concerning an unrelated project, I still got around to deal with tools and tooling for Prosperous Universe.

Tools: Material Tree Editor

A while back, when Michi and I sat together for one of our planning sessions, we realized that we needed proper tool-support to design the material tree for Prosperous Universe.

To recap: The material tree defines all the dependencies that exist between materials, population levels, planet types, resources etc. As such, it determines things like how fast a player can progress in the game or the complexity of any given product. Initially we tried to design this tree manually in code, which worked fine for testing and development purposes. But we had to admit that it's not going to be a viable method in the long run, when we need to come up with the full, final tree for the production instance of Prosperous Universe.

This week, work on an actual material tree editor commenced. I didn't get far beyond the basics, like the setup of the program itself, functions to add materials etc. Next up will be to actually allow defining interdependencies. I have a feeling this editor project will keep me busy for a while...

Tooling: Our own Docker registry

This section is a bit more technical and quite lengthy, so feel free to skip it if you're not into operational stuff :-)

To deploy and run the different applications that make up a Prosperous Universe game world, we use Docker. And whenever you want to run Docker containers, you need a registry to host the respective Docker images. For our own registry, we had a few important requirements:

1. It needs to be private as we don't want our game to end up available to anyone on the internet.
2. It needs to be cheap as we have to run everything on a very tight budget.
3. It must be low- or zero-maintenance as we want to spend our time working on the game, not maintaining infrastructure.

When we did our first setup trials a few months ago, we went with the Amazon EC2 Container Registry (ECR) as it ticked most of the above boxes: Super cheap, private and no maintenance. There was one catch, though: ECR is supposed to be used from within AWS data centers, in which case no manual authentication is required to access the registry. Since we cannot afford and don't want to run the game on AWS, this meant that we had to generate new authentication credentials for ECR every 12 hours. This added unnecessary complexity all along our Continuous Delivery pipeline and often resulted in annoying deployment failures when re-authentication failed or you simply forgot to do it.

Since we operate a tooling server that runs Docker anyway, I decided to roll our own registry instead. I installed and configured Sonatype Nexus using the Docker image they provide and to my surprise, the process was relatively painless. It means we'll have to do at least some maintenance ourselves, but I hope that it'll be minimal. On the upside, it doesn't incur any additional costs (zero is even less than the few cents we paid for ECR) and it's completely private...the images never even leave our own hardware.

So now we have our own build server building Docker images, pushing them to our own Docker registry and deploying them to our own Kubernetes cluster. Fully automated and triggered only by a new push to a Git repository. I'm rather happy with how this turned out :-)