It was puzzle and computer game designer Scott Kim who said: ‘My goal as a puzzle designer is to create a meaningful experience for the player, not just ‘I solved it.’
It’s a good philosophy, especially when you’re trying to create a game like We Were Here Together, which is about atmosphere and exploration as well as solving puzzles.

Getting the balance right can be a challenge – from one point of view, the We Were Here games are all about puzzles. From another point of view they’re all about leaving your best friend to die, but let’s not get into that right now…

Where do we get our puzzles from? To find out, we talked to one of our designers, Niels de Jong.

Walkie-Talk:
Greeting Niels, thanks for taking the time to answer our questions today! Let’s start with the big one: where do the puzzle ideas for the We Were Here series come from?

Niels de Jong:
We steal them from others of course. ;p
Seriously though, ideas can come from a lot of different places.

An approach we take a lot lately is to do a quick summary of everything we already know about the point in the game we want to create a puzzle for, and then we start throwing ideas at each other. In these brainstorming sessions, we can quickly discuss different options. The advantage of working with three game designers is that you rarely run out of ideas!

We’re able to take this approach because we know what most environments are going to be at this point in development. An example of an environment is the crypt at the start of We Were Here Together. So we start off with knowing it is a crypt-like space, and the general atmosphere we want players to feel. The position of the puzzle in the complete game flow is also important. You don’t want to have several high-pressure puzzles in a row, for example. These limitations are often a source of inspiration.

Can anyone suggest puzzle ideas, or is it just the designers that come up with concepts?

Everyone can suggest ideas! The thing is, it takes more than an idea to get to a functioning puzzle. So while other team members can provide the initial point of inspiration, there is still a lot of work that is mostly done by the design team.

Another thing to note is that while we call most of the things we make puzzles, they do not necessarily have to be puzzles. The game is about playing together first and foremost. So if you are doing something besides solving puzzles together and you’re having a great time, then that’s a win for us!

In my experience, the fun is in trying to figure out how not to fail completely at any given task or puzzle… on a side note, I need to find new, better coordinated friends.
Once you have an idea though, how do you work out the details of a puzzle?

Currently we have a way of pushing puzzles through several stages that are more or less the same for each puzzle. We start off with an initial brainstorm as already described. The next stage is to create a paper prototype of the puzzle. Some puzzles are difficult to paper prototype, so we sometimes skip this step and go straight to the next step: whiteboxing.

After testing the paper prototype and making changes based on feedback from testers, we start bringing the puzzle to the digital medium. This usually involves placing the puzzle elements in a 3D space, thinking about viewing angles and level layout and placing lighting.

After this whiteboxing step, we start preparing the puzzle for alpha testing. By this point, we know the puzzle is playable IF you understand it. Of course, understanding how a puzzle works is part of the challenge. In this step, we mostly focus on adding feedback elements that tell the player how a puzzle works. An example: where before you were “pressing” a cube, there is now has an actual button model and a click-sound plays when you press it.

After adding extra feedback elements, a puzzle goes into an alpha build, where all our lovely alpha testers can give feedback and we can spot any glaring issues.

Do you ever encounter problems turning a puzzle from a paper prototype into a digital form – going from the paper prototype to whiteboxing?

Yes, definitely. It makes a big difference whether you are controlling an avatar in a 3D world or looking at some pieces of paper. When fleshing out initial ideas (the brainstorming part), we try to think about how the puzzle will fit in the digital game, even when we do not immediately test the puzzle digitally.

An example: we were working on a puzzle in a cave. The paper prototype was very doable. But of course, when you’re actually standing in a cramped cave with a wall in front of your nose, you have no overview of the entire level. Having no overview means you cannot plan your moves, which in turn means solving the puzzle becomes much, much harder. We had people who ran around in circles both figuratively and literally, because there was no way to distinguish between separate paths in this cave.

I swear I wasn’t one of those people! On the subject of testing, what is the process for testing out puzzles?

We try to annoy our colleagues as much as possible by regularly asking them to test new puzzles! Because we can sit right next to them, we can improvise and get an idea of what a puzzle would be like, without having to actually make each and every element or have the game enforce every limitation. I think it’s time for me to mention the alpha tests again! Those give invaluable feedback.

Thank you for your time!

So there you have it – puzzles definitely don’t spring into existence fully formed, and it can be a tough process sometimes to make them work at all, no matter how cool the initial idea is. Join us in the next edition of Walkie-Talk to hear more from your favorite studio!