Is there anything that can’t be generated? In the past, games have tried their hands at generating level designs, monsters and items, world histories, musical scores, artwork and puzzles[1]Â – it seems like there’s nothing we couldn’t try to generate. I like that attitude a lot. I think that trying to generate every bit of a videogame we can think of can help us shine a light on new game mechanics, new ways to approach game design, and new ways of thinking about game creation. This week we’re looking at a system I put together just over a year ago for generating simple game mechanics for platform games.
We’re reading Mechanic Miner: Reflection-Driven Game Mechanic Discovery and Level Design by Michael Cook, Simon Colton, Azalea Raad and Jeremy Gow. I wouldn’t normally talk about my own work in this column, but I’ve been thinking a lot about Mechanic Miner lately and trying to reapply the ideas to the current version of ANGELINA in Unity. Since the topic is on my mind, I thought I’d revisit it in this column, too. In the paper, we described a system called Mechanic Miner, which was able to invent simple platform game mechanics using some very straightforward code generation and a bit of simulation trickery. It’s not the most elegant system in the world – but it got some interesting results.
The first part of the work is about generating these game mechanics. While the paper is about simple 2D platform games programmed in Flixel, really the principles work for any kind of game, as long as you can think of a simple representation for the mechanical ideas you want to discover. For our work, mechanics looked like this:
if(specialButtonPressed){
if(triggeredOn)
someVariable += someValue;
else
someVariable -= someValue;
triggeredOn = !triggeredOn;
}
When you press a special button, the mechanic toggles between ‘on’ and ‘off’. In the example above, it’s about adding/subtracting a number from a game variable, but there are a few variations on this (like flipping a boolean from false to true). There are other analogues for other genres: maybe button sequences and effects for a beat ’em up, or even gun properties for a first-person shooter. The way we did this for Mechanic Miner was to use Java’s built-in ability to examine its own code, a process called Reflection. Reflection lets you look at a codebase and ask questions, like “What variables does this object have?” or “How many arguments does this method take?” Mechanic Miner uses this information to pick out variables and values to fill in the blanks in the code segment above.
Of course, most of the mechanics we generate randomly will be complete garbage. In fact most of them will be worse than just garbage – they’ll crash the game completely if used. They might fiddle with exposed game engine data, for instance, or delete the player from the game completely. So how do we find out if a game mechanic is a good idea or not? We use a game design staple: we playtest it and try it out.
The image above is the template level that we use for playtesting. The objective of our ‘game’ is to get Santa to the present on the right-hand side of the screen, but Santa can’t jump high enough to get over the barrier in the middle. This is the key property of the level:Â it’s unsolvable using the current game mechanics. We’re going to use this fact to make it easy for Mechanic Miner to separate good mechanics from bad ones.
The next step is to write a solver for the game, and this is where things get a bit complicated. Normally, writing a solver for a level like this would be like writing a specialised bit of AI – you’d give it instructions on how to reach the exit, what abilities to use, and so on. The catch is that this solver needs to use game mechanics you haven’t invented or seen yet. The quickest way to do this is to make the solver try every possible combination of button presses and record the outcome. As you can imagine, this gets rather hellish if the problem gets too big.
At this point I recommend looking at the paper for details on this bit in particular. The way I approached this was to explore combinations of button presses in a breadth-first manner, and hold down each button until nothing in the game was changing any more. As you hold down a button, record new game states and add them to a stack of game states to deal with in the future. So imagine holding down the ‘Move Right’ button, and every half-second or so, recording a snapshot of the game until you can’t move right any more. Then pick up the next state, load the game back to this snapshot, and start pressing buttons again.
Once you have this solver, you’re almost done. Now we can add one of our randomly-generated game mechanics into the game, and run the solver on the level. Because we knew that the level design wasn’t solvable with our basic move set of jumping and running, if we can reach the exit now then it must be because our new mechanic gives us some special power that lets us do something new. This unsolvable level is now solvable – and that means we probably found something interesting.
Using this simple generate-and-test process, we turned blind code manipulation into a system that could reliable output real game mechanics – like inverting gravity (like VVVVVV), making the player bouncy (somewhat like The Floor Is Jelly) or teleporting (like a bajillion games). I’m interested to see if these techniques can be applied more widely – either to generate more complicated game mechanics, or to apply them to new genres and types of content, like roguelikes.
At the start of the column I said that generating new kinds of things in games leads us to new discoveries, and new kinds of game. As a result of this work, I discovered that Mechanic Miner could also be used to generate game levels for the mechanics it produced, by turning the generate-and-test cycle back on itself and testing levels using game mechanics instead of the other way around. This meant that Mechanic Miner could invent a game mechanic and then make levels for it, even though it had never seen this mechanic before. This was a really surprising discovery, and in theory would mean that a game could invent an idea you hadn’t seen before and test your understanding of it. Derek Yu said that he designed Spelunky’s procedural generator in order to make platform games less about memorisation and more about improvisation. Imagine the kind of improvisation you’d need to adapt to a new game mechanic each time you played…
Where To Find More
You can see some of our results in a game called A Puzzling Present which we released a Christmas or two ago. Michael Cook (that’s me) is finishing up his PhD at Imperial College now but officially works for Goldsmiths as a researcher as well, under the supervision of Professor Simon Colton. Jeremy Gow is a lecturer at Goldsmiths with us, while Azalea Raad continues her PhD on formal verification at Imperial College, London. if you want to chat more about Mechanic Miner, get in touch with me!
- [1]There are many other examples for this list – these were just the ones that leapt out at me.↩