Azure Abyss
My second year team project where I aimed to focus on level design more, but got held up with development issues throughout.
For this project, we were given a full academic year to develop a game but had to base it on a world that a team member had developed. We made that decision quite quickly but struggled with deciding on a game genre. After much debate, the agreed-upon genre was a turn-based RPG from the first-person perspective. We also decided to focus on exploring a cave network within the world we chose, giving us a good blend of cramped dungeon crawling, perhaps with some additional horror elements, inspired by the world we chose and our interests as a group.
We had some tension in the team due to differing perspectives of gameplay, which would cause conflict from time to time, but we were able to work past that as best we could and managed to make a game in the end. Initially though, due to said conflict, I spent the start of the game focusing on the mechanics that would be included, and how they would be implemented.
I and the other designer came up with an elemental combination system, inspired by Mass Effect and it's combo system, but applied to turn-based combat, and using fictional elements from the games world to set itself apart, and as a world-building tool.
After pinning down the core ideas and discussing them further, most of our issues were due to misunderstandings in communication. Ever since I have aimed to improve my ability to communicate ideas within a team so that we can all be on the same page quicker.
Fortunately, despite the initial rough patch, I didn't let it get to me and decided to research level design, specifically for first-person games to get a better understanding of the art form. I learnt from a variety of resources but found the maps of the Halo series, and the molecular level design from Valve to be extremely useful in improving my understanding of level design.
I applied what I learned to the first section of our game, acting as a tutorial. Often I've seen advice of starting with the tutorial last, but I never intended to have my initial idea stay.
I tried to imagine a player picking up a controller for the first time, and how I would be able to communicate basic movement wordlessly.
I implemented this with a backwards 'D' at the start, which would have the player move forward, and then have to turn to their right to continue. I made the D descend downwards so that the player would have to adjust the vertically of the camera as they proceeded. This was then followed by a climb upward that required the player to look upwards too. This was my response to the infamous issue of getting players to look up, which was a common talking point when researching Halo. There was also an opening to the left that players could look out of to see the titular abyss. This was in the hope of drawing the player's eye and camera movement to the left, giving them a point of reference or 'weenie' to look forward to.
The weenie in question was not just the abyss, but a small village where inhabitants of the abyss lived. The idea was to have rope bridges connecting stalactites to each other, that also ran along walls with small caves for people to live in. There was also to be a town hall of sorts being suspended in the centre. I thought that it would make for an interesting site to see early on, and would also make for an interesting village to explore and learn about.
On the left is a representation of how the two sections would connect, showing the relative size and view of each other. The circles along the tutorial path were the location of enemies that were there to teach the combat. The hope was that after 3 combat encounters, the player would feel anxious from being low on health, but would then be rewarded with a village full of life, where they could also heal and feel safe. The player would then come back here later on as a safe space when needed, after delving deeper into the abyss.
Another difficulty that the game had was that the team had settled on using the Unreal engine to make this game, despite our unfamiliarity with the engine, we gave it a shot. This did however lead to delays in implementation, as I struggled to learn the engine during development.
The tutorial made it in after some time, whilst we used a placeholder for the village. People liked the vista showing off a weenie, and whilst I liked my idea of the backwards 'D', I think that our playtesters were too experienced, so the purpose of the 'D' was unnecessary. I plan to revisit the idea again but will need to bear in mind the target audience more in future.
Unfortunately, whilst the view of the village was good, the amount of time that it took to get to the village was too long. I redesigned the tutorial to be shorter, whilst still trying to maintain the view. The best I got was making it an optional tutorial with the view, but it lost its effect if the player could choose not to see it, or be unaware it was there (bottom sketch for example). In the end, we settled on the top sketch, making it short and optional, this proved better for future playtests, but I did miss the view, as did others. Sometimes good ideas have to be cut to improve a product as a whole, which I'd rather do than make the game suffer.
With the tutorial remade, I worked on the hub. This also took some time as I was still learning, but unfortunately followed a similar fate to the old tutorial. We weren't able to get as many NPCs or their scripts working, so we just scrapped the village as it was just an empty bit of scenery that distracted from the core of the game.
Thankfully, during this time I was also sketching out the next section of the game, which were the caves that the core game would take place in. This became a vertical slice of what we wanted the game to be. A series of combat encounters, treasure to find, and resources to gather.
I followed the Valve rule of molecular level design and placed the enemy encounters in the sequence that I planned enemies to encounter them in. I had a plan to make the player zig-zag between the enemies, exploring as many corners of the cavern as I could make them without making it drag. Verticality was also implemented to disguise this and show the player the parts of the cavern they had previously explored, culminating in being able to see the whole of it.
This would lead into a long descending corridor to bring the player down from the high of completing the cavern and allow them to become calm, whilst also building tension for the next encounter. There was concern about this being too long without action, so I implemented an optional maze area north of the tunnel if players wanted to explore some more.
This would then end in an even larger cavern, with floating stalactites that were connected by rope bridges again. The player would ascend these, in contrast to the corridor until they reached the top, which would be a boss encounter. Once the boss was defeated the player could descend once more until they found a lift that brought them back to the village.
As I mentioned though, the village was cut, as were the floating stalactites. As a team, we weren't familiar with the flow of art assets into Unreal, which caused collision issues throughout. The bulk of my time near the end was spent amending these issues, to the point that I was never able to work on my initial plan, and instead had the boss fight just occur in a big cavern.
This was a difficult development cycle, due to biting off more than we could chew. The use of Unreal slowed the project down, the combat system was interesting, but I spent so much time on the levels, whilst the other designer also struggled with Unreal, slowing down the mechanics too. Both levels and mechanics were meant to be more complex but came out very rudimentary in places. I valued my time on the project as I got to explore level design more, whilst also learning a new engine, but in future, I think I would stick to what I know with engines, or scope down further to make development run smoothly.