Greed Run is a race to get a treasure goblin to the exit of a volcanic tomb before traps or raising lava kill you. Then do it over and over through infinite procedural tombs until you die.
Greed Run was created over 48 hours for Ludum Dare 27 for the theme 10 Seconds.
Being a little more familiar with Unity at this point I of course planned something significantly more ambitious than last LD. I envisioned 10 seconds to loot through infinite dungeon type levels, while traps escalated, and some overarching danger would end it at the end of the time.
I quickly realized I couldn't do it all and focused on random level generation and a maximum of 10 seconds.
What didn't work well:
Controls
A real point of annoyance to me in some games I play is controls that work against you, and yet I made this mistake. As I was expecting to make a game about fast limited decisions I went with “simple” controls. The game controls like snake, but in a fixed isometric angle. Forward always makes the goblin move forwards, no matter his heading pressing “right” would make him turn right. By far the largest feedback was that control was unintuitive.
Potential Fixes:
- Keep snake controls, reorient the camera when the goblin turns so that “right” is always right relative the screen.
- Keep the locked camera, but make controls relative the screen, I didn't really want this as like snake I didn't want you to be able to turn back into yourself.
Danger Explanation
Levels “start” as soon as any input is pressed. This means lava will start rising and the timer for boulders dropping will start. The problem is that levels load instantly, so if the player is holding a direction when they hit the exit it's very likely that they will immediately trigger the start of the next level.
Potential Fixes:
- Put some kind of timer at the top to show the level has “started immediately”
- Have more visual effects showing the lava is rising.
- Some kind of graphical indicator to show how high the lava is currently, but not giving exact timing. To help stretch tension.
- Require a specific new input to start a level (though this would break the games frantic feeling)
What worked well:
Procedural Levels
I made a simple system that would created a level that occupied a grid. It would have an exit, some spike trap tiles, and potentially open gaps. The gaps and spikes were always only 1 tile in size, and could be jumped with good timing. While I was still destroying and instantiating tiles each time a level was generated, the small level size meant it was almost instantaneous.
Game Pace
The game is relentless. I found most players would be a bit tentative with the controls and what they planned to do in a level until a boulder crushed them. From that moment on they would always hold “forward” and just do their best to zig zag through levels. While controls were rough, the pace was exactly as I wanted it.
Overall
I liked how the game turned out, but had much more polish to add and features left out than my last game. On one hand I feel that this game could be updated in a bunch of ways to make it a more full experience, but on the other I think other games may have already accomplished similar.