I am building a stealth puzzler based on Sokoban. The underlying theme being that you play as a robber, pulling off heists in banks, museums, offices, trains, you name a famous heist, there’s going to be a flavour of it in the game, granted, it won’t be historically accurate, but it’ll be fun and challenging, at least that’s what I’m hoping for.
This is my first real crack at game design, I’ve been reading up a lot and watching a lot of talks from industry experts (GDC Vaults are pretty good for this, among other things), but I think I’m starting to pick things up a little and I’m applying my new knowledge with this game.
The importance of paper prototyping is not lost on me, at least now it isn’t. When it came to thinking about designing my levels, I had heard a lot about people using paper prototyping in their games, and I decided to try it out. I had done paper prototyping before, just not for a game. I’ve used UX concepts before, but only to design GUIs, websites, etc., never for a game.
There’s a few things that I knew starting out. My initial levels should provide some amount of problem solving, at least, the problems should be only slightly obvious, these levels are more about introducing the mechanics of the game to the player. I had learned this watching GDC talks (I don’t remember which one specifically taught me this, but I do remember it making a lot of sense, looking at games like Portal, where the mechanics are introduced slowly over a few quick levels, and then the puzzles kick in.)
The other thing I knew was which mechanics I wanted to include. I knew that I wanted the game to be a Sokoban clone with a twist. I wanted to include the stealth element, since that was always a game mechanic that I had enjoyed in other games. I love puzzle games as well, and I vividly remember the Sokoban-like challenges where you had to roll boulders around in Pokemon Sapphire, one of my favourite games of all time, I was always slightly frustrated by these challenges, but the feeling of triumph upon completing them was unmatched by anything (except maybe beating the Elite Four for the first time).
Based on this I picked out a few ideas:
- Sokoban elements
- Sweeping cameras
- Patrolling security guards
I also wanted to include a mini-game of sorts, the first thing that came to my mind was a lock-picking mini game. In true hacker fashion, I’ve played a little bit with lock picking (as a hobby only, not to actually pick locks with malicious intent). In the games that I have seen with this mechanic, I’m looking at you, specifically, TES, the lock picking mechanic just isn’t what I thought it was going to be. In my game I wanted to give the player a side on view of all the pins in the lock and let them pull contortions with their hands to complete the lock picking process, a bit more like the real thing, I guess.
The lock picking mechanic isn’t so pertinent, although I felt I should include it since I added a mini-game trigger into my paper prototypes. Anyway, let’s get to the actual process, my final result, and the things I learned.
So for the first, introductory level, I wanted to teach the player a few things about the game:
- How to move
- How to push blocks
- How to avoid cameras
- How to use blocks to block the camera line of sight and ‘hide’ from the camera
- How to move the block to the target
I wanted to illustrate this in the most simple way possible, so I decided to go with the most simple puzzle I could think of. The block should be in the middle of a 3×3 space, giving the player enough room to manoeuvre around it and push it out of the 3×3 space, through a tunnel, and onto the target square, which would then ‘unlock’ the door for them to proceed into the next level.
The next puzzle was fairly similar, a block in a 3×3 space, but this time it was guarded by a security guard and a camera. The player would have to avoid the security guard and the camera, (using the block to stop the camera’s vision from seeing the player).
This taught the player about security guards, whilst having them practice the skills they learned in the previous level.
Finally, the last level would ramp up the difficulty a little, with two security guards and a camera. The player would need to sneak into a room, and play the lockpicking mini game to open a safe and get the ‘golden block’.
This tests the player’s skills and adds in the mini-game, making sure that the player knows how to beat that mechanic.
Mechanics Evolve, Issues Solved
Whilst running through my level designs I looked at a few sticking points. Firstly, I had drawn the walls too tightly on the first level. This would be an issue, so I had to do something to fix this. Essentially, if the player pushed the block onto the target block it would mean that they would not be able to proceed.
I had a couple of ideas, I could have easily opened the corridor up a bit, but that would mean drawing the level out again, I decided that there was a better way. We’d make a hole in the floor that the player couldn’t walk over, this way they only have one way to go – towards the block. It’s a nice subtle way of directing the player. They would then have to push the block into the hole, and that would then allow them to traverse the rest of the level.
The next decision to make was what to do with the door that the block supposedly unlocked. I decided to throw in another lock picking mini game here. This meant that the player was introduced to the idea of it early on, and it meant that they would be able to play it in ‘easy mode’ first, and then at the end of the level, have a chance to play it in ‘hard’ mode.
With this, I had not only solved the issue of the level being too tight and pretty badly designed, I had also found some cool new mechanics and ended up with a nicer level.
The next issue that I found was that in the second level there was no way for the player to move the block into the right place because the camera would always see the player. I decided that the best thing to do would be to change the level so that the target wouldn’t unlock a door, instead, the block would need to be pushed right in front of the camera, completely blocking it’s line of sight, rendering the camera useless.
The final level was very simple to implement, but again, I had drawn the level too tight. I realised that the best thing to do would be to inset the ‘safe’ into the wall, and add a block into the middle of the level. I’d give the security guards a longer range of vision, which would require the player to use the block to protect themselves from line of sight of the guards so that they could pick the lock. The player could then use the block to block off the camera guarding the exit door so that they could make a safe escape.
Whilst thinking about all of this I realised that I could be implementing something else here. The player could steal a valuable ‘dossier’ which would contain blueprints of a museum and correspondence between the curator of the museum and two high powered people about some artefacts that would be transferred to the museum the next day. This would nicely segue into the next level, where the player would be able to make a choice on which artefact they should steal, allowing for story branching.
In my opinion, paper prototyping has really helped me to figure out the kinks in my game before I’ve implemented anything, and it’s been fun to find new opportunities to make the game look good and fun to play. It’s also nice to see how my levels are going to fit together visually before I actually get around to implementing the game.
My next steps are to implement the levels. I’ll be using Puzzlescript to rapidly prototype the levels, this is a really awesome tool that I’ve learned about from watching a GDC talk by the guy who made Sokobond and A Good Snowman Is Hard To Build, and there’s so much that can be done with it in terms of prototyping levels.
Here’s the final design – after I made all my fixes:
This is a really important document to me, because it illustrates clearly (at least to me, maybe not to anyone else), how my levels are going to play out for the first mission. I’ve got a clear idea of where I’m going with each level and I know exactly where everything will go.
Once my mechanics have actually been implemented, it’ll just be a matter of placing each item in the right place and I’ll have a nicely working demo that I can show off. I’ll be posting later about the demo, and the challenges I faced during implementation.