A Game in Thirty Days: Part Two

I made a game in thirty days! And now I’m writing about it. In part one of this mini-series I talked about the process of getting started: setting my goal, picking my tools, etc. Now, in part two, I’d like to talk about a few things I learned along the way.

As a quick refresher, this is the end product:

It’s a short Zelda-like action game built with GameMaker Studio 2. The game consists of a village, a dungeon, a quest, and “remembered” progression — that is, if you unlock a door or complete a puzzle, the dungeon will remember.

Lesson: Don’t just dive in

More than once, I decided what to do next and started working on it right away. The time this bit me hardest was when I originally implemented elevation changes and pits you could fall into.

Originally the game had just two elevations. Collisions worked with tile layers, one for each elevation, and had multiple tile maps for each elevation. This worked fine, but ended up being a lot more work than it needed to be: code to set depth/z-ordering based on an entity’s current elevation; code and triggers to change elevation; code to reset elevation when certain conditions were met; extra work mapping “portions” of the map; so on.

Then came time to implement pitfalls. In Zelda you can walk over a pit or hole, or knock an enemy into one, and you fall. I tried to do this using objects, collision, and triggers, and eventually got something that worked most of the time, except for if you walked funky or collided without realizing it. This ended up being frustrating if you didn’t take the happy path. I spent a lot of time tuning and tweaking these triggers. It felt like I was banging my head against GameMaker for a while.

I spent an entire day on these pits before scrapping the feature altogether.

Five days later the solution came to me, along with a way to unify both features and simplify the collision system. I spent another day doing this, as well as adding ledge jumping, while also removing large swaths of code and combining everything into a sort of “collision state machine.”

Doing this made it easier to implement all of these features, and more, with less code. The end result was more robust, required less work to build out when creating new maps, and made it easier to extend to add new features. A similar approach was used by the Pokemon games, which is where I got the idea.

Plus, it looks kind of neat.

The main lesson here? A little bit of planning can save days of work. If I had sat back and thought about this a little while before jumping in, I’d have had at least an extra day to work on other things.

Lesson: Get friendly with graph paper

Pen and paper will always be cheaper and easier to use than writing code or building tilemaps or whatever else. This is, luckily, something I did not have to learn the hard way.

Before placing a single tile in GameMaker, I drew every room of the dungeon on a graph pad. I placed doors, monsters, traps, chests, in little squares on paper, and ran through the dungeon in my imagination. Once I found a tileset to use, it was just a matter of putting the pieces together in GameMaker and running through to make sure it was all right.

Iterating on paper instead of in-game reduced the overall time spent on the project by a considerable amount.

That said, there were still a few changes made in-game once I was able to playtest the dungeon. A puzzle got scrapped, a room was rearranged, and a new room was added.

Still, pen and paper proved invaluable, and for the next steps in the project I’ve been doing almost all the up-front work on my trusty graph pad. If anything can be mapped visually or sketched up, then it’s probably worth doing that before you even think of writing code or building maps or anything of that nature.

Lesson: Waste your time wisely

I’m not an artist. In the beginning of this project I spent a little too much time trying to draw my own sprites and animations. The fourth time I scrapped everything and closed GraphicsGale in frustration, I decided it was time to find some art to use.

There’s almost too much good, free, and open art to use on the internet. You could spend hours looking through everything, which I did. The point is, as usual, just to pick something and stick with it. It’s not worth spending too much time on the visual appearance of your game at the early stages. As long as it’s tolerable, or at least the intent is clear in your presentation, it doesn’t matter how it looks until much, much later.

In the end I paid for some assets and drew some others. It’s probably clear which ones were “mine”: the slimes and the bosses don’t necessarily jive with the rest of the game’s aesthetic. But that’s fine.

Lesson: Play it!

You can’t know if your game is fun unless you play it. Not just the one room you’re working on, or the new feature you’re building and testing in your debug room.

Before releasing the demo, I went through the game beginning to end more than a dozen times. In the process I tweaked hitboxes, changed some behaviors, found some bugs (and left some bugs! for the attentive player to exploit if they want), and adjusted the difficulty.

^{Me, almost getting wrecked by a simple encounter.}

This might have also worked against me. I was worried the game would be too easy, but the first feedback I got was exactly the opposite. One of my first players spent nearly an hour, collecting 12 heart containers and throwing 23 bombs, and still struggled with the final boss.

(This was partially due to the fight difficulty and partially due to the control scheme being a struggle, but the point stands! I added a new control scheme and it became easier for him. )

Details aside, the bottom line is this: if you’re not having fun playing in, then others won’t, either.

Wrapping Up

If nothing else, the thing to take away from all this is, “plan ahead, and plan the right way for what you’re doing.”

Or don’t. Five hours of work can save you twenty whole minutes of planning. 😉

The Game

If you want to view, download, or leave feedback for the game, click here: