Hello! Long time no blog. I’m still working on Delugional, my puzzle game. As it’s (hopefully) nearing release, I want to talk more about the creative and development process.
I apparently promised, many moons ago, to talk about prototyping. Prototyping is a crucial part of game design.
Here’s the thing. You’re trying to do something new in your game, whether it’s a new mechanic you invent, or a novel combination of existing elements. That’s important – ultimately your game’s identity is whatever you put in it that’s new.
But your cool new idea might not work. Plenty of ideas that’re promising on paper just don’t turn out to be fun in practice. The history of innovation in games is littered with noble failures.
That’s where the prototype comes in. The aim is to take your risky, novel idea, and construct the simplest, quickest test that answers the question: is this fun?
I made a couple of initial prototypes for Delugional – at the time only knowing I wanted to make a puzzle game of some sort. The purpose was to find a fun ‘core mechanic’ with enough depth to build a whole game around.
I thought it could be interesting to make a game inspired by physics simulations. The first prototype took this inspiration very literally – it was a ‘simulation’ of particles that could collide with each other, and off the walls, the idea being that you ‘won’ by finding the right initial configuration for the particles to end up in their proper places.
Here’s a picture.
The red dots are ‘atoms,’ the arrows and numbers represent their ‘momentum.’ Quotes added for the sake of my physicist street cred.You can see I didn’t sink any time into pretty graphics. I also put barely any work into the interface. The puzzles were created directly in code, and I even ‘solved’ them by editing the code. That’s all I needed to be able to explore the mechanic.
It took me a couple of days to code the basic interactions between particles, along with a dirt-simple UI, and another day or so to play around with it and reach a verdict.
The verdict? Thumbs down. Quoting straight from my notes at the time:
What I don’t see here is ‘manageable complexity.’ This is something that good puzzle games have. Meaning that the problem is complex, but breakable into smaller parts. …
I don’t see that here. I think the problem is that the simulation component places a big inferential gap between the effect the game enables you to have, and the outcome you’re trying to achieve. Solution steps are either trivially obvious (this atom’s will hit that one) or effectively unforeseeable (multiple atom interactions and multiple reflections rapidly lead to a board situation that can’t be inferred by a player from the initial configuration; that in turn makes it impossible to reason about the effect that small changes to the initial set-up will have). The latter is compounded by the fact that (in my opinion) key simulation rules are non-intuitive.
You can see I was pretty critical of an idea that I’d initially been hopeful about. That’s what you should do in the prototyping phase: generate ideas prolifically, and cull them mercilessly.
Eventually I hit upon a prototype that had legs. That’s a story for another post…