Level design
Plan
When beginning level design, each room was sketched out. As mentioned in the design, each room will attempt to feel unique and lived in and actively part of the world. Such with in the case of Figure 1, where the location inhabited by exclusively Screecher enemies (based on an invasive plant species) is overgrown, and instead of featuring pools and streams of lava as the environmental hazard, its poison, further linking it to the enemies populating the room. Similar design is used for other creatures, such as rooms focusing more on the Felled enemy being smaller, furthering the impact of the enemy, seen in Figure 2. Or having the Eye enemies be in larger room with more verticality, bringing out their unique ranged abilities, Seen in Figure 3. Having this clear plan for the levels will allow a more streamlined process of creating the levels, as focus will be spent on learning Unitys Pro Building and blocking out the rooms, apposed to attempting to design and create the levels simultaneously.
Figure 1 - Level design sketches
Figure 2 - Level design sketches
Figure 3 - Level design sketches
Many level design elements will require unique visuals, especially some reoccurring ones, such as pillars, debris or various scaffolding. And whilst the visual and audio overall is planned for later in development, some time will be spent to creating common visuals or mapping textures. Whilst blocking out levels with simple shapes is important to ensuring no development time isn’t wasted furthering elements that may be scraped or go unused later (Yang, 2019), doing simple texture mapping will ensure the possibility of further texturing after the level is designed and confirming the ability to do so, especially with the unfamiliar Unity Pro Builder.
Between Room pathfinding
When developing the first few levels, and issue was faced where enemies were unable to leave their room due to the nav-meshes needing to bake when the doors are shut, this ensures the enemies can’t just walk through the door but also lead to the aforementioned bug, seen in Figure 4. For part of level creation, it was ignored and treated as a feature. However, this led to being able to stand in the hallway and fire at the enemies who can’t approach you, making two of the three enemies redundant. So it was made a priority to fix, especially due to the encroaching planned play-testing. Since you can't bake a NavMesh during runtime, the initial idea was to attach a NavMesh Volume to the open door, activating on the door opening and allowing the Agents to walk on any Surface in that volume. Unfortunately, this did not work, even after a few hours of debugging, since NavMesh Volumes are also declared exclusively at the start of runtime. Alternatively, a NavMesh Link component was used, which was activated and deactivated in a similar fashion, with it working this time. Unfortunately, this occasionally leads to the enemies moving between rooms in a very unnatural way, Seen in Figure 5, and requiring a copy of each NavMash Link for each enemy. This solution was used for a majority of the early development, thought after consideration, it was swapped to have the shut door unutilised NavMesh Obstacles. The entire NavMesh would be baked with the doors open and using the obstical to prevent enemies walking through. To save time manually opening and closing doors any time the NavMesh needed to be re-bakes, the doors were left open in the scene, with a script shutting each door at runtime, Seen in Figure 6.
Figure 4 - Issue faced with NavMesh agents (NavMesh Surface visualized in blue )
Figure 5 - Example of level design and NavMesh Link's
Figure 6 - Code that shuts all door at runtime
Multiple Paths
Figure 7 - Video of the multiple door options
As shown in Figure 7, one room in the level provides the player with diverting paths, and interacting with one door will open it whilst locking the others. In the spirit of many personal development goals, despite the system only being specific to this one room, it was coded to be adaptable and dynamic, working with as many doors as are set. See Figure 8 for an explanation of the systems and code.
Figure 8 - Explanation of code behind the multiple doors (With commentary)
ooops... Added a boss
As the title implies, a slight side quest was embarked on. As seen in Figure 9, there had been a vague idea of a boss-type enemy that would act as a turret stationed in the middle of the room with a large amount of health. However, when making a rudimentary version of this, it didn’t impose much of a threat, as clearing the room of the enemies would leave players strafing in and out of cover and avoiding all challenges until the boss was defeated. To up the stakes and make the final boss more fun and challenging, from the volley of bullets the boss shoots at you, one bullet will spawn an enemy on impact. Since this would mean creating another bullet type instead of cloning the entire code, an abstract projectile class was created, handling all functions of shooting towards the player and the stats of the bullets. This allowed for multiple bullets with unique functionality to be made, in this case, of spawning enemies, without creating repeats of the same projectile script. One issue with the new enemies is assigning the door, to require the newly created enemies to be defeated before advancing. It would’ve been nicer to find a more elegant solution to this problem; however, due to the fast-approaching planned playtesting, a rougher solution was implemented for the time being. If the “Assigned Door” field is null (Empty), which will be the case when creating a new enemy, the enemy will be assigned to the final door. Whilst this system works, it can only be applied in this one case and doesn’t allow for multiple cases. As mentioned, there isn’t much time left to fix it, though if there is spare time during the end of development, a solution will be investigated. Regardless, see Figure 10 for a look at the final boss.
Figure 9 - Early sketches of final room
Figure 10 - Demonstration of the final boss turret
The level
So, with all that being said, what better way to show you the level than to guide you through playing it! Seen in Figure 11.
Figure 11 - Level guide (With commentary)
The level design turned out spectacular. Despite a few areas lacking decoration that will be populated later, especially the hidden rooms, each room feels unique and fun. Extending the development of the level was a smart choice, especially going into testing, providing players with a genuine glimpse of what the level will look like, as opposed to the layout when testing was originally planned, seen in Figure 12. This will also provide more in-depth feedback surrounding the level as a whole instead of just a short section. The main areas of improvement, apart from the aforementioned decorations, is the enemy placement and population, as it plays a large factor into the games difficulty (Bajaj, 2021). Hopefully player feedback over the coming week will assist in balancing the game to further align the difficulty towards the UX Personas.
Figure 12 - An early state of level design when playtesting was originally planned
Concluding
LEvel design
Before moving onto playtesting, it's important to ensure that every feature is included. For this, temporary dialogue and voice clips were added to the secret characters, alongside an early look at a few archive entries and an early main menu, as seen in Figure 12 and 13. Outside of this, the only other thing to account for is...
Figure 12 - Early archive entry
… Myself. In honesty, I have completely disregarded taking any breaks. Whilst I still spend time socially, any time to myself is spent working on this project, and in a twist of irony, I am writing this on a Tuesday, the day originally set for breaks. Once playtesting officially begins, I will take a step back for a week, until the end of playtesting, to ensure I avoid burnout and any dips in quality.
