Koje

Koje is a game in which players develop programming for autonomous spacecraft in an attempt to solve various problematic scenarios. Currently these scenarios are simple puzzle-like missions in which the player must try to figure out the most optimal way for their vessel to complete a set of tasks. The tasks can be something as simple as reaching a target area or keeping the vessel functional for a required amount of time. What is considered "optimal" is a choice the players make. Similar to many Zachtronics games, the game will feature leaderboards for different categories (speed, power consumption, etc.) on a per scenario basis.

This project started off as a little experiment on writing games using Zig. I had previously been toying around with Zig while solving Advent of Code puzzles and I grew to enjoy the language quite a bit. It's been a while since I've written games outside the context of premade game engines and oh boy - it is really refreshing! There is just something very satisfying about working with lower level problems and being in full control of everything.

I have been working on Koje on and off for a bit over a year now and it is still very much in an early stage. I am still exploring which parts of the design are actually fun. The game is playable and has tutorials to teach players how things work, but it lacks a lot of surface layers like fancy graphics, UI/UX and audio. In addition, there are lots of unexplored avenues for gameplay.

Simulation

The simulation in which everything happens is at the core of the game. At first, I implemented the physics system from scratch, which was a very pleasant learning experience. It worked fine but I knew it was lacking a lot of well known optimizations and I could spend all my development time on this. So I opted to move on to using Box2D, which has been great so far. I might revisit the idea of a custom physics system at some point.

I wanted to develop the game and the underlying systems so that they support emergent gameplay as well as creativity on the player side. My idea is to provide an open sandbox with interesting tools for the players to play with.

The simulation will have a flexible degree of realism. I would prefer the feel of the game to be more towards hard science fiction where players need to consider available delta-v and heat management, but also keep it soft enough to allow for fun and engaging gameplay. The game is unlikely to simulate full n-body dynamics, but I'll try to keep handwavium and unobtainium relatively scarce.

APIs

Currently the game features two Lua APIs, one for defining scenarios and one for controlling vessels. The programmable scenario API allows setting up different kinds of missions and puzzles. I use this API to implement all the tutorials in the game. I will most likely expand this later to better facilitate player made scenarios and modding.

A tutorial scenario implementation with the current Lua API

Players control their spacecraft via another Lua API. I designed the current iteration of the API to be very low level and simple in hopes of facilitating creative programming as well as enabling easier expansion of functions. The API has a single function for sending data in and receiving it back. As parameters, players provide an index for a "slot" in the spacecraft and the data they want to feed in. The resulting impact on the simulation and data returned will depend on what kind of a spacecraft component is attached to the slot.

Closeup of a debug view of vessel slots and components

Currently the game includes thrusters, range sensors, inertial measurement units and radio receivers and transmitters. Each component expect the input data and usage pattern to conform to their individual specifications. It is the players responsibility to adhere to the documentation from the component manufacturer in order to utilize the components fully. To make it easier for players to get accustomed to the programming, a higher level Lua library is included. The goal is to first teach players what is needed in order to accomplish the mission tasks and then let them have full reign over every implementation detail.

Debugging sensor code can turn into art!

I am still debating if I should implement a programming language of my own or continue with Lua. A purpose built language can change the player experience significantly, but whether the end result is better or worse is unclear. I imagine it is something that has to be tried out in order to make that decision. The game is not only about programming, players have to implement strategy and problem solving to deal with the difficulties of the harsh space environment. The language used to do so should not be in too much of a spotlight.

On the other hand, a custom language could have significant positive performance impact if implemented well. I want the game to scale into fairly large numbers of vessels in order to facilitate large scale scenarios and production of new vessels during missions. The current Lua implementation will become a bottleneck as each vessel has it's own "virtual machine" etc. It can hold up to around 500 vessels without much optimization done yet, but that will come down when players implement more complex scripts.

What's next?

The game will enter an alpha testing stage soon in order to collect feedback and estimate if the gameplay is actually fun enough. If the reception is encouraging, I will continue development and push towards a more open release. I imagine it will take at least 6-12 months to reach that point depending on how much time I have to work on it.