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)

GameMaker Studio 2: Exporting/Importing Rooms

Background

I’ve been looking for a way to allow another user to create rooms for my existing project using templates I’d created with consistent instance, tile, and background layers.

After my experiment with source control ended in disaster, I decided to shelf that for the time being and try a simpler approach:

Procedure

  1. On PC1, I Exported the as-is project as a .yyz file (File > Export Project > YYZ) and then saved the file to a network share.
  2. On PC2, I downloaded the [MyProjectName].yyz file and Imported it (File > Import Project > Path\To\.yyz file).
  3. I updated the project on PC2 by creating a new room, and then I saved the project.
  4. I opened File Explorer on PC2 and browsed to the project’s rooms subfolder (i.e., C:\>Users\[MyUsername]\Documents\GameMakerStudio2\[MyProjectName]\rooms).
  5. I located the corresponding folder to the new room I’d created, then copied the room2.yy file back to the network share.
  6. Back on PC1, I created a subfolder in my project with an identical folder name and then copied the room2.yy file to that location.
  7. I opened GameMaker Studio 2, right-clicked in the Asset Browser, and selected “Add Existing“. After navigating to the room subfolder from the previous step, I selected the .yy file and clicked “Open.” Nothing happened!

At this point, the rooms list didn’t update with the new asset, nor did I receive an error.

The Missing Step

After opening the game’s project file (.yyp) in a text editor, I could see a list of resources, including rooms, along with their relative paths:

"resources": [
{"id":{"name":"room1","path":"rooms/room1/room1.yy",},},
],

What I did not see was an entry for the new room I created, so I simply appended the list with the new room:

"resources": [
{"id":{"name":"room1","path":"rooms/room1/room1.yy",},},
{"id":{"name":"room2","path":"rooms/room2/room2.yy",},},
],

Towards the bottom of the list is the room order, which I also appended:

 "RoomOrderNodes": [
{"roomId":{"name":"room1","path":"rooms/room1/room1.yy",},},
{"roomId":{"name":"room2","path":"rooms/room2/room2.yy",},},

After saving and closing the text editor, I fired GMS2 back up, opened the project, and after an agonizing minute or so of loading, the project opened without error!

To my delight, there sat the imported room in the asset browser. I double-clicked it, and there it was:

Alternatives Considered

Someone on the official forums had suggested having Eric submit asset packs – I have no idea what that means exactly, but he seemed to suggest this was less than ideal.

Eric’s original levels were created in Tiled, and then I’d manually recreate them in GMS2, which was inefficient and very time-consuming; however, I’d heard that there were tools that could convert a Tiled map to a GMS2 .yy room resource file but couldn’t get it to work properly with my project. This is because our maps utilize multiple tile layers sandwiched between an instance layer (where the objects live) and the background layer. Most of these tools assume you are working for a single tile layer to another single tile layer, and none of the address how to get the room.yy file back into your project.

Caveats and Disclaimers

  • In order for this to work, all of the resources used in the room (i.e., objects, sprites, tilesets, etc.) must be present and unchanged in both the source and destination projects
  • GMS2 is known to not play nice with Cloud-synced project folders, so make neither system

Purgatory Purgers: Git Thee to a Repository!

Doing Things the “Right” Way

I’ve worked alongside development teams for most of my professional career, and they all used source control. So, if I wanted to do things the “right” way, I also needed to use source control [with GameMaker Studio 2]. But alas, the map is not the territory, and you really screw things up if you don’t know what you’re doing. I didn’t know what I was doing.

Initial Setup

Although GMS2 offers [limited] native support for source control, it seemed simpler (and easier) to install GitHub Desktop and point it to the project folder.

Using this method, I was able to upload an entire project to GitHub, then install GitHub Desktop on another PC and clone (download a local copy of) the entire repository (i.e., the project folder) onto the second PC.

Once I got it working to my satisfaction on my end, I went ahead and walked Eric through it over Discord/screen share.

Where It All Went Wrong

Eric volunteered to clean up the tile layers of several maps – little mistakes where the incorrect tile was used for a given room that needed to be updated. Eric and I both thought that he’d pushed these changes to the repository, but the mistakes were still present.

Initially, I’d assumed these were regression problems that Eric introduced, but after looking at the same levels on my second PC, I realized these problems were present in older versions of the project, meaning Eric’s updates didn’t get pushed.

By then, I’d already fixed these problems on my end and pushed the updates to the repository. When Eric introduced his changes on top of mine, the levels were suddenly missing.

Recovery

After quite a lot of troubleshooting, I eventually decided to make a backup copy of the broken project, export the backup I had on my second PC, and then manually redo the changes I’d made over the last 24-48 hours.

This worked, and I was able to get back on track despite losing a day of productivity.

Lessons Learned

In troubleshooting, I discovered:

  1. Eric’s project folder was being synced with OneDrive, which I later learned could cause problems with GMS2 Projects.
  2. We were using different versions of the GMS2 IDE, which is also a bad thing.
  3. You have to be very careful when merging changes, as this can cause problems for individual resource (.yy) and project (.yyp) files.

At this point, I’m going to abandon source control for the time being in favor of something I know (traditional backup), but I may revisit it later…

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.