Spider Dungeon Spider postmortem

After making my 7-hour Roguelike in 2018 and finally participating in the 7-Day Roguelike competition in 2019, I decided that I’d try doing a few random game jams in 2020.  Not a New Year’s resolution, precisely, just something I’d always wanted to do but never made the time for.

I kept forgetting to unsubscribe from an itch.io e-mail newsletter that lists jams, and one showed up that featured MiniJam #45 with the theme of “DUNGEON.”  I got excited, because I like dungeons. Dungeons are way better than dragons, I’ve always said. I didn’t have a particular game idea in mind, I figured I’d just do another turn-based QuickBASIC thing to get back in the habit of quickly starting and finishing something.

The way MiniJam works is that the theme is announced weeks ahead of time, but when the jam starts an additional constraint is revealed.  Something like “mouse input only” or “has to use the CGA palette.” This time it was “pocket-sized,” and described as being more open to interpretation than usual.  The limitation was announced at 9pm, so I slept on it, and woke up with the idea for SDS more or less fully formed.

The premise is that you’re a spider, crawling around on a Game Boy, using its controls to play a simple dungeon crawl game.  There’s a hunger meter that you have to refill by eating flies that land on the Game Boy, but that requires you to move away from the controls, which puts your avatar in danger. The dungeon crawl game is just a small scale grid-based, turn-based treasure hunt in a series of nominally procgen rooms.

Balance requirements emerged -- monsters had to respawn (and HP had to tick down, Gauntlet-style,) in the interior game or you could just leave the avatar in a safe spot while you went and filled up on flies.  I added between-level confirmation screens so you’d have to go to the more distant A button more regularly, but realized that I needed to stop new flies from landing while the interior game was effectively paused.  This isn’t communicated.

I’ve found it hard, historically, to design systems that are intrinsically interesting like the ones in games I like to play.  I’m too in love with the feeling of a sword that gives you +3 to your Strength stat to ever do anything particularly innovative.  So instead, I’ve either made games that a) rely primarily on tons of entertaining content, or b) have systems so big and messy that interesting interactions emerge accidentally.

Type a) didn’t feel like a good fit for this, so I figured I’d try to force out a b) in a short timeframe.  Instead of having one big system that piles up against itself, though, this one has two systems that I hoped would multiply against one another.

I’d been playing a bunch of Hearthstone’s Battlegrounds mode, which is their answer to DOTA Autochess.  Battlegrounds is essentially two games, a card drafting one and one that plays itself. Neither of them is all that complex, but their intersection is compelling.

I guess the same thing is true of poker.  There’s the card game, which is math+randomness, and the betting game, which is math+psychology.  The intersection of two simple things creates a hugely complex and appealing and enduring gestalt.

Anyway, SPIDER DUNGEON SPIDER didn’t do any of that.  I just wanted to try making a game that was larger by virtue of multiplying two small games instead of perpetually adding to one.

Watching the submissions get judged was illuminating.  There were a handful of people who, like me, played and rated basically every game in the jam.  Those people commented on SDS, mostly surprised that it was written in BASIC. The submissions that were web-playable got 5x as many ratings and plays as the download-only ones.  Downloading an executable becomes a bigger ask with every passing browser version. I suppose I should be grateful to the QB64 folks that it’s still even possible to write a game in a 35-year-old language and get it running on 2020 hardware.  For the purposes of these jams, though, it’s probably time to stop being afraid of Javascript.