Artist’s Statement
Cavern Crafters: Homebound, is a whimsical puzzle-based RPG designed to rekindle the joy of adventures and exploration in players of all ages. In this lighthearted game, players are immersed in a vibrant underground world, where they must find their way home by completing puzzles and collecting items. Through this game, we combine traditional elements of RPGs with engaging puzzles to create a gameplay experience interwoven with the game’s narrative.
Our goal with this game was to build an exciting and magical world, where players directly interact with characters and aspects of the environment, and are brought closer to their goal with each puzzle and item collection. Through intuitive gameplay, carefully designed puzzles, and whimsical visuals, this game was intentionally designed for players to enjoy the sense of challenge in solving puzzles, whose difficulty increases as the game progresses. We want our players to tap into their love of exploration by navigating the rooms of the underground cave, immersing themselves fully through both visual and auditory ambiance. Through the narrative woven into the game’s mechanics, we wanted players to feel a sense of accomplishment as they complete their item collection tasks and navigate through puzzles, with the help of characters like Squeaks and Whiskers to find their way home.
Consequently, Cavern Crafters: Homebound, employs the thrill of exploration coupled with the satisfaction of solving puzzles to contribute to a grander narrative. This game serves as a means for players to dive into a new and mystical world, where each new discovery fuels the excitement of finding one’s way home.
Model
Above is the model of our game system. When players begin the game, they are presented with a start menu. After clicking “Start Game”, there is a cut scene, where the player is familiarized with the world. They find out that they are lost far from home in a mouse village.
After speaking with the mouse, named Squeaks, through pressing “Q” and entering our dialogue system, the player finds out that they can obtain an enchanted compass and “flying contraption” by exploring the cave levels, solving the puzzles, and obtaining all of the resources they need. At this time, there is a text layer at the bottom of the screen signaling to the player that the resources they need are 15 stones, 10 steel, 5 gems, and the lost “flying contraption” parts.
After this, the players are free to explore the level, which includes some obstacles and a maze-like experience. During their exploration, they mine resources by pressing “E” and collect them into their inventory. When a resource is mined, the text layer updates to show their progress towards their objective. There may be boulders that the players must push out of the way to reach certain resources.
At the end of the last level, they interact with another mouse, Whiskers, who congratulates the player and wishes them luck on their journey. Finally, a cut scene plays where the player turns in their resources and obtains an enchanted compass. Then they build the “flying contraption” and fly away. This is where the game ends.
Initial decisions about formal elements and values of your game
Original Concept
Initially, we wanted to incorporate a magic-based, rogue-like, dungeon crawler experience, where they would need to choose the right combination of elemental spells to maximize the effectiveness of their attack strategy, introducing a spell choice and boss special move dynamic to the gameplay. Our gameplay will primarily have a 2D overhead perspective. This game is intended for players ages 8+. It would offer a player v. game mechanic. We envision people from all backgrounds to be able to immerse themselves in our fantasy world. Players who naturally have an interest in fantasy, folklore, role-playing, and dungeon crawling will probably be among the most ecstatic to try our game.
Our first iterations of our game included a larger map that had three main village/dungeon locations: 1) a mouse village with a cave dungeon, 2) a beaver village with a water dungeon, and 3) a bear village with a forest dungeon. A summarized outline of the dungeons, villages, and bosses can be found here. Each location in our world would have an accompanying village. Every village would have an accompanying dungeon. Each dungeon would have multiple rooms with mineable materials that the player would need to collect before entering a puzzle room that would precede a concluding boss fight level. As they crawl from room to room in the dungeon, looking for these materials, the player’s ears are aurally pleasured by the calming, adventurous background music that helps build a sensation and discovery aesthetic. Each boss fight rewards the player with one of the three key items they need to beat the main objective of the game: build a hot-air balloon to return back home. Overall, we are attempting to satisfy the following aesthetics: sensation, fantasy, narrative, challenge, discovery, and submission. A more detailed outline of our original world building vision can be found here.
The first key item, coal, would be the fuel source for the fire that powers the hot-air balloon which can be found inside the cave dungeon next to a mouse village with villagers that are friendly to the player. The mouse village with anthropomorphic mouse NPCs that offer the player with expositional dialogue help sustain a narrative aesthetic. The cave dungeon levels would have an earth-based elemental theme. We intended on having a mining mechanic that would satisfy the submission aesthetic for players that might enjoy farming resources that can be found inside a cave, like stones, iron, and diamonds. Before entering the boss room in the dungeon, the player would need to solve a rock-pushing puzzle that would open a clear path to the room. The rock-pushing obstacle course builds a challenge aesthetic for players to interact with, changing the type of fun to help avoid the game from feeling too repetitive.
In order to obtain the coal, the player must slain a giant rock monster that is blocking the exit of the cave dungeon. The magical creature, alongside the spells that our hero uses to defeat it, help construct a fantasy aesthetic. The player would need to take advantage of the character movement mechanics to evade incoming rock attack projectiles from the giant rock boss. Concurrently, the player would need to dynamically refine their mouse movement and click timing to successfully land their spell projectile attacks on their enemy while staying alive. The player would optimally choose the correct magic school to maximize their spell’s damage against the rock monster. Our intended magic system can be found here. They would have had the freedom to choose any magic spell type, allowing them agency in what strategy they choose to attempt to maintain a role-playing, real-time 2D projectile-based combat experience.
The second key item, a large clam shell, would serve as a substitute for a basket in a hot-air balloon which is consistent with its discovery location, a large river next to a beaver colony that has been terrorized by a local serpent monster. Our hero agrees to eliminate the serpent monster in exchange for the large clam shell that the beavers offered as a reward. The beaver village with anthropomorphic beaver NPCs that offer the player with expositional dialogue help sustain a narrative aesthetic. The water dungeon levels would have a water elemental theme. We intended on having a mining mechanic that would satisfy the submission aesthetic for players that might enjoy farming resources that can be found inside a river, like shells and fish. To differentiate the puzzle level from the previous one, our hero would need to place beaver dams to drain the river and reveal the serpent’s location. Similarly, the player would use the movement and attack mechanics to dynamically adjust their keyboard and mouse inputs in real time, according to their own strategy to survive and defeat the boss. To help differentiate the boss, the serpent would have a “wall of fire” attack that had a large area of effect. Again, the type of magic spell is in the control of the player, allowing them to fulfill the role-playing combat experience of a rogue character crawling through dungeons to defeat a boss in order to obtain a key item necessary to complete the main objective of the game. Our intended magic system can be found here.
The third key item, strong vines, would be obtained by defeating the ent boss that lives in a mystical forest and is guarding a spellbook with a legendary flying spell next to a village inhabited by friendly bears. The bear village with anthropomorphic bear NPCs that offer the player with expositional dialogue help sustain a narrative aesthetic. The forest dungeon levels would have a wood/earth elemental theme. We intended on having a foraging mechanic that would satisfy the submission aesthetic for players that might enjoy farming resources that can be found inside a forest, like wood and honey. To differentiate the puzzle level from the previous one, our hero would need to navigate a complex maze with many false exits to reach the ent’s location in the forest. To help differentiate the boss attack mechanics, the ent would have the ability to occasionally shoot roots up from the ground in a random pattern in addition to its default fire-based projectile attack. This puts emphasis on the character movement mechanics to help increase the chances of survival as they dodge a new obstacle course every time the boss uses that special move, contributing to a challenge aesthetic. Our intended magic system can be found here.
Moreover, we planned on having hostile mobs randomly spawn throughout the dungeon rooms to slow the player down on their material harvesting quest. These mobs would have had the capability to “kill” the player which would make them drop all their inventory, making them have to either: A) restart their collection attempt from zero; or B) quickly pick up their inventory at their death location to resume their progress.
In the case that we would have pursued option A, we were planning on incorporating “save points” at the beginning of each new level so that they could save their progress, and not become overly frustrated and stop playing the game because they no longer are having fun. To stay consistent with the magical lore of our game’s narrative, we were thinking of using elementally-consistent waystones that would summon the player at the latest “save point” alongside their last saved inventory, health, and location. This saving system was inspired by the campfire saving mechanic in the Dark Souls series by FromSoftware. Since each dungeon level would have an elemental theme, dependent on its location, the waystones would be made of different colors, materials, and particle effects. This would help build a mystical, expansive atmosphere that would reinforce the role-playing aesthetic as the player freely explores the dungeon levels at the pacing of their choosing, fast or slow, enabled by this saving mechanic.
In the case that we would have pursued option B, we were planning on incorporating a collectible “tombstone” that the player would walk over and recover the inventory they dropped where and when they died.
Overall, the player will have the following goals: outwit, solution, exploration, construction, and escape. The objective is non zero-sum.
However, due to time constraints, we decided to focus on creating an MVP of our game, dedicating our energy to improving the puzzles and having to cut our boss combat system. Instead of having multiple village locations, we focused our efforts on refining the narrative at Squeaky Cavern, a cave dungeon that neighbors the mouse village.
Minimum Viable Product (MVP)
The combination of immovable and moveable objects in the map provide the player with a navigation conflict that they must resolve to make it to the next puzzle level and acquire the next key item to reach the main goal of the game: build a hot air balloon to return back home after getting lost and finding an anthropomorphic mouse village. The immovable crystals, rocks, and water bodies found throughout the dungeons all block the player’s path so that they must plan their movements akin to a maze to be able to mine collectible items or hidden keys that are required to unlock the next puzzle rooms. This design decision contributes to a challenge, submission, and discovery aesthetic. We decided to keep the background music to help build ambience, mood, and pacing that grant a sensation aesthetic. Each new dungeon level in squeaky cavern has a distinct style theme, layout, and secondary objectives (i.e., collecting a key in a hidden room before unlocking a puzzle level) which helps construct a discovery aesthetic as they explore every hidden room and a sensation aesthetic as they visually indulge in our 8-bit retro artstyle. Overall, we attempted to build the following aesthetics in our MVP: sensation, fantasy, narrative, challenge, discovery, and submission.
Testing and iteration history
Initial Puzzle Prototypes
For our puzzles, we knew that we wanted to do something that would tie in well with the cave theme of our game. We were inspired by rock-themed puzzles in some other games we’ve played before, like the boulder puzzles from Pokemon Ruby/Sapphire. We decided to go with the idea of a boulder-pushing puzzle, where players have to push boulders to the correct targets in order to proceed to the next level in the cavern. We thought this would also be a good way to monitor the degree of difficulty between levels, because we could easily make a puzzle harder or easier by adding/removing boulders and barriers.
For our initial prototypes, we implemented a Python script where players could run the puzzles through the Terminal and use arrow keys to move boulders around on a 12×7 grid. We wanted to see whether this kind of puzzle felt intuitive and challenging while still being fun. Since a puzzle like this requires clever maneuvering of both objects and the player, players will likely run into roadblocks and have to restart a couple of times before figuring out the path. This might feel frustrating for players, so we wanted to see whether the puzzles felt too frustrating or if they were a fun kind of frustrating. The Python rendering was a simple way for us to test just the core mechanics, which were the player maneuvering and player pushing around objects. If these mechanics weren’t intuitive with a simple grid layout, then they likely wouldn’t be intuitive in our rendered game either.
We had three puzzles total, an easy, medium, and hard one. When playtesting, we were particularly looking for how long each puzzle took and whether they felt challenging without being too frustrating. Players used arrow keys to move and could press “r” to reset the puzzle and “z” to undo one step. For our first playtest, we had three different people test the three different puzzles, because we were trying to get as many perspectives as possible.
We found that the third puzzle took significantly longer, around 9-10 minutes, whereas the first two only took between 3-5 minutes each. When we asked our playtester about the difficulty level of the third puzzle, she mentioned how although the puzzle was hard, if she had gone through the first and second puzzles and become more acclimated to the strategies and techniques as the puzzles built up in difficulty, then she probably would have had an easier time. This indicated to us that we should allow our playtesters to experience all three puzzles in order, instead of giving them one isolated puzzle. In addition, we also started to think about how we could familiarize players with the puzzle mechanics, such as the boulder-pushing, throughout the game so that when they encounter the puzzles they’re already somewhat familiar with the mechanics.
Playtest for puzzles 1 and 2
Playtest for puzzle 3
For our last couple of playtests with this prototype, we decided to focus on taking one player through all three puzzles to see whether learning from the first couple of puzzles would help with the difficulty level of the third one. From these playtests, our players did express that although the last puzzle was challenging, it didn’t feel too difficult because going through the first two helped them think about strategies better.
In-Game Puzzle Prototypes
Since most of our playtesters seemed satisfied with the experience and difficulty levels of our puzzles, we wanted to playtest how the puzzles would feel in our actual game environment. We started with some initial rendering of our puzzles using Godot 4, and wanted to get player feedback on whether the player movement and mechanics were intuitive in the context of the puzzles. We also wanted to see whether the level of challenge would change since the grid-layout wouldn’t be visible and there would be more visual stimulation, which could affect the experience.
Generally, the overall player movement seemed intuitive, but there was more confusion when it came to what spaces the player could fit inside and how to maneuver the boulder around, because they weren’t snapping to each pixel anymore. There were times when a player expected that they could fit in between the boulder and a rock, only to be blocked by the collision shapes (see below video 0:13). I think this caused some unintended frustration, and was a signal for us to match the collisions more closely to the visuals so that players aren’t getting confused. Out of three playtests, two players said the difficulty curve felt reasonable and one player mentioned that the third puzzle seemed a little too hard compared to the other two. I think this sentiment may have been due to the fact that there were many times in her playtest where this issue of the collisions came up, and she had to restart in order to proceed, which made the puzzle feel more frustrating.
Moving forward, we wanted to see whether the experience of the difficulty curve would improve once we addressed the confusing collisions. In addition, thinking more holistically, we also wanted to think about how to introduce the players to some of the puzzle mechanics early so that when they encounter the actual puzzles, they already have an idea of what to do. Throwing new mechanics at them in the middle of the game might feel more frustrating and difficult since they have to learn new mechanics while also strategizing about the puzzle. This is why in our final prototype, we add some mini-puzzles in the level rooms where players learn to push boulders out of the way and navigate through barriers.
Snippet from playtest of Puzzle 3 rendered in our game
With improved collisions, we decided to playtest our puzzles again, this time including audio as well as an explanation of the narrative. We found that the difficulty curve of our puzzles improved and players expressed less frustration since the collisions now matched the visuals of the game better. Players also liked the audio and thought it fit well with the theme of the game. When it comes to the narrative, since we were explaining the narrative out loud and players didn’t get to see how the key items fit into the game, I think they were a little confused by the relevance of the story to the game. Moving forward, we wanted to make sure that the items and mechanics made sense to both the gameplay and the narrative, and that the purpose of the different items were motivated correctly.
Snippet of playtesting our game while explaining the narrative
See this drive for all videos from our playtesting.
Play Our Game
You can download the MVP of our game and play it through Godot 4 here:
https://sophiejin28.itch.io/cavern-crafter
Demonstration of experience
Our final playtest included most of the finished features of our game, including narrative structure with beginning and ending dialogue, an introductory cutscene, room decorations and mini-puzzles, resource collection, and audio. In this video, the game is in a mostly finished state except for a few things. We’re missing the final cutscene, which we merged afterwards. We also have some bugs in collisions because we updated our tilesets for the decorations/themes, which messed with them a bit.
