Originally published on Golden Moose Studios' blog.

At indie studio, Golden Moose Studios, we just released an early prototype level on TIGForums of our 2D/3D hybrid, roguelike space shooter.

The design process and iteration for this build became quite the balancing act, as you’ll read about in this article.

Over the 2 days it took to build and adjust this level, I found myself questioning:
 

 
There were many moments throughout the design process, where I questioned my design intuition, “Would it even be fun for someone who is thrown into this level for the first time?”

Here’s the story of my process - working through these design questions, while creating a quick vertical slice level for a challenging, roguelike game.

The Purpose of this Level

Before I dive into this dev diary, here’s a little background information about our goals in creating this level:

We are in the process of building a series of “throwaway levels” to learn more about the game we’re creating, such as:
 

 
Of course, we’re also using these levels to experiment with new systems, enemies and weapons, to learn what feels good and what needs improvement.

For example, I also experimented with level width (wider play areas) in this level, which ended up being easier to design for than I initially thought.

Manne wrote spline metadata scripts that we can use in conjunction with the Curvy Unity plugin and camera path/enemy paths.

This means we can specify a camera offset at each point on the camera spline, allowing players to maneuver farther out to the sides of certain areas:

This was a feature we hadn’t explored in our previous build but I found an interesting aspect of this build, as it allows for different play strategies to emerge.

Here’s what it looks like in the level:

One of the most valuable parts of this entire process is seeing how players react to what we’re building - if any aspects of the design are unclear and so on. Fellow developers were great at giving us feedback for our first build on TIG, and we incorporated some of their suggestions into this second build! 

(We like to say that, in a way, the game development community is acting as our stand-in producer or publisher.)

Each of our milestones has a specific objective. For this particular milestone, we decided to make a short build in order to show:
 

Here's how my thought process and the level design changed over the course of 2 days it took to build:

The Design Process

Building a Functional Level

I created a small first area for the level, which started out challenging. I couldn't get past this small area the first few times I tried it, but I figured it was fine I wasn't able to beat my own level easily. As I mentioned in my tweet:
 

Getting Too Good as a Player

By the time I created a basic outline for the whole level (placing all enemies, rocks, camera spline points), I had played through it a number of times and was rather bored by my own level. It was no longer a challenge for me to beat...although it was good that I still wasn’t able to turn my mind off completely to play. Playthroughs still kept me engaged as a player.

Playtesting & Feedback

At this point, I asked the other half of Golden Moose Studios - Manne - to try out the level. He died a few times but eventually made it through to the end.

Since Manne regularly plays difficult roguelikes, I thought Manne was testing out possible issues (programming, collision or design issues), rather than playing the level as an actual player. I was surprised to discover he was playing as he typically would and actually did find the level challenging.

I figured, “This is good! He died multiple times but eventually found the level possible.”

Manne pointed out a few areas to change, such as moving the enemies from the beginning of the level so they attack from ahead of the player, instead of behind. He also pointed out places where players could get stuck between rocks and emphasized the need for us to construct a design language, making it more intuitive to players which rocks are possible to fly & shoot over versus which ones aren’t.

I asked him a few follow up questions to learn why he had or hadn’t played in certain ways, such as "Why didn't you use any weapons, aside from your main projectiles?"

Tweaking & Polishing

By the afternoon of the 1st day, I was making additional tweaks (such as adjusting the timing of enemies) and incorporating Manne’s feedback.

At this point, I was so good at the level that I was wiping out enemies as soon as they entered the screen. This meant that nearly every area now felt as though it had a serious lull in action.

I knew exactly where enemies would come from before they appeared, so I had developed a strategy to maneuver around the level and knew which weapons were ideal to use and when to use them.

In a way, this was good. We’re making a roguelike game - players are going to play the same levels many, many times and know where enemies will appear. We need to make sure the game remains fun and engaging for players who learn levels extremely well.

I started adding more grunt enemies to make up for the “lulls in action” - Basic enemies that flew and shot straight ahead. This was okay, I figured, because they provided a small bonus for experienced players, who could earn additional pickups to repair their ship, but they shouldn’t get in the way of players who are new to the level.

Second Guessing My Design

Then came the point where I started to question my design, second guessing whether I was adding too many enemies to the level unnecessarily.

Would new players quickly become overwhelmed by the enemies and rage quit?

Does it still feel fun enough to where players will want to develop their skills/strategy to progress in the level?

Overcoming Design Doubt

Instead of immediately eliminating what I thought may be a problem (the new enemies I had just added), I tried to play as I thought a new player might play - I stopped using special weapons and, instead of heading directly into the middle of the action, I hid behind rocks, only taking out enemies that felt “safe.”

This helped me understand which areas may feel like a mess to players who hadn't played the level multiple times and are instead, seeing it with fresh eyes.

By playing in this way, I also discovered that there were even more strategies and ways of approaching enemies than I initially realized. I started using areas of the level I hadn’t used previously, taking out key enemies only and subsequently surprising myself with the new play patterns that emerged. (For example, I discovered one enemy would make my life more difficult later in the level if I didn’t prioritize it in the previous section.)

Revisiting Design Doubt

I took a break from the design for a full day, and when I came back to it, I was shocked that I ended up dying multiple times before I was able to reach the end. This really made me question whether the level would be too difficult for someone to jump right into...much less play through the whole level!

(Even though I overcame my design doubt the previous week, that didn’t mean I was done second guessing my design!)

I wondered whether I should tone down the level so more playtesters could finish after a few tries, but I resisted that urge, reminding myself this is the point of the game - it is supposed to be a challenge. Players shouldn’t be able to finish levels on their first try or even their second. The idea is to learn from death and improve, so players get farther the next time they play. Plus, like other challenging games (Super Meat Boy or Castlevania for example), your skills simply won’t be as good after you take a break.

In short, it helped to remind myself of our design goals and that what we are showing is a vertical slice. We don’t want make the level less challenging simply because there’s a learning curve. (We don’t even give players time to try out the controls before enemies appear, as we did in the previous build!)

(It should be noted that in these early prototype levels, players die after only a few hits, whereas in the final game, players will have a range of abilities - including a shield and side dash - to prevent some projectiles from getting through. In that regard, the final game will be more forgiving than these early builds, though we do want to reflect enemy difficulty in these early builds.)

Conclusion

My concerns about the difficulty actually made me find the level even more interesting to try out on actual users.

What better way to test the difficulty than by testing this threshold with a level I sometimes find easy and other times challenging?

It’s a good way of learning, "How far can I push players...without pushing them to the point where they will rage quit?" (I sincerely want to thank each and everyone of you who tries the level. We hope you didn’t find it too frustrating!...but if you do, absolutely let us know in the comments!)

Part of the exercise in building “throwaway levels” is to learn where this user threshold is. It isn’t easy, as every player will have their own difficulty threshold.

My job, as a designer, is to design the level so I basically hand the decision making baton over to the player - It’s up to players to balance risk taking with defensive strategies. It isn’t my job to handhold and show them how to do this.

From a design perspective, I find it interesting that it’s highly likely strategies will change as players play the level more and their skills improve (such as mine did - playing more defensively Monday morning (when I was had trouble beating the level) and far more aggressively the week before (when I was really good at the level)). I wish I could personally observe more players testing the level to see how/if playstyles change over time.

It’s very possible some players will get frustrated after a few tries and quit, and that’s perfectly okay.

After a certain point of tweaking and balancing, I had to let go - I had to stop overthinking and simply learn from the players. (Design intuition and constant iteration will only get you so far!)

Anyway, try out the build for yourself!

Stay in Touch!

Thanks for reading!

@KarinESkoog

@MrPotatoStealer
 

What are some of the ways you balance difficulty curve in games that are designed to be challenging?