GMTK2020 Postmortem


Brainstorming

One hour after this year’s theme (“Out Of Control”) was revealed, I started brainstorming ideas together with a friend. We deliberately took our time here to avoid too obvious associations and stand-out a little bit in the large pool of games that would be submitted.

It quickly became apparent that many of our ideas ran into issues game-designers usually try to avoid: Take too much control away and players will get bored and your game effectively becomes a movie. Or you might end up taking something very important away and the game gets frustrating or even outright impossible to play. And if your game includes a lot of randomness it will certainly feel out of control but the truth is: your game would likely still be better without it. All of that made this years theme viciously tricky to get right. Which is not to say it was a bad theme - I quite liked it!

Looking back at it though, I wished we had spent more time thinking out of the box. That is: more about conveying that feeling of being out of control or embracing a setting that’s out of control and less about a (more or less) literal interpretation of the theme as in “what does the player / the developer / the game usually control?”.

Picking the Pearls

At the end of our brainstorming session, I eventually settled for three ideas I considered worthy of deeper exploration:

  1. A shmup game where one can either dodge enemy ships (i.e. the player is in control) or let go of that control, to automatically start firing once the ship stops moving. This would’ve probably been the easiest idea to implement, but because I’m not huge fan of the genre I decided to drop the idea.
  2. A building sim loosely inspired by Tetris, where you’re dealt buildings of different shape and size and have to fit them together into an isometric grid. What is built and when is out of the player’s control, turning one of the genres core assumptions upside down. I quite liked the idea but gave up on it, as I couldn’t come up with a satisfying solution for how the player would create more space or free up old tiles.
  3. A dungeon crawler where you cannot control the hero directly, but indirectly by constructing the dungeon around him. I was inspired by the “Labyrinth”-boardgame where players can slide in new rooms at the sides of the playing field, which then will move all other rooms in that line as well, requiring players to plan ahead and adapt to an everchanging labyrinth.

I decided to call it a day, consulted my pillow over all three – and finally chose to stick with the dungeon crawler idea.

Refining The Concept

After I took a first shot at puzzle game design with my last year’s GMTK entry Wonkey, I wanted to stay away from puzzles as much as possible this year. While I love playing puzzle games, I honestly hated designing them - especially under the strict time limit of a gamejam. Being an avid lover of Arcade-games and Roguelikes as well, I quickly decided to make this year’s entry instead about cracking your own highscore in one endless level and without any goal other than “keep going as long as you can”.

Without much consideration I decided for a topdown-perspective and started sketching down a few simple room layouts. Considering possible exits on each side of a square room, I counted 16 different possible room layouts: 1 without any exits, 4 “dead ends” with just one exit, 6 “corridor” rooms with two exits, 4 “T”-shaped rooms with three exits and a "crossroad"-room with exits in all directions.
Checking the “Labyrinth”-boardgame out, I realized they only have 10 though: there aren’t any rooms with four or no exits and - most importantly - there are no dead ends! Instead dead ends are created when the adjacent room contains a wall where the exit of the current room would lead. It was this realization that eventually sparked the idea of controlling the heroes movement by blocking paths off instead of simply ensuring the dungeon goes on.

Looking for a narrative explanation, I came up with the idea of the player taking over a young dungeon master that has to guide an impatient and somewhat stupid "hero" through his first adventure by creating an absolutely fool-proof dungeon around him. So I introduced a timer to represent the heroes patience. Once the timer hit zero, the hero would automatically move into a random direction. If he walked somewhere the player hadn't placed a room yet, the hero died and the game was lost. This was the first prototype:


Next I dreamt up some modifiers to spice things up: effects that would be placed randomly on some of the cards to incentivize players to consider more factors than just the room layout itself. I imagined things like monsters the hero would need to fight if he stepped into the room, shrines to refill his HP after a battle or equipment the hero could collect to improve his odds of longterm surviving in the dungeon. But first I needed to turn my GUI-mockup into a fully functional prototype. Little did I know...

Running Into Trouble

Because there was neither a size-limit to the dungeon nor a way out of it, displaying the whole map was never even a possibility! But at this point my mockup only kept track of the rooms directly surrounding the hero. So if he eventually made a U-turn and went backwards the illusion of one big dungeon would fall apart. Thus I needed a system to “remember” the entire dungeon, not just the parts visible to the player. And this is where things went south! My implementation for a scrolling dungeon cutout turned out to be an absolute nightmare. In hindsight, I should’ve started from scratch once I started seeing the flaws. But the jam was already at the halfway point and I was afraid a full rewrite would take too long. So I opted to fix the bugs instead. Which ended up taking roughly 6 hours, a lot of nerves and about 400 lines of messy code...

Once things finally started working out, I ran into another problem: When the hero turned around and walked back, it was very easy to navigate him into a wall now because one could not look ahead two tiles. The fix I came up was stunningly simple (increasing the cutout-size to 5x5 rooms), but lead to a whole bunch of new, nasty bugs.
At that point it became apparent that I wouldn’t be able to finish everything in time: there were still no modifiers on the cards, no tutorial how to play and the game had neither art- nor sound-design. So with a heavy heart I chose to focus on the former two and fully gave up on the presentation, concluding that an ugly but decent game was better than an pretty but boring one.

Finishing Touches

I figured the fastest way to add a score to the game was to simply count how many rooms the hero had visited before dying. However, that revealed a problem: if players managed to built a closed circle (no matter the size, intended or not) the hero would never stop moving and the score would skyrocket. To prevent this from happening, I added another trait to the heroes personality: now he would be “bored to death” once he crossed his own footsteps:


Originally I had considered simply closing the doors of a room once the player left, but I liked the little extra bit of lore the footsteps added to the game. So I decided to double down on that and make the heroes personality an important part of the tutorial as well. Coming up with a short story intro (that I forgot to comment back in for the final build... -.-) and an interactive, step-by-step tutorial took another 2-3 hours, but actually went surprisingly smooth considering how much of an afterthought it actually was.

However, now I was merely 1,5 hours away from the deadline and implementing multiple modifiers was out of question. Nevertheless I wasn’t ready yet to give up on the concept, so I went with the simplest modifier I could think of: gold! Now 10% of all cards would have a sack of gold on them and once the hero stepped into the room, that gold was collected and added to the heroes personal wealth. That left players with two things to look out for: (a) crafting a safe passage for the hero while (b) making sure the gold pieces weren’t wasted in locations the hero didn’t visit. I quickly added a gold counter below the step counter, fired up GIMP and drew some quick symbols for footsteps, gold and the patience timer. Then rushed to export the game without any further thought on polishing or balancing out anything, setup an itch.io-page for the game and ended up submitting just nine minutes before the deadline!

Rating & Lessons Learned

"Dungeons For Dummies" ended up getting a whopping 44 ratings! That is significantly more than both the average of 26.4 and median of 18 ratings games have gotten this year. In comparison to last years numbers (average: 17.9 / median: 10) one could assume that I also got more ratings than with my game last year. However, that’s not the case: Wonkey actually had ten more ratings!

CriteriaRankScore*Raw Score
Originality#5993.7503.750
Fun#15183.0003.000
Overall#16593.0683.068
Presentation#32712.5002.500

Unlike last year I spent a lot less effort at promoting the game though: For the first 24 hours my game didn’t even had a thumbnail, I reviewed substantially less games (14 this year VS 74 last year) and the only public appearance "Dungeons For Dummies" made was in a (hardly relevant) reddit post. Now considering the very basic art style, a lack of music and sounds and a much simpler gameloop than I originally envisioned, I’m still insanely happy with my 44 ratings! Thanks again to every single one of you who gave the game a go despite of it’s poor looks – you’re amazing!

The overall feedback was very positive: Most reviewers saw great potential in the idea, many praised the tutorial and some even voiced interest in a full version of the game. Most criticism (rightfully) revolved around the poor presentation and the game being too easy. Originally I had intended to decrease the heroes patience over time to ramp up the difficulty. However, with barely any playtesting, I wasn’t confident enough to pick a rate and lower limit and kept the time at a constant 20 seconds instead.
Currently the game’s difficulty mainly depends on the luck of the draw anyways: players who get a very bad starting hand can quickly lose even when planning ahead while others might mindlessly pilot their hero along a near-infinite corridor without really understanding any of the game’s mechanics. This high variance in the first player experience might actually have harmed this games reception quite a bit. Also I'm not really sure the tutorial did enough to teach players that they can (a) block exits by placing non-fitting rooms and (b) return to previously placed, but unvisited rooms.

I'll continue working on the game, so if you have made it till here and like the idea, consider following me here or on Twitter to get updated once a new version is ready. And if you have any feedback or ideas for the game, feel free to leave a comment anytime.

Files

Windows Version 35 MB
Jul 12, 2020
Linux Version 41 MB
Jul 12, 2020
MacOS Version 15 MB
Jul 12, 2020

Get Dungeons For Dummies

Leave a comment

Log in with itch.io to leave a comment.