Chris Picone - CSH Picone
Martin Firbacher - Daisy Games
Wade Adams - Twintertainment
Mhmd Subhi - RD Interactive
Nic Ford - RBOR Games
Michael von Korff - RBOR Games
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.
Martin: Of course, story and environmental changes help a lot too. All my games do this to a certain extent. In Hack Grid the first set of levels has blue HUD and game board. The second set of levels is brown, and so on. Dark Sheep? Well, the first two chapters are outdoors and have a black background. The third chapter still has black background but is inside a temple which results in different environment, now there are pillars, candles instead of the trees and stones you’d see outdoors. Dark Crypt is much more similar to Hack Grid in this regard. The entire game takes place in a crypt which is split into 6 different floors. Each floor has a different color palette and also lighting levels. The further down you get, the darker it gets!
Wade: Dark Dragonkin uses this idea. It features realms with different elemental influences. Each area has a new curve that it throws at you if you pay really close attention there is more on boarding here. There is a new concept introduced in a manageable way that you are expected to master before you leave that realm.
CSH: Alright, I think we’ve spent more than enough time on the mechanics and game design now. Last few questions. How important are sound and visuals for puzzle games?
Wade: I think for puzzle games they should be consistent and not distracting. There really are no unimportant parts of a game.
Martin: No matter how many times you tell people NOT to judge a book by its cover, they’ll keep doing it anyway and games are the same. The most important thing about your game is not the game itself, but the game’s banner art, because that’s how most people will experience your game first.
As for the in-game visuals, they need to be clean! Puzzle gamers in general don’t seem to be too concerned with how the game looks, but it needs to be readable, clarity is a must!
Subhi: The most important aspect of puzzle game sound and visuals is clarity, and that should be the uncompromised rule, in my opinion. Games with more complex graphics can sometimes struggle with clarity. In general, high quality sounds and visuals present the production value of any game, and usually, production value can allow for higher price tags and/or more sales. That being said, puzzle games in general depend on peer recommendations to get sales so mechanics and puzzle design plays bigger rule in puzzle games than in other genres.
For puzzle games, the standard for visuals isn’t usually that high, and I think it is a good thing, because this relieves puzzle game developers from loads of extra work and allows them to pour their time into system and puzzle design. In my opinion, sound design is much more important as it can help to increase clarity and immerse the player into the world, lowering the need for advanced graphics.
Martin: Of course, if you want to attract mainstream gamers that aren’t necessarily puzzle lovers, your game will need to look professional – 3D is great for this or going for a very cute art style or an anime look will do you wonders as well.
As for sound, I believe it is an underrated element of puzzle games. Sound does so much for the feeling the game gives you, whenever we are talking about feedback when you solve part of the puzzle or even atmosphere.
I was surprised by the amount of people that praised Dark Crypt’s sound design – whenever they were gamers or critics, but I can see why. The sounds add a lot and the game becomes very creepy if you turn the music off.
Nic: I think they're important for two reasons. The first is the same reason they're important to any video game --- they add character, increase the player's immersion, and overall make the game more fun to play. But for puzzle games in particular there's a second dimension, which is that they can communicate information to the player about the state of the puzzle and the mechanics of the game. To pick a small example, one of the monsters in Bean and Nothingness floats above the ground, and so it doesn't hold down switches. The game has switches that you can step on to open and close doors, and every other monster in the game holds them down when they're on the same tile. Having one monster randomly not interact with a mechanic like this would be a ridiculous choice to make in the absence of the art, but given that the art looks the way it does it's much more natural that this one monster would be the exception to the rule.
The fact that so much information is communicated by the art is one reason why it was so important to us to build in support for colorblindness. Our game has eight different possible bean colors, and without some sort of accessibility setting (which in our case makes each color of bean also have a different shape) the state of the game would be very difficult to read for colorblind people.
CSH: I’m glad you brought up accessibility features, Nic. It’s something I hadn’t thought to ask about but it’s definitely important and I’ll make a point of featuring that topic in future interviews.
Alright, we need to start wrapping this interview up. One of the main goals for this interview was to provide a sort of “design bible” for future puzzle developers, and I’m sure we’ve achieved this. But of course the other goal is to draw some attention to your own amazing games. Now there are absolutely stacks of puzzle games out there: What features make yours unique?
Wade: Dark Dragonkin’s puzzles are integrated into an RPG format.
Subhi: In Hackshot, you are a hacker in a cyberworld where Trojan viruses are actual horses; do I need to say more? It’s full of good old internet scams, popup ads and big tech group hacking heists. Hackshot is about challenge, pushing ideas to the extreme, and the emphases on immersing the player in a world that feels real. Usually, I don’t repeat an idea more than two or three times, and I like to mix ideas to create new interesting ideas, and to make the world feel real. These are without a doubt the most celebrated aspects by my players.
Martin: I do a lot to make sure the experience is as pleasant for the player as possible. There is very little waiting time in my games. If you tell the game to do something it happens almost instantly, there are no long-winded animations. This applies to menus as well. You wanna go to settings? BAM! You are in settings.
Another thing I am doing is allowing infinite undos into my games. I let people take back as many moves as they want; this allows them to experiment without being punished for it and it also leads to much less of frustration from not being able to solve a puzzle. See, once you solve a part of the puzzle there’s nothing you gain from re-doing it. This is why just allowing the player to restart the level from scratch is not good enough. This is especially useful in longer levels. Imagine a level takes 200 moves to beat, you are at move 100 and you made a crucial mistake 20 moves ago. What is faster? Undoing 20 moves or restarting the entire level and moving 80 times?
I’ve also got the whole PC retro-aesthetic going on. Hack Grid looks and sounds like a DOS game, Dark Sheep achieves the same in the Commodore 64 style and while Dark Crypt is the most modern looking title, it’s still pixely and uses Sound Blaster 16-inspired instruments in its soundtrack.
Then there’s the stories of course. While Hack Grid was purely a gameplay affair, Dark Sheep and Dark Crypt have a B-horror atmosphere and their stories revolve around an ancient evil that wants to conquer our world. Those with a keen eye and a bit of imagination will notice that both games are set in the same universe. Also, fun fact, Dark Sheep is the only puzzle game where you get to burn a church! And yes, there are people in it.
Nic: This is an interesting question to think about! One small thing is that a lot of the games I just mentioned above --- Cosmic Express is the lone exception --- are what I'd call "Sokoban-likes". That is, one of their fundamental mechanics is pushing things around on a grid under some constraints. This is something we intentionally leaned away from, not because those aren't all good games (I think they are!), but because we felt like there might be a lot more puzzle space to explore elsewhere too.
More broadly, I'd pick out two things that feel pretty unique to me. One is just that our game has a lot of rules and interactions, and the player has to both figure out how they work and reason about their consequences in order to solve the puzzles. Having to deduce how mechanics work is nothing new, of course, but I think we lean into the complexity of the ruleset in a way that I haven't seen in too many other games (Baba Is You might come the closest). There are new things to learn almost all the way to the end of the game.
The second thing that comes to mind is the bean mechanic itself. We've found that it creates space for a lot of puzzles that feel pretty different from other puzzle games we've played.
Michael: In Bean and Nothingness, you navigate a temple filled with monsters that both help and hurt you, wielding a magic wand that can create monsters out of the beans scattered throughout each puzzle. This ability to create monsters means that the game plays like a combination of mechanics-exploration game (a la Snakebird) and “coding” game (a la The Incredible Machine). The other game I know of that combines these subgenres is Baba is You, though I feel like the “heart” of Baba is You is its programmatic element (the “rules text”), whereas the “heart” of Bean and Nothingness is exploring the interactions between monsters.
CSH: So what’s next? Tell us all about your current project and/or your next game!
Nic: Bean and Nothingness is our first and likely only game! We had a lot of fun making it and we're proud of what we put together, but we've mostly all been employed outside the games industry the whole time we've been working on it, and that's likely to remain true now. But we'll be sure to let you know if any of us do end up working on any other projects.
Subhi: My current project is the aforementioned game, Hackshot, which is easily my most complex yet. It is a big investment because I have developed specific tools that help in its development process. My next project will most likely be a sequel to Hackshot, which I jokingly call Cheapshot. I’ve had an idea in my head for about 6 years now, about making a true puzzle role playing game, where the player chooses a class, and the story is affected by dialogue and gameplay choices, but the gameplay is purely puzzle solving. I believe that this vision can become reality with Hackshot’s gameplay mechanics and set in Hackshot’s world.
Martin: I’ve just released my newest game, Sokobos! It’s Greek Tragedy meets Sokoban. It’s a minimalistic puzzle game and is visually inspired by the orange and black colored Greek Pots. Just like with Dark Sheep, I took the basic block-pushing formula and extended it. You won't find yourself pushing crates nor sheep, you will be assembling pillars, gardens and even a huge Greek temple. There's also cool features like having to paint certain structures first before pushing them to their destination or pressure plates that have to be activated to open a gate so you can move through it. The game released on April the 1st and has been very well received both by critics and players alike!
Wade: I have a new project in the works. It is tentatively called Draconis Volatus. The concept is a shmup with more tactics and some RPG Elements.
CSH: Alright, let’s go for a “too long: didn’t read” summary. You were all chosen for this interview because you’re masters of your craft. What’s one “golden rule” or “lesson learned the hard way” you could pass on to help budding puzzle developers?
Subhi: I would say, for game developers in general, and puzzle developers in particular, is to always have an early playable prototype, even without proper visuals. It will help immensely in getting feedback and rectifying any design flow there is as early as possible, and it will help the developer to discover the full potential of their design from discussions with testers.
Wade: Totally agree. Dark Dragonkin has a surprising number of interactions between the different components and the dungeon is designed intentionally to restrict movement. Those tight tolerances caused a lot of extra development that wasn’t initially expected, especially as the mechanics begin to layer of top of each other. One mechanic change may affect another that was okay on a previous level. Puzzle games are by their very nature complex and precise with interaction between different objects. Make sure you have it completely mapped out before you start developing. If I hadn’t done that, I would have had a mess because I wouldn’t have had a checklist to test against.
Martin: If you wanna release your game for money DO NOT price your game below $4.99.
A) People associate quality with price. If you go below 5 bucks, people will view your game as an asset flip or shovelware;
B) PC market is discount driven, 99.99% people buy during sales;
C) When pricing your game, ask how much you want to sell it for when it’s 50% off. Personally, I like to price in $5 dollar tiers, people seem to be very used to that too. Eg: $4.99, $9.99, $14.99.
Nic: My mother has done a lot of fiction writing, and she's told me that writers have the slogan "kill your darlings", meaning that sometimes you have to get rid of a piece of your story you really love if it's not serving the greater whole. I think this is good advice for basically any creative project, including making a puzzle game: if it's not working as part of the whole game, even if you really love it for other reasons, cut it. Bean and Nothingness is a huge game, but we've removed even more than that over the course of developing it, and I don't think I regret any of the cuts we made.
CSH: Solid advice. Now as anyone who’s ever read any of my interviews will know, I always finish on the same question: Game development is a process of learning as much as creation. What have you learned from the experience of creating your games?
Wade: I come from a software development background; so, I wouldn’t say I made major gains in that area writing Dark Dragonkin. My major struggle is trying to look at the game objectively as someone from the outside. Game design is as much an art as a science. It is really hard to tell when something bothers you about your own game is something you need to jump or is no one going to thing that is important but you? There were many hills I died on that I am not sure if anyone else will appreciate the effort that it took to make it “right”.
Martin: Funnily enough, I learned a lot about the human nature. As you finish the game, gather feedback or even promote your game, you will interact with all kind of people in all kind of ways.
I learned a lot about how people play puzzle games and how they approach problem solving. You’ll have people who will repeat the same thing 5 times in a row, even though it didn’t work the first time and then they’ll just say “this game is too hard” and then repeat the same thing for the 6th time, wondering why it didn’t work.
Michael: That’s one lesson I learned the hard way: puzzle difficulty is subjective. We rate every puzzle in the game on a 1-to-5 difficulty scale but I’ve seen skilled solvers get stuck on a 2 because they got fixated on a particular wrong solution path or just didn’t quite see the puzzle’s “aha!” moment. As game designer Tom Francis says, “difficulty is random", which can lead to a frustrating experience for some solvers – it can be discouraging to get stuck on a supposedly “easy” puzzle.
There’s no one solution to this problem but I think it’s valuable to keep it in mind when developing and playtesting a game.
Martin: Oh, and marketing is a huge part of game development, more important than actually making the game, believe it or not. I learned so much about how the topic itself but also how people react to it. The most important lesson in this field is that there is no such thing as ethical or non-ethical marketing. You know those “hot singles in your area” ads? You know those awful ads with huge red arrows? You might hate them personally or even look down on them, but they are still here. Why? Because they work. The moment you start constraining yourself by what is ethical, good, etc., you are missing out on opportunities. Marketing is complex, it is platform-specific, it is target group-specific, and it can change over time. You have to experiment and see what works for you and what doesn’t.
Subhi: Always have a small design document, even if you are a solo indie dev. It helps in many ways, but the most important one is that it is a guide to your game’s vision. For example, Hackshot’s design document has the line “the player should feel like a cool badass hacker, but this feeling should be earned” at the head of the document. This line epitomizes what the player should feel playing the game, and when I add any mechanic or story beat to the game, I always ask myself, does this addition realize the vision of this line?
Nic: I've learned a ton over the course of working on Bean and Nothingness. Part of that is surely just because it's taken more than a quarter of my life so far! On a fairly mundane level, I actually think I was pretty bad at designing puzzles when I started working on the game, if only because I'd never really had to think about what makes a puzzle challenging and enjoyable to solve. The first few puzzles I came up with were very linear and straightforward; there was hardly anything for the player to deduce at all. Spending so long on this project really forced me to up my game, and I'm pretty proud of the puzzles I'm responsible for in the final product.
I also learned a lot about working on a long-term project with a team. Of all the projects in my life that I've actually completed, this one is definitely the biggest, and I'm including my Ph.D. thesis in that! There's so much about organizing something of this scope that I just had no idea about before doing this, and I'm looking forward to taking advantage of those skills in the future.
Thanks so much, CSH Picone, for organizing this! You or anyone who's reading this should feel very free to reach out to us about the game or anything else. We're on Twitter (@RBORgames) and you can email us at email@example.com.
Thank you everyone for your time; and I know how valuable that is – for everyone, of course, but even more particularly for indie game developers, I think. I know I got a lot out of it and I’m sure others will too.
Bean and Nothingness’ Steam page
A timelapse video of Subhi designing a level in Hackshot:.