Skadi Tower Devlog #2
An evolving puzzle design process
It's not immediately obvious how to design a level for a puzzle game. Do you just combine all possible mechanics into a single level? How many mechanics should you introduce in a single level? How do you even figure out the possible interactions in the puzzle space? How much should you playtest a single level? When do you know to stop iterating on versions of the same level?
We’ve been actively working on our game, Skadi Tower, for the last two years and we’ve responded to these design questions with a constantly evolving puzzle design process. Since we created a new system of 3D line puzzles for our games, we didn't have the advantage of direct game references that explored the same puzzle space. In this devlog, I want to share how our process evolved with us as we grew more and more familiar with the design space.
A common approach to explorative puzzle design is to create a ‘playground’ level - a sandbox of sorts where you can explore interactions and mechanics. This is akin to playing with a box of lego pieces, all strewn out on the floor around you. However, our game doesn't lend itself to this approach because movement inherently cuts off your old path - and navigating this constraint in 3D space across multiple floors is the core puzzle we ask our players to solve. Since we had to design with this constraint in mind, it was tough to create a playful playground space to explore instead of just creating full levels.
During the ideation stages of development, we had already drafted a number of tile types and mechanic interactions on paper. The first year of development mostly involved implementing these ideas into code and working in-game. This past year, we made a push to create as many levels as possible - every week, both Chapin and I created at least 2-5 levels for each other and playtested them with each other.
This collaborative approach to puzzle design was great for these reasons:
We were able to bounce off of each other's level design ideas
We both still had space to independently think of ideas for new levels in our own styles
We could push the difficulty of the puzzles because our playtesters (us!) were experienced players
We fixed this weekly playtest as a constant in our process and over time we used different materials, physical and digital, to create our levels. This devlog explores how each material influenced our puzzle design uniquely.
ASCII
Our game uses an ascii-based system to save and load levels in text files. So, naturally we designed our early levels directly in text files. This worked well during early development, since we tended to create smaller levels exploring specific interactions.
While typing up a text file took a trivial amount of time, at this early stage of development we had trouble visualizing the level in 3D space as we designed it.
PENCIL AND PAPER
Ideas can strike at any time during the day - and fortunately we're both the kind of designers who always keep a notebook on hand to capture stray flashes of lightning. Initially, we drew each floor from an orthogonal perspective just like in the game. It helped to chalk out the levels from this perspective since we were not yet used to parsing the spatial relations between each floor.
Eventually, as our familiarity grew with the 3D grid-space we stopped drawing the perspective views and wrote the ascii text as it would be saved in the text file loaded in-game. When we got back to our computers, we would transcribe the levels in time for our next dev playtest. I felt most comfortable with this flow of level design because it afforded me a physical medium to play with the design before moving it to the digital space.1
WOODEN CUBES
During development, I was reading The Extended Mind2 which inspired me to explore bringing more physicality into our level design process. I was enamored by the idea of using physical wooden cubes to design our levels and it turns out you can easily buy a bag of one hundred 2” wooden cubes online…so we both did.
We designed a handful of levels using these cubes but quickly realised the physical world held us back with this design material. Obviously, wooden cubes can't float without support like the tiles in our game do. Also, the cubes were opaque which made it hard to see through the level as we physically built them.3
While we quickly dropped off using these cubes, it felt like a worthwhile experiment that generated a some unique level ideas and left us both with prototyping material that we've used in other prototypes.
UNITY LEVEL EDITOR
Meanwhile, Chapin had been slowly chipping away at creating a level editor in Unity engine that we could use to create, edit, save and load levels. The goal was to create a comprehensive dev tool that would allow us to keep the entire level design workflow within the editor itself. It took a while to implement because we had built up tech debt - we had to extricate a lot of the game level completion logic from the level loading scripts and functions…but, we did it!
Building this level editor was a great experience in internal-facing design tools development. I'll let Chapin chime in with his thoughts on using it in our puzzle design process:
I think the level editor is a great example of something we made that was useful in the early stages, but quickly fell off in use as development continued. Early on, it was so much easier to work in the level editor, to be able to see and test levels in 3D right away.
However, the nature of the codebase for the game meant that every new type of object in the game had to be manually added to the level editor’s spawning code, and the level editor itself could create bugs in the main system if its code was not properly maintained. Over time, the level editor became something of a burden to maintain, and we let it deprecate as we continued to add new content and polish.
Eventually, I returned to ASCII level editing as my primary means of creating new levels. By restarting a level whenever you change the ASCII file, you get a lot of the benefit of the level editor, without the maintenance drawbacks. I don’t think I could have created levels this way at the start – learning how levels worked and how to think about designing them in a 3D space was essential for my understanding of the game – but I do think the level editor distracted me from other features that I could have more productively worked on. The process of creating the level editor gave me a deeper understanding of the systems at play, but the tool itself became less useful over time.
- Chapin
IN-GAME
At this point, we returned to testing levels directly in game using our ascii files; but we were able to streamline the process even more by implementing a few custom scripts. First, we created a ‘For Review’ folder for our freshly designed levels which we would playtest every week. After playtesting, we would move approved levels into a ‘Playtested‘ folder or keep them in ‘For Review‘ for further level design revision.
Then, we wrote a script to automatically add all the levels in the ‘For Review’ folder into a debug testing stack at the top of the menu in-game. Levels in a stack must be completed in order so we also automatically unlocked these levels so we didn’t soft-lock ourselves from playing them.
Finally, as a quality of life update for us, we added a script to automatically remove the debug stack from builds. That let us avoid showing up to playtests and realizing we forgot to turn off the debug stack when playtesters load into one of our WIP levels.
CLOSING THOUGHTS
As we built up a stockpile of levels, we felt better about culling more than half of the initial levels we designed. Those early levels served as sketches in a sketchbook that helped us identify specific interactions we wanted to explore.
It was incredibly helpful for us to explore multiple mediums when learning the puzzle space during early development. Once we had a grasp on the systems though, we were best served by speeding up the process of ideation and playtesting for each level. Throw your puzzle-spaghetti on the wall as quickly as possible to see if it sticks!
Thanks for reading this Skadi Tower devlog! If you're interested in the game, you can watch our latest teaser trailer or join our studio mailing list for more frequent updates.
Working in a different medium is a great way to enable more creative ideas. The process of transcribing your idea affords you a new perspective on it. The alternate medium may also present you with different constraints which further encourages novel ideas.
Paul, Annie Murphy. The Extended Mind: The Power of Thinking Outside the Brain. Houghton Mifflin Harcourt, 2021.
This was a long-standing design challenge for us in the digital game as well. During playtests, players often expressed the wish to see through the current floors and preview all upcoming floors. However, when testing this we found players would get stuck with analysis paralysis as they tried to solve the entire level top-to-bottom in their minds-eye without moving a step in-game. Our current answer is a ‘Floor Peek’ button which allows players to see through the current floor and preview only the next floor below them. This gives them steadily increasing information about the upcoming floors without overwhelming them.