Introducing Mechanic Miner

I originally had this plan for a very elegant introductory piece about the new things I’ve been working on, but I’ve been faffing around for too long and I’d rather just start talking about it. So this post will introduce a new system I’ve been working on called Mechanic Miner, what it does, when it’ll produce something playable, and what it might mean for ANGELINA in 2013.

When I started working with platform games last August, I wanted to build powerups by letting ANGELINA have control over the code. I couldn’t do that, though, because ANGELINA is written in the Java programming language, and the platform games are written in the ActionScript language. ANGELINA actually had no access to the game code – all it could do was examine the simulation I’d made. The simulation was like a really bad attempt at letting ANGELINA simulate things like jumping. It was okay, but it really only covered jumping – we couldn’t simulate combat, for instance, because it was too complicated for me to add to the simulation.

ANGELINA did its best though – it could design powerups for the three variables I gave it (jump height, gravity and lock status for the doors). It just didn’t look very impressive. When Free Indie Games linked to us, a commenter noted:

What makes the early work so interesting is that the machine is actually iterating through different game types by changing the fundamental rulesets — what gets triggered when two object-types collide, how each object-type moves, what constitutes a win- or lose-state etc.

By comparison, the platformer work has far less potential for novel gameplay results (if any at all), since all the fundamental rules are hardcoded by the human designers.

Ironically, it felt like the opposite to me. In the arcade game stuff, ANGELINA was just mashing together rule templates I’d given it. Here, it was actually choosing the value of a number in the code so it achieved a certain effect. The problem was that my crappy simulation didn’t really show this off very well.

Fast-forward twelve months, and I’ve just put the newspaper-game stuff to bed temporarily. I finally stumble across the missing piece I needed back in 2011: a version of the game library I was using, ported from ActionScript to Java. Now both ANGELINA and the platform game could be in the same language, and this meant I could start building something really interesting. I began work on Mechanic Miner.

Mechanic Miner uses something called reflection to examine the code of a game. Reflection is a property some programming languages have that lets them talk about themselves. Normally you write program code about data – numbers that tell you what the player’s health is, or what co-ordinate they’re at. Reflection lets me talk about the code itself. It’s a bit hard to get your head around if you’ve never used it before – but if you think of a computer program as a list of instructions, normal programs just do the instructions one after the other. Reflection lets me tell ANGELINA to write new instructions itself, or to change existing things on the list. It’s very powerful.

Mechanic Miner finds new ideas for game mechanics. What do I mean by game mechanics? Well, probably different to what everyone else means. It’s not a very well-defined word. Instead of defining it, how about some examples? Jumping on things to kill them in Super Mario is a game mechanic. Eating power pills to let you destroy ghosts is a game mechanic in PacMan. Game mechanics are ways the player can change the game in order to achieve something. Here’s how Mechanic Miner uses reflection to find new game mechanics:

1. Start with a level you know is impossible to solve normally

Yep. First we start with a platforming game level that you can’t actually finish. Sounds silly, but here it is:

You start at the S and have to reach the X. You can probably see why it’s impossible if you imagine it as a Super Mario level – the tower in the middle is just too high. So we have a level you can’t solve. Super. Now what?

2. Invent a new game mechanic randomly

This is where the reflection comes in. Remember I said it let Mechanic Miner examine the code of a game? Mechanic Miner starts looking through all the different variables in the game library. I mean all of them – things like playerHealth, screenWidth, targetFrameRate – anything and everything. We do it randomly because we’re hoping to find mechanics from anywhere. We really don’t know what we might find!

Once Mechanic Miner finds a variable, it randomly chooses a way of modifying it, and then gives the player a button that does just that. So it might choose playerXPosition and it might choose to Halve the value of it. Now, when the player presses the special power button, their x-co-ordinate halves. If they press it again, it reverses the action and the variable doubles in value. (We do it as a toggle to try and avoid mechanics getting out of control.)

3. Test playing the level using the new mechanic

Now Mechanic Miner uses a simulator to play the level, with the normal platformer controls (moving and jumping) as well as this new game mechanic. We look for longer and longer simulations until we either find a solution, run out of possible simulations, or just give up because it’s taking too long. The levels are quite small, so the last one doesn’t happen often. Most of the time we either find a solution, or we try everything and find that we just can’t get anywhere.

If we find a solution, we know something new. Remember – in step 1 we chose a level that can’t be solved normally. So if we have a solution now, we know that only one thing has changed – we added a button that changed a game variable. That must mean that that variable helps the player do something new. We don’t know if it’s fun or not, but we know it’s something brand new and potentially interesting. We’ve found a game mechanic.

This idea of reflectively looking at game code is really flexible. This is the simplest demonstration of it possible – imagine if we extend it beyond variables to writing game code or inventing new game objects? Imagine if we change the ‘unsolvable example’ in step 1 to an RPG combat scenario, and ask the system to invent new spells or abilities? That’s exactly the kind of research I’m hoping to do next year, as we test out this technique in new areas.

For now, I’m focusing on writing this technique up for EvoGAMES 2013, and compiling a list of Mechanic Miner-made game mechanics into a game called A Puzzling Present, for release in mid-December. I’ll keep you posted as to how that goes.

This was a bit of a full post. If you’d like to know more specifics, please get in touch on email, Twitter, or below in the comments!