Hey all! It’s been a while since the last update. March has been a pretty busy month. Between trying to implement all the feedback from IndieCade East in February, attending GDC, and starting playtesting again, I haven’t found the time to post here as regularly.
Anyway, finally made enough progress on the different fronts to take a small break and write up an update.
GDC
So, this was my first time attending GDC, and just as everyone had told me, it turned out to be awesome. I only had an expo pass, so didn’t get to go to any of the talks or workshops. But even then, for me, it was amazing just meeting other developers and getting feedback on my work.
There were so many indie developers whose work I respect that were there, and all of them were super approachable and generous with their feedback. Some of the people who I had playtest the game and get feedback from were Justin Ma (FTL), Marc ten Bosch (Miegakure), Brendon Chung (Quadrilateral Cowboy), and Pohung Chen (Perspective). They all had very different and interesting insight and feedback on the game.
Justin talked about having a clear distinction between areas where the player is solving a puzzle, vs areas where the player is supposed to be exploring. If there’s confusion between what the player is supposed to do, the player can’t quite approach the problem with the right mindset. For me, this was a really good insight, because I had noticed that sometimes players would walk into a puzzle room, and when they don’t get the puzzle right away, they would turn around and walk out, thinking they had missed something they need earlier.
For me, when playing other puzzle games, this is a really frustrating feeling to have. Is the reason why I’m not able to solve this puzzle because I’m not getting it? Or is it because I just don’t have the right tool? This is why I really enjoyed Portal’s puzzles, because you knew in each test chamber, that all the elements you need were right there, you just needed to piece them together correctly.
From this, I know I need to make the distinction between puzzles and exploration areas more clear. The challenge is that, unlike Portal, there is backtracking in Relativity. I don’t seal off a test chamber once you enter it, so how can make sure that the player understands that they have everything they need right there to solve it? Fortunately, because the player can walk on all different surfaces in the game, I can place the entrance in an area that’s not as easy to go back into once the player enters a puzzle area, so that it’s clear, “hey, this is an isolated area with a puzzle”.
He also had some feedback with the visuals, and really emphasize the need for the game to have a unique visual identity, to distinguish it from a lot of other FPS puzzle games.
I showed the game to Marc ten Bosch and Brendon Chung separately on Thursday afternoon at GDC, one after the other, and both gave me really good feedback on puzzle pacing and level design, specifically on how to isolate individual concepts, and introduce them one at a time. I didn’t realize until then that in a lot of my earlier puzzles, I was actually introducing 2 or more concepts at once, and a lot of players would get confused on what they were supposed to take away.
It was also interesting to see their approaches to puzzles. Marc, himself working on a puzzle game based on an abtract mathematical idea, found the difficulty level in the puzzles to be just right, and said that any hints or additions to make them easier would ruin the puzzles, but Brendon, who does more linear narrative based games, found the first puzzle to be really challenging. In a way, both are correct. The puzzles don’t need to be made easier, but there needs to be other puzzles before those, to correctly lead up the player. This way, it can address the issue of pacing. For example, I ended up adding another puzzle before what was originally the first one, to isolate one of the concepts, and but kept a lot of the other designs. From playtesting I’ve done since then, this seems to work a lot better.
Pohung gave me some awesome insight on puzzle design. He used an analogy from the Chris Nolan film, The Prestige, specifically this line about the structure of magic acts:
Every great magic trick consists of three parts or acts. The first part is called "The Pledge". The magician shows you something ordinary: a deck of cards, a bird or a man. He shows you this object. Perhaps he asks you to inspect it to see if it is indeed real, unaltered, normal. But of course... it probably isn't. The second act is called "The Turn". The magician takes the ordinary something and makes it do something extraordinary. Now you're looking for the secret... but you won't find it, because of course you're not really looking. You don't really want to know. You want to be fooled. But you wouldn't clap yet. Because making something disappear isn't enough; you have to bring it back. That's why every magic trick has a third act, the hardest part, the part we call "The Prestige".
In the same way, a great puzzle should follow this structure. Pohung used one the puzzles from Relativity that he felt did this correctly (which was actually unintended on my part). The puzzle had two parts. The first part is pretty easy, and is meant as a build up to the second part. The second part at first seems like the first part, but actually requires a variation of the technique. Pohung talked about his line of thinking in approaching the second part, going “Ah, this looks easy, it’s just what I did before…. wait a minute… that’s not going to work here… hm….. ah ha!”. As such, this puzzle shows something ordinary (a simple technique that the player learns), then something extraordinary (the puzzle looks similar, but it seems the technique no longer applies…), and then brings it back (player realizes a variation of the technique would work).
Anyway, it’s quite difficult to talk about puzzle design in depth without showing you the actual puzzles. However, hopefully there’s some high-level stuff that you may find helpful in approaching puzzle design for you own games.