In this instalment of our puzzle design interviews, we talk to Guy Lima, one of the founders of Ragtime Games. Ragtime Games brought us Continuity, a sliding-tile platform puzzler, and will soon bring us the sequel, Continuity 2, as well.
In Continuity, the platform part of the game is finding a key and unlocking the door to escape from one level to the next. But the world is put onto tiles, and the tiles are scrambled. The puzzle part of the game is sliding the tiles so that the character can move around in the world. Unlike many sliding game puzzles, Continuity levels do not have static solutions – players must move tiles continuously to get the character towards the key or the exit.
Continuity won Best Student Game at the 2010 Independent Games Festival and the Gameplay Innovation Award at IndieCade 2010.
Guy Lima answers our questions below.
Dev.Mag: What are the qualities of a good puzzle?
I think a really great puzzle stumps you for a long time, but once you’ve figured it out, you just can’t understand how you didn’t get it before.
Dev.Mag: What process do you follow to design puzzles?
I’m not sure that we ever had a specific process of level design in Continuity. Personally, I’d say my time was split evenly between making levels where I’d have a very clear vision of what I wanted and those where I just kind of explored while creating.
Looking back, I think the more concrete a level was in my mind before I started making it, the better it turned out. Those levels just seemed to be more focused. They also feel much more distinct than the ones I created by just making it up as I went along.
For Continuity 2, we’re trying to spend more time considering what we want from each level before we design it. Playtesting really helps with this, as it indicates when our difficulty curve is way out of whack.
Dev.Mag: In a sequence of puzzles based on a small set of mechanics, how do you make sure the puzzles stay interesting? How do you maintain a feel of progression without introducing new elements later in the game?
One of the good aspects of having such a small set of mechanics is that we were able to finalize them early and move on to designing levels. So, even though development was less than two months, we were able to spend a large portion of time designing levels without being concerned that some mechanical change would come up and render a bunch of levels obsolete. Since the mechanics were stable, we were hopefully able to figure out some of the more interesting uses.
Another way in which we tried to keep the player motivated to continue was to arrange the levels so that they didn’t just get harder and more complicated as the player progressed. We found that, if you presented another level that looked harder directly after the player had completed a difficult level, he or she would just lose interest in continuing. If you gave the player a level that made them think, “Oh, this looks easy”, they’d be more likely to play. Once they got their confidence back up, you could confront them with a really hard level.
|A level introducing the basic platform aspect of the game.||A level for introducing freefall.|
Dev.Mag: How do you judge whether a puzzle is fun and how difficult it is to solve?
We’ve been working on Continuity for a while now so it’s not really easy for us to do either in the absence of playtesting. What we have to do is just trust that the mechanics that we’ve created are fun. Using that, we just try to make diverse levels that emphasize different aspects or consequences of the mechanics. In the end though, it all comes down to playtesting and whether people find something frustrating or fun.
Dev.Mag: In an interview you said that, in Continuity, you wanted the player to learn everything by playing the game. Do you use strategies in your level design to make the gameplay clear and to guide the player towards the solution?
One thing we decided very early on in Continuity was that we wanted to avoid help text, because many players just won’t read it (especially in Flash games, where the player can just click on to the next thing). Our thought was that if we put up walls of text before the player gets to play, people wouldn’t bother playing for long.
Our main strategy for teaching the game without text was based on trying to anticipate misunderstandings of the game’s rules. Then we’d put the player in a position where he or she could realize that what he or she assumed about the game was incorrect.
For example, in Continuity, you can only move the character from one tile to another when the two tiles match exactly along their shared edge. This rule isn’t necessarily something you would anticipate, so what we did was put some levels really early in the game that enticed the player to try and fail to cross such a non-matching edge. We tried to design levels in such a way that players would be confronted with this situation several times, hoping that they’d reflect on why they were able to cross certain borders but not others.
An example of letting the player fail to learn.
Do you have any advice for those who want to design their own puzzles?
I’ve found it very helpful to just shut up when someone is playtesting my game. It’s often excruciatingly painful to watch as someone just completely fails over and over again in the exact same way (you’d think after failing, people would try a different approach, but they often don’t). Once you open your mouth you’ve biased your study. Even asking, “Why’d you do that just now” leads the player to reflect on their actions in a way they normally wouldn’t. So just watch and note down every moment that you cringe as a problem for which you need to design a solution.