The Problem with Programming

Confession: I am a programmer by trade. I’ve been cutting code for more than 30 years ever since I was a little kid and my dad brought home AmigaBASIC and I would spend my time copying example programs from the back of the book and getting them to run. I was doomed at an early age.

But I can’t stand programmable action games. I have tried to enjoy them, but to no avail. Each one has been an exercise in tedium. It’s not over-exposure to programming - I still take great joy in writing code. But every programmable action game I have played has lacked some critical element or concept.

The programmable action games I have experience with fall into one of two categories. They are either: puzzle solving, or action conflict (or some combination of the two).

Puzzle Solving requires deducing a series of steps (sometimes using loops or functions to minimize the number of operations) to complete a task. This type of programmable action game is an exercise in visualization - being able to mentally follow the game state to craft the correct solution. The purpose of the game is the puzzle aspect, and coming up with the correct sequence of steps to solve it.

Action Conflict is crafting a (usually limited) sequence of commands to execute when there are other moving components on the board. It is a game of anticipation. When something unexpected happens, your program goes off the rails and chaos ensues. The purpose of the game is simply chaos - that is where the entertainment is, when a carefully crafted plan goes pear-shaped. But it can also be terribly frustrating because of the lack of agency the player has when their program is running.

The problem is that neither of these captures the essence of what programming is. Both operate from a known input state, and the only way to be successful is if you deduce (or correctly anticipate) the exact steps and sequence required to complete the task.

But programming is not about dealing with a known input and handling one specific anticipated sequence of events. It is exactly the opposite. Programming is about creating a flexible algorithm that can handle any input and make decisions in response to events. The programmable action games I have seen are about producing fragile, unreliable, and fixed programs - and experiencing the consequences. The do not allow runtime decisions and epitomize extremely poor programming practices in their execution.

A Better Approach

So when I decided to try making some changes to one of my designs (F5) and implement programmable actions, I wanted to do something different that avoided the core issues I had with most programmable action systems. I wanted the possibility for the input state to have some uncertainty - the possibility for random variance from what the players could see on the board. And I wanted the players to have some tools and options to create a program that could handle or mitigate that randomness at runtime (if they were clever and spent the resources to build their program to do so).

To accomplish these goals I made two significant changes.

1) After all players have programmed their actions for the turn, a random effect is applied. Sometimes it is a change in direction, sometimes a change in position, sometimes nothing happens at all. This randomizes the input state of the program that will execute.

2) Players can spent some of their limited resources on acquiring and using actions that have multiple options to choose from. These actions allow the player to select which action to use when executing the program, giving them a limited ability to adapt to the random effect. Although it may be possible to create a program to perfectly handle any randomization - the cost of doing so is prohibitive. So players must strategically decide when to use them to their best advantage, and when the reward is worth the extra cost.

These changes would make the core of the game be about anticipating decision points and a range of possible input options rather than anticipating events, and managing limited resources to do. Ideally this will shift the focus away from creating a perfect sequence of actions in an all-or-nothing situations to the real-world programmer’s dilemma of efficiently creating a program and sequence of decisions that can return a reasonable result (though maybe not perfect!) for any starting point.

Playtesting so far has shown this approach to be both puzzling, challenging, and can also induce an entertaining level of chaos when, despite your best efforts, things still managed to go sideways. The most entertaining turn I have played so far is one such situation where I managed to deftly create a program that was flexible, adaptable, and still managed to thread a narrow that that perfectly avoided every possible scoring opportunity!