Working on a new idea is always good fun, but I particularly enjoyed the Mechanic Miner stuff I’ve been doing lately because it threw up a lot of interesting ideas and is making me think a lot about future work as well. If you read the post about it and weren’t too sure, I wanted to write down a few big things that I got out of Mechanic Miner that you might find more exciting.
1. It produced game mechanics that humans came up with
Among the mechanics MM came up with were low gravity (seen in a variety of games - Rochard used it recently) and my personal favourite, inverting gravity (seen in Terry Cavanagh’s peerless VVVVVV). There are a few caveats – MM’s mechanics are simplistic compared to the human-designed ones, because the system is in its infancy. A good example is VVVVVV, actually – you can’t jump in the game, and you can’t invert gravity in mid-air. These constraints actually improve the quality of the mechanic – something that Terry Cavanagh can identify well using his squishy human brain. I wrote some code that allowed MM to generate constraints, but it never made it to testing. Something for next year perhaps.
Producing output that is similar to human output is a noted theme in computational creativity, not because it’s great, but because it might imply that a system is heading down the right avenues. I’m not sure MM has much to do with computational creativity yet, but I think that the system is showing potential here by reinventing known game mechanics.
2. It produced game mechanics that (some) humans haven’t come up with
I know there is probably someone reading this who can contradict me, but I can’t think of a game that used bouncing as its core mechanic. MM discovered that Flixel’s somewhat-unstable physics system has a feature called elasticity which affects how objects in the game react to collisions. By fiddling with this value, it produced a mechanic whereby the player becomes rubbery and can bounce higher and higher over time to navigate the level. It’s totally weird and I had no idea Flixel could do that until MM presented me with the result.
Clearly, generating things that I couldn’t think of is a good indication that the system is doing something valuable. I’d like to make games myself one day, spare time or otherwise, and this system is already showing value to me as a game developer. That’s pretty exciting.
3. It found an exploit in one of its own mechanics
Pretty early on, MM came up with a mechanic based around teleportation. It moved the player a constant value left or right, letting it skip over obstacles. I then asked MM to design levels that used this teleportation mechanic (I haven’t spoken about the level designer, but I will later – it’s basically as it sounds). Problem was, MM kept returning results that didn’t make any sense – it would show me a level, and tell me its solution, and the solution would seem to be completely illegal. Each time it would show it jumping in what looked like mid-air.
I spent three days debugging the simulator. Were the keys configured wrongly? No. Was it not saving the state of the world each time? No. Eventually, I realised that MM was telling me the truth all along, and that it had discovered a way to glitch some of Flixel’s built-in code to allow it to wall-jump.
In the sample game that I wrote for MM to analyse, when you press the jump button I ask Flixel if the player is touching the floor. If they are, they can jump, otherwise they can’t jump. The floor-check stops the player from jumping unless they’re on the ground (in theory). But MM’s simulator discovered that if it teleported inside a wall – even if this was halfway up the side of the wall, not touching the floor at all – Flixel would treat this as if it was touching the floor. By pressing jump while inside the wall, Flixel would push the player out of the solid object, propelling them upwards.
It instantly reminded me of the Portal speed runs that use geometry glitches to boost through levels quickly. It’s also, effectively, an emergent mechanic. MM’s mechanic had nothing to do with wall jumps – it just let the player teleport left and right. In doing so, though, it found a use for the mechanic that went beyond its obvious design. I had to drop the mechanic from my pilot study at the last minute, at the realisation that no-one would work out the trick before they got frustrated. It was irritating to do, but also incredibly exciting.
What next then?
Well, the end of the year is wrapped up with game development. Come January I’m hoping to take some of these ideas into new genres (possibly) or further expand them by connecting them to ANGELINA’s main platform generation (no more seeing the same two powerups over and over again!) As usual, I’ll keep you posted here.
More on the Christmas game soon! Thanks to everyone continuing to comment, share and email. I love talking to people – mike <at> gamesbyangelina.org
Mike, these are extremely cool discoveries. MM sounds like it is doing something right. Is it just brute-forcing them Deep Blue style or is it just finding them and applying them in computationally logical ways? Or something scientific? Whatever the case, I am impressed.
I seem to recall an entirely terrible game called Baron Von Puttingdon vs the Cancerous MC Escher Maze of Cheese, which quite possibly used bouncing as a mechanic (however my mind is full of some really poor games so this one has been lost; I couldn’t recall nor find after a quick google, though it’ll probably be on youtube). Obviously this was an early indie ground breaker in that it was awful and had a ridiculous name.
Hey, you!
It’s a little of both. Both discovering mechanics and designing levels that use the mechanics are driven by computational evolution – the same stuff that powers ANGELINA. It’s all about generating lots of initial stuff randomly, then iteratively selecting the best and combining them together to create better children, and so on and so on.
The mechanic discovery is a little weak right now. What it needs is more options – it needs more operations it can apply (it has stuff like HALVE or ADD now but it needs more operations, conditions, etc.) to be really effective. But it’s a lot better than just brute force at the moment, I think. I want to test this theory out though and that means expanding it further.
Within A Deep Forest used bouncing as a core mechanic.
Ah, I should’ve known that, I love Nifflas’ games!
Thanks for letting me know – that’ll be a useful example.
Wizball, C64 – Atari, Amiga et al used bouncing as the main movement method initially (it could be overridden by powerups). Also there is a game on iOS called Papijump which uses bouncing as its main mechanic (vertical platformer), although I don’t know if it predates your work.