Escape Xerith Dungeon
Can you Escape the unescapable?
Solo Project
Time spent on Project: Two Weeks
The Beginning of it all
I had a couple of weeks to make a game all by myself in an engine I had never worked in before, where do I start? Well I knew from the announcement of the project that I wanted to make a 2D dungeon-crawler type of game. With this mind, I began crafting and molding the world through narrative design. I created different factions and histories of the world that all tied to the strange and dangerous Xerith Dungeon. Many had ventured to the dungeon, but all were lost and forgotten with the passage of time.
Yet, I didn't want to get to complicated for I still had a game to make, so I structed the rest of the narrative based of the standard hero arch, although altering it slightly to add an element of uniqueness. Hero is trapped inside the dungeon and most escape before they are consumed by the Tree of Xerith. Thus its a story more of self-preservation rather than than self-sacrifice. From there the world and basic plot of Escape Xerith Dungeon was born. Now where to begin shaping this world?
Item Interaction Design
With the baseline of what I wanted to make in my mind, I knew that I couldn't make a true dungeon crawler without some sort of pickups and interactables.
I started out with with the most well known pickup, the health pickup. I didn't quite have enemies that would deal damage to the player, yet that didn't quite matter for I wanted to keep its design simple. It healed one point of damage that the player had taken. With this simple design, I was able to save a lot of time that I might have wasted designing something that really shouldn't take all that long to design given the nature of this game. Since I didn't spend all that long designing and coding the functionality of health pickups I was able to spend more time on something a little more intriguing.
That aspect of intrigue was spawned from keys and doors. I knew that I wanted to create some pickup that would dictate how the player would traverse through the different sections of a given level. What better to do this than the ancient invention doors and keys? First I needed to design the basic symbolism that would indicate to the player a usable key. I decided to go with a key on a table for it made visual sense that a key might be placed or stored on a table. From there I needed to design the doors around the map and how the player would use their keys on said doors. Furthermore, how could I represent that a door needed a key to be opened?
I approached this question from two different angles, one was visual via creating a door asset with a massive lock at its center thus representing its locked state. Yet, if that visual cue was missed, I coded in a pop up that appeared if the player tried to go through the door without unlocking it first. Now the player could go to tables to obtain keys that the discovered to be locked through either visual representation or by being told the door is locked. From here I had one last question to answer, what key should I bind this interaction to? Given that my movement was WASD based it made sense to either use Q or E as the interaction key. I personally thought E as more the universally used interact key and thus it would feel more natural to a player if the interaction between the doors and keys was bound to that key.
Enemy Interaction Design
After getting a sense of what I wanted, creating a narrative/world, and doing some interactable design, such as the interactions between keys and doors in mind, I decided to the next step was to populate this mysterious dungeon with dangerous beasts and strange critters. I knew I wanted three different enemy archetypes, melee swarmed based enemies, high damage ranged based enemies, and trap enemies. Since this was one of the first video game projects that I was going in more depth with where I was the only one on the dev team I knew I had to stay within scope despite these desires to add many variations of enemies. Knowing this I took very careful steps when first designing each enemy type and how they interacted with the player.
I first started off with the swarm melee-based enemies. These enemies are known as Cryspirs and have too different modes. Given that this one of my first games that I was making my own AI, these two modes consisted of dormant and swarm mode. In the dormant mode the Cryspirs awaited in their preselected locations for the player to travel into their view range cone.
Once the player enters this cone the color of the Cryspirs changed to reflect their attack state. Also, at this point in time I didn't quite know what or how to do a simple flocking algorithm, so I purposely placed the Cryspirs in a way where if the player was in range of one, they were in range of at least one other Cyspir. This created a sense that a small swarm of enemies was headed for the player.
To further this feeling, I purposefully created small chokepoints in while doing my level design that would funnel the Cryspirs towards the player. Yet, this funneling looked really weird and due to the 2D nature of the game it was hard to tell how many Cryspirs there were in the swarm. To fix this I gave the Cryspirs the ability to pass through walls. Now on paper this sounds rather like a rather strange decision, which to be fair it is a tad, but janky.
Yet, this change enabled the Cryspirs to swarm the player much more effectively, which was their intended design. Of course if I would redo this today, I would make a small flocking algorithm to make them actually swarm and redesign the levels to further this feel of being swarmed, but hey this was freshman year, so I was still pretty green back then.
Despite my green nature, I stilled added visual indication of when the Cryspirs were phasing through the walls. This was done by changing the sprite color whenever they passed through walls. Lastly given their nature of being swarm type enemies, I made sure they player could easily dispatch them and thus their health pool was rather low.
With my swarm melee-based enemy now swarming the Dungeons of Xerith I knew that I needed a ranged enemy to support them from afar. This is where the redeye enemy type came into play. The redeye were the sentry archetype enemy within the Dungeons of Xerith. This means that they wouldn't move, but would shoot at anything within their range.
For the redeyes they would fling fireballs from their dead red eyes towards the player. Since they couldn't move to avoid a player's rush I needed to add methods for the redeyes to fend off any player's attack. Thus I made the redeyes' fireball very painful for the player to get hit by. Yet, this didn't feel like enough for most players would just easily dodge the shot over and over until the closed in to finish the fight. Well, lets make the shot more difficult to dodge then.
To accomplish this there were four different options, make the shot bigger, make it faster, make the redeye shoot more than one fireball at once, or make the redeye just shoot faster. I couldn't make the shot much larger for if I did I would have to redesign all of the maps to allow for this change and I didn't have time to implement such time consuming updates. Ok what other options do we have? Well we could make the redeye shoot more than one shot such as a triple shot in a trident formation?
This also wouldn't work for the same reasons as the increasing the size of the shot for it would cover too much area and make it too hard for the player to avoid. Down to two options then, make the shots faster and increase the rate of fire of the redeye. Alright lets try making the shot faster first just to see how players react. Of course I have to be careful with this and not make the shot so quick that it pretty much auto hits the player.
After watching a couple of testers it appears that making the shot faster worked for the player's hard to work harder to avoid the redeyes fireball barrages. Yet, at time testers said they felt it was a little too quick. Alright I can work with that, what if I make the shots a little slower, but increase the rate of fire of the redeyes by a factor of 1/2 or increase the rate of fire from one to one point five. For the most part testers stated these changes worked for the most part, but felt as if they almost needed to take damage in order to kill a redeye. Yet, I had to put this issue on the back burner for the time being for I still had three enemies to design.
Those three remaining enemies fell under the trap enemy archetype. Going into design of the first of these three different enemies I knew I wanted to make a enemy class that was focused more on ensnaring the player instead of directly damaging them.
This is where the basic mimicker came into play. I might have draw the mimicker to look like mimics in other games, but that was more to add a visual warning to the player of what they might encounter. Although most players know what a mimic looks like and in my drawing I made it quite obvious. Yet how do I lure the player over to the beast? Well everyone likes money, so lets try that.
Thus I began placing "free" golden coins in front of the mimickers. These coins acted as the perfect bait for more greedy players and once they took a single coin, the trap was sprung. From there the mimicker would catapult itself towards the player hoping to trap them within its jaws. If the mimicker was able to catch the player, they ensnared the player and thus stopped them from moving. While trapped the mimicker would wait for other dangerous beasts of the dungeon to finish the player off. Yet, it felt unfair if the player was just stuck their at the mercy of an angry box. With this in mind, I thought it would be for the best if the player was able to kill the mimic from within its jaws. For if they were able to fell the beast, they will be released from its deadly grip and free to continue venturing forth.
With the design of the basic mimicker done, I thought it would be interesting if I created a more dangerous class of mimicker., the shadow mimicker. Yet, what could I added too increase to make the shadow mimicker more deadly than its basic counterpart?
Well, the basic mimicker couldn't damage the player once they were caught. So lets start there and add a damage affect while the player is trapped within the jaws of a shadow mimicker. This is nice, but some extra damage didn't feel like quite enough, why not add some other feature that made the shadow mimickers more deadly. What if I made them faster and thus harder to escape from?
This worked well, but I had to be careful that I didn't make it impossible for the player to dodge the shadow mimicker. Now that I had added the extra danger, how should I reward the player for killing such a monster? This got me thinking, why not add a key drop? For adding this key drop it would give the players a choice, either fight the deadly shadow mimic and be able to skip certain areas of a level or follow the normal path. With this added element of player choice the design of the shadow mimicker came end, but one enemy remained to be created, one last mimicker variant.
This last variant was heart mimic for I thought it might be interesting to go back to the roots of mimics. Instead of acting like a chest full of loot, the heart mimics would act like the life line that keeps the player going, heart pickups. Yet, a problem was created with this desire to create such an enemy.
This problem was that it broke players' trust much like the mimics of old did to those who first encountered them. What I mean by this is that when designing a game you have to take into account certain accepted design and visual norms aka symbols. In this case when a player sees a heart pickup they see a chance to regain lost health, not a dangerous enemy waiting to kill them. Thus I had to make sure not to fully break that trust.
I did this by creating three different states of the heart mimic: sleeping, alert, and attacking each of which are represented by a different enemy sprite. When a the player gets within a certain range of heart mimic it goes from its sleeping state to its alert state. This is visually represented by a more colorful sprite as seen in the image below. If the player spots this and backs off, the heart mimic will return to its sleep state. Yet, if the player keeps pushing forward, the heart mimic will fully wake up and switch to its attack state, which is represented by another sprite change. While in this state the heart mimic will not stop chasing the player until it or the player is dead. If the player is able to kill the beast I felt that it was only right to reward them with a heart pickup for breaking their trust.
Combat Design
Now that my dungeon was crawling with lethal creatures how would I have the player combat them? Well, combat within Escape Xerith Dungeon was broken down into a couple different sections. The first section was the player summoning their magic blade to deal death to the residents of the dungeon. The player through use of the "I," "J," "K," and "L" keys could summon their sword to on all sides depending on what button they pressed. The main reason behind this design decision was how the Cryspirs and mimickers where designed and acted.
Due to this monsters ability to pass through walls I thought it was only fair that the player could fend off these creatures no matter what angle they came from.
Thus at the time the best way that I found to accomplish this was to use the I,J,K, and L buttons to summon the sword, north of the player (I key), west of the player (J key), south of the player (K key), and east of the player (L key).
Furthermore, given that I was working on this solo with only a couple of weeks I didn't have time to learn and create fully animated attacks for each direction and thus another reason I went with this method of player attack.
From the player dealing damage we move to them taking damage. Like many games, the player has a set health pool represented by heart sprites in the upper left corner.
Designing this was a simpler process than the attack design process for it was mainly down to balancing damage numbers of the enemy. Furthermore, it also entailed the tweaking of damage wait times for the melee-based enemies so they didn't just drain the player's health instantly upon first contact.
Enemy Drop Design
With all of the enemies designs and how the player could slay them out of the way I wanted to reward the player in some manner for killing them, rather than just running past. Thus I decided to add in a item drop system. Due to my experience at this point in time it was rather rudimentary, but it still functioned as I desired it would. How this system worked is that I attached certain drops to enemies based on their difficulty via their respective health and how dangerous they were to the player.
The less dangerous enemies dropped gold coins, which were worth one point each.
Thus I decided to add in a item drop system. Due to my experience at this point in time it was rather rudimentary, but it still functioned as I desired it would. How this system worked is that I attached certain drops to enemies based on their difficulty via their respective health and how dangerous they were to the player.
The less dangerous enemies dropped gold coins, which were worth one point each.
After designing the gold coins and adding them in, they felt cool and all, but I thought it would be interesting if I added another layer onto the drops. This is where the next tier of coins come into play, blood coins. Blood coins where different from their golden counter parts in that they gave five points instead of one and they restored a small portion of health to the player. If I am being honest, I didn't just add them for another feature related to the coins. I also added them as a balancing measure for the redeye enemy type.
For I noticed that testers would almost always take some damage from the redeyes unless they were rather skilled. Thus I decided it was only fair to give them a little health bonus after slaying one.
Not wanting to overdo the coins for I only had a couple of weeks to work on this solo, the next two coins only gave extra points. Yet, in order to get these coins the player had to kill mimickers and that was always a challenge.
Overall the design process behind the drops wasn't all to complicated, for as stated above, I did it to add more content into the game and reward players for slaying the monsters of the Xerith Dungeon.
Level Creation and Flow
Finally with all the base aspects of the game done, I could finally start crafting the levels with the Xerith Dungeon. For this process I created a base flow of how each level should function. The first couple levels would be to introduce enemy types and teach the player the basic gameplay features within the game. Whereas the later levels would act as skill tests for the player to see if they had learned an AI behavior or how good their were at dodging/attacking. With this baseline constructed I began the tutorial level.
The most important aspect the of the tutorial was that it taught the player different interactions through visual representation and not just text on the screen. This was accomplished through the use of a trigger points that forced the player to watch an interaction before being able to continue through the tutorial. Sadly not all aspects could be shown visually such as the basic movement, but for the most part all other interactions were purely visual.
Now with the tutorial finished, I needed to figure out how many levels I wanted to make, but also had the time to test, update, and perfect. I first started the idea of making 18 levels given that it didn't take me all that long to grey box out a level. Yet, as time went own it went down and down until eventually landing at nine excluding the tutorial level that I had time to "perfect," which wasn't to bad of a number. From there I began segmenting out what levels would be the intro levels or the ones used for teaching the player. What levels would be the intermediate levels, testing the players knowledge with some extra layer of difficulty. Then finally what levels would be the more difficult levels essentially acting as the final skill test for the player. Since I had nine levels this three stage difficulty layer worked out quite well.
Yet, instead of breaking them into three levels each I wanted to give the player a little more time to learn before truly challenging them. This means that the first difficulty tier would have four levels, the second would have two levels, and the last difficulty tier would have three levels. Now with the basic overall level structure and how the difficulty would increase after a set amount of levels, I needed to start placing the created levels into these nine level slots.
For the first four levels I wanted the player to be moving left to right for the first two levels, given that most of my testers where American this would feel more natural to them and thus would ease them into the game. Next I wanted these levels to have more rooms for the player to move into to hopefully avoid triggering more enemies than they could handle at their current skill level. This was also done so the player could get into the grove of exploring the dungeon and looking for keys to escape. Thus by having all of these different rooms and locked doors its forced the player to learn and master this little game of find-a-key.
All of this was good for the first four levels, but I also wanted to make sure the more experienced players didn't get bored of these levels. Therefore I added in optional enemies for the player to fight if they wanted a little extra reward and challenge. To add onto this the first couple of levels generally had more health pickups than the later ones to help the player out a little bit more if they needed it. Lastly, the final level out of the four levels has the player spawning the in the middle of the room. This was done to prepare the player for stranger level layouts in the later stages of the game as well as get them used to different spawn locations rather than always being spawned on the left or right side of the screen.
With the first four levels out of the way, it was time to increase the difficulty a little more and test the players' skills. This was done in a couple of different manners, ranging from the structure and flow of these rooms, enemy placements within these rooms, and the decreasing amount of health pickups. Adding more enemies is nice in all, but it feels like a fake difficulty increase. Thus to avoid just adding more enemies, what if I structured the levels to make the enemies that are there more effective and thus deadlier? With this in mind, I began building levels with chokepoints not for the player to use against the AI, but for the AI to funnel the player into kill boxes. From there I made the rooms smaller and thus harder to maneuver in making avoiding smarms of Cryspirs and redeye fireballs more strenuous task to complete.
Alright now we got smaller rooms and chokepoints, what else can I change in the level structure to make it more difficult? Well, I could make getting the keys more difficult through enemy placement. I could then further this by making the doors harder to access as well. All of this then flowed amazingly into the enemy placement within these rooms for the rooms themselves were structured around a set enemy placement. Lastly, with the structure and enemy placements done, I made sure to decrease the amount of free health pickups as well as making them more heavily guarded. All of these small, but impactful changes appeared to work well in tandem given most players felt as if the game's difficult jumped when they went from level four to level five.
After completing level five and six, the player entered of level seven, this is where the real challenge for the player really began (even for me, cause this level killed me all the time). For the final three levels I took what I did in the two intermediate levels, but turned it up a notch. For enemy placement I made redeyes more difficult to get to for they were now protected by a swarm of Cryspirs. Basic mimickers for the most part were replaced by shadow mimickers. Mimickers now worked more together and thus the player would have to deal with more than one at a time. At this point in time, I also realized that I still hadn't employed my heart mimic.
Thus to fix this I started placing those around the map to ambush unsuspecting players. For level structure, I made rooms even smaller and thus even more difficult to move around in. From there I created small points in the map made for enemies to ambush the player. Lastly, not only did I reduce the number of health pickups, I also had them guarded more heavily and placed behind locked doors. The only way to open these doors and still have enough keys to escape was to kill the shadow mimickers lurking in the level. All of these changes most definitely increased the difficulty for only the most skilled players were able to get past these three hellish levels, I myself also sometimes fell victim to these levels, but hey this was all in their design.