The Origins of Kikai

This is the first post talking about the development of Kikai.

Kikai is a programmable RTS game, inspired by Zachtronics and Screeps. The idea is that in order to get an advantage in the battlefield you can tweak your whole army. Absolutely nothing of your army is fixed, types of units, their costs and their code are all able to be modified by the player.

The idea of the game came after playing screeps many years ago, I was a bit frustrated because it felt that either you coded quite a bit of the initial strategy upfront or you would die very soon. The development feedback cycle was slow and it felt that the only thing I could do was build this enormous initial framework. Kikai takes the idea of an programmable RTS and attempts to simplify the onboarding by providing a normal RTS experience from the get go. From the beggining you have units you can create, move and command to attack. The game provides a kind of “Army Template”, helping you jump straight into the fray without having to make too many decisions. This tries to skip the “analysis paralysis” phase, where you don’t know about the game, so you don’t know what to build, so you end up doing nothing (my case with Screeps). You first learn by interacting directly with the game and you can incrementally add small helpers for yourself. Patrolling for example.

The game is “balanced” around the idea that for each unit you can add extra components (up to 16), like engines, weapons, radio, sensors, etc. For each type of component there will be lots of different options with different tradeoffs in power, cost, etc.

This creates a lot of possibilities and directions in which you can optimize your army. If you are creating a scout unit, maybe you can spend a lot on a powerful radio and movement unit, and completely ignore the rest, making these units a lot cheaper to produce.

The CPU you choose also matters, since each unit will have a limit in the number of operations it will be able to execute per frame. Some very cheap CPUs may only run dozens or low-hundreds of operations per frame, allowing only very simple strategies to work.

What should the units be programmed with?

After this idea popped into my mind I obviously started envisioning how a player would interact with this. Here is where the second influence comes into play: Zachtronics Games. For those who don’t know Zachtronics is a small game developer that builds these programming-oriented puzzle games. You are given small instruction sets for strange unique machines and you need to solve programming puzzles. I wanted the game to feel a bit like this. The game is basically split in two different phases. In the RTS phase you are playing a normal RTS, with some extras with whatever you’ve built yourself, but it’s a real time battle. The other phase is more like Zachtronics games, try to build better units using cheaper components, try to make your units smarter or do unique things like talk to each other using the radio and self-organize.

The question then became how would this language look like. I’ve done some attempts here and there over the years but nothing clicked. Everything looked either too simplistic or too complex to do even the simplest things.

Some years ago the 100 rabbits collective built a very interesting personal computing stack, the Uxn/Varavara ecosystem. I had seen this and looked at it many times but I never really related it to my idea of Kikai. Recently while exploring Kikai once more and talking to the programming half of 100rabbits, Devine I asked him how easy it would be to embed Uxn in Kikai and he said that it would be very easy, he sent the C implementation of Uxn and it’s incredibly small and simple. I did a small PoC integrating it into an SDL application and it took me half an hour to have something working. This fully unlocked this project for me this time since I could worry less about language design and more about the game itself.

Uxn really is a perfect language for this project, a lot of the things I was struggling with when designing the original test languages for this project have been solved beautifully by Devine. It is a low-level, stack-based event-driven simple and small computing environment. Very dynamic (self-modifying code) and a system to talk to arbitrary devices. It ticked all the boxes for the project and it gave me a ecosystem of existing tooling, knowledge, tutorials and software around it.

One idea I had from the start was a higher level language that compiled to unoptimized Kikai code. So you could start working on this high level language but it would be slower compared to hand-optimized Uxn. The Uxn ecosystem already has languages like this. I onboarded so many good things by adopting this ecosystem that it really has enabled me to focus on what’s next and finally unblock Kikai development for me. All this ties with this idea I was talking about at the top about different types of CPUs. These high-level languages may make your units more expensive to produce.

Player Experience

The last thing I wanted to talk about is how I envision the player loop of building the army in the future. I’m a big fan of Common Lisp, particularly because of the hyper-fast feedback loop where you change everything at runtime. This allows for incredibly fast development, since writing, testing and fixing your code happens in a continuous flow. I’d like this game to feel like this.

I imagine a Sandbox environment, where you can spawn your units, enemy units, obstacles, buildings, ruins, lakes, you name it. Then while the sandbox is running you can modify the code, run the code, reset the machines, modify the memory, the stack, everything. You have a full developing environment right there in the game.

Today I started the initial system in order to achieve this vision, a live per-unit debugger with breakpoints, individual stepping, built-in documentation and a disassembler. This is currently functional but very rough around the edges. But it motivates me to continue working on this vision.

Next Steps

I’ll be working on the Sandbox during the next few weeks. I think it’s key for me to develop a lot of the game from inside the game, since that’s a big part of Kikai and I need to have this be very polished. Once I have a simple sandbox and the rest of the basic devices implemented (radio, weapons, sensors, etc). I want to release a sandbox demo for people to test.