It is an old wisdom in game design that the player should have fun, rather than the computer. The thrust of this wisdom is that a game can be infinitely complex and model everything down to the smallest of detail, but if the player does not (or can not) do anything significant to affect outcomes, it is not a good game. While the computer might have a blast simulating every bouncing atom, the player may or may not understand what even is going on or what to do with this information.

The phrase also functions as a subtle reminder to game developers to remain parsimonious in their efforts. A game system does not need to be endlessly complex to be fun – it needs only be complex enough that players enjoy interacting with it. Given that development time is a finite resource, knowing when to make something good enough and focus elsewhere is literally cash money.

Outpost (1994) (and its WIP modern remake) is an interesting example of this design principle in action. The game has a myriad of systems that interrelate, interact and (dys)function together, often in the least intuitive ways possible. Most of these systems are completely automated, meaning that there is little the player can do to relieve bottlenecks or stoppages. For all practical purposes, things either work or do not work; the computer gets to have both all the fun and all the misery.

This is not to say that the player’s actions have no impact. Indeed, it is very easy to reach a game over state. Trying to figure out why it happened is anything but easy. One moment, things seem to be going fine; the next, 32 colonists died all at once for seemingly no reason. Something the player did caused this outcome, but at no point is this communicated directly through the interface. Did they die from lack of food, asphyxiation or an alien virus outbreak? The answer is yes.

Each of these causes have a way of preventing it from happening. The way to find out it is happening, however, involves clicking through a labyrinthine series of menus, boxes and interface doodads to get at the relevant numbers. The numbers themselves do not tell you anything – they require a surprisingly vast amount of extramural information on the part of the player. In the case of food, the relevant numbers are those of total production and the population size. By comparing these numbers, a player can figure out if there is enough to go around – if they know the ratio between units of food and population fed.

If the food production is too low, the obvious solution is to build more agridomes. More agridomes means more food means more better. Often this is the correct solution. There is, however, the possibility that the number of agridomes is already quite sufficient, but that they can not sustain production due to a lack of input materials. The obvious reason for lack of materials is insufficient production at the mines. This warrants an investigation of the various mines in operation – are they deep enough, are there enough of them, are there sufficient trucks available to transfer minerals to the smelter? Is the smelter operational? Do I need another one? Is there enough storage to distribute the processed materials, or has production stalled due to lack of space? Are the tubes clogged with fusion again?

Each of these questions require a series of click to answer, each following the logic of giving you a number which may or may not immediately signify what is going on. It is fully possible that the root cause for the lacking food production is that the trucks have empty fuel cells, and are thus stranded in a visually unrepresented middle of nowhere. Figuring this out requires additional clicks and possessing knowledge of how fuel cells and robots interact. Oh, also, trucks are robots.

At no point does the game inform you of these investigative chains. It does hint that the way to gain information about a particular building is to click on it and read the resulting popup, which is akin to explaining a forest by pointing to a tree. The player is assumed to just know these things and make the inductive leap spontaneously. Much like it assumes knowledge of acronyms such as SPEW, CHAP or DIRT. Are these important? Why should I research entomology on a barren planet completely devoid of even the possibility of ecology? Click around and find out.

There is no small irony in that the game running itself (until it does not) is its own kind of fun. Things are happening, and it is your job to figuring out just where the wrongs have happened, are happening or will happen. You have been cast into the role of an expert, whose task it is to synthesize disparate streams of incongruous information into a course of action that will lead to tomorrow’s problems. Gathering any given bit of information is tedious, but figuring it all out and fixing it feels good. The computer has all the fun, and after hours of labor-intense learning, you get to partake of a small part of it.

The game is ultimately hampered by the fact that it is fundamentally unfinished. None of the victory conditions were ever fully implemented, and of those that were, their impact is limited to a popup proclaiming that, congratulations, you did it. Then gameplay continues unperturbed. Most of the enjoyment of play stems from imagining what the situation might be, beneath and beyond the interface. The rest stems from doing something you know how to do; a circular proposition at best,

Perhaps this is a lesson for life at large. The rewards for expertise lie in a private recognition of a work well done, and the reward for a job well done lies in getting to do it again tomorrow. We make our own fun where we can make it, with or without the assistance of design principles.