Interview by Chris Picone, 16 April 2022

I absolutely love delving into game design philosophy, and that’s what this interview is all about.  It’s the third of its kind; back in 2019 I interviewed some legendary adventure game developers, in 2020 I interviewed some up-and-coming strategy developers, and now I’m back with what I think must be some of the most innovative puzzle developers around today.  I take great pleasure in introducing Martin Firbacher of Daisy Games; Wade Adams from Twintertainment; Mhmd Subhi from RD Interactive; and Nic Ford & Michael von Korff from RBOR games.  These developers were chosen because they are responsible some of the most creative, well-developed puzzle games that I’ve played in recent years, and so I am extremely grateful that they were kind enough to share their time and knowledge with us.  We go into quite a bit of detail through the interview, so it’s a long one.  But if you’re interested in becoming a puzzle game designer or want to include some puzzles in your non-puzzle games, or maybe you want to learn more about those developers and their amazing games or possibly you’re just a game design nerd like me, read on!

***

CSH:  First, I’d like to thank you all for giving up your time – I’m extremely aware how busy indie developers are.  Now, on the off chance some of our readers have never heard of some of you, let’s start with some introductions.

Wade:  Wade Adams, Solo Dev, Twintertainment, Dark Dragonkin

CSH:  Short and to the point!  Who’s next?

Martin: Hi, thanks for having me. My name is Martin Firbacher but due to my English-unfriendly family name I go by Daisy Games. I’m a solo indie developer located in the Czech Republic. Puzzle games with a retro aesthetic are my specialty. I released my first commercial title in early 2021 and haven’t stopped since then!

CSH:  You really haven’t!  I’m blown away by how quickly you’ve been pumping out puzzle games - and they’re all massive!  Your turn, Subhi.

Subhi:  My name is Mhmd Subhi; I’ve been a solo dev for over 10 years now. I usually go by the studio name RD Interactive because sometimes I do non-game interactive simulations (usually in engineering fields). I have published 3 games and am working currently on my fourth. The first three were released on mobile: Multiplication Ball, Ball Seal and Happiness.  Only Happiness is still up on Google play.

I didn’t find success in the mobile market and I am a PC gamer anyway, so I decided to turn towards PC for my next project, which is the current game I am working on, called Hackshot.

CSH:  Makes sense to me.  Thanks Subhi.  Nic and Michael, you’re both part of a development team and that makes you the odd ones out here.  Tell us about RBOR?

Michael:  RBOR Games started in spring 2012 when the four of us (Jordan, Mary, Nic & myself) were math graduate students at the University of Michigan. We just wanted to mess around with game design together as a fun distraction from our graduate theses. I distinctly remember agreeing that we should first spend a few weeks making a simple little game, just to learn the ropes. That “simple little game” grew… and grew… and just released, ten years later, as Bean and Nothingness!

The game took so long in large part because we all went our separate ways after graduate school. There were long stretches where only Nic and Jordan were working on the game, or only Jordan. It took the pandemic to bring us back together to finish it!

Nic:  I'm Nic Ford. We don't really have job titles but I worked on both the game design and the code for Bean and Nothingness. I was also the one who first brought the team together but we were pretty leaderless from then on. Professionally I work as a private math tutor, mostly for adults, and this year I'm also helping to run Canada/USA Mathcamp, an academic summer program for high school kids.  

As Michael said, RBOR Games are a four-person team, and we started working on Bean and Nothingness while we were all in the math Ph.D. program at the University of Michigan in 2012. (The name is both a reference to Ann Arbor, where we all met, and an acronym for "robots building other robots".) I had enjoyed working on tiny games on my own ever since high school, and I thought it would be fun to get some people together to make something a little bigger. None of us had any idea the project would get this big or take this long! I'm honestly pretty happy it did though; it's been a lot of fun.

CSH:  Ten years is an extraordinary length of time to work on a game but with 150 levels and the range of mechanics involved, I can’t say I’m surprised.  Now, I really want to get stuck into a lengthy chat about those mechanics but before we delve into the technical stuff, what are some of your favourite puzzles or puzzle games that influenced your own work?

Martin:  Funnily enough, none. I really liked Puzzle Agent, but it wasn’t an inspiration for any of my games. Truth to be told, I am really awful at puzzle games. This is partially what I found attractive about giving the puzzle genre a try as a game developer. I wanted to make a puzzle game that even someone like me could get into. It seems like it worked, because I have a lot of people who normally don’t enjoy puzzle games telling me they liked mine.

CSH:  I find it really hard to believe that you’re no good at puzzle games, watching how quickly you pump them out and knowing how many times you play through them in testing.  But I think you said you had a similar experience, Wade?  You were more inspired by RPGs than other puzzle games?

Wade:  Lost Vikings was a big influence for Dark Dragonkin, as well a number of the classic RPGs like Final Fantasy, Chono trigger, etc

CSH:  I’ve never played Lost Vikings but I can definitely see how that might have inspired you to work with the idea of having multiple characters.  Any other surprise influences?

Subhi:  At first I was influenced by adventure games, which usually have a mix of combat and puzzles, such as the Crash Bandicoot series, God of War series, and Sly Cooper series. This was most noticeable in my first two games, which were also adventure games but with lots of puzzles that relied on both thinking and execution.

Then I decided to recreate the first video game I ever created, which I made in 2005 before becoming an indie gamedev. I was just learning programming so it was made using simple toggle buttons. That’s the story behind the game that was recreated and expanded as a new game, called Happiness.

The most influential games for my recent works are Stephen’s Sausage Roll, Zachtronics games, and immersive sims such as Deus Ex and Prey (2017).

CSH Picone: I’ve played Deus Ex, of course, but I’ve never heard of and was not expecting an answer like “Stephen’s Sausage Roll.”  Sounds delicious, by the way.  Nic and Michael, what about you?

Michael:  I think my most formative puzzling experiences came from my experience with non-digital puzzle hunt-type puzzles. These puzzles are often designed to be totally mysterious at first glance, leaving solvers to progress through a series of delightful “aha!” moments as they realize “what’s going on” in the puzzle and how to solve it. Elyot Grant, in his wonderful GDC talk on puzzle game design, calls these Eureka moments and defines them as “sudden, pleasureful, fluent, confident feelings of understanding.”

Nic:  Part of our goal was to make a puzzle game for people who like thinking hard about puzzles, and it was important to us to make puzzles that were both challenging and satisfying to solve. There are a lot more indie puzzle games that hit this mark really well than there were when we started development! To name a few, Stephen's Sausage Roll, Snakebird, Cosmic Express, Pipe Push Paradise, and Baba Is You all came out while we were working on Bean and Nothingness and they all influenced how I thought about puzzle design.

Michael:  At the time we started working on Bean and Nothingness in 2012, the only modern puzzler I’d played was Portal, but that game had a tremendous influence on my puzzle design philosophy; in particular, Portal does a great job teaching the player new puzzle-solving tricks while making it feel like the player is discovering these tricks on their own. I definitely sought to capture that feeling as I was designing the first puzzles for our game. There’s an excellent video on puzzle design from Game Maker’s Toolkit that delves into this topic in more detail!

Nic:  A couple other members of the team have played Adventures of Lolo and Chip's Challenge, and they definitely had an influence on some of the mechanics, but I don’t think the puzzles actually have a ton in common with ours. And I also know Jordan has played a lot of DROD, which he's said inspired a lot of his thinking about the game.

CSH:  Interestingly – and unusually – the four of you seem to have incorporated a narrative into your puzzle games.  Why?

Michael:  A puzzle game is primarily an intellectual experience; story, character, and atmosphere allow players to engage with the game emotionally. Take Portal, for example: friends of mine owned Portal companion cube plushies, and I could sing GLaDOS’ passive-aggressive farewell song (“this was a triumph…”) by heart. Story gives players who enjoy and admire a game like Portal a way to love it.

I’m not saying every game needs to be Portal, and we didn’t hire Jonathan Coulton to write a song for Bean and Nothingness! But I find the story Nic created for the game delightful and I’m really glad to have it.

Nic:  This was a very gradual decision and it wasn't always the plan. For a while we were going to have a very simple "world map" screen where you just click on a puzzle and solve it but as we went we found ourselves thinking the game would feel richer if the player were walking around a world that felt more lived in. We ended up writing a story about graduate students and academic research, which felt fitting given that we started working on it while we were in graduate school ourselves.

That said, we also had to be conscious of the fact that Bean and Nothingness was a puzzle game first and a story second. We made sure that the story mostly stayed out of the way of the puzzle-solving, and each player is free to engage with the story as much or as little as they feel like. We've gotten some nice feedback on the story, but we've also been well-received by a lot of players who speak very little English, or none at all, who were still able to fully engage with the puzzles, and honestly the second group does more to make me feel like we built a successful game.

Subhi:  For me, games are worlds to experience, and the more the player is immersed into my world, the more I succeed. In a hacking game, where you destroy other hacker viruses, they should be pissed, so the player may make enemies. Why does the player hack in the first place? Why are they hacking into this device? A story gives context and motivation to player actions. When the player is being contacted by a hacker that is pissed because his plans were ruined, the player feels like he is dealing with a living world that exists. To add to this, the dialogue in Hackshot changes depending on the player’s performance in hacking jobs.  Some characters praise the player’s ability when a hack is optimized and successful but mock the player when a hacking job isn’t well done. This not only bring characters to life, but also allows the player to see the characters from different sides. A character who offers advice when a job goes bad is different than another one who got on his high horse in a similar situation.

Martin:  I originally released Hack Grid in January 2021 on Itch.io and, well, despite my best efforts I only sold 12 copies in the first month. I was crushed but I didn’t give up. I went on a Googling crusade, wanting to learn where I failed. Turns out, Itch.io sucks for selling games (unless you have a huge following already) and Steam is where it’s at!

So I went to Steam and, yeah it went better, but it still wasn’t what I expected. So I spoke to a couple of people and there was a very common reply that I received –  “It’s just a bunch of squares, man” – and it hit me! We are humans, we love stories, we love to relate to the characters in them and I finally understood. My next game needs a story.

Also, adding a story felt like natural progression for my game-making career. Every time I make a new game, I wanna do something I haven’t done before. While Dark Sheep wasn’t the best seller, the amount of interest the game generated and the fact it has a very small but dedicated following to this day that upvotes every single patch update I make for the game speaks for itself. Just for comparison, Dark Sheep has over double the wishlists that Hack Grid has, so yeah, having a story is a great move for any game to be honest!

Wade:  For me, the RPG theme of Dark Dragonkin called for a story.  I also like story-driven games.  Story is a thread that can pull you through a game.  To me a game with character and zero story of why the characters are there doing what they are doing would be weird

CSH: I have a policy of checking out games before I accept review copies, and in doing so I’ve recently learned a bunch of new terms like “pixel hunt,” “Match 3,” and most recently, “Sokoban.”

So now I’m curious.  I know you’ve all taken an innovative approach but what are the fundamental “puzzle types” you have used in your games?  I’m not sure how else to refer to them but I’m talking about, say, logic puzzles, sequence puzzles, relational puzzles, etc.  How have you used them?  And where you’ve included more than one puzzle type, how did you integrate them?

Martin: I often feel like that what’s more important than a puzzle type is how you dress the puzzle up.  Hack Grid in its essence is entirely made up of pieces of a different shape and color. The largest board is 4x4 and you have to make the pieces consume each other until only one remains. A lot of people told me it plays a lot like chess puzzles.

Dark Sheep used the Sokoban formula but added a twist and a few new mechanics. For the uninitiated, in Sokoban you have blocks that you can only push and there are pre-placed destinations for the blocks to be pushed on. To make this harder, there are walls that block both the player character and the blocks. So it’s about finding the right path where to push the blocks, how to stack them and often times you have to back track while making sure you don’t become stuck.

Subhi:  My first two games had puzzles that were usually relational, where understanding the world and how player abilities can affect it is the key; as they were adventure games, that suited them well. In Happiness, the puzzles were usually logical, with some mix of logical and sequential puzzles later in the game.

In my upcoming puzzle game, Hackshot, I have taken a design approach similar to Immersive Sims, where the player has a set of tools and a set of problems, and the goal is to solve these problems. The player has full freedom to use any tools and environmental interactions possible to solve these problems.  This design was then combined with some limitations and a scoring system, similar to the system found in the Zachtronics line of puzzle games, and the mechanical depth of understanding each tool, which is found in Stephen’s Sausage Roll.  This combination gives fluidity to puzzle design, where a puzzle can tackle either the mechanical depth of using tools or environmental logic and understanding, or both, in different mixed portions. This means that puzzles are designed as a combination of logic, relational and sequential at the same time.

Nic:  I think most of the puzzles in Bean and Nothingness have a logic puzzle feel to them. It's definitely a game where you have to take a sequence of actions that play out over time (so it's not like a Sudoku or something, if that's what you mean by "logic puzzle") but the vast majority of the puzzles have one or more "big ideas" that we're trying to communicate and that the player needs to deduce in order to finish. That is, there's an intended solution path to almost all the puzzles in the game, with more or less flexibility depending on the puzzle.

There was an important change we made relatively late in development that I think facilitated this a lot: the final version of the game is turn-based, but it was actually real-time (though still on a grid) for more than half the time we were working on it. By removing the question of speed and timing we opened up a lot more space for more logically intricate puzzles, which is what our game was really about anyway. There are a lot of puzzles in the final version that I think would have been punishingly unfair otherwise.

Wade:  All of the puzzles in Dark Dragonkin are RPG-flavoured.  Every switch, door, portal, crystal and enemy must be solved in real-time. Dark Dragonkin was designed in such a way that basically everything is part of the puzzle and fits organically together.

CSH:  That’s a nice segue into my next question.  What are the key elements in your puzzles and how have you used them to build on the themes in your games to create cohesion?

Wade:  Basically, I spent a lot of time thinking about what the game actually needed to be.  I created the initial design and basically added what was missing and cut what didn’t make sense until I had what got developed.  It was really a key point that everything was balanced and everything went together and everything was organic to universe of the game.  Everything from the puzzle mechanics to the art being consistent to the core game music loop not being too distracting while you play.

Subhi:  In my upcoming game, Hackshot, the player plays as a hacker, and the puzzles are contextualized as hacking jobs or heists, such as tracking the source of annoying popup ads and completely destroying them, or sometimes beta testing a security system for a friend.  From this context, the world the player plays in is Cyberspacetime, and puzzle elements are comical representations of hacking and security terms; for example, Firewalls are represented by a wall of fire and Trojan horses are horse-shaped viruses that disguise themselves as unharmful files, and so on.

There are two groups of elements; security systems and hacker stuff. Each level in the game consists of a bunch of puzzles, usually 2 to 5. These puzzles can be almost completely separated from each other, or can affect other puzzles in the same level, which adds a sort of sequential element to a level. Usually, the majority of the elements come from the security system of the device, and there are files that the player should hack to complete the job. As the game progresses, the player will begin to notice viruses from other hackers that have already breached the system and have taken control over some elements.

Viruses are physical, so they can be pushed around, depending on the type of virus and its properties. Some viruses are special, such as the aforementioned Trojans, Worms, and Ransomware. Worms, in the game’s context, add and destroy elements in the level as turns go on, like adding a virus to the level, or worse, deleting a file before the player had the chance to get it. Ransomware virus holds files hostage, and will delete them if not dealt with properly.  I will keep the mechanics of this one as a teaser for the readers.  Of course, against all of these hackers, there are security systems, which are just as formidable. For example, the player has to think of a way to get around firewalls while Anti-malware can strip some hacking tools from the player’s hand, forcing the player to think twice about what to use and how to use it. We also can’t forget detection systems, which detect some tools when used by the player, starting Safe mode, which introduces new firewalls and obstacles.

Nic:  Maybe this is the time to talk about the beans! The central mechanic of Bean and Nothingness is that the player has a magic wand that turns piles of beans into monsters, and there are also ways to turn monsters back into their constituent beans. The "recipes" --- which monsters are made from which sets of beans --- change with every puzzle. We've found that this idea opened up a lot of pretty novel-feeling puzzle space. For example, it can be important both where and when you create a particular monster; the beans become a resource to keep track of that can be consumed in more than one way, and a lot of puzzles require you to transport some of the beans from a recently-destroyed monster somewhere and combine them with others to make a recipe for some monster other than the one you started with. Internally, we referred to the puzzles that make heavy use of this last idea as "bean math" puzzles, and they're some of my favorites in the game.

Martin:  In Dark Sheep I decided to replace the blocks (usually depicted as crates in Sokoban) with Sheep. Why Sheep? I don’t know, my brain is weird. However, I didn’t want to just use walls to create the puzzles, that’s been done to death. Then it hit me... SHEEP EAT GRASS! So instead of limiting where the player can move, I decided to mainly limit the movement of the sheep. So I added grass tiles that the sheep move on and once they do, they eat the grass and no sheep can step on the tile ever again. This proved to be a very fun and unique take on Sokoban. It also made the game more approachable, since player’s movement is not as restricted as in classic Sokoban titles.

Remember when I mentioned dressing up the puzzles? This is the fun part. So, why are we pushing Sheep around on grass? Well, we want to kidnap them. Why do we want to kidnap them? Well, we are part of an evil cult that wants to bring an evil being into our world. Okay, but why Sheep though? SACRIFICIAL LAMBS!!! Yeah, my brain is weird.

Dark Sheep integrated the gameplay with the story too. Allow me a few spoilers to elaborate. The game is split into 4 chapters. The first chapter – The Kidnapping is all about getting enough sheep for what is to come. For each sheep in the level, there is one crate and you must make the sheep eat all the grass and make sure it ends up in a crate where it becomes trapped and cannot be moved. The first chapter also shows you that the player character will stop at nothing. In one level you end up killing an innocent bystander as part of the puzzle. Most people that played Dark Sheep will tell you about this very moment when you ask them about the game. Puzzle games aren’t usually violent, so this really stood out to people, not only for its pixel violence but also because of what it reveals about the main character.

The second chapter – The Feeding, takes the Sheep-trapping crates away. You kidnapped the sheep and brought them an island that is under the control of your cult. You are there to look over them while they breed and grow bigger and fatter for the day of the sacrifice. While the crates are gone, new mechanics are introduced to increase the challenge in the game and to keep things fresh and fun. This is also the least story-intense chapter on a purpose:   It lets the player relax and let their guard down, very important for the next chapter!

In the third chapter – The Witnessing,  you are not outdoors anymore; you find yourself inside an unholy temple. All the sheep that were kidnapped appear in this chapter. They’re locked up in cages and there are pentagrams (come to think of it, I should have called them Lambtagrams!) everywhere. The day of the sacrifice is here, it’s time to push the imprisoned sheep onto the sacrificial pentagrams which results in their instant death. Funnily enough, at this point, I wanted to mix the basic gameplay up so this chapter actually plays exactly like Sokoban.

However, as you make it halfway through the chapter, things change. The water inside temple is now colored red by blood. As you push on, you start seeing the corpses of your fellow cult members, some even have their heads decapitated. Then in one of the levels you you see strange, sheep-like creatures. They ignore you while they feed on the corpses of humans and sheep alike. I won’t spoil the rest of the game, but looking back, I am impressed how much I managed to do with such simple visuals and only a handful of sprites.

CSH:  Now we’re getting to the good stuff!  I mentioned earlier that, although your games might be based on classical puzzle types like logic of Sokoban, etc., you’ve not just reinvented but really reimagined those genres and created your own totally unique experiences.  What are some of the different and more interesting mechanics you’ve included in your game? 

Wade:  When the Earth Dragonkin die they turn in to boulders that can block the way or be positioned to solve puzzles.  I really like how that adds depth without taking anything away from the immersion.

Subhi:  So, I have been avoiding talking about what kind of tools the player has, because it is where things get interesting. The player hacks systems by shooting cyberballs, similar to catapult games such as Angry Birds. The game parodies hacking after all. The twist is, usually, the player in these games have different projectile types, and each one has its own special usage and ability. In Hackshot, the player crafts whichever cyberball he wishes to use. There are several types of hacks the player can add to a cyberball, such as inverting its gravity or removing it completely, or manipulating its bounce, or increasing its hacking power, which is used logically in the game.  I won’t spoil the other types, because that’s where the fun really starts.

The player can mix and match these powers together to craft unique cyberballs with unique behaviours, which then can be used to solve a wide variety of puzzles. Statistically, there are over 7000 combinations possible, which then can be narrowed down by the player’s experience and critical thinking.

Nic:  One slogan we had when we were designing the mechanics was "do it with a monster". That is, any time we were thinking of introducing a new mechanic into the game, we tried to make it a monster that did it, because then we get the interesting interactions with beans for free. There are, I think, two monsters in the final version of the game that started out as non-monster mechanics.

I think my favorite monster is the one that is introduced to the player last. It's sort of funny that this one is my favorite now, since Jordan actually had to work to convince me it was a good idea in the first place. I don't want to spoil any players who might be reading this by talking too much about it, so I'm probably going to have to leave it there!

CSH:  That’s fair.  Puzzle games are tricky to talk about – you need to reveal some of your interesting mechanics to engage interest, but how to do it without spoiling all the surprises? 

We’ve talked about mechanics and cohesion so now let’s keep building on that.  How did you manage the increasing complexity of the game in terms of initial tutorial and the introduction of new mechanics?

Martin:  For me personally, this has been jokingly easy; just combine mechanics! When I worked on Hack Grid’s prototype, I started super simple. I programmed a piece that can be cyan or pink and can move but only on a piece of a different color. I made a few levels with it and it was fun.

Then I made a piece that is stationary with a green color. Then I made another stationary piece that is cyan or pink but every time you move another piece, it changes color and I kept going like this, making new pieces and then I started combining them into same levels and suddenly I had a brain-twisting game! It’s crazy how much variety a couple of mechanics can provide even on a board as small as 4x4.

Wade:  I actually had the opposite experience.  I developed a game that I thought was almost too easy to start with and with initial testing I found out the learning curve was too steep and I had to go back and rework the tutorial to smooth out the on-boarding experience for players.  I actually spent a lot of development time trying to get that right so that players would “get it”.

Martin:  My games are easy to pick up but hard to master. The rules of each game are very simple but the way I combine the rules in my games is where the difficulty comes from. Of course, I pay a lot of attention to how I increase the difficulty as the game goes on, so people have enough time to adjust. 

Another little trick I have in my sleeve is that I don’t allow player to get used to the same combination of puzzle elements too much. Let’s say I have game mechanics A, B, C, D, and E. If I make the player play 10 levels in a row with the same combination, they’ll get too good at it. So I’ll make them play 2 levels of A, B. Then 2 levels of B, C and so on.

Subhi:  As I am a designer who like to design challenging puzzles, the challenge curve in my games is a bit steep, but I have tried to refine each game to at least have a more welcoming start. From my experience, a good tutorial or instruction is best given when the player needs it. Most of the tutorials in Hackshot are related to controls, not for mechanics, because I want the player to explore the hacking world and experience it without interruptions and discover its secrets, rules and mechanics.

For cyberball crafting, when the player earns a new power, I usually don’t tell the player what this power does because I want the player to test it and explore it. This gives the player a similar experience to that of learning how to program; you have tools and code, now you explore its potential. Of course I had to craft some specific tutorial puzzles with a set of interactions that allowed the player to explore a new mechanic or power in a bit of a controlled way, that is necessary to not cause any frustration.

Nic:  This is something we thought a lot about, and we definitely had to iterate on it a few times with playtesters. We tried to handle this in a couple different ways.

First, we introduce the player to the mechanics very slowly --- in fact, every single new area also contains a new mechanic, so the player never gains access to all the mechanics until the game is almost over. The first ones that are introduced are the simplest, which I think helps to get the player comfortable with the fact that they're going to have to run experiments to figure out how every monster behaves.

Second, we give the player a lot of freedom to explore new areas at the pace they choose. New areas are gated based on the number of puzzles solved, but we deliberately chose numbers that are pretty low, so that the player is free to either move on to new areas or hang back and try to solve move puzzles. This also has the effect that it's pretty rare for the player to be in a situation where they only have one puzzle to work on, which I think is very important in a game as difficult as this one. I love Stephen's Sausage Roll to pieces but it does basically the opposite of this --- you have to solve every single puzzle before it lets you move on, and I don’t think it serves the game very well.

Finally, we have puzzles across a wide range of difficulty levels in every area of the game. Every puzzle has a difficulty rating, from 1 to 5 beans, and while the puzzles near the end are certainly a lot more challenging on average than the ones at the beginning, there is a 5-bean puzzle in the very first area and there are 1-bean puzzles in the final area. Our goal with this was both to get players used to moving on when they're stuck, and also to give them something to come back to when they revisit earlier areas later on.

CSH:  Okay, the player is through the tutorial now and has a good handle on at least the game’s core mechanics.  How do you manage the difficulty curve through the rest of the game?

Wade:  Difficulty is achieved by adding new mechanics to each area.  Also, as you progress the mechanics are positioned where they will be less forgiving of failure and the layouts of the puzzles progressively force you select the correct answer and not just the first thing you see. You need to evaluate your character selection their position and the environment to make your decisions.

Martin:  Oh man, do I hate this part. Here’s how I approach it and what I’d suggest to everyone else who decides to make a puzzle game:

Have enough people play your game from the beginning and have them write down how many tries each level took them and do this yourself too. Once you have all the data, find the average amount of tries for each level and move them around accordingly.

The key word is accordingly; there are two things to keep in mind. Do NOT exhaust your player! And don’t make them face 5 crushingly difficult levels in a row, put in some simpler levels in between. This is where introducing new mechanics comes in very handy! Those levels should be easy, feel free to even make them so mindless they are impossible to fail.

The way I design games in terms of adding new mechanics makes this task easier as well. In all of my games, I know the order I want to introduce mechanics. In Hack Grid, I introduce a new mechanic every 10 levels. So I sort levels 1-10 separately and then I sort levels 11-20 separately and so on.

Last word of advice I’d like to share is that you’ll have levels where half of your testers breezed through and the other half struggled with. There is no perfect difficulty curve. Puzzles are extremely subjective and there is no one size fits all. Use the numbers and your personal judgment to the best of your ability but don’t dwell on making it flawless, it’s just not possible.

Subhi:  As Hackshot design is built on self-exploration of the game world and how it works, many of the early levels gain their difficulty through the introduction of a new crafting option, a new virus type, or a new security obstacle. The process of learning and exploring these new mechanics provides enough difficulty at first but after a while it becomes important to introduce a mix of familiar ideas and new ideas. At one point, usually two thirds of the way through the game, I prefer to stop introducing new mechanics and to just rely on the synergy between mechanics to create advanced obstacles.  It’s like telling the player, “okay, enough tutorials and new mechanics, now it’s final showdown time.”

If I would describe it, it’s like a three-act structure of storytelling, we all love them. In the first act the hero begins to discover new ideas and powers, in the second act the hero has to learn them and to improve through conflict, and the third and final act have no new lessons (mechanics in this case), it’s all about that final showdown and climax.

Nic:  The difficulty curve was something we had to revise quite a few times. The first several drafts of the whole game we showed to playtesters got way too difficult way too fast. It can be so easy to forget what it's like to not already understand your game's mechanics when you've spent so much time with them! We spent a lot of time making the first couple of areas friendlier, and while I think the final game is still quite challenging, I hope it's more welcoming than it used to be. One personal reason for hope for me is that my father, who is not really a puzzle game person at all, told me a couple days ago that he made it to the second area.

Beyond the first couple of areas, a large part of what makes the later puzzles more difficult is just that the mechanics they're built around lend themselves to harder puzzles. The last four mechanics in particular all mess around with the number and color of beans in interesting ways, which naturally leads to the sorts of puzzles where players have to stop and think for longer. We definitely chose the sequence in which the mechanics are introduced with this in mind. The monster that's introduced in the sixth area, for example, was actually one of the first ones we designed, but we found ourselves pushing it later and later in the game as we went because the puzzles that that monster seemed to want to be designed around were so much trickier.

CSH:  I have to say – and particularly considering the wide range of mechanics and interactions involved in your games – that you’ve all done a marvellous job of introducing them to the player.  At no point did I feel unchallenged, but I also never felt overwhelmed or like I was out of options. 

Another thing you’re all very good at is creating synergy. How have you achieved that?

Martin:  I can’t remember who it was, but someone said that a great game design is about establishing base rules and then building on top of them and to spice things up break your own rules sometimes!

I don’t want to sound like a broken record, so I’ll use Dark Crypt as an example this time, since I consider it my current peak of game design.  Dark Crypt is a turn-based game, where you avoid the sight-lines of the undead. The game starts and you are introduced to skeletons that only look in two directions horizontally or vertically. Every time you move, they turn and look elsewhere - simple enough, right?

You progress through the game and I introduce you to the armored skeletons.  These boney boys look in all 4 directions, yikes!  All the enemies so far have been standing still, so what’s next? Well of course Vampires that actually walk around! Oh, and remember those skeletons that look up, down, right or left? Well, how about we introduce another enemy type that looks in diagonals!

Subhi:  Another mechanic that I consider interesting and unique in Hackshot is the fact that the game has three main “teams”; the player, other hackers, and device security, and all of them are enemies. That means that the player can push a virus into a firewall to destroy the virus or use another hacker’s virus to disable a security system. This adds realism to the game’s hacking-themed world, and allows for a lot of interesting interactions where the player can outsmart both other hackers and security systems and use them against each other.

Michael:  I’ve seen this called “emergent behavior”: various simple game elements interacting with each other in ways even their creators could not have foreseen.  With Bean and Nothingness, we had enough monsters, each with a sufficiently interesting mechanic, that the interactions between them felt practically limitless! I’d often notice a funny monster interaction while testing a puzzle, then build a new puzzle with that funny interaction as the central conceit.

Nic:  This was an important design goal for us. Most of the monsters interact in some meaningful way with most other monsters, even if the interaction is something as simple as "monster A is solid, so monster B will stop moving when it hits it.” Every time we introduced a new monster, we thought about all the ways it could interact with each one we had already introduced, and we tried to make sure each interaction was both interesting and felt reasonable to ask the player to deduce. This doesn't mean the player should be able to guess what the interaction would be ahead of time! Just that, when they run the experiment and figure out what the behavior is, it doesn't feel "unfair".

The mechanics we cut are mostly ones that failed this test. That is, it's less that they weren't interesting in isolation, and more that they didn't have enough interesting interactions with what we already had.

Michael:  The work was less about making up clever puzzles from scratch and more about noticing novel interactions and then inventing elegant ways to force the player to discover them. Jonathan Blow once said that developing Braid was "more like discovering things that already exist […] there’s an extent to which this game designed itself.” I can relate to that!

 CSH:  Another thing you’re all very good at is keeping things “fresh” even though your games are huge.  They should feel repetitive but they don’t.  How have you achieved that? 

Nic:  I'm glad you think so! I think this is definitely a place where we're helped by our giant, complicated ruleset. We can roll out new mechanics throughout the entire game, so the player always has something new to explore and play with. The largest area in the game only has 25 puzzles in it, which I hope keeps any one mechanic from getting too stale.

Michael:  I’m proud of the way Bean and Nothingness uses different monsters and mechanics to generate different types of puzzle. There are monsters that lend themselves to deeply geometric puzzles; monsters whose puzzles tend to feel more like “coding puzzles”; “efficiency puzzles” where you need to make the most of scarce resources; and so on.  More than that, I think the “emergent behavior” I mentioned earlier keeps players engaged. As long as each puzzle culminates in a revelation of some clever new trick for exploiting monster interactions, they keep feeling new and exciting!

Martin:  I just introduced new mechanics and combinations of previously established mechanics. All my games are very formulaic in this sense. Every couple of levels a new mechanic gets thrown at the player, then I go easy on them for a level or two and then I start combing it with other mechanics resulting in more challenging levels.

Subhi:  I would like to quote Hugo Martin, the director of my favourite game of 2020, Doom Eternal. He was talking on several occasions about what they called “the engagement curve”.  The short version is, a new mechanic is introduced to the player, the player learns it and uses it. The learning process keep the player engaged and pays off when the player masters the mechanic.  After a while, the player will start to feel bored because using the same mechanic in the same way becomes repetitive. In this instance, I as a game designer should either introduce a new mechanic, a new twist on an existing mechanic, or a new situation that forces the player to think and not just repeat the same thing again, this shoots up player engagement up again. This process should be repeated in order to create a pacing that feels good, to keep the players engaged with the game.

CSH:  I was hoping someone would bring this up.  A while ago I was helping a platform game developer improve his level design and I was trying to find a few articles to send him.  One was an article outlining a “demake” of Mario. It very much relied on the same concepts and the author attributed this to its accessibility and success.

Subhi:  In Hackshot, I actually use a chart that plots the intensity of the story throughout the game. This helps me to create good pacing, and harmony between the intensity of the story and the intensity of gameplay. As an example, if the story is that the player is hacking a top-level security, the puzzle should introduce more than one twist at the same time, so that it reinforces what the story is telling the player about the situation. After the player succeeds in his hacking job, I introduce a puzzle with more familiar ideas, so the player can have an easier time with it and feel that hacking that top-level security has really taught him a lot.