Polishing and Finishing the Level Design of the Mausoleum of the Arbiter from Halo 2


In this blog, I will be demonstrating iterating and polishing of my version of Halo 2’s Mausoleum of the Arbiter following the successful creation of the blockout in the previous blog. This includes major changes that were made to the blockout such as additional level elements, replacing BSP geometry with alternative, less expensive, assets where appropriate and other actions taken to optimise the level, creating AI enemies to demonstrate effectiveness as a combat-driven level and making final additions to the level.

Ultimately, this blog is about me finishing a level blockout that could be passed on to and discussed with other disciplines within a game development studio.

Recap of Level Design Objectives

The full analysis of the Level Design objectives can be found in last month’s post but here is a recap of the objectives of the level design for this particular case study:

The overall objective was to recreate a combat scenario where the player is caught between a conflict of two enemy factions trying to kill each other but will both attack the player should they be spotted. In the original level, the player is even suggested to watch the battle take place and finish off what’s left of the enemies after they have finished their fight.

How the Level should play:

  • Cross the bridge safely and enter the Mausoleum
  • Enter a Combat Arena scenario where the player has to fight 3 waves of Elite and Brute enemies.
  • After the third wave, the Mausoleum exit will open, allowing a Sword Elite to run into the combat area and chase the player. Killing this enemy is optional
  • After leaving the Mausoleum, the player must cross another bridge, no combat taking place, ending the level


  • Two Bridges, planes or boxes, outside of the Mausoleum, linking the player to the entrance and exit
    • Bridge to entrance must contain cover and enemy encounters
    • Bridge leaving the Mausoleum must not contain any combat elements, only containing a volume that ends the level when the player walks into it
  • Circular main area (Interior)
    • Two Floors, Upper and Lower
    • 8 – 16 Columns on the perimeter of both floors
    • 2 – 4 Jump Pads on Ground Floor
    • Large pit in the centre
    • Brute Spawns on Western side of the Mausoleum
    • Elite Spawns on the Eastern side of the Mausoleum
  • Cylinder to be used as the base shape for the Mausoleum structure


  • Spotlight must be coming out of the centre of the Mausoleum’s interior
  • Neon lighting in the interior walls
  • Ambient lighting to create an eerie environment inside the Mausoleum
    • Allowing the player to see but avoiding being overly bright

Level Optimisation

Replacing Excessive BSP Brushes with Blockout Assets

While using BSP geometry served the very useful and practical purpose of visualising the level layout without too much difficulty, I found out that relying on it entirely can lead to performance problems.

While I acknowledge that in a studio scenario, I would not be expected to optimise level design work the way I did here, I still wanted to demonstrate that I could optimise my levels to potentially improve performance (especially since I have been developing this level blockout using a PC that is seven years old at the time of writing) in addition to wanting to use an alternative blocking out method for future level blockouts.

The image above shows how I started the process of replacing the BSP brushes in the level by progressively replacing them with appropriate blockout assets, such as cylinders and tubes. I continued this process by adding additional shapes such as ramps and pyramids to bring back the sloped appearance that was easily created using BSP geometry, as shown below.

The downside to this process was that it took much longer to recreate the same shapes as before in addition to requiring more objects than before when creating such shapes was much quicker and simpler using BSP brushes, however, it allowed me to use a range of colours to highlight different elements such as floors, ramps and so on.

Unfortunately, I could not make use of blockout assets for the entire level, particularly the main structure, as that would be an even more time consuming process for creating a blockout, thus keeping the main structure as a BSP brush.

References for this section



Lighting Optimisation

Another optimisation method I used for this level was to change the lighting throughout the level to Static, which sped up rendering in the level, possibly making the level less heavy on processing speed and GPU usage.

To conclude this section of the blog, I recognise that level optimisation is not likely to be expected of me when working in a studio environment as a Level Designer, however, it’s part of my ability to demonstrate how I can polish my level designs and help with performance problems should they come up in a real-world scenario, regardless of whether or not I make use of proprietary level design tools and/or BSP geometry brushes.

Combat AI

Creating the Artificial Intelligence

To allow me to test the level for combat gameplay, I made the decision to create some combat AI which had basic functionality, that being moving, shooting and finding cover, to allow me to find out if the player can make use of the level design to be effective in combat and whether combat was too challenging or easy and how I could iterate from there. The AI was developed by following this series of tutorials initially to get the core behaviour in place and was itereated afterwards to achieve a behaviour that would be suitable for this project.

I will not be going too in-depth with the AI programming in this blog, however, I will give an overview of the AI behaviour and how I intended it to work. The image above shows the intended behaviour to when the AI idles as well as what happens when the AI sees the player (heading to the player location and then shooting in the player’s direction).

I also made a second AI behaviour tree to handle how the enemies will respond to being shot, finding and going into cover as well as going out of cover when the enemies no longer feel threatened (shown above).

Enemy Gun Variants

I had to duplicate the Gun Parent and remake the different weapon types for the enemy due to the line tracing. By this, I mean that line traces from the player’s gun made use of the camera to determine where the line trace would end which caused very strange behaviour in the enemy when they fired their gun. The difference between the player gun and the enemy gun is that the enemy gun makes use of an arrow component to determine direction instead of components for the player. A test was done by allowing the player to use the arrow component as well as the enemies but it resulted in player aim being off at all times.

Enemy Variants

After completing the enemy programming and was happy with the behaviour, I created different enemy variants to reflect four different species of Covenant enemies, specifically the Elites, Brutes, Grunts and Jackals. To make them unique to each other, I made the enemies have the following traits:

  • Elites: Same size as the player, moves slightly slower than the player, has the same amount of health as the player
  • Brutes: Larger than the player, moves slightly slower than Elites, has slightly more health than the player
  • Grunts: Half the size of the player, moves slowly due to smaller size, has low health
  • Jackals: Slightly smaller than the player, moves at the same speed as the player, has low health

Enemy and Cover Placements in the Level

To recreate the original experience, I started by placing enemies on a left/right divide, placing the Brutes and Jackals on the left of the main mausoleum (above), the Elites and Grunts on the right (below)

In addition to remaking the original enemy placements, I decided to add some more cover, namely the red cuboids, to give the player more options of places to hide, particularly if they were wishing to observe a battle and finish off what’s left of the surviving Covenant as prompted to the player in the original level, as well as making the level appear more populated, especially after the initial blockout had little to no cover apart from larger elements like columns and walls.

The image above in particular was a way in which I used cover to protect the player from a sudden attack from an enemy. Before the red cover block was added, the enemy would charge at the player the moment they entered the mausoleum which would force the player straight into combat which goes against the vision of allowing the player to simply hide and observe the battle between the Elite and Brute factions.

At the end of the level, I placed two Elites into corridors to come out and ambush the player, giving them the choice to either fight the two Elites or head straight to the door, avoiding combat entirely. In the original level, this would be in the form of some camouflaged Elites wielding energy swords coming out of the level and pursuing the player.

The Completed Level

The video above shows a playthrough of the completed level

Post Completion Level Breakdown

The top-down view of the level shows where different enemies should initially be placed, where weapons can be found and picked up by the player, where the player starts and a few possible paths that the player can take. It’s worth noting that due to the nature of this level being a very combat-heavy one where the player has a very wide range of options, such as observing the combat, a stealthy approach or running into the fight head-on to name a few, the player paths illustrated are only some ideas but it all leads to the same ending.

As shown in the image above, the player travels from south to north, with the western part of the level being dominated by the Brute faction and the east dominated by the Elite faction, as it was in the original Mausoleum of the Arbiter level in Halo 2. 

The only major concern with this level design is the start of the level where the player is almost walking in a straight line, possibly having to walk around some obstacles or jumping over them to reach the main part of the level. The addition of weapon pickups at the start of the level (shown as pink circles) was an idea from earlier iterations of the level, originally planned to have combat but the idea was scrapped for optimisation purposes, that the player could take advantage of should they run out of ammo for either of the weapons they hold, but that means backtracking, making the placements effectively obsolete.

Successes, Learnings and Future Improvements


This case study has been more than successful in recreating the original experience of the Mausoleum of the Arbiter level from Halo 2. This project was peer reviewed as I was working on it and it was highlighted to me that the level has successfully managed to cater for a wide range of play styles, such as rushing into the level head-on, taking stealthy approaches and the intended effect of being an observational scenario, as well as sticking very true to being a Halo 2 level. Furthermore, the additional level elements such as additional columns, arches and extra cover objects allows the player to approach the level in almost any way they wish with little to no consequence while still maintaining the original emotional feeling and the challenge provided in the original level, thanks to using a moodboard containing lots of images of the original level to guide the blockout process.

Another success was the use of lighting. While the level didn’t become as dark as intended, it still achieved a much more eerie and sombre environment, creating a significantly darker tone than both the original level from Halo 2 and the graphical remake presented in Halo 2 Anniversary.

What was Learned?

For the lessons that were learned from working on this level, for me it was an introduction to a wide variety of level design theories and practical skills, this includes getting to grips with shape theory, creating and optimising lighting to create an alternative level feel without putting the player at a disadvantage, taking a level from a blank scene to a fully polished level ready to be handed over to other disciplines within a game development team, such as Art and Programming, and making use of flexible tools made to help the level design process.

I also learned a significant amount about the technical side of designing gameplay and level elements, these learnings are shown in much more detail in the first blog in this series, by moving away from techniques commonly used in online tutorials, such as relying heavily on Tick Events in Blueprint and creating individual code for objects inherited from a parent made by myself, to more optimised and simpler approaches that only meant I was required to make changes to one object to iterate on a wider range of objects instead of having to go over multiple objects to iterate on a very small game mechanic or interaction. More details about this can be found in my blog from September 2020 where I broke down and remade the overheating weapon mechanics used in the Plasma Rifle in the Halo series.

What could be Improved?

If I was to do anything differently doing this particular project again, I would have started by making a handful of sketches, both on paper and/or using photo manipulation software such as Photoshop or GIMP, prior to blocking out the level to get a much clearer visual plan of the level before jumping straight into the engine and blocking out.

Using what I’ve learned, particularly on lighting and shape theory, I’d make sure I’m more informed of how to successfully use them for level design and apply it in a way that I know would create a great level experience for the player instead of just jumping in with little to no understanding of what I was doing.

Last but not least, I found myself being distracted a lot by the programming and optimisation of the gameplay mechanics and level elements. While this clearly shows that I can be flexible by scripting gameplay elements and interactions for prototyping purposes, something valued a lot for general game design and/or technical design, it did slow down the level design process significantly. In future, it would be worth looking into using pre-made packages containing the things I need (i.e. AI, weapons, interactable objects, etc.) ready to use so I can focus all of my attention on placing objects in the level, testing them and iterating on them to speed up the process, especially since I would not likely be expected to do heavy amounts of scripting in a level design position within a large studio environment.

Overall, this project was a very successful one that I really enjoyed working on and I have learned a lot form working on it. Now it’s time to move forward to my second Level Design case study which I will be introducing to the world via my Twitter and LinkedIN posts in the near future as well as next month’s blog in a more formal manner.