Caesura - Capstone Project
ROLE
Level Design
DESCRIPTION
This is the Capstone for my Masters degree at FIEA. It was made on a team of 18 people of various disciplines over the course of 8 months. I owned the middle level of the game and did all level design aspects, communicated with artist about assets needed, and blueprinted the level specific mechanics.
YEAR
2024
GENRE
Action Adventure
Engine
Unreal Engine 5
Video Playthrough
LEVEL DESIGN
Layout
For the layout, all the designers knew 3 things for me to start the layout, that it was going to be in the treetop of our giant tree in the game, that we wanted the platforms to have more of a city feel, and we wanted to use something in that environment that would be unique to it compared to the other levels. I struggled with the second objective for several iterations of the layout until I had a discussion with my Design Lead and Lead Level Designer about what makes a city. For me initially, it was nothing more than a cluster of buildings that have a similar look, but that was coming across more as a village. What we figured out through discussion was that a city is more about the density of buildings and the claustrophobic feeling a player gets from small paths with buildings lining the side. So for the final iteration of the layout, I included that as well as plazas so the player had some open areas to kind of explore. Another thing we wanted to do with the city is several smaller paths that reached the same place and interconnectivity between platforms. We ended cutting both for time, both to save time set dressing areas and because we didn't end up having a collectable system to incentivize more areas and exploration.​
Step 1: Beginning Capstone
I started out the Capstone period by gathering references on what we wanted the treetop level to look like in its initial conception. For the initial conception, I really liked the idea of an area like Kashyyyk where the platforms are on the branches and on the side of the tree. I also enjoyed the origin tree level in Star Wars Jedi: Fallen Order and wanted to use that for inspiration on small vista areas and the platforms themselves. For the buildings, our initial idea was more curved and natural looking buildings. As the city idea grew and developed, and time started to run out, that idea was abandon for more traditional looking buildings that were modular and could be used in more situations. For the windmill, we knew we wanted something that was not the traditional windmill, but we wanted to leave the look more up to the artist discretion so I found windmills that looked different than a normal windmill to try and emphasize that. The bottom group of images were images we found when the leads and I were discussing how the city should look and help me with the density of the buildings.
Reference Board
Step 2: Level Blockouts
The next part of the process was blocking out the level. The pictures shown below are from the second to last iteration of the blockout. The blockout process started by trying to fill platforms to get the right feel for the city. My first platform was too open and the platform itself was too small. After that feedback from my Lead Level Designer (LLD), I decided to expand the platforms from a diameter of 40 meters to 70 which felt a lot better, but the buildings were too spread out. After that iteration, my LLD decided to have me ignore the path and make a platform that had the right density and fit with the bottom images on my reference board. That platform fit the vibe we wanted and ended up being the first platform of my level.
Blueprint: Rotator
While I was doing that, I was also working on my functionality. I started the rotators pretty quickly since they were a big part of the traversal of my level. At first, I made it where the rotator would rotate based off a number inputted into a variable in the editor. I was worried about the rotator being inaccessible to the player if they rotated it the wrong way so I switched the rotation to be set values assigned in the editor into an array. This allowed the developer to choose if the player had access to the rotator when it rotated in different directions, but had the unfortunate side effect of making the rotation between the front and back of the array weird. So I just made it to where the rotator couldn't rotate that way and added a failed rotation event.
Rotator Working
Rotator Failed
Another problem that I encountered happened with the input detection on the paddle. Originally I had two separate triggers on the paddle (one on each side of the paddle) and I was setting which direction the paddle would rotate when the player entered the volume. I was running into the problem where the volumes wouldn't always register the player entering and leaving if they went from one trigger volume to the other. I decided to change it to one trigger volume and moved the rotation direction to the input detection function where I take the relative position of the paddle and the relative position of the player to determine the direction the rotator should rotate.
The last part of the wind rotator was having the paddle react to the wind. I started out with the paddle calling the rotation event if the trigger on the paddle collided with the wind zones. This was fine until the I switched the rotation to the array of rotations. I could just switch the indexes, but that allowed the paddle to jump where it would have ended up before heading to the right rotation. To fix this, I decided to get the current rotation of the actor and rotate from that to the index I needed. Another problem we encountered with the wind was that it would work when the rotator was moving, but not when it was still. To fix this, in the collision detection I had a branch where I checked if the current timeline was playing and if not, it would find the position of the wind like I did with the player earlier and run the rotation based off the player had used the input on that side.
Rotation From Both Sides
Rotation with Wind
Step 3: Finishing Functionality and Iteration
For the final iteration of the level, it was mainly fixing problems with feedback. The pictures shown below is the last iteration of the white box before moving to set dressing. One of the major changes that I made was mostly getting rid of the secondary paths. We realized that were was not any incentive for the player to take the second path and it was just confusing. Another thing I changed was how the rotators work. I realized that having the player walk through the wind when it can blow you away was immersion breaking and confusing. So what I did was change the rotator so that the windmill raises up above the rotator so that was not a problem. This also allowed me to create a different rotator without having to add art assets to my asset list.
Step 4: Set Dressing and Final Pathing
The final iteration of the project was set dressing and changing the final path to reduce some scope on the project. For set dressing, all the assets were made by our talented art team and put into the scene by me. The houses are made from a modular house pack that one of our environment artist made. For the final pathing, we needed the content for the level to be more condensed for scope and level play time. To do this, I moved the knots that had optional story material more onto the main path to where you pass the entrances as you progress through the level. This eliminated a platform that would have needed to be set dressed. Another thing I did was condensed the level between the arenas and the Caesura fight. To do this, I changed the ending to eliminate 2 platforms with a switch activated elevator which decreased the set dressing needed.
Lessons Learned:
The biggest lesson learned in this project was the perils of over scoping. We had our initial idea for our vertical slice, but we didn't like the feedback on it so we changed most of our initial idea, but kept the same game size. It wasn't until a couple months were left in the project that we started to realize that we had well over scoped the game and started to cut things where we could. My level initially had 3 arenas with puzzle areas and more content in between. This was then shortened into an arena with puzzles and content before and a scripted event that I did after the arena.
​
Another thing we didn't properly evaluate was how many assets would come from making 3 levels. We had amazing artist so luckily nothing had to get cut, but we made our asset lists way too late in the process. Some of this could have been mitigated with the use of asset packs, but our goal was to have everything in the project be made by someone on the team. To try to help mitigate this, I tried to cut off assets that were not strictly needed, like things that were more for the environment feel and not gameplay related.