Purgatory Purgers: Level Design

What Should a Level Look Like?

In my last post, I solved a major collaboration issue by figuring out how to export/import individual rooms in GameMaker Studio 2.

Since then, Eric and I have been creating levels to round out the game, and with a little over an hour’s worth of content, I’ve been looking at some of the larger levels to see which parts I can cull so that the game doesn’t get dull/outstay it’s welcome.

Level design is difficult to do well. Purgatory Purgers’ level elements can be broken down into a few different components:

Features

At its heart, Purgatory Purgers is a puzzle-exploration game. Each level is a series of interconnected rooms of varying shapes and sizes and could include:

  • Gambits: Rooms with one or more dangerous enemies
  • Treasure Rooms: Filled with lost souls (the primary objective of the game/scoring system) and free lives
  • Puzzles: Moveable blocks, bridges, etc.
  • Secrets: Hidden rooms and passages marked by a small crack in the floor or an odd-looking bush.

These aren’t mutually exclusive and could be combined to form interesting and progressively more challenging areas.

Flow

A good level shouldn’t railroad the player down a specific route; instead, there should be 2-3 branching paths and reward players for exploration with additional lives and/or hidden shortcuts through the level.

Embellishments

To bring the Purgatory Purgers levels to life, I created lots of additional tiles to add flavor and mystery to each set of levels. Locked doors, sewer grates, pools of water, grass, grates, blood spatters, arcane symbols, and even emptiness in the later levels.

Putting It All Together

A good level combines all of the above to form a cohesive package; the level is:

  1. Good looking (i.e., makes good use of the available tileset and avoids excessive repetition)
  2. Intuitive to navigate (it doesn’t require a lot of backtracking)
  3. Sufficiently diverse in enemies, puzzles, and mechanics
  4. Above all, fun to play (read: sufficiently challenging, but not too difficult)

Purgatory Purgers: Simple Music Control

Background

In past projects, I controlled music using the room creation code, e.g.:

audio_stop_all();
audio_play_sound(snd_music1,100,true);

This would stop all previously playing audio and start the new music track, looping it until the next room was created.

Functionally, this works fine, but I wanted a more centralized way of handling this so that if I wanted to make a change, I didn’t have to do it N number of places, equal to the number of rooms I created.

How It Works

I created an object called “obj_sound” and placed it in the first room, then I flagged it as ‘Persistent’ so that it would carry forward from room to room.

I added a Room Start event with the following code:

if room==rm_level1 {
audio_play_sound(snd_lvl1,100,true);
}

if room==rm_level2 {
audio_play_sound(snd_lvl2,100,true);
}

At the start of the room, it checks to see if the name of the room matches “rm_level1” (the name of the first room/level), and if it does, it plays the sound “snd_lvl1” at a priority of “100”, and sets looping to “true.”

Once that was working, we needed to be able to stop the previous music track before loading the next one. This can be done using a Room End event:

audio_stop_all();

This stops all audio before the next room is loaded, preventing tracks from playing over each other.

Conclusions

There are other ways this could be handled, however…

  • It works for what I need it to do (starts a looping music track that’s definable by room name).
  • It’s centrally controlled.
  • It does this in the simplest way I know of, and more importantly, I understand it!

Purgatory Purgers

Here We Go Again!

Back in May, my life was starting to slow down enough to spend some time on game development again. Shortly after, I reached out to my old friend Eric to reconnect.

After a few weeks and several emails back and forth, we decided to start again, this time on a new project.

Game Mechanics

Eric suggested Chip’s Challenge (specifically, the Windows 3.1 version) in brainstorming ideas, which incorporates a few key elements:

  • Collecting McGuffins (computer chips)
  • Pushing things (similar to Sokoban)
  • Avoiding enemies

While Chip’s Challenge is more complex than that, we decided to focus on those 3 design ideas and start there. Eric proposed the idea of the player controlling an angel and a demon trapped in limbo. The two would have to work together to solve puzzles to advance to the next level.

The McGuffin would be souls, which would be set free from limbo to either ascend to heaven if collected by the angel or descend to hell if collected by the demon. Collecting all of the souls would allow the player to exit the stage and move on to the next level.

We incorporated a Sokoban-like push mechanic and decided to give this ability to the demon. Blocks would be used to obstruct enemy movement/line-of-sight and also to solve key/lock puzzles.

But we also needed something for the angel to do, so we decided to include water tiles that only the angel could traverse, using the same key/button that the push mechanic utilized.

After getting these features working, I had the idea to introduce bridges that the angel could lower, allowing the demon (and, by extension, blocks) to traverse areas that would normally be cut off by water.

Next Steps

With most of the core mechanics working, there’s a lot to do insofar as creating assets (art, music, etc.), levels, and the like. Eric is primarily responsible for level design, so I leave it to him to work on cranking those out while I work on polish.