Recursion
Unity - Gitlab - Jira
Embedded Files
Click here to check out the game's itch.io page!
Overview / Goals
Recursion is a FPS stealth game being created by a team of 10 with the assistance of 4 Bungie industry mentors in weekly meetings. Recursion is a semester long project to be completed by the end of April. For this project I worked as a level / technical designer.
The main gameplay loop of Recursion is the player explores the environment, sneaking past or killing enemies when necessary, collecting upgrades, and extracting with them, with the end goal of finding the boss and defeating him in the time limit. The game was inspired off of games like Dishonored, Deathloop and extraction shooters (partially because of our Marathon excitement).
Design pillars
Fair and fun FPS stealth
We wanted the stealth to feel good, meaning enemies felt fair in their behavior and detection, and there to be a good overall sense of cat-and-mouse. The player controller also needed to feel good, but not too powerful, to fit the style of the game.
A learnable time loop with Metroid-vania elements
The learnable time-loop was a strong priority for us, as we wanted players to be able to find a path through the loop through trial and error, eventually being able to utilize their tools to the fullest and speedily make it to the boss.
An environment built for stealth
A good stealth level is interactive with a lot of tools for the player to interact and play with. For us this meant breakable doors and vents to crawl through, shootable chains as distractions, energy pickups in hard to reach places,
Development process
My contributions to the project:
Player controller polish, tuning and additions like leaning/peeking, state based FOV changes, and sprint shake
Level design pieces like energy pickups to refill player energy, and customizable extraction prefabs for our new LD
Level design for the first 2/3 of the project
Designing gadgets to fix gameplay problems
General design documentation
Occasional general bug fixes when other programmers needed help with Enemies or abilities, and other random tasks where needed like setting up rag dolls for enemies and other small polish features
Foundational level design
While I don't usually take on the role of level designer, for the first half of the project I was the sole designer on the project so welcomed the challenge of creating an interesting level and experimenting to figure out what worked! This is worth talking about even as a TD as I believe it shows iterative capability and my understanding of the general design process.
Initial stage
I began by drawing out the map in Figma, initially planning on creating two floors, but started with one for now.
I went through three major initial iterations, with the first one being very large and more of a semi linear path to the goal, shaped more like a 3-lane Call of Duty map. However, I was met the feedback that the space would be difficult for the artists to fill, and set a larger space for me to fill out with enemy paths and unique rooms.
The other issue with the initial level is it felt like upgrades were sort of randomly placed around the level, as I was treating them more like hidden collectibles than intended upgrades. I fixed this by creating set loot rooms, indicated with golden lights. These had a bit more enemies, but more clearly communicated to the player where upgrades were.
The initial draw-out of the level
The initial much larger level
Second stage (week 2-3)
For this stage, I condensed the level down to smaller rooms and hallways. The feedback to this for this section was generally that the hallways could trap the player with an enemy as there wasn't enough cover. At this point, it was also generally hard for the player to gain environmental information without hurling themselves into dangerous situations, so this needed to be fixed in the future. However, this iteration helped reinforce loot rooms, as this was the main test feature for this level.
Third stage (week 3-4 onward)
For this third stage I focused on creating more connected rooms, and for the hallways I included they were a bit wider and taller, with more small props for player cover. I also centralized the spawn to make the map feel more expansive rather than linear to a point, ideally encouraging exploration.
This also allowed for a more scalable level, as we could always expand outwards, rather than having to rearrange in betweens in the previous layout.
This map also incorporated the first vent, which we received very positive feedback about, as it really contributed to our pillar of building the environment for stealth.
Solving problems and iterating!
The player "Kiting" enemies
The gun...
For the first few weeks of the project, the gun behaved as a cure-all to the players problems. They were able to move quickly enough that they could "kite" the enemies behind them like zombies and one shot them.
The problem here was that we wanted the gun to be strong as we were limiting the player's ammo, and they shouldn't be spamming their heavy revolver.
The first solution to this was slowing the player down a bit, which helped some, but would cause players to just shoot enemies before running through a room. So our next solution was to put the gun on a heat-cooldown system, where the player could only shoot ~2 shots before their gun was unusable for a bit.
However, what this caused was just a negative slow down in gameplay where it didn't fix the problem, just made it slower to do. Players still weren't getting the intended experience.
The gun... (cont)
The wonderful design fix here was taking inspiration from CoD and making the enemies only take damage in their head weak spots. We also ended up bringing back ammo instead of the overheat, as the overheat was too punishing when missing the head.
However, there was another issue that popped up here, as enemies were now a bit too hard to hit. Their animations had been created before we changed to headshots only, so the head's position bobbed around a lot, making the enemies relatively hard to hit in the head.
To fix this, we ended up bringing back body shots and just making them a 3 shot kill, really just making them a panic button if you get trapped with an enemy you can't shoot in the head.
The other great decision here (that I didn't come up with, but strongly supported when talking to the team) was making the gun and abilities all share the same energy or "mana" bar. This allowed for better readability for the amount left for abilities and ammo, and supported a breadth of play styles, as people could use whatever they liked best more frequently rather than be limited to a few uses of each.
The enemies in the game
Energy system, UI soon to be altered to simplify it
The player controller
For the first few weeks, the player controller was just too fast. I kept tuning it to be slower, but it didn't feel right until I made the dramatic change of cutting the player's speed in half.
After doing this, I remembered a talk about starting with strong changes like this to see the effect, but making this mistake has definitely implanted this in my head for the future.
This ended up fixing a slew of issues, like the player kiting enemies, running through the level without sneaking, and our general lack of stakes and intensity.
Peeking vs leaning
Early on, we realized we needed a way to gather information around corners, especially with how condensed our map was. Our initial fix to this was adding a lean similar to Rainbow Six Siege.
The main issue with this, however, is that players could peek out and snipe enemies with how the gun was set on the camera, paired with the fact that the gun didn't alert enemies to your position for a while, this was pretty broken.
The fix that we tested for this was adding peeking, where the player could hold a button to peek the camera out in their mouse direction. However, people found this unintuitive and slower to use.
In the end, we found the R6 leaning to be more fun and easier to use, and once we ended up getting in the system where enemies were detected to gun sounds it ended up feeling a lot less broken.
Sneaky verticality in the boss maze
Vents as viewpoints
Verticality and increasing level sneakiness
There was a period in development where we wanted two phases for our boss, where the first phase was a maze filled with enemies the player would have to navigate to reach the boss.
I ended up gray boxing two boss levels before we ended up scrapping the idea and just going with one phase for the boss, but in the maze level I had made, there were a few places players could gain verticality with jumping puzzles that led to some sneaky cut throughs. This was received very well by players, and we ended up taking some of this into the main level to help build that pillar of an environment made for sneaking.
We also added more vents to the environment, partially as shortcuts and safe routes, and partially as peepholes to help players gain more information about rooms they hadn't yet explored.
Abilities with utility
We wanted the tools to exist to fill issues in gameplay, so we created them with this in mind. The gadgets we implemented are:
Enemy swap; trade places with an enemy
allows for shortcuts in LD and sometimes a quick escape from a bad situation
Realm shift; think wraith from Apex Legends, the player becomes intangible and invisible for a short period, making the enemies lose track of them
a high-energy cost panic button for the player, allowing for a safe exit from dangerous situations
Remote explosive; a c4 explosive you can throw out, then detonate from anywhere.
Players can use it to break open doors and vents, damage enemies, and as a large sound to bait enemies to
The player using the enemy swap ability
More things I learned from the project!
Sometimes you get it right the first time, but other systems aren't working
There were a few previous mentions of this, like with the leaning and gun ammo, but I wanted to mention this as a key lesson learned, that it's alright to go back to previous iterations as they may work better for gameplay once you've changed other aspects of the game.
Effective time management and set internal playtesting
We had set meetings with Bungie every week on Wednesday, which after a few buggy builds we realized we needed more internal deadlines for features and building to be better prepared for these meetings.
Our solution to this was setting an internal feature due date of Monday, meaning we wanted to have all the new stuff in by then to internally test and bug fix before brining it to Bungie on Wednesday.
The importance of always having a build ready
This was something that heavily pushed by our Bungie mentors, as they wanted a build week 2. We pitched them our idea and expected a build of the game the next week. This was great for rapid prototyping as it made us have the core systems and loop in early, and we were able to build on the systems from there.
It also set the expectation of weekly updates, which helped us stay on track for our goals, and the next version of the game was almost always better than the last.
Page updated
Google Sites
Report abuse