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.
Friday, January 30, 2015
Thursday, January 29, 2015
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.
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.
Wednesday, January 21, 2015
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.
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.
Tuesday, January 20, 2015
Rogue Matrix Debriefing
I want to take a few minutes to collect my thoughts about what did & didn't work with Rogue Matrix. I think I should try to do this with all of my games, just to give myself some direction in terms of design.
HOT POTATOES:
Music Generation: This was a successful little experiment which I'll definitely be exploring further.
Dungeon Generation: I like the look of the dungeons, layout-wise. I'll probably use this same algorithm if I ever make another roguelike, which I almost certainly will.
Light Strategy: There's just enough strategy involved to keep the game a little interesting. Check it:
The more enemies there are wandering around the level, the more the loot is worth. So to maximize your score on a given level, the best strategy is usually to pick up all the loot first, then kill the enemies. However, having more enemies around also causes your time to decrease faster, shortening your overall playtime & making it difficult to reach the later stages where loot is worth more. So then it would seem that the best strategy is to sprint through the first few levels to get where the big points are. But then you miss out on all of the items you could have collected, which are often essential for survival in the late game. So it's a balance, but there are enough random elements to keep the player from guessing at an optimal strategy for a specific game until all of the items have been discovered.
Look, I'm not saying it's a great game, but I do think there's a little more depth to it than first meets the eye.
COLD POTATOES:
Exploration is Boring: This is an immediate deathblow to a roguelike. Every part of every level looks exactly the same. Every enemy looks exactly the same. Exploration is a central game mechanic here & it just isn't much fun.
Worst Graphics Award: I mean, have a little bit of pride. Jesus.
Terrible UI: All that text in the infobar needs to be there because the game does such a bad job of explaining itself to the player. The strategic elements should be communicated to the player more elegantly through gameplay. It's Ok for a game to be hard to figure out completely, but only if figuring out the rules is designed to be part of the fun or the challenge. Here, it's just shitball UI & UX design.
CONCLUSION:
I think this game turned out alright considering the minimal amount of effort I ended up putting into it. I'll probably use this game as a starting point for building another roguelike in the future.
Monday, January 19, 2015
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:
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.
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:
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.
Tuesday, January 13, 2015
Rogue Matrix Official Release
Rogue Matrix is finished & has been uploaded to the Potato Clock Games website. I actually think it turned out pretty well for what it is, which is a shitty, low effort roguelike.
Enjoy! For like, a minute. Then do something else. In the meantime, I'll figure out which game I should get cracking on next.
Enjoy! For like, a minute. Then do something else. In the meantime, I'll figure out which game I should get cracking on next.
Monday, January 12, 2015
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.
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.
Friday, January 9, 2015
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.
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.
Wednesday, January 7, 2015
First Up: Rogue Matrix
I just played what I think is the most recent build of Rogue Matrix, it seems pretty much finished so I think that's where I'll start. Low hanging fruit, yeah?
As the name implies, this is a computer hacking-themed roguelike. It is not good. It's pretty bare-bones as far as roguelikes go, but don't worry, it's got a hella hot soundtrack. This game is an experiment that got out of hand, I really just wanted to see if I could make a random dungeon generator that I liked. Once I got it working I figured I may as well get a dude walking around in there. Then, you know, may as well give him some loot to collect. Things to fight. & so on until a successful experiment became a shitty game. CIRCLE OF LIFE.
The effects of the items you can pick up in the game are randomized with each playthrough so I had to come up with a bunch of different things for items to do; some good, some bad, some just for kicks. One of the just for kicks effects was "matrix mode" where everything on the screen is made out of falling numbers. It took longer to get this stupid effect working properly than it did to get the dungeon generator working. I thought it would be hilarious if the game was just always in matrix mode & thus was born Rogue Matrix.
I just need to finish up some audio stuff, then this gem should be ready to go. Probably a few hours of work. Taking into consideration my real job, getting ready for next semester which begins on Monday, & the fact that every season of Friends just landed on Netflix, I'd say I should be able to have this one wrapped up by the end of the weekend.
I'LL BE THERE FOR YOOOOOOU.
As the name implies, this is a computer hacking-themed roguelike. It is not good. It's pretty bare-bones as far as roguelikes go, but don't worry, it's got a hella hot soundtrack. This game is an experiment that got out of hand, I really just wanted to see if I could make a random dungeon generator that I liked. Once I got it working I figured I may as well get a dude walking around in there. Then, you know, may as well give him some loot to collect. Things to fight. & so on until a successful experiment became a shitty game. CIRCLE OF LIFE.
The effects of the items you can pick up in the game are randomized with each playthrough so I had to come up with a bunch of different things for items to do; some good, some bad, some just for kicks. One of the just for kicks effects was "matrix mode" where everything on the screen is made out of falling numbers. It took longer to get this stupid effect working properly than it did to get the dungeon generator working. I thought it would be hilarious if the game was just always in matrix mode & thus was born Rogue Matrix.
I just need to finish up some audio stuff, then this gem should be ready to go. Probably a few hours of work. Taking into consideration my real job, getting ready for next semester which begins on Monday, & the fact that every season of Friends just landed on Netflix, I'd say I should be able to have this one wrapped up by the end of the weekend.
I'LL BE THERE FOR YOOOOOOU.
Monday, January 5, 2015
PotatoLog Zero
I'm starting this undercover devlog to motivate myself by making my lack of progress unavoidably apparent.
I have a bunch of games that I started like 5 years ago that I need to finish so that I can start working on other things. All of these games are dumb. Why do I want to finish them? I'm sure that this is a question that has already been resolved by the scientific community. I am moving on.
I'll write more about them as I get to working on them, but here are the games:
Jack Ham Zero - prequel to the beloved Jack Ham's Maze of Tribulations.
Sunrise Sunset - a terrible platformer / shroom tripping simulator.
Giraffe Adventures - a simple, browser-based choose your own adventure story.
RGB - a small puzzle game about colors & squares.
Justin Bieber's Mega CockBlockaz 2 - a controversial puzzle game about colors & squares.
SquareWave - an action/puzzle game about colors & squares.
Rogue Matrix - a shitty roguelike with a sick soundtrack.
Jesus fuck, that's about twice as many games as I thought I had to finish. Where to start?
Subscribe to:
Posts (Atom)