Alpha Base: Devlog Pt. 1


Alpha Base: A Halo 3 ODST Level

Why does this level exist?
This level is a single-player level that takes place during the events of Halo: Combat Evolved. However, unlike the first game, you are playing as an ODST (Orbital Drop Shock Trooper) and not the main character, Master Chief. This adds a different dynamic to how the player should interact with the environment because you aren't as strong, can't jump as high, and don't have shields that will recharge (at least not in the manner of the original game). 
Being that this level is developed on the Halo 3 ODST engine, AKA "BLAM!", and not a modern engine, it presented some unique benefits and challenges that you won't get in any modern engine such as Unreal Engine or Unity Engine. I saw this as an opportunity to learn how levels were made before there was a set "standard" for how to use a game engine.
My target for this level is existing Halo fans who will enjoy having a unique take on the original game's setting. I'm also keeping new players in mind who are curious about Halo mods and want to try community-made content, so overall there will be a challenging element for veteran players, but it will be friendly enough for new players. 
For the purpose of this blog, this entry is just about the process of making the level. Here is a link to the Design document. Keep in mind some things may have been changed since the document's creation. 

The Process

Pre-Production
Before starting anything I focused on what I want the player to feel. As a Halo level it's easy to get stuck trying to recreate something that someone else has made. My goal was get the player to feel this as a fresh experience. They should feel a sense of exploration of a new word, and a sense of accomplishment at the end. There should be moments of action and tension, and there should be moments of rest to take in the environment they are in.

About a year before the project, I had bought "A Practical Guide to Level Design" by Ben Bauer and read through the book, taking many of the pre-production tips he laid out throughout the book. 

Early on I started with pre-production. I spent close to four months on pre-production gathering reference, reading some of the Halo books, and overall investing a lot of time into what I wanted to feel and show while playing the level. I knew at this point that I wanted the level to be based on events that happened in "Halo: The Flood" by William C. Dietz. The event in question is the capturing of a butte that is controlled by enemy forces. Because of this, the level will be very straightforward; flush out enemies and capture an important area.
I made data sheets (Figure 1) showing the mission blocks and pacing of the level, showing the difference in intensity for each block. Under the blocks are the "beats" of the level. These are things like "World building" or "Loud" or "Exploration"—anything the player should theoretically feel. 

Figure 1

Once completed with this step, I started blocking a basic overview of what the world would be (Figure 2). I placed down all the major blocks of the mission to show a rough estimation of where things would happen. 

Figure 2

I followed the basic block with a more detailed breakdown including player pathing and the "loops" the player should experience when encountering enemies. Loops are just an abstract breakdown of how lanes connect to each other in this case. 
After the overview was finished, I focused on what kind of enemies the player will encounter (Figure 3), so I kept it simple. Since then I have made minor changes while testing, but it has more or less remained the base for enemies.  

Figure 3

To finish up pre-production, I made a detailed sketch of the level (Figure 4) followed by an SVG file to clean up the overview (Figure 5).

Figure 4

Figure 5
Pass 1: Object placement


Pass 2: Enemy placement


Pass 3: Noting AI movement

I finalized everything using Miro as a canvas to pull in references as well as match them with my own sketches. I also made changes to the level showing areas that I was unsatisfied with once modeled and in-game (Figure 6).

Figure 6


Production

Sculpting
Once I felt satisfied that I had a clear goal and vision for the level, I knew it was time to put the project into production. I started with blocking out the level. Since Halo 3 ODST's engine doesn't have a terrain system, the terrain must be modeled by hand. In my first attempt, I tried to set boundary walls and sculpt at a game resolution so I wouldn't have to retopologize. 
I realized I wasn't really getting the result I liked, so I decided to sculpt at a higher resolution and go the retopology route. I started to see a result that I was liking.
I came from a game art background before switching to design, and one of the key things I took away from this process was that I spent far too much time on details that won't matter. Because I can't bake any of the detail down, I would spend far less time on details and focus more on the functionality of the level, because much of the background details were cut as you will later see. Once I finished sculpting, I started moving onto retopology. 
Around this time I decided to make some basic materials for the terrain. These are just basic block-out materials. (Don't mind the duplicates). I did this so I would have something in the engine. 
At this point, I had a base mesh for my level and decided to test it in-game. 

Key Takeaways, Learning, Troubleshooting.
I have since then thought of several different ways to achieve better results and plan to use better methods in later new projects.
BSPs and render portals were things I knew about before this project, but I had not fully understood them and I ran into a lot of issues that would usually not be an issue in modern engines. BLAM! is very specific about your BSP geometry and even more specific about render portals. I got help from other members of the Halo modding community as well as some of Microsoft's official documentation of portals in Halo to give me direction on how to properly set up portals. 

Wrong:

At the time I had a misconception about render portals. Even still I don't have a complete grasp on it, but over time I will be able to plan more effectively. 

Better:

As you can see from this last screenshot, much of the level has been stripped away. This was because the player mostly wouldn't see a lot of the things I sculpted, and they would be better used in BLAM!'s skybox. So I stripped much of the background away.
One crucial element that I didn't prepare for very well during pre-production was "zone sets," which is how BLAM! utilizes level streaming. I had a vague idea of how to do it in a prototype I made before I started production, but I realized I needed to spend a lot more time thinking about it. On top of cutting big chunks of the level's background, I now had to slice it up for level streaming. 
After a lot of trial and error, I finally completed the base mesh block out and traversability of the level. 

AI and Scripting

I think it goes without saying, but when I say AI, I'm talking about NPCs in the game and not LLMs. I followed most of my initial AI layouts that I set up during pre-production so far, but of course after self-playtesting, changes were made. Since the player is constantly advancing, there needed to be elements that broke up the running and gunning aspect of the level. Because of this, interactive elements were added to the level such as objects to destroy, doors to open, bridges to extend, and elevators to take in order to proceed with the mission. During this stage, I set up the enemies, scripted their objectives, and placed cover for enemies and for the players. 
Even some things were added that I felt were missing that would help make the experience more interesting, such as hunters and engineers. If you aren't familiar with Halo's enemies, hunters are large tanky AI that have massive cannons. On their own they aren't very threatening, but combined with regular infantry, they can add a real challenge.
I'm using engineers for the final "boss fight" block. The player must kill a very strong squad to finish the game. While playtesting, I found that the encounter was far too easy and needed a way for the player to constantly be moving and trying to find new ways to win: shoot, cover, and repeat. That's where engineers come in. Engineers have a feature that grants the enemy AI shields that can't be destroyed. The player must focus on the engineer before they can manage the final squad. 
Scripting for the BLAM! engine was completely new. The engine has its own scripting language called HSC, which is based on the Lisp programming language. I was somewhat more familiar with C# for scripting so the transition to this language was relatively easy, but nonetheless, there were certain syntax differences that took time to get used to.  
To finish things up for this post, I'm currently getting ready for player tests and setting up dates for multiple sessions. As it stands right now, the level is playable all the way until the end. The only major block that hasn't been included is the firefight at the end of the level. This needs time to set up and I wanted to start getting feedback on the current state of the level. I will post an update on the play session in the future and keep updates once I go into the Environment art stage of production. For now, thanks for reading and I look forward to sharing updates in the future. 

Cheers,
Tyler Swier