Recently, I was struck by that familiar urge: to make a video game. After a few hours of reading and thinking I decided I was going to jump in and do it, but this time it would be different. I would just pick a platform, start working, and make a game in thirty days.
This is the result.
As you can see it’s got a few rough edges, and it’s obviously incomplete (no title screen, no saving, etc.), but for now it’s “done” and it’s time to reflect, take away some key lessons, and move on to the next project. For the curious, I’ll put a link to the download page on Itch.io at the bottom of this post.
I want to talk about this project: how it was formed, what I learned, and what’s next. This post is part one in a series.
The Plan
Obviously, the Zelda games were a huge inspiration for this project. A Link to the Past is my favorite game in the series and in my opinion one of the greatest games of all time. I always thought that, given the rise of nostalgia titles and revivals of older genres, no one had really given ALTTP the same treatment.
(This isn’t entirely true. There have been some. But none that have really captured the essence of the games, like the two I linked above. But that’s probably a topic for another blog post.)
So I thought I should be the change I wanted to see. It was time to dig in.
Picking My Tools
In every past attempt to make a game, I always focused too hard on vague future possibilities. Not picking Tool X because I might want to do XYZ thing in the future. Or picking Tool Y because I wanted better control over ABC thing. This focus on tools, platforms, or languages limited me and doomed my projects from the beginning: by focusing too much on some nebulous definition of quality or maintainability or extensibility, the projects became about the code and not the game.
This is not to say that these things are unimportant! Just that when you’re making a game, the game comes first. If you’re not producing something that can be played, you’re not making a game. And that’s fine if the goal is to learn about specific aspects of game development, because there are a lot. But this time, my goal was to make a game.
So my mantra became make it work; make it right; make it fast.
I closed my eyes, picked an engine, and downloaded the 30 day trial of GameMaker Studio. No further thought or planning went into this, for better or worse. The important thing was to just stick with something and make a game with it.
The first week of my thirty day trial I spent learning about GameMaker Studio and GML, its scripting language. The official resources and Shaun Spalding are excellent, and I could not have done this so quickly without help from his ARPG tutorials.
Picking My Battles
After all that, the next most important thing to focus on was scope. I didn’t want this to balloon out of control and become another thing I wouldn’t finish because I decided I wanted to do more than was possible. So I decided, one dungeon. That was it. If time allowed, maybe a little more, like a village.
If I was going to stick with the Zelda format, one dungeon meant kind of a lot. Secret rooms, special items, chests, a variety of monsters, traps, a boss battle, item drops. The idea was to write out a list of these high-level ideas. Each day I would pick an item from the list and implement it.
This was a huge help even if I wasn’t completely successful at it. There are a few features I implemented that aren’t even really visible in the end product. On top of that, there are a few features I started to implement then scrapped when I realized they were too much work, or not very fun. I probably spent a week total on these things.
A few other features I started to implement, took a break, then came back and restarted with fresh eyes. Sometimes this meant throwing away everything I’d done before, and others it was just a wall I’d hit and I needed a break. Sometimes a feature I thought would take me an hour took me a day.
I wouldn’t consider any of this lost or wasted time. That’s part of making a game: if it isn’t fun, scrap it. So it was important to frequently playtest and make sure even this narrow slice of gameplay was fun and satisfying.
The Process
During the development process I kept a devlog, just kind of raw notes at the end of each day going over everything I did and what I wanted to do the next day. This was helpful for me because I could come back without that “what now?” feeling: I already knew what was next, and Past Me told Present Me exactly what it was.
I also started sharing screenshots and gifs with some friends and family over Discord and Twitter. Feedback, even if it was just “that’s cool, keep it up,” really helped keep my motivation up.
The devlog details my setbacks and triumphs. Originally I kind of wanted to post daily or weekly updates with the devlog but decided it would take too much time to clean up and post and would detract from the energy I needed to make the game. Later, I’ll clean it up and post it. I always enjoy reading other developers talk about their process and it’s always heartening to read about others facing and overcoming their own setbacks. I want to share my own experiences with that.
Next
This post is already longer than I thought it would be, so I’ll cut things short for next time, where I’ll go over some specific lessons I learned, a few techniques I used, and more.
The Game
View the game, download it, etc., below.