Purgatory Purgers: Version 1.5 Released!

Update Summary

  • Collecting 100% of the souls with Bob (the demon) is now possible!
  • Resolved clipping issues in the levels “Stilted Pond” and “Toad Hall.”
  • Gamepads, including PlayStation, Xbox, and Super Nintendo-style controllers, are now generally supported*. See the notes below for additional information.
  • Updated the Purgatory Purgers Manual to include gamepad button mappings

Special thanks to @ABitNosthalgic for suggesting that we make it possible to collect 100% of the souls with one character or another!

Gamepad/Controller Support Notes

*Most PC-compatible controllers with a Direction Pad (D-Pad), Start and Select buttons, and four face buttons should work. The game has been tested on the following devices:

  • Logitech F310
  • X-Box Elite Series 2 Wireless
  • Megafire 412-NO5 (generic PlayStation 2 Style Controller)
  • 8BitDo SN30 Pro (SNES-style controller)

@ABitNosthalgic reported that the Suily brand NES-style controllers did not work for him. While I haven’t tested this myself, the reviews seem to suggest that problems, particularly with the D-Pad, aren’t that uncommon.

Purgatory Purgers: Version 1.4 Released!

Update Summary

  • Resolved a bug (warning, spoilers!) that would destroy objects unintentionally when two blocks collided
  • Added a spawn/respawn animation and sound effect
  • Reworked the Passphrase mechanic (used to continue to a previously visited level) to display the Passphrase on the pause screen under the main menu as well as the Game Over screen.
  • Updated the Purgatory Purgers Game Manual to better describe the Continue/Passphrase mechanic and other menu features.

Special thanks to @ABitNosthalgic for catching the bug and Jason D for passphrase feedback!

 

Purgatory Purgers: Buggery

Warning: Spoilers Ahead!

This post discloses the locations of some of the secret rooms found within Purgatory Purgers. If you’d rather discover these surprises for yourself while playing the game, you may want to avoid reading further!

A Fresh Perspective

Players are often your best resource for identifying possible bugs, exploits, and missed opportunities (read: feature requests). The week Purgatory was released, I received a lot of feedback and, with it, fresh eyes to point out my mistakes.

I addressed what I could and tabled the rest, save for one elusive bug I could never pin down but appeared so infrequently that I couldn’t get a bead on it. Occasionally, an object or group of objects (e.g., a gem block, ethereal coins, etc.) would go missing from a room, and I couldn’t explain why nor duplicate the behavior. Unable to identify the culprit, coupled with the sporadic nature of the bug, I decided to leave well enough alone…

Recently, a new YouTube channel, “Back to the Past Gaming,” started a playthrough series for Purgatory Purgers. While watching ABitNosthaligic‘s playthrough of the fourth level of Purgatory Purgers, “Stilted Pond,” I was surprised to see that the secret room he discovered was empty:

He suggested it might have been an oversight, and while it’s certainly possible that I’d forgotten to populate the room, the problem was (unfortunately) not that simple… And so, after a 3-month hiatus, I decided to tear back into the code to under, once and for all, why this was happening!

First, Check the Obvious

Looking at the room layout in the GameMaker IDE, I could see the objects had been placed:

So why were they missing during his playthrough? I fired up the game, went straight to the offending level, and made a beeline for the secret room. Upon entering, there were the Ethereal Coins right where I expected them to be:

To try to duplicate the [unwanted] behavior, I did a normal playthrough, and lo behold, the coins were missing for me, too! Progress, at last! But why? What exactly was happening to the coins? Were they failing to render? Were they being destroyed?

So, to begin my troubleshooting, I added the following code to the “obj_oneup” object’s Draw GUI Event:

// Am I here?
draw_self();
draw_text(20,20,"I'm still here!")

Whenever you use custom draw code (e.g., draw_text), you must precede it with “draw_self(),” or the sprite won’t be drawn. The purpose of the draw_text message is to print the string “I’m still here!” in the upper left-hand corner to let me know that at least one instance of the object still exists on the map. Simply put, these two lines of code tell me that the object is both visible and present.

I saved my work, then launched the game, and upon entering the first level, I could see the message right where I expected it:

After collecting the Ethereal Coins, the message disappeared as expected. So, I continued playing until I reached the offending level (Stilted Pond), and after some experimentation, I was finally able to observe what was happening…

Next, Eliminate the Impossible

“When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”
– Sherlock Holmes, The Sign of Four

Whenever I pushed one block into another block, all of the Ethereal Coins in the current room were instantly destroyed. This was true, regardless of level, but I couldn’t yet understand why…

The way I coded movement for blocks, enemies, and the player in Purgatory Purgers was a modified version of my grid movement system, explained here and here. In short, here’s what happens when you “push” a block:

  1. An instance of an invisible 16x16px target object is created 32 pixels ahead.
  2. The block moves toward the target object.
  3. Upon collision, the target object is destroyed, and the block’s movement speed is set to zero, stopping it.

Because we’re using an Instance Variable, it has to be declared in the Create Event, e.g.:

block_target=0;

This variable would later be defined in the Step Event whenever the block was moved, something to the effect of,

block_target=instance_create_layer(x-bdist,y,"Instances",obj_block_target);

In the example above, “block_target” is the variable that refers to the Instance ID of the specific instance of the obj_block_target object we’re dealing with and nothing else! So when obj_block collides with the instance of obj_block_target that it created, i.e., “block_target,” only that instance should be destroyed, but somehow, the obj_oneup was being [mis]associated with “block_target.”

Block movement was one of the first features I coded, and later implementations used the place_meeting function in the End Step Event. So, simply recording it to do that fixed the issue.

I still don’t fully understand this, and after hours of troubleshooting, I am relieved that this was resolved. I have since posted the fix to itch.io as version 1.4.

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)

Stepping Stones and a Clear Path Forward

Building on an Unstable Foundation

As we draw closer to a working prototype, it’s become increasingly more apparent that there are some fundamentally flawed issues with the way we’re going about implementation.

Eric is new to both programming in general (save for some college level coursework a few years ago), and GML. All in all, he’s got about 4 or 5 weeks worth of experience in total, but no formal training. As such, he doesn’t have a solid foundation of knowledge to build on, forcing him to seek out tutorials (usually YouTube videos) which give him ideas as to how a thing can be done.

The most popular videos are more akin to “Let’s Plays” with little (if any) structure, and even fewer explanations as to why the developer elected to go about doing things a certain way.

This forced Eric to look at what the other developer did, attempt reproduce it, then reverse engineer it without understanding what each piece’s purpose – trying different arrangements and configurations until it worked (or at least appeared to).

What troubled me was that sometimes I’d ask for a seemingly trivial feature only to find that he was unable to work out how to program it, and compromised with an implementation that wasn’t up to spec.

For example, instead of using keys 1-6 to toggle a different weapon type, and Ctrl to fire,  he mapped weapon type 1 to key 1 because from a logic standpoint, he had no idea how that would work, let alone how to frame the problem so that he could look it up.

Another example was the breakable wall from my prototype specifications in the last post. What I asked for was for wall, when placed, to take damage when it collided with the enemy, and update it’s animation frames to show progressively more damage before being destroyed.

Because he didn’t understand how variables worked, the wall was killing the enemy rather than the other way around – my suspicion was that he didn’t use the “with other” construct to indicate that it was the wall taking damage, not the enemy as they both had an instance variable called “hp” (i.e. hitpoints).

After a few more hours of working on it, he came back and this time the walls were taking damage, but being destroyed after only a second or two. This was because he was using the image_index property to advance the frames of damage to the wall sprite, destroying the object when it reached the end of the animation, foregoing hitpoints altogether.

Since the room speed was set to 30 (i.e. 30 cycles/second), the enemy was colliding with the wall 30 times a second, causing the wall to cycle through each frame of its sprite sheet within a fraction of a second. While this “appeared” to work, it in fact did not follow my design specifications (no hitpoint system) and was therefore not fit for purpose.

I suggested how this could be solved in pseudo code, but he insisted he tried that and it didn’t work – again, probably because of which object he was calling the variables from, but I didn’t know that either at the time.

So where could we go from here?

You Don’t Know What You Don’t Know…

The root of the issue was that while I understood the basic logic I wanted to use, I didn’t have the syntax for it, and neither did Eric. We needed to take a step back and learn the basics before trying to implement big, hairy, complicated features.

So again, I took to YouTube – we’d watched several of the Let’s Learn GameMaker: Studio channel’s videos, lots good information covering what was available and what options there were for each feature, but there was no practical application of those lessons; at at the end of the lesson, there was no example of a typical use case for that feature in your game

A Clear Path Forward

Just when I was about to give up, I managed to stumble upon another channel aptly named, Gamemaker Game Programming Course.  The channel is a bit confusing (the playlists in particular) until you work out that it’s actually just a video repository for his website:

www.gameprogrammingcourse.com

Start there, download the resource packs and project files, then start with the playlist labeled: Level 02 [ GameMaker Basics Sprites Objects Events ].

The site and videos were created by computer programming teacher named John Janetka for his high school’s computer science program. The quality of the content and structure of the lessons are the best I’ve come across on YouTube thus far.

By the end of Level 02, I was able to solve both of the programming issues Eric was struggling with above, and created two games in the process. Simple as they were, the experience was valuable.

I’d asked Eric to place his programming efforts on hold to go through this course with me. I asked him to try not to think of this as a step backward, but rather rather a stepping stone forward toward better, more stable code. He agreed, and will continue to check in every day or so to share what we’ve learned.

###

Image Credit: “Martyn B

Disclaimer: I have no affiliation with any of the websites, applications or YouTube channels referenced above.