Making Watches And Making Games

Game design is a prodding process. We push the axes of the game in various ways, carefully, and measure the outcomes of our changes against the player. In the process, the goal is sometimes unclear. What are we pushing towards? What are we measuring? Some sternly insist on the vague objective of ‘fun.’ Some have expanded the meaning to include the unpleasant or banal experiences that games can have – they call these game moments ‘engaging.’ Although a formal framework of game design is still far, what we can say is that the objective of a game design process is comprised of the vision of the game designer and a soup of experiments and insights the game designer has internalised through previous design outcomes and a sprinkling of principles. Game design is an evolution of a vision. Usually this evolution is a manual process, very mechanical, reliant on mixture of intuition and data. But it is slow, designed in the same way a watchmaker might carve the inlets of each gear of a watch. There is no need for game design to keep such a punctuated pace. The contemporary watchmaker could, say, make one-hundred watches, select the ones closest to their vision, and make one-hundred more from that choice watch, without having to bother with the underlying ticks. This is akin to an evolutionary process and it can both move fast and surprise us. In this article I will discuss a new game designer I see emerging, that of the evolutionary game designer.

The Game Designer Frame

I said that a formal structure for game design does not exist yet. But for the purpose of discussion, let us frame game design as a softly-constrained optimisation process. Whether the game designer is aware of it or not, they are optimising. It is generally not useful, though, for the game designer to be aware that they are optimising. It is as much an art as a process; many artists work better by allowing their subconscious drivers to chug. But finding a frame to talk about game design helps us to forecast the future of the game designer vocation. Let’s formalize the game design process with some abuse of mathematical notation. Our impassioned, theoretically-inclined game designer perhaps optimizes the following objective:

game-quality(x) = vision(x) + player-quality(x) + etc.(x)

On the right-hand side we have etc, which displaces all the dribbling constants for any contextual constraints unique to the game. This might be time, money, social constraints related to a community, and so forth. The vision is all the stuff incidental to what the game designer hopes to build. The player-quality is the information the game designer receives from the environment: the players of the game. x is then all the parameters that go into making the game. In this toy model of game design, the faithful game designer ‘designs’ by doing the following:

(1) Perturbs x to create a variation in the game.

(2) Measures vision(x). If this has not improved by some margin, return to (1).

(3) Measures player-quality(x). If this has not improved by some margin, return to (1).

(4) Checks if game-quality(x) is above a satisfactory threshold. If not, return to (1).

(5) Game complete.

How does the game designer act on these steps of the design process? The best game designers have good models of their player-quality and can reduce the amount of time on the expensive step (3). But although step (3) is expensive, it is not the hardest step. The hardest step, I would argue, is step (1), the perturbation, or designing of the game. How should we perturb x? A wrong choice (or interesting choice) could lead to months of added development time, but a doubling payoff in game-quality. Many technologies are attempting to address step (3) because it is the most obvious bottleneck to try to solve from an automation perspective. Automated QA systems, massive player communities services, A/B testing systems for game versions. In contrast, the interest in step (1) is considerably less. The design of a game’s variables are subject to the tools they are designed with. Feature-full game engines have created a standardisation of the practise and limited the ability for open discourse on the topic of how one game designs. But, there are people out there working on step (1) in ways that deserve more attention. They all fall under a shared umbrella, and there are more than I have had the time to put here. Let’s welcome the evolutionary game designer through two interesting games out there now.

M. Charity’s Fortress

There is nothing more important than the name of something. Not only do I pain over making sure I name an article or a game or a project well, but I project this scrutiny onto other’s work. It is a good preliminary filter: when I see a good name, I instinctively know the project is worth investigating. Introducing: The Amorphous Fortress. For me, the name had undertones of the familiar and the nostalgic, and I consistently mixed it up with Eternal Castle: Remastered and Dwarf Fortress.

The game is closer to a game engine than a single game experience. It uses a node-based agent design tool to allow the designer to build different agent behaviours. Core to the game creation process in Amorphous Fortress is the re-scoping of game design as an atomistic one rather than a holistic one. Faced with a collection of logical nodes, the designer creates individual entities by determining their sensors and actions, and then releases them within a classic rogue-esque grid-world. To design in Amorphous Fortress is to concede control. Naturally, the engine encourages you to build systemically. A game in AF is a clod of five or six agents (though the game can support many more) whose minds you have tinkered with, and then must dump into the petri-dish of the square arena. This game is not just played at a distance, though, and the designer can place player-controlled entities too.

But where AF surprises is not in its systems-first, agents-only design philosophy. By establishing a standard language and environment for its agents across all games, AF easily allows for other agents to exist in other games. It is as simple as putting an agent into your designer backpack and carrying it over to another game. Perhaps a game that someone else has designed? How does a mischievous imp enemy interact with a Game Of Life glider? A bouncing sphere of Breakout versus a PacMan ghost? These intersections, the game designer can explore for themselves. This is a universal representation for an agent, scoped well within a specific game genre.

It’s easy to see how this type of design is a pixel-perfect dream for our evolutionary game designer. Here the DNA of a game in AF is not its code, but its collection of agents and their behaviour graphs. The transaction of agents, the impure passing of agent between games, we could say is a crossover process. And with a smirk we can imagine a lineage of thousands of AF games bred, inbred, recycled. An insestual gene pool of monochrome grid worlds, run over and over, spliced and grafted. What is the thousandth generation of an AF game? We might not know, nor never know. AF, despite its originality, doesn’t seem to have enough players for an escape velocity. As an academic experiment, it has stayed within the sphere of its initial design conceptions. If it won’t be AF, sometime in the future where many games share an agent standard, might we then get an agent-blending engine that benefits from scale.

Younès’s One-Hundred Poke Worlds

Most of the effort in game development over the last couple decades has been on abstracting our design away from these silicon machines we are chained to. Abstraction has been crucial for bringing more game designers to the field, and, as with games like Amorphous Fortress, wastes less time spent on building pieces and frees up more time to spend on experimenting with the relationship of the pieces. But we should not forget the bedrock of our work as video game makers. Many think of software as the essence of a game, but this is still too vague. In reality, we use a higher-level language to build our game and only then compile this down to its lowest-level representation which we deliver to the player. Our final game then is a file of byte commands for the machine.

A compiler will shout at you if you have missed a closing parenthesis, a trailing semicolon, or any of the language violations put in place to help the programmer. Again, this is an abstraction designed to make writing machine instruction easier. But in terms of the final instructions we send the machine, there is very little limitation here for what we can write. In fact, the bytes in a game binary, each representing a command for the machine, can be any of 255 values. Why not design at the byte level instead?

Although this might have been approachable fifty years ago, any eager game designer now would have to first learn patience before they learned design. Iteration at this level would be a mess. But we can forget human fingers for a moment and bring in an algorithm – something random and wild and uncontrollable – that might help us design better in this complex design space. Enter Younès Rabii’s Pokemon Glitch.

Pokemon Glitch is a cyber-nightmare. Its Pokemon run on the hardware of your midnight dreams. The Pokemon here spasm like television static, people speak in a blend of English and hellish tongue, and not even a wall or door can be trusted to not be a fatal encounter. Yet the game is playable. It has a beginning, an end, and even a convincing narrative arc. To understand Pokemon Glitch is to understand its main menu – no, to understand Pokemon Glitch is to understand its many possible menus. I have reproduced Younès results to create the many other possible Pokemon Glitches that never saw the light of day. Here are some screenshots:

Each screenshot is a Pokemon Glitch. A thousandth child of the random process that beget this game’s stark, retro-punk, vomit color palette. Most of these do not survive beyond the START button. They crash into a white void, swallowed up by humming digital tones, perhaps a glyph of a red ‘C’ character turning on and off in the corner of the screen. Some of these Pokemon offspring allow the player as far as the opening level of the town square. Here lies a deceiving stability. The player wanders, harmlessly interacts with a door, walks over a patch of grass, investigates an NPC whose arm and face have traded places, or even (an honest mistake) moves to the left for too long, and is rewarded with the screen of white death.

What Younès found, though, was that if they were persistent in their iterations, carefully checking and testing the different Pokemon offspring, eventually some games would be more and more successful. The details of Younès talk are vague at times, but eventually through sheer persistence and iteration, Younès found an iteration of Pokemon Glitch that was playable from start to finish. Younès spends most of the talk diving into various vignettes of this new game, and it is fascinating to see this messy design process produce something with coherent moments we would expect from a game with more intention in its design. But to call this intentionless design is unfair to the designer. We can already see how this design process could expand beyond Younès’s initial approach. Rather than single perturbations of the bytes of the game’s ROM, perhaps an interface where the designer could visualise a grid of hundreds of Nth generation game ROMs. They could select, crossbreed, or enhance their ROM generations. A ROM-evolution tool, similar to those genetic-based art tools of yore (see Pic Breeder, The Genetic Art Project or Karl Sim’s genetic images). Inspired by Younès’s work, and the pic-breeder project I working on such a tool. I’ll perhaps share details in a future article.

ROMs are a perfect space for our evolutionary game design to play in. They are small, generally well-documented, and there is a vast ROM-hacking community that supports some great emulation tools. There are other evolutionary-adjacent ideas being applied to ROM design, such as item randomisers that make use of knowledge of the ROM’s data layout to randomly change the memory in ways that preserve the gameplay but change the item placements. Or ROM reinjection (same paper) to generate random but sensible game layouts. These more controllable ROM-design methods could be more useful for some evolutionary game designers than the randomness of Younès’s approach.

The Origin

The evolutionary game designer deals with quantity. In terms of our equation at the start of this article, their design process involves minimising the time and effort required to produce variations in variations in the parameters that make the game, so that they can reinvest their time in a more selective design process. They inspect the hundreds or thousands of outcomes of their evolutionary designs, and design by selection rather than select by design. What they forgo in control, they gain in abundance – and further, gain in coverage, traversing design spaces they might never have had the time to.

It is worth closing on a comment about game development in general. Right now there exist a set of standard tools and practises for making a standard video game. We must remember that these tools have only become concrete in the last decade, driven by the boon in number of video game developers and establishment of a video games ‘industry.’ Whenever we have questioned our tools and practises, we change the landscape, redefine concepts, and invent new terminology. As game designers we should always be questioning our tools and practises because it is the tools that define what is a constraint and what is admissible in the problem of design. If that problem is optimising for some design objective, we should consider how we are optimising for that objective. Right now, game design and game development in general lean heavily on a very principled approach to game creation. The limitations of this approach are already being breached as we see new systemic games come to the forefront. Games such as Tears Of The Kingdom, Mosa Lina, and Baba Is You are examples of games where the designers have admitted that they may know less about the game than the player does. As more games like these are built, it is only natural that the designer might do less and less work to conceive of a game concept, and instead will work at the scale of possible game worlds, exploring, instead, this vast design space by a process of selection. This, perhaps, is the evolutionary game designer in full swing. Or perhaps, automation and massive data-driven approaches will remove the designer all together. I want to doubt the latter and protect game design under the wing of artistic and creative practice. The video game is still far too complex, and even our most impressive automation technologies are still too limiting for there not to be a human in the design loop. It seems the human skill will always subsume the technology. We shall see.

Closing Remarks

Finally, I will add that at my game studio, Martian Lawyers Club, I have been advocating for us to always continue to question the game design medium and its design assumptions. With this core principle and a toolkit of machine learning, we have cracked open an interesting vein in the design mine. Starships TV is our first public project showcasing this (whose visuals, you can tell, are inspired by Amorphous Fortress). Starships TV explores evolution as a functionality generation mechanic for the player. Players choose any two ships and breed their respective functions, producing a child ship with properties of both parents. This we do all inside of the game’s software, not some domain-specific language. This results in some interesting freedom in how the ship behave, constrained only by the complexity of our code representation. There are relationships between this and the evolutionary game design processes mentioned above, but that is best left for a future discussion.

Until then: keep on evolving!