SCORCHED KEEP
I solo developed Scorched Keep in two weeks as a submission to a game jam hosted on itch.io.
SUMMARY
DETAILS
Platform: PC Browser
Engine: Godot 3
Team Size: 1
Development Time: 2 weeks
The game jam's theme was "locked". You play as a prisoner brought to this fortress in the desert when you and your captors are attacked by a dragon. You break free of the cage, but your hands are still chained together, meaning you must find a way to escape the fortress while only able to hold one item at a time.
The game contains three levels of rooms to navigate in the Keep. Your goal is to find a way to escape, with an optional quest to explore the Keep further and learn why you were captured in the first place.
Platform: PC Browser
Engine: Godot 3
Team Size: 1
Development Time: 2 weeks
The game jam's theme was "locked". You play as a prisoner brought to this fortress in the desert when you and your captors are attacked by a dragon. You break free of the cage, but your hands are still chained together, meaning you must find a way to escape the fortress while only able to hold one item at a time.
The game contains three levels of rooms to navigate in the Keep. Your goal is to find a way to escape, with an optional quest to explore the Keep further and learn why you were captured in the first place.
Scorched Keep is the second game I ever made, yet it still appears in my portfolio. I am incredibly proud of my work for this game, and it is a giant leap from my very first game project that I completed merely a month before this one (If you're curious, you can find my first ever game here). Within the game jam's two week timeline, I simultaneously learned from the ground up how to script each system at the same time as implementing it.
About halfway through development, I was able to switch from referencing GDScript's documentation or tutorials with my questions and instead had the intuition to know where to begin implementing what I needed. By the end of this project, I truly felt like I had a grasp of how game engines function, which became invaluable when I began working with game teams later that year.
About halfway through development, I was able to switch from referencing GDScript's documentation or tutorials with my questions and instead had the intuition to know where to begin implementing what I needed. By the end of this project, I truly felt like I had a grasp of how game engines function, which became invaluable when I began working with game teams later that year.
DESIGN DETAILS
LEVEL DESIGN
There are four main areas to explore in the Keep. Most rooms contain either a story beat or a vital quest item for the player to find.
POSTMORTEM ON LEVEL DESIGN
Overall, I am proud of the amount of level content I was able to develop in such a short time. I was able to program all of the systems for scene transitions, item pickup, narrative discovery, locked rooms, and have time to populate many rooms with this content. I believe I was successful in creating the mini dungeon experience that I wanted it to be and providing the player with an interesting layout to explore and discover.
Looking back, my main criticism is that these areas are unnecessarily big. I wanted the Keep to feel vast, but I did not adjust the long hallways to the scale of the player in a way that makes them fun to walk through. A lot of the play time through this experience is spent walking through long empty hallways. There were better ways to invoke the feeling of being in a large space without making the player walk through long spaces, and in this case fun should've outweighed the goal of scale. This is especially pertinent in a game jam game, where players are looking to get through the experience quickly, enjoy it, and move on. This level design choice discourages any replay ability with multiple minutes of gameplay time spent just walking through the levels.
Each door is a scene transition, and it took a good chunk of my development time scripting the system to save room states so items would appear in the same place you left them across room transitions, chests would stay opened, etc. When uploading my build for the jam, every version that I tested in browser had a host of bugs that did not come up in engine, including a bug with this system where it would reload a completed state of the scene from one of my playthroughs instead of dynamically updating the save state during gameplay. I was unable to fix this before submitting to the jam.
The scene state saving worked perfectly in engine, and I have since tested an export build for Windows that also works. I had been reading that there were problems with Godot's export to browser given that it was still a relatively new engine, and with my subsequent testing I believe that it is in fact a problem with the export rather than my code itself. Still, it was disappointing to have a system that I worked so hard to perfect ultimately break the game in the build, and I wish I had thought to test a Windows build before submitting to the jam so any playtesters wouldn't experience these bugs.
Alternatively, if I had accounted for the weighty system that it would take to develop scene state saving, I could have saved a lot of development time by cutting scene transitions altogether. With four level the environment is quite large to take place all in one scene, but likely not large enough that it would lag the system. Doors opening and traversing staircases could easily have been handled with an animation and a shader to reveal one room at a time. There is no mechanical reason why each of these rooms needed to be their own scene, rendering the whole system unncessary.
Looking back, my main criticism is that these areas are unnecessarily big. I wanted the Keep to feel vast, but I did not adjust the long hallways to the scale of the player in a way that makes them fun to walk through. A lot of the play time through this experience is spent walking through long empty hallways. There were better ways to invoke the feeling of being in a large space without making the player walk through long spaces, and in this case fun should've outweighed the goal of scale. This is especially pertinent in a game jam game, where players are looking to get through the experience quickly, enjoy it, and move on. This level design choice discourages any replay ability with multiple minutes of gameplay time spent just walking through the levels.
Each door is a scene transition, and it took a good chunk of my development time scripting the system to save room states so items would appear in the same place you left them across room transitions, chests would stay opened, etc. When uploading my build for the jam, every version that I tested in browser had a host of bugs that did not come up in engine, including a bug with this system where it would reload a completed state of the scene from one of my playthroughs instead of dynamically updating the save state during gameplay. I was unable to fix this before submitting to the jam.
The scene state saving worked perfectly in engine, and I have since tested an export build for Windows that also works. I had been reading that there were problems with Godot's export to browser given that it was still a relatively new engine, and with my subsequent testing I believe that it is in fact a problem with the export rather than my code itself. Still, it was disappointing to have a system that I worked so hard to perfect ultimately break the game in the build, and I wish I had thought to test a Windows build before submitting to the jam so any playtesters wouldn't experience these bugs.
Alternatively, if I had accounted for the weighty system that it would take to develop scene state saving, I could have saved a lot of development time by cutting scene transitions altogether. With four level the environment is quite large to take place all in one scene, but likely not large enough that it would lag the system. Doors opening and traversing staircases could easily have been handled with an animation and a shader to reveal one room at a time. There is no mechanical reason why each of these rooms needed to be their own scene, rendering the whole system unncessary.
CONTENT DESIGN
There are three main challenges on your journey to escape the Keep.
SCRIPTING THE CHALLENGES IN GDSCRIPT (PYTHON)
Through implementing these puzzles, I learned quite a bit about game object designation to achieve specific functions. In Godot, this is handled with item "tags". While each key and each locked door was derived from the same parent behavior, each key type had to be individually tagged so that, for example, only the gold key could unlock the gold door.
Once I had learned the system, I had to adapt it in a variety of ways for each puzzle. In the gold key trapped room, the trap arrows only hurt the player if they aren't holding the shield. In the sapphire key puzzle, each platform needed to check if the orange, green, or purple item was on it, whether there were any other items on them, and whether all three of the necessary items were on all platforms, before the sapphire key would unlock. In the cage puzzle, each button had an individual correct rotation value that was required before the code was complete.
Once I had learned the system, I had to adapt it in a variety of ways for each puzzle. In the gold key trapped room, the trap arrows only hurt the player if they aren't holding the shield. In the sapphire key puzzle, each platform needed to check if the orange, green, or purple item was on it, whether there were any other items on them, and whether all three of the necessary items were on all platforms, before the sapphire key would unlock. In the cage puzzle, each button had an individual correct rotation value that was required before the code was complete.
CHALLENGE 1: THE GOLD KEY
The player comes upon a door with a gold lock.
Further down the hall is a long rectangular room. Walking through, the player will be battered with arrows from the walls. Several of the tiles on the ground are of a color slightly warmer than the color palette--those are the trapped tiles that trigger arrows to shoot when stepped on.
The player can avoid the trapped tiles to reach the end of the room, finding the chest with gold key. If the player explored the top level of the Keep and picked up the shield item, they will be protected from the arrows and won't take damage if they are holding it.
Further down the hall is a long rectangular room. Walking through, the player will be battered with arrows from the walls. Several of the tiles on the ground are of a color slightly warmer than the color palette--those are the trapped tiles that trigger arrows to shoot when stepped on.
The player can avoid the trapped tiles to reach the end of the room, finding the chest with gold key. If the player explored the top level of the Keep and picked up the shield item, they will be protected from the arrows and won't take damage if they are holding it.
CHALLENGE 2: THE SAPPHIRE KEY
The player comes upon a room with a sapphire lock.
Player enters a room with three gray platforms. The chest contains six items: a red heart, an orange flame, a yellow bolt, a green leaf, a blue droplet, and a purple breeze. On the wall is an image with three columns of red and yellow, yellow and blue, blue and red.
The player must place the items onto the platforms that represent each color pair combination: orange, green, and purple. After doing so, the sapphire key appears.
I adapted this puzzle from one I had used while running a Dungeons and Dragons game a couple years prior.
Player enters a room with three gray platforms. The chest contains six items: a red heart, an orange flame, a yellow bolt, a green leaf, a blue droplet, and a purple breeze. On the wall is an image with three columns of red and yellow, yellow and blue, blue and red.
The player must place the items onto the platforms that represent each color pair combination: orange, green, and purple. After doing so, the sapphire key appears.
I adapted this puzzle from one I had used while running a Dungeons and Dragons game a couple years prior.
CHALLENGE 3: FREE THE DRAGON
The player enters the dungeon and discovers a sleeping dragon behind bars. Dials beside the cage each have an arrow and can be spun at 90-degree increments, the right combination required to open the cage.
The correct combination can be found on the wall in the previous room. The player must remember the combination and turn the dials to the correct direction to open the dragon's cage.
After the semi-challenging puzzle for the sapphire key, I wanted this one to be more straightforward to propel the player through the ending. The various paintings on the walls throughout the fortress had always served a purpose. So when the player finds one that seemingly is just decoration, they remember it immediately when seeing the corresponding arrows in the next room. The buttons are the same shade of gray as the chain pull and the cage bars, showing that they link together and inputting the right combination will allow you to open the cage.
The correct combination can be found on the wall in the previous room. The player must remember the combination and turn the dials to the correct direction to open the dragon's cage.
After the semi-challenging puzzle for the sapphire key, I wanted this one to be more straightforward to propel the player through the ending. The various paintings on the walls throughout the fortress had always served a purpose. So when the player finds one that seemingly is just decoration, they remember it immediately when seeing the corresponding arrows in the next room. The buttons are the same shade of gray as the chain pull and the cage bars, showing that they link together and inputting the right combination will allow you to open the cage.
OPTIONAL QUEST: UNCOVER THE TRUTH
SCRIPTING THE NARRATIVE SYSTEM IN GDSCRIPT (PYTHON)
Like most of what I needed to implement for this project, this was my first time implementing a narrative system in a game. The method I settled on was to make each dialogue UI segment an instance that is created, plays, and then destroyed when complete. The lines of dialogue are variables designated by the trigger points, which can be collision boxes in the world or interactables.
I later used what I learned from this project to script a similar system for the narrative in my Unity game made with three other developers, Memory.
I later used what I learned from this project to script a similar system for the narrative in my Unity game made with three other developers, Memory.
TURRET
MAP ROOM
LIBRARY