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.

RGB Debriefing

RGB is the reason we prototype games. What seemed, in my head, to be a clever, elegant puzzle game turned out to be sort of a shallow, boring one.

HOT POTATOES:

One of my personal criteria for a good puzzle game is simple mechanics. Really good puzzle games take a small rule set (like the various Japanese number puzzles) or a single interesting mechanic (Portal, or the different chapters in Braid) & craft interesting puzzles from that minimal toolkit. If you have to remember a bunch of rules & relationships (looking at you, Road Not Taken) then it's not a good puzzle game.

However...

COLD POTATOES:

The problem in this case is that it's just not very fun or interesting. RGB puts a big check in the elegance box but the puzzles just don't end up feeling worth the player's effort. I really don't like randomly generated puzzles, like, at all. A good puzzle game should feel like you're playing one-on-one against the designer; it should feel like an interaction with the puzzle crafter. RGB isn't as cold as, say, Minesweeper, but it's not that far off. Hand crafting puzzles would have taken a long time & I don't think that the benefit it would provide would be enough to save the game. So yeah, I took the easy way out.

CONCLUSION:

I only put a few hours of effort into this one so I'm not sweating it. It's good for maybe an hour or two of achievement hunting if you're really into puzzle games. I might use this mechanic as a part of another game (it might work as a room in a Chip's Challenge-ish game or something) but it's just not deep enough to make an entire game out of.

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.

RGB Official Release

RGB is officially available from the Potato Clock Games website.

The save/load system took like 15 minutes to code & I decided not to worry about the shitty audio design. Instead of encrypting the save file in any way I just added a note in there that Jesus was watching. That oughta do it, yeah?

I'm still 2 achievements short of 100%ing my own game & I think that's the way it's going to stay.

Second Course: RGB

I've decided to finish up this little puzzle game called RGB. It wins both the Potato Clock Games Awards for Minimalism & Lamest Title. The puzzles are generated randomly (well, it's not really random) & look like this:

Moving the highlighted space to an adjacent space changes that space's color; from red to green, green to blue, or blue to red. GET IT, RGB. The goal is to get all of the spaces the same color:

The catch is that you can't visit any particular space more than 3 times (the markings on the squares in the completed puzzle indicate how many times I visited them).

There are 4 difficulty levels (the example above is "amateur" difficulty, level 2 of 4) & a simple achievement system, that's about it. All I have left to do is some audio work & a save/load system so that your achievements don't just get wiped when you close the game. In case you didn't know what saving & loading was.

I'll try to have this finished one week from today.