Four weeks ago I wrote a lengthy post about why I want to build a video game for programmers. Since then the foundation for the project has been laid, I joined forces with my good friend Rob, and it is now time to develop the first game mechanic.

Programming as a Game Mechanic

Developing a video game for programmers has a fascinating and unique feature: Programming is the game's first and most important game mechanic. Because it is the primary interface through which users interact with the game world, it dominates the user experience and sets the tone for the whole game. In TIS-100, the limited set of instructions in the game's custom programming language creates intricate puzzles. While playing Screeps' with its almost unrestricted support of JavaScript feels powerful and creative.

For this game, the latter is definitely the goal as well. Players should feel encouraged to experiment, powerful when using all of their chosen language's features, and creative as they develop their own strategy and implementation. Much of this is determined by the API between the game and the player, and the environment that runs the player's code. Both will be addressed in a later article, when the game mechanic described in the following sections will be implemented in a prototype.

Mechanics as Games

While researching game design, I came across the article Fundamentals of Game Design by Raph Koster and the following quote:

The first thing to understand is that games are made out of games. A large game is actually composed of minigames.

This advice has guided the design of the first game mechanic for the prototype. The goal is to develop a first game mechanic as its own small game, but design it in such a way that it can become part of a bigger game with small modifications and a bit of balancing.

This approach has two major benefits. First, it allows us to quickly and cheaply set up a meaningful prototype. We can focus on a single game mechanic, spin up the project, and start testing how engaging it is to play the game by writing code. This takes much less time than designing everything upfront. And second, we can (hopefully) reuse work we do now at a later stage. Since there is no huge team working on this project, being efficient with our resources is important.

Mechanic #1: Cleaning Solar Panels

Much of the game has yet to be designed, but as it stands now it will be space themed. Players will find themselves on a foreign planet, where they will start to build a base. Even though many details are still unclear, players will need to generate energy to operate their buildings and units. This is where we set off for the first game mechanic.

For this mechanic, we are focusing on a tiny slice of the final product. We assume that the player landed safely on a new planet, and that they brought a command module, one or more drones, some solar panels, and a battery with them. The command module is at the heart of the new colony, as it contains an AI (i.e. the player's code) that controls the colony. Drones perform tasks, solar panels generate energy, and batteries store it. Both the command module and the drone(s) consume energy to function.

The planet the player finds themselves on is similar to Mars, and has a dry, sandy surface. Over time, wind deposits sand and dust on the solar panels, which causes them to produce less and less energy. Eventually, they produce less energy than the command module and drones consume, and the colony starts to run out of energy. The player has to use drones to periodically clean the solar panels to maintain a sustainable energy supply.

These are preliminary rules:

• The command module, solar panels, and battery are placed at random distances from each other.
• Sand is deposited on the solar panels at a pseudo-random rate.
• The rate with which solar panels produce energy slowly decreases as more sand is deposited on the panel.
• The energy produced by the solar panels is stored in the battery, from where it is consumed by the command module and drones.
• The command module consumes a constant amount of energy to operate.
• Drones consume a constant amount of energy to operate, and additional energy to move and clean a panel.
• Drones have to recharge at the command module when they run low on energy. When a drone runs out of energy, it has to be recharged using another drone.
• The game is lost when the command module runs out of energy.

This is the rough idea for the first game mechanic, and the first feature of the prototype.

Learning Objectives

This scenario has been picked because it allows us to make progress with a few different objectives.

First, we can experiment with event generation in the game engine. The initial idea is to have a decay function that reduces the output of the solar panels at pseudo-random intervals, and push updates whenever the rate hits a certain threshold. For example at 90%, 80%, and so on. Many ideas for the game are built around the assumption that we can reliably calculate and publish these events in real-time in the backend.

Second, we can experience how it is to interact with the game through a gRPC interface. Our assumption is that it will feel natural and engaging to write code in one's favorite language using this type of API, but we have not tested this yet.

And third, we end up with a "playable" release that allows us to go in many different directions based on the lessons we learn. We can either invest in building out the infrastructure around the game, for example account management and server hosting. Or we can add a new game mechanic that complements the first, and slowly starts moving the game further.

Next Steps

With Rob joining the project, we have a lot of things to figure out. Most importantly a good cadence for discussion, planning, and delivering. We are both interested in the Shape Up methodology developed at Basecamp, and might aim to work in four week long cycles. This would then be the target for an initial implementation of this game mechanic.

We will try to work as much in the open as possible. I will continue to write articles about interesting topics and problems we encounter, and we will discuss the progress in our podcast Dev 'n Life. Please reach out with any questions or ideas you have. We'd love to talk to you, and we definitely need you to sanity check our ideas... 😬

Thanks for following along!