Abyss

Abyss is a game that combines a few core ideas that I have from playing Roguelikes and Mystery Dungeons games.

The core mechanic of Abyss is the concept of knowing when to push your luck and when to “take profits”. This idea of push your luck is very common in MD games, where you can go down 1 floor, or escape with what you have. It is also present in some form in games like Cataclysm where you can continue to loot the city or return to your base with whatever you have. Another roguelike that had this push your luck aspect that I like is 868-HACK.

With this core mechanic, I added a few constraints to limit the scope of my game.

1. Mobile friendly; Simple Control and Short sessions
2. One Screen; which means no big maps and fog

I also had another mechanic in my list that I always wanted to try which fits nicely into a One Screen Roguelike.

What if the floor breaks as you move ?

With this, and a few days before the start of 7DRL, I started writing down ideas for the game, and what is the MVP that I want to deliver by the end of 7 days

Start of Development

As I am currently building a Roguelike/MD game, I had an existing engine that I could use.

• https://gitlab.com/ZwodahS/haxe-zf
• https://gitlab.com/ZwodahS/ren

I had also decided to just use a tileset, “DawnLike”, and recolor it and add on to it for the 7DRL. This allow me to focus on building the core mechanic and experiment with it rather than making things look good, not that it matters for Roguelike ;)

Below is an account of how the days went, skip ahead if you want to just know the summary of the lessons and design choices.

Day 1

Day 1 isn’t exciting as I did not prepare a boilerplate for Roguelike. I only had a generic boilerplate that I use for all game jams, and it was outdated. I ended up spending the whole day getting my set up; build pipeline, assets pipeline, itch io page.

By the end of the day, I only managed to render the player and floors onto the screen a bit of movement.

Lesson 1: Prepare beforehand if the game jam allows.

Day 2

One key lesson I learnt from other game jams is to always get the game core loop complete as early as possible. In short the steps to any game jams almost always look like this:

• Step 1. Get something onto the screen
• Step 2. Complete playable loop
• Step 3. Add Content
• Step 4. Balance
• Step 5. Polish

The thing is, the time getting from step 1 to step 2 is unknown, as it is up to you to define how a playable loop looks like.

In the case of Abyss, the game loop is Enter Abyss -> Exit Abyss. Yeap. I didn’t even add in the treasure gathering. To achieve this, I just generate the level, place a stair directly beside the player for testing and call that a playable loop.

By the end of day 2, I had a fully playable loop. I managed to even squeeze in the floor spawning and breaking logic, which was one of the core mechanic I wanted to test. I also added gold as the first goal for the player.

Day 3

Day 3 for me is content adding, in particular the treasure hunting part. Initially the game was meant to be run based, and your score is based on how much treasure you get. However, if you die, you get a score of 0.

Day 3 was not eventful, as I just continue to add content to the game. Day 3 is also the day I renamed the game from ‘treasure-hunter’ to “Abyss” and started sharing the game with friends and community.

Day 4 & 5

Day 4 and 5 was purely about playtesting and balancing the game and also adding any content that I felt was interesting.

After gathering feedbacks from friends my own playtest, there were a few issues.

Lesson 2: Get feedback early

1. The level doesn’t feel dynamic
2. There was no goal.
3. The risk of pushing your luck was not apparent, as you just lose your current score.

To solve 1, I started brainstorming about what type of feature I can add to make it more interesting. Getting the feedbacks from friends, I added “Moving Treasure” and “Spreading Danger” to the list of things to do. Eventually this 2 item became the Diamond Squirrel and Lavapool.

To solve 2 and 3, the initial idea is to put some meta progression. I know that this is likely too big of a scope for the game jam, but I could do a simple hack. What if your score persist and you lose everything when you die. This makes escaping an important decision.

By the end of day 5, I already know what are the rest of the features I want to include. The only tricky part is building the fire mechanic. To do this, I had to change some fundamental assumption of the game.

Day 6 & 7

Lesson 3: Know when not to add a feature.

Day 6 was a nightmare for me. I had deem adding fire to be an important feature to the game but because the current assumption of the game engine did not allow for it, I had to rewrite quite a bit. In additional to that, adding the fire mechanic also stretched the core system that decide whose’s turn it is. This created a lot of infinite loops in the game and I had to rewrite the entire turn system logic multiple times.

By the time I realised that I should not have added this feature, I was in too deep to quit.

The entire day 6 was just adding Fire to the game, and I have no choice but to cut the rest of the features I wanted to add.

On day 7, I decided to just call it and just wrap up the game by cleaning up some animations and screens.

Lessons

1. Prepare your boilerplates if your game jams allows.
2. Get feedback early
3. Know when not to add a feature.

Design choices

There were a few decision choices that I thought were interesting to point out.

The initial Stair

Firstly, the stair at the start of the game. This was initially used for debugging purposes, but after playing around with it, I decided to keep it there. In additional to that, I placed gold a few steps away and also limited the entire starting area.

These served 2 purposes.

First, it allow the player to move to a stair and exit immediately. This teaches the player how to leave the dungeon. Second, if the player choose to move towards the gold, they will immediately see that the floor breaks below them. In additional to that, if the player choose to get the gold, the stair will break by the time they return back to the stair.

This entire section serves as a tutorial and expectation setting for the player, at least that is what I hope to achieve.

Carrot and Stick

Another design decision that I made was how I choose what entity to add to the game.

I classify entities onto 2 axis in particular, Static/Dynamic and Goal/Neutral/Danger.

For example, gold are Static Goal; essentially something that the player wants to get, and does not move. On the opposite side, Fire is considered as the most Dynamic Danger, as it spread and continue to disrupt the player.

When the game became too chaotic, I add more static entity. When the game became too static, I add more dynamic ones. I did the same for Goal vs Danger.

After adding Fire, the whole game became a lot more chaotic. I wanted to add a few more Static entity, but time didn’t allow. This cause the game to be a bit out of balance, so I had to reduce the spawn rate of LavaPool and Fire.

Meta Progression

The vault(meta progression) feature was one of the last thing I add. This is probably one of the least roguelike feature in the game, but as it does not affect the gameplay itself, I feel that it is fine.

Having a high score that keep going up until you die, is really quite punishing. However, because of this, the feature actually work very well with the push your luck mechanic as it makes the decision of leaving more important.

Summary

The 7DRL is really a great experience for me. I wanted to participate in 7DRL for a few years now, but didn’t had the time. I’m really glad I did it this year. Will definitely do it again, so see you next year.