Wumpus Bastards Update #2

So web development, as it turns out, is a pain in the ass. Browsers rarely complain; it's probably part of the reason that the internet got so popular so quickly and it makes it hard to fuck up a simple text & images sort of website, but it also makes debugging a bit of a nightmare. Here's the sort of error message you usually get:

Just Google "WHY DOES NOTHING WORK WHAT IS HAPPENING IT'S JUST WHITE".

 Or, if you're lucky:

SHIP IT.

And debugging webshit is sort of a bubblegum & shoelace MacGyver kind of situation:

I finally spotted the missing parens while cropping this in mspaint.

It was more of a struggle than expected just to get a basic Hunt the Wumpus game going, but it's done. I've got quite a bit of new stuff in there, too; the biggest new mechanics are level exits, which open when you kill the wumpus & lead to ever more dangerous caverns, and a stamina gauge which decreases every time you move, adding a little more tension to exploration. I've added enough stuff that just about every room has something interesting going on, from cave taco oases to the classic instakill bottomless pits. Lots of UI stuff to go, balancing, that sort of thing. Probably like half done? Which means, like, 10%, you know.

On Save State Hacking

CockBlockaz auto-saves the player's progress whenever a new puzzle is solved. Saving the game state is a pretty simple affair; there are 25 puzzles, each of which is in one of three possible states (locked, unlocked, or solved). So all I have to do is write a 25-character long string (one character per puzzle) to a text file, using the characters 0, 1 & 2 to represent the 3 possible states. For instance, "1000000000000000000000000" means that the first puzzle is unlocked while the rest are locked (this is the initial state of the game).

So that's fine. But, obviously, anyone could open up that text file and edit the string to mark every puzzle as available or completed. My general stance on this matter is, who gives a fuck? There's no cash prize for completing the game (as far as I know?) & no online leaderboards or anything, so the only motivation to hack the save file is for the pure joy that certain flavors of crypto-nerds get from doing those kinds of things. I think that's great. In fact, it makes me want people to hack my save states.

But now I have an unexpected problem. If I'm approaching save state hacking as a sort of meta-game, just a fun, geeky thing to do, then my current save file is way too easy to figure out! I could obfuscate the shit out of it so that only the serious cryptokids could figure it out, but that's not really what I want. How do you encrypt a string, but just enough to make it a little bit of a challenge, something that anyone with the motivation to try could figure out? I'm not sure, but I'm gonna give it a shot.

First person to successfully hack the CockBlockaz save state wins!

CockBlockaz Level Select System Complete

I was pretty lazy about it, but the level select/unlock system is finally working & in place. I still have some UI work to do but the code's all there & I finished the save/load system as well since they kind of go hand-in-hand. Here's what it looks like; white squares are unlocked puzzles, blue ones are completed. Completing a puzzle unlocks the adjacent puzzles:

So, anyway, that's a wrap for all the major systems in the game.

I still have like 25 puzzles to make, all of the music to write, & a heavy buttload of tedious bullshit details to take care of. There's almost no way this is going to be done by my arbitrary & masochistic tentative release date of April 15th. I haven't decided if I'll just keep pushing through this one at the expense of all my future planned release dates, or just move on & come back to this one at the end of the summer. Probably the latter. The final stretch of game development is seriously such a drag.

CockBlockaz Puzzle Select / Unlock System Design

The tutorial sequence is complete, I think, & I made a handful of new game-proper puzzles along the way. So, moving on, I dug out the sort-of-design doc for the CockBlockaz puzzle select system:

Sort of nestled in between doodles & notes on binary search trees. The idea is that you have this grid with the tutorial sequence in the middle; each of the other gridspaces represent individual puzzles. Completing a puzzle unlocks any adjacent still-locked puzzles, with the more difficult puzzles being at the outside edge.

I like it, aesthetically, & it imposes a nice constraint on how many puzzles I need to make. In order for this system to work, with the tutorial sequence in the middle, there obviously needs to be a middle square. So if I want the grid itself to be a perfect square, that means that the length of its side needs to be an odd number. A 5x5 grid would only hold 25 puzzles, that seems a bit skimpy. 9x9, forget about it, I don't want to be making CockBlockaz puzzles for the rest of my life. 7x7 seems like a good size & it gives me an exact number of puzzles to shoot for; 48 plus the tutorial sequence. I'm probably like halfway there at the moment.

Aesthetics aside, I think it's important for a puzzle game like this to give players a chance to quit a puzzle that they're stuck on & try another one. The obvious option is to just make all of the puzzles available from the start, which I think is a good design decision for a puzzle game, but I also think that unlocking levels like this provides a nice sense of progression while leaving the player with lots of available puzzles at any given time.

I haven't decided exactly how I want to implement this system at code-level, but the overall project is small enough that I feel Ok about just cracking a beer, banging out some code, & seeing what happens. Here we go!

CockBlockaz Tutorial Sequence

In the CockbBlockaz demo, the tutorial levels include text at the top of the window which basically amounts to "HEY DUMBASS, THIS IS WHAT I'M TRYING TO TEACH YOU." Which is fine, but I like the idea of a tutorial that teaches the rules of the game without any text or arrows or whatever. Just assume that the player will try hitting the arrow keys & let the learning experience build from there. I found these notes which I'm basically sticking to:

I guess you can ignore the search tree stuff & the dino-rooster man & the poem about Steven Segal. I ended up combining points 1 & 2 in the sequence & am working on #5 at the moment. I'm coming up with new puzzles as I go & am pretty happy with how things are coming together.

RGB Design Document

Found this in a notebook sandwiched between 2 pages of notes on floating point representation. Sort of an interesting artifact:

(Click to enlarge in case you've never used the internet before.)

This represents the first time that I bothered to plan shit out before coding a game. That's sort of  lie, I had already taken a failed crack at this game & decided to sketch out the next version, mostly because I am a rebel & was not paying attention to a lecture on floating point representation. Anyway, it turns out that a little bit of planning doesn't turn a bad idea into a good one but it does allow you to make crappy games more quickly & less buggy.

Puzzle Generation in RGB & A Tale of Rapid Prototyping

Computer generated puzzles are usually no fun & RGB presents no exception to this rule.

The motivation for the basic gameplay mechanic of RGB came from another game I'm working on (more on that one later) that has a "crumbling floor" tile; you know, you can only walk over the tile once before it crumbles away & becomes impassable, forcing you to carefully choose your route. WHAT IF THAT WAS THE ENTIRE GAME, I thought to myself, IT WILL BE SO EASY TO PROGRAM DUDE JUST DO IT. So I did.

It was no fun.

A few iterations on that idea brought me to RGB but without the restriction on how many times you could visit each tile; spaces never became impassable. This was a mistake, I don't know what I was thinking. Anyway, I still didn't love it & didn't care enough about the game to lovingly handcraft puzzles so I just had each game start with a random board.

That didn't work.

Sometimes interesting boards would be generated but it turned out that many truly random boards are simply unsolvable. This is probably easy to prove mathematically but it was easier to just try it & see it fail. So, instead, I had the computer start with a board of a solid color & play the game backwards in order to generate the boards.

The puzzles were terrible.

Because by "play the game backwards" I mean "randomly move around & change the tile colors." I had the computer make a certain number of moves & reaching that number was the end condition for completing the board. What often happened is that I would end up with a green board with like 2 red tiles in the corner. So I had the computer look at the surrounding spaces before making each move & made it more likely to choose the least visited surrounding tiles. After completing the puzzle it counts how many spaces there are of each color & if there's too much of an imbalance it just starts over. This is a terrible, terrible algorithm but who cares, at least it worked. Sort of.

Every puzzle was way too easy.

So I finally introduced the tile counting mechanic so that you could only visit each tile 3 times. This required rewriting the puzzle generator to ensure that every puzzle was solvable but it finally made RGB feel like a puzzle game.

It's still not a great puzzle game.

The End.

Music Generation in Rogue Matrix

I should be able to wrap Rogue Matrix up tomorrow, just working some kinks out of the music engine. I want to get this in good working order because the music is the only thing I really like about Rogue Matrix. It's about the simplest procedural music generation system I could think of, & ignoring some technical constraints imposed by Game Maker which I'm still working through, it's been pretty simple to implement.

It works like this. I wrote five songs, each one minute long & loopable, all in the same key & at the same BPM. Each song has 4 parts: drum, bass, harmony, melody. Once the song is written, I save each part as its own track. So I have 5 drum tracks, 5 bass tracks, etc. Then, at the beginning of a level of Rogue Matrix, the system chooses at random one of the available drum parts, bass parts, etc. & plays them all at the same time on a loop. So the drum part of song C is played with the bass part of song A, the melody of song B & the harmony of song D. Or whatever. The five minutes of music that I wrote become over 10 hours worth of possible combinations:

5 songs, 4 parts each
So when generating a song there are 5 choices for each of the 4 parts
That's 5^4 = 625 possible unique songs
The parts, & therefore the songs, are all one minute long
625 minutes = 10.4167 hours
10.4167 hours > The amount of time anyone will ever spend playing this game

I think of this as a song template; because the key & tempo are always going to be the same, songs from the same template will be pretty similar to each other. This was just an experiment; Rogue Matrix uses a single song template, but adding more is just a matter of writing the base jams. Writing those songs, by the way, is a lot fun & relatively easy; you can't be bothered with obsessing over anything because it's just going to be disassembled & frankensteined together with the other songs. I'm really looking forward to scaling this system up for some future project.

Dungeon Generation in Rogue Matrix

I went through quite a few design iterations before landing on a dungeon-generating algorithm that I liked. First, what do we mean by dungeon? I'm talking about a top-down, 2-D representation of interconnected rooms & hallways with a traversable path between any 2 points. That last requirement is the trickier part. It's even more tricky to get something that's unpredictable, yet believable; like, not just a bullshit jumble that a computer obviously puked up. Like, maybe some dude really designed this dungeon.

Here's what I ended up with; it's pretty simple but I like the results:

1. Divide the play area into a 3x3 grid. This is just what happened to work with the screen resolution I was working with.

2. At each gridspace, decide with some probability to build a room there. You can get a lot of mileage out of tweeking that probability, depending on how room-dense you want your dungeon to be. This leaves the possibility of a roomless dungeon, which I didn't want, so if we end up with no rooms I just go ahead & build 2; a start room & an end room.

3. Build each room with randomly chosen widths, lengths, & starting point offsets. You've got to tweek the minimum & maximum values for all of those parameters depending on what you're going for. I used maximum values large enough to allow rooms to cross over gridlines & even over each other, which makes for much more interesting dungeons, I think.

4. Inside of each room, choose a random "anchor point" for creating hallways. I started out just using the room's midpoint but it made the dungeons sort of predictable &, I don't know, computery.

5. Build hallways. This is what really makes the dungeon. We have a list of rooms. Randomly choose one (room A) & remove it from the list. Then, randomly choose another (room B) & remove it from the list. Build a hallway between room A's anchor & room B's anchor. Choose another room (room C), remove it from the list, build a hallway between B & C, & so on until the list is empty. This guarantees that we can now choose any 2 random rooms & travel between them, very important. Note that we're allowing hallways to pass through rooms that happen to be in their way; this, again, makes the dungeon more interesting & unpredictable, compared to a procedure that just builds hallways between adjacent rooms, which is common in these kinds of games.

With the dungeon built, we can toss the player at a random spot in a random room, do the same for the exit object, & be confident that it's possible for the player to reach the exit. I didn't put any constraint on where the exit could be in relation to the player, so the exit could be like 2 steps away in the next room. This decision was informed more heavily by my not giving a good god damn than by any sort of design principal.

So next time you're in a jam & you need to write a procedural dungeon generating algorithm I guess you'll be all set.