Running Long
Skadi Tower's Development and Quick Dev Time
For the past two years, I’ve been working on my first Indie Game release: Skadi Tower (out now on mobile!). Any experienced developer will tell you that your first project should be small scale and quick to develop. Releasing is the most important part of becoming a game designer. I would give that advice as well, but despite that, I did not take that advice myself.
When Siddarth and I started working on Skadi Tower (out now, gotta repeat yourself for strong marketing), we planned to spend less than a year on the game. Siddarth brought a prototype over to my house that began as a tech demo for a programming class. Initially, he just wanted to see if he could make a grid based puzzle game that loaded levels using a simple text file. Each letter on the file would correspond to a type of tile on the grid. From there, Siddarth continued to poke away at the project over the years, trying out some different graphics, different puzzle types, etc.
By the time he brought that prototype to my house, Siddarth had landed on the core hook of the game: these puzzles would not be simple 2D Hamiltonian path puzzles like you might find in an RPG dungeon. Instead, we would stack a series of these puzzles on top of one another, creating a little tower (hey there you go, the name of the game). That one idea unlocked the game for me.
When you stack these Hamiltonian Path Puzzles, you create a unique way of interacting with them. You can’t solve them in the same ways anymore, and you need to start analyzing the shapes much differently in order to understand where you need to land, and how you need to visually cut up each puzzle in order to succeed.
We realized we had a ready made game here. Because Siddarth had done the exploratory work of refining the gameplay over the years, we now had something we could take right into content development and release. With this, we were going to do what everyone tells you to do: release a game quickly.
This, of course, did not happen.
Before we get too far into the discussion of why this didn’t happen, I want to establish something: I am not upset at the longer development time of Skadi Tower. I spent my twenties consumed by the feeling that I was not moving fast enough, that if I couldn’t get an indie game out the door, or get a job quickly, or something, anything, I was going to fall behind. Falling behind would be the end of that ambition. I would somehow become poisoned by that failure: permanently too slow, too lazy, too unambitious, without skill.
When I got into grad school for game design, this felt like the escape from that fate. Finally I could make the games, build the skills, and get the job. And I did. I built multiple games over my time at the Game Center. I developed my skills immensely. And I did get a job as a game designer and programmer. It felt great. But I still had not released a full game that was mine. The student work, as valuable as it was, was always going to be somewhat unfinished, underpolished, not released to the wider public in an official way. The job, as much as it taught me a lot and made me some good friends, was focused more on client work and early stage development. I needed to launch something fully polished, fully realized.
A common point of advice for new game developers is to make something small, and make it fast. One of our mentors even suggested releasing Skadi Tower with almost no further development from the initial prototype that Siddarth showed me. Just make a few more levels and get it out there. See what happens.
It’s not bad advice. It’s advice I would give anyone who was in a similar position to us. The process of releasing Skadi Tower has been immensely instructive. The (frankly asinine) processes of launching a game on a modern storefront are weird, and a little inscrutable until you’ve done it. The experience of having to respond to new bugs cropping up in real time, wrestling with what to prioritize, realizing one fix has caused another issue, these are experiences you cannot gain until you launch something that you are responsible for. Why not get to that phase earlier? Why guard your games so closely?
Moreover, you don’t know how your audience is going to respond. Quality matters of course, and a polished product is always more likely to make a splash, but you are rolling the dice no matter what you do. What audiences find and love is not up to you, and no amount of marketing (that an indie can afford) will get you the kind of mass audience that you might dream of.
So yeah, release that damn game, as soon as you can. Find the thorns, the hurdles, see how the audience reacts. You can always build off that same base: make a sequel, a major update, a spinoff. If your crappy looking little game makes it bigger than you expect, that’s not the end for it. You can turn it into something more. Don’t be so precious with your ideas that you can’t share them even if they don’t feel fully baked.
And yet…
I could not have made Skadi Tower in a year. When we started the process of polishing Skadi Tower for release, we frankly had no goddamn idea what we were doing. Our initial plan was to make aton of levels, maybe (deeply maybe) polish up a couple animations and graphics, put together the necessaries to actually launch the thing (options menus, analytics, monetization, etc.) and push the game out the door. It was a good plan, and one that required intense focus of work to pull off. So naturally, I decided to start with a level editor.
Up to that point, Siddarth had been designing puzzles with pen and paper. I tried to follow suit, but found it to be pretty clunky. I didn’t have the eye for glancing at a puzzle and recognizing how to complete it (or if you even could). I spent way too much time drawing and redrawing floors, getting confused, thinking I’d made something solvable and then punching it into the game only to find that it was impossible. We needed a level editor. Something in engine that we could create levels out of and test live. Bonus: we could use that level editor as a feature in the game! Players could make their own levels to share with friends.
Experienced developers are screaming at their computer monitors right now. A level editor is, of course, a massive balloon to the scope of the game. If you note our goals above, nowhere did it say we needed to add this major dev tool and then try to polish it into an actual new feature. Moreover, the game loaded levels from text files (remember that from so many pages above?) so the level editor had to work in a weird way: converting a grid of Unity objects into letters in a txt file, so that could be passed to the level spawner to convert back to Unity objects.
It probably took me a month or two to get the thing working, but finally we did have a level editor. We had dropped the idea of making it publicly available (thank god for past us on that one) and instead I just created it in the Unity editor. When you made a level and hit the play button, it would drop the character right into the level you were designing. It was pretty sleek, if I do say so myself. You could make rapid adjustments to the level, see the thing visually as you put it together, and once completed, easily save that level right into the game.
I think I made about ten levels with the thing.
The level editor had two main issues: 1) It required additional programming any time we added anything to the game like a new tile type or messed with other parts of the UI too much, and 2) we found better ways to interact with levels visually.
Right about the time I was wrapping the level editor, we got a bunch of wooden blocks. With the application of a simple pen, we could note out all the different tile types on these blocks, and stack them together to design levels. This meant we no longer had to work digitally to visualize the level in 3d. It was honestly a huge breakthrough. As good as the level editor was when it was fully updated to whatever version we were working on, you still had to navigate the Unity editor to make it work. This took time. On the desktop, I could just move some blocks around and get the shape I wanted. From there, it was as easy as creating a text file and typing the letters into it to replicate what I had made out of blocks. More than that, eventually we stopped needing the blocks altogether. We returned to drawing out level shapes in notebooks, and then began quickly typing them up right into text files. Because of the way the game loaded these levels, you could simply open the level in Notepad, make edits, and restart the level in Unity to see those edits damn near realtime. After making probably close to a hundred levels for the game, and discarding tons more, Siddarth and I were able to see so quickly and clearly whether a shape would work or a level concept made sense, that simply typing the levels into a text file gave us a clear indication of what the level would look like.
So that’s it then, the level editor was a waste of time. I could have spent those months working on levels more slowly in notebooks as I got up to speed, or fixing bugs, or any other task and it would have been a better use of my time, right? Well, I mean yeah. And also no.
This is what the ethos of launching quickly misses about new indie developers: Game development is not a formula. There’s no one right way to do anything, and like any art, its adherents need to develop their own skills, their own understanding in order to make work that works.
When I started designing that level editor, I COULD NOT have made levels in the way I did by the end of the project. I did not possess the skill-set to make a level that quickly (which by the way, still takes a load of time. Making puzzles is hard). Could I have spent that time not working on a level editor we ultimately would not make much use of? Absolutely. But I still needed time with the system in order to come to my new method of level design. And I needed that process in order to understand why the level editor was not a great use of my time. When we started Skadi Tower, making a level editor felt like the most logical decision in the world. Now, I can look back on it and understand why we did not need to do it, but at the time there was no other decision I would have made.
Making a game is the process of learning how to make the game. By the time you’re done with the game, you’ll be better at making that game than you have ever been and you’ll likely be able to look back at early decisions you made and shake your head. “What was I thinking? Obviously that was a mistake.” But you cannot know that without spending that most valuable of currencies: time.
When we started Skadi Tower development, I could not have released the game quickly. I can confidently say that no formula or method would have allowed me to avoid the lessons I needed to learn, the time I needed to spend to fully understand the craft as I was engaging with it. Nothing could have been more valuable to me than those hours toiling away at tasks that ultimately did not go anywhere. That level editor is my teacher as much as any successful part of Skadi’s development has been. It’s a bellwether for similar features going forward, a tool to evaluate if some kind of dev tool is needed, or if it’s a feature in search of a problem.
Download Buttons Below