Cradle of the Rift is a 3D Action Roguelike where you play as a fairy as you fly through a forest, slashing and blasting your way through hordes of monsters to reach home.
Playable on Steam. Cradle of the Rift was my Capstone project for my senior year at the University of Utah. In teams of 15-16 students our goal was to select a reference game to use as a starting point in the development of our own game, which would take place over the next seven months. Our team consisted of six artists, six engineers, two producers, and two designers. Our selected reference game was Risk of Rain 2. We had decided on this game because we felt a roguelike was a genre that could be easily scaled or cut down due to our time restraints and inexperience working on a larger project with a larger team.
Goals
● Learn about working with a larger team
● Develop prototyping skills in Unity
● Develop an engaging Roguelike that has:
○ Swift and engaging combat
○ Contrasting builds centered around elemental
item systems
○ A balance of player choice and randomness
As one of only two designers on this team I got to work on all aspects of design for this project. I also did lots and lots of playtesting myself and watched many others playtest on this project. I discovered many issues that helped me iterate through gameplay systems and fix bugs. I think however that the most important issues I had noticed on this project were ones that lead to lack of player understanding or player feedback. The player being unaware of how our mechanics function, how our game works, and what their goals are. Many of the changes that I made were to give the player more feedback and more options to learn about how the game works. For example we introduced a menu that would allow for the player to see their items and their effects. We also introduced a tutorial level to show the player how their abilities worked along with a goals tab to show current objectives.
Player Design
Early on in this project our art team had decided that we would have a fantasy theme with a fairy as our first playable character. Knowing this I wanted to create a feel for the player that reflected three main pillars. A player system that felt light, agile, and engaging. We looked to our reference games for where to get started. I wanted to focus heavily on the mobility of the character to really drive the light and agile feeling. To start I developed a dash and a glide mechanic. These were the foundation of the player's mobility and kit, and while simple, I attempted to tune them to have a uniquely light feel for our fairy character.
After having implemented both of these I was still unsatisfied with the player's mobility and overall feel. I decided to add one more mobility tool to the player's kit. To do this I led a discussion with our group to suggest different ideas I had for the final ability. The discussion narrowed it down to three ideas: a simple boost jump, a more complex flight mode, and an omnidirectional dash. Working with one of our engineers I prototyped these three concepts. After testing them all I believed the flight mode contributed the most to the player feel I was looking for.
At this point it was time to dive into combat. We had made a basic bullet projectile placeholder to test with however; our playtests quickly revealed that with our game only having two basic enemies at the time, one of which was melee, players very easily stayed away from our enemies and hardly interacted with them. At the time we decided to continue down the path we were going and add a few more combat abilities. We hoped that having more options in combat would make the player more motivated to engage with the enemies.
During our next round of testing we had added an aoe surge ability that required the player to be much closer to the enemies. This ability could also be used during flight to try and make the whole kit feel more cohesive. We found that the same issue appeared. Players were still not interacting with our enemies. At this point I decided to pitch a large pivot to my team. I had planned out a pivot to a melee character. This would include swapping our primary attack with a melee swing, and moving our ranged projectile to an ability key with a cooldown. To really sell the change thematically I had suggested changing our fairy's staff to a magical spear. I believed this would make our gameplay more engaging as it would require the player to engage with the enemies directly. There were many adjustments to numbers after this change to help compensate and to solve other issues.
The final tool we added to our player's kit was the ability to change their weapon. Changing their weapon was done by finding altars around the map and paying XP or gold for a new weapon. The weapon would change a how your melee attack felt and how your ranged projectile functioned. This meant that each weapon had its own feel and style.
Level Design
I began working on the design of our first level very early on in this project. After taking a look at our reference games levels and fantasy reference for our games theme I had some ideas. My first sketch of the level was a outcropping on a cliff side that included three different biomes within the level. There was a forest, including a giant tree with large roots to traverse around, a river with a swamp area, and a cave area built into the cliff side. This became the layout of our first prototype level.
Quickly we noticed many issues with the layout during our first playtest. The main issues being that the map was too large and far too empty. It also lacked interest in art however that was an issue that would hopefully resolve itself farther down the line with more art assets. To hopefully resolve this issue I made the map smaller and attempted to make more interesting terrain through the use of some assets the art team had developed. This included putting rocks and trees throughout the map as well as creating paths across the river with lily pads and flowers.
We had discussed placing different items in each area and only giving the player enough time to explore a few areas. This would make the player have to choose which area they would like to explore, and in following attempts they could use the information of which items each area holds to inform their decisions. Due to this concept I want to make each area feel distinct; however, the areas needed to flow into each other. After talking with my art team we had come up with a slightly different layout that included four biomes. We decided to lean into the massive tree and utilize its large roots to break up the play area and create its own biome. This would hopefully decrease the repetitiveness of the map while also giving us more tools to break up and diversify the playable space.
During our next playtests the main concern we received from players was that the map had very little verticality. Our solution to this issue was to add more vertical play space in the level by using large mushrooms, rocks, and roots as well as adding an additional plateau area to the map. Other than that we also added in our altars which were biome specific. Each weapon had a different biome they were found in with random spawn locations in that biome. I was hoping that this would create a fun sense of exploration and reward while also helping each biome have its distinct feel and distinct rewards as we had hoped to have from the beginning. I also hoped this would make replays feel satisfying as a player could run to their favorite biome for their favorite weapon to quickly acquire their preferred playstyle.
The final part of level design that I did for this project was to develop a tutorial level which was a void in between portals with floating islands. Each island would teach you about a different mechanic in our game and once you had made it through all the islands you were placed into the main level of our game. The tutorial would automatically be played on first launch; however, not afterwards and could be accessed again in the main menu if you had forgotten anything and wanted to revisit.
Item and Upgrade Design
Since this project was going to be a roguelike we had decided to have chests and items to open throughout the map. We began with mainly having items that influenced the players basic stats because these were easy to prototype in bulk to fill out our item pool. Me and the other designer on our team had expressed wanting to make more interesting and unique items to add to our game. We had long discussions narrowing down how we wanted that to look, and after workshopping it and taking inspiration from other games in the genre, we decided we wanted to make an elemental item system with elemental effects and combinations. I thought that this would work best in an "Upgrade" system with more player choice that was parallel our item system. While items you unlocked through gold and chests on the map, upgrades you could unlock through XP gained by killing enemies and leveling up. You would then receive a choice between three different upgrade options that could be rerolled with gold.
Once this system was in place and our elemental upgrades had been put in we were very happy with how it had turned out however there were two main issues. First our players didn't understand how to access the upgrade system due to lack of player feedback for when an upgrade was available. Second, most of our upgrades made the base combat system irrelevant due to how much better the upgrades scaled.
To solve these issues first we made the system much more clear through feedback but also integrated this system into our tutorial level to explain it to our players on their first launch. Then to help with the scaling issue, we reformatted some of our upgrades to better align with our base move set and the combat we wanted to promote for our player. We did however want to let each different element of the system have its own identity and playstyle so that players could experiment and find their favorite combos and playstyles. We finally updated our item system to have items that synergized with our upgrade system. To do this however we had to first implement a system that would update the item pool for chests mid game so that the player would only get items that would effect the elements they currenlty had access to.
Enemy Design
For this project after our team had decided on starting with two basic enemies and building from there. We began with our basic slime enemy and our ranged flying wisp enemy. Our enemies would spawn in random locations around the players current location under multiple limitations based on how long the player had been in a run. The enemies stats and the amount of enemies available to spawn were affected by a multiplier based on how long the game had been going. Our two enemies were both rather simple and due to that I did a lot of work with number adjustment and balancing with base numbers and our enemy scaling system to try to make it still challenging enough.
Later on we updated our enemy spawner because our enemies were spawning out of the map and inside walls. We developed a spawner that used nodes that I could place around the map, designating optional spawn points. We also made it so that the enemies would spawn around the player in a halo rather than a circle to avoid enemies spawning directly on the player. Finally we added a system to despawn and respawn enemies that were too far from the player. During this phase we also introduced boss version of our two basic enemies. Our bosses had many more attack options from their very basic counterparts.
For the last stretch of our project we wanted to introduce a more interesting enemy that would be more challenging and imposing than our basic enemies. Our art team had really wanted to create a rock golem and we felt that it would be a good addition to our fantasy environment so I set designed a move set for our golem that mixed both ranged and melee attacks. To go along with the rock golem I also designed a boss version and we developed elemental variants of our slime and wisp that had different effects and stats making them unique threats.
Gameplay Design
At first our game loop consisted of fighting enemies to collect gold, using gold to open chests, getting items from chests to make you stronger, and trying to find and defeat the boss before the timer ran out. I quickly felt that the timer conflicted with the game feel and fantasy we were trying to create. We wanted our players to be able to explore our map and interact with our world while trying to grow stronger to continue competing with the enemies rising strength. However our timer created an opposite feeling of trying to finish the game as quickly as possible. This also created many unsatisfying moments where a player would be fighting a boss while the timer ran out and would lose. This was especially bad when we introduced a portal charge mechanic like our reference game. The player could kill the boss, and then have to wait to charge the portal, only for the timer to run out during charging and have the player lose their run. This was incredibly unsatisfying.
Immediately I knew the timer had to go. Along with the removal of the timer we implemented the XP system to go along with our upgrades, giving the player more things to stay in the map for and more reasons to want to continue fighting. However we were still having two main issues. First, players had little reason to actually explore the map. there was very little to find and actually interact with in the map leading to little motivation and reward for actually exploring. This was especially true because our upgrade system required no exploration. Second was people had very little understanding of their goal. Players quickly would find the teleporter and start it immediately without noticing what it was. Then either kill the boss and charge the portal and win very quickly after starting their run, or they would kill the boss and not understand why it spawned or that they need to charge the portal and they would leave without understanding their win condition.
To resolve these issues I thought first that we needed a quest tab and more player feedback for when the boss was spawning and when the portal was charging. This included both a boss HP bar and a portal charge meter to show charge progress. Also up until this point our boss spawn was automatic when the player approached it, now we made it an interactable for the player to start manually when within range. Giving the player the decision to start it I thought would create less confusion and allow for the player to better understand what was happening. To go along with these changes I also decided to have multiple portals throughout the map. I thought this decision would be good not only to help players explore more of our map but also since most roguelikes typically go through their loop multiple times I thought it would be good to have multiple teleporters. Since we only had our one larger level with multiple biomes, instead of multiple different levels to go to, I thought having portals in different biomes could lead to a unique yet similar feeling and allow for more exploration of our larger map. This way the player would also interact with multiple of our bosses in a single run. To ensure this happened when one boss was spawned in a run it was then removed from the boss pool for the remainder of the run. Along with these changes we added in our altars for our new weapons which added more reason to explore and interact with our world.