Post-mortem: Black Mesa Hazard Course

PSR’s Black Mesa Hazard Course mod was in development between 2012 and 2015. (That’s counting only the first release for the mod version of Black Mesa -- an updated port of the add-on to the commercial version of the game, currently in early access, is planned but on hold for technical reasons.) Over the course of development, our small but dedicated team worked on a single goal-- a worthy remake of the training level of Half-Life in the fan-made remake Black Mesa.

    Ours was not the first attempt to fulfil this goal. When it was first announced on the official Black Mesa forums that the team who would go on to be named Crowbar Collective would not be remaking the original hazard course maps (using the-- admittedly correct-- rationale that due to Half-Life 2’s introduction of tutorial HUD hints it was obsolete), some forum members began working on a version of the project that quietly fizzled out. Time went on, and in September of 2012, the mod version of Black Mesa launched. This version lacked  the long-awaited, soon-to-be-released Xen chapters and the Hazard Course, but did include all the files needed to make custom maps in the Source Engine’s level editor, Hammer. As there were forum regulars who felt a playthrough of the Hazard Course was an essential part of Half-Life’s story, four of us who used Hammer semi-regularly decided to recreate the training level. Three years and a lot more community involvement later, our vision of the hazard course launched. As with most projects, it was not without some difficulties, but also not without it’s good points.

What went right

1. Constant communication between displaced developers

    One of the unique challenges of working as part of a volunteer mod team instead of a professional studio is the geographic displacement. Among the five core PSR developers, only two share a nation (the United States) and even then are halfway across the country from each other. Our core testing team is similarly displaced. Somewhat miraculously, we’ve somehow managed to keep a constant line of communications open for nearly the entirety of development using little more than Skype, without dedicated meeting times, and without having ever physically met. (I would not recommend trying to replicate this if you can avoid it!) Communication hasn’t been without its challenges, but the addition of a ticket system to keep track of tasks midway through development helped smooth out the majority of issues and kept things running smoothly without people doubling up on work-- something which happened frequently in the first weeks of development when we were still using only the official Black Mesa forums as a means of keeping touch.
 

2. Dedicated testing throughout

    Our team realized early on that developing in a vacuum was an awful idea. To make sure that our gameplay and tutoralization worked outside of our own thought processes, we brought in members of the Black Mesa community who were interested in playtesting the mod as soon as our first alpha build was ready. To ensure that the people we were handing out builds to were actually looking to help with the project, we did a short vetting process wherein the prospective testers each filled out a survey and participated in a text interview through Skype. Afterwards, they were given the most recent alpha and access to our main testing Skype chat where they could give us their feedback. As fans of Half-Life and Black Mesa, but not people who were personally invested in any particular part of our vision, our testers kept us reined in and focused, and helped us direct where the project should go. Every addition to the mod that wasn’t in the original was given extra attention and iteration until it was up to snuff, and a lot of bad ideas were sent to the cutting room floor.

    After giving their first impressions of each build, we asked our testers to go back and replay the build with a fine-toothed comb looking for bugs. This isn’t necessarily something that a professional studio should do, but having our playtesters also be hybrid QA testers helped us find many bugs and visual issues that we missed in our own QA passes, which was very valuable for us, especially as we lacked the time and resources to bring in and manage two separate testing teams. It’s certainly breaking the established rules of both playtesting and QA, and it takes a certain personality type to make someone willing and able to play something as they would normally and then go back and say “All right, now to break this in as many ways as possible”, but we took a gamble that paid off for us. In addition, a decent portion of our testers, while not level designers or modellers like the development team, also had their own technical skills, meaning they were able to supply not only great feedback and ideas, but the occasional art asset, voice lines, and the entirety of our english closed captions. Most of these methods shouldn’t be carried over to professional development, but if there’s a takeaway from our experiences with testing the Hazard Course that can be applied, it’s this: Treat your playtesters and QA well. They’re not “core” staff, but they’re still an important part of the team-- a good tester will be as dedicated as any programmer, designer, or artist, and their feedback and skills can be invaluable in making your game a better product.

3. Getting professional-quality voice acting on our script

    The script for Black Mesa Hazard Course is 45 pages spread out over six maps, initially written by former team member Craig Spivack and finalized by me after his departure to focus on his career. It’s a vast increase in size over the script of Half-Life’s hazard course, even including the extra lobby area Gearbox added during their development of the PlayStation 2 port. We held off on making a casting call for voice actors for the majority of development, wanting to lock the script down first. For testing purposes, I recorded the entirety of the script as a one-man show, which led to some… interesting takes on characters for the sake of recognizability that I’m sure are still burned into the minds of the testing team.

    Once the script was finalized (no small task, as every member of the team including our testers kept coming up with great ideas to add!), we had to search for voice actors. Luckily, we didn’t have to look very far for the most part, as we had gotten enough traction and support on the Black Mesa forums in the meantime to get the attention of Crowbar Collective’s official voice actors, who generously volunteered their help. This was especially good for consistency, as it allowed our generic scientist and guard NPCs to be voiced by the same people who voiced them in the base game! With the main Black Mesa voice cast onboard, we only needed to find actors to fill a few remaining roles. In the end, our cast ended up being full of talented actors, all of whom were also familiar with the Half-Life franchise and characters, so direction was rarely an issue during recording. Having access to Black Mesa’s voice actors and their connections was a massive help for us making the project feel like an authentic part of the Half-Life universe.

4. We built skills

    When we started out, every member of the development team had some experience with creating assets and designing levels. However, being hobbyists, we had critical blind spots-- some of us didn’t have experience creating materials, others hadn’t explored the full entity set Source had to offer, and none of us had any idea how to use Faceposer, Source’s choreography tool. As this was a hobby project, we couldn’t just hire on people to fill in the blanks for us. This meant that we all had to learn new skills in order to finish the project. Also, since we had no publisher to please, there were no real deadlines to meet, which meant that we could take the time we needed to do things the right way. The members of the team shared skills, learned from each other, and dove into the engine documentation to solve any problems none of us knew the answer to. Just about the only thing our team didn’t touch at one point or another was game code (since we had no access to Black Mesa’s C++ source files). It also helped that the Source engine, while not having a scripting API built in, has a fairly robust entity trigger system, to the point where we were able to figure out a way to quickly cobble together a functional Five Nights at Freddy’s clone map for our 2015 April Fool’s prank.

5. We learned how to work like professionals 

    In autumn of 2012, half of the dev team consisted of high school students who had never worked on a team in a serious capacity before. None of us were in the habit of communicating with others about our works in progress outside of showing screenshots, and we had no serious project management workflow set up. Throughout the development process we were able to go from total chaos to a task-based workflow with ticket assignments, documentation, division of labour, and lots of back-and-forth discussion, greatly increasing our efficiency and the quality of our work.

 

What went wrong

1. Late to the Source Control party

    At the beginning of development, we were using Dropbox as a host for our files without any source control applied. Aside from being a workflow to shudder at in retrospect, this didn’t affect development early on because we were all working in self-contained boxes - our own folders, our own source files for sub-areas of maps. However, the occasional overwritten file or lost change began to creep up on us as we began to consolidate our work together into playable form, causing headaches that could have been easily avoided. At one point we wrote a custom checkout tool which layered overtop Dropbox, but it proved insufficient for our needs. Once we moved to a VCS (In the case of Hazard Course, we used Subversion) the majority of our file management issues disappeared, leaving only a few instances of user error in the form of forgetting to pull.

2. Lack of Pre-Production planning

    Due to our inexperience, when the project first started, the entire team jumped in headfirst without stopping to think about pre-production. This meant we didn’t have a set of team standards for things like wall widths, a consistent art style (or any concept work!) or a plan for how we would make the disparate sections of the course fit together. While in the final product a lot of our connecting corridors turned out to be very aesthetically pleasing, for the majority of development they were messes of broken brushwork, stemming from the fact that the hallways often needed to connect multiple rooms with different doorway sizes.

    Lack of planning also led us to double up on work, as there was no clear outline indicating who was responsible for what area. When cases like that arose, the team took a look at each version and voted for which area’s overall vision was better. Luckily, we were able to stay objective throughout the process and team members rarely walked away with hurt feelings.

    Another symptom of our lack of pre-planning was the number of times various areas were made and re-made as our goalposts for quality, aesthetics, and function repeatedly changed. One early area of the game went from being both a near carbon-copy of Black Mesa’s underground Sector C tram station, to being largely expanded with a lounge, to having an open window view to outside, to no longer being a station the player gets off the tram at, to finally being a completely visually distinct topside area. The second train station where the player then disembarked from the tram also went through two or three similar overhauls before reaching its final iteration.

This area was redone or replaced many times during development.

3. Half-Baked Ideas

    The plans we did have for Hazard Course weren’t always the best ideas. One such idea was a large expansion of the swimming section of the tutorial, featuring a large underwater maze with minimal lighting, few air pockets, and no defining landmarks. Needless to say, the first alpha build that section was featured in was given poor reviews by testers, and the maze was cut with extreme prejudice. A less extreme example was the flare training course, initially thought to be a necessity due to the addition of flares as weapons in the early portions of Black Mesa. For a bit of context for those who have never played the original Half-Life, one of the rooms in the original Hazard Course features a short, elevated path through a dark room, which the player must navigate with their flashlight. Our initial idea was to have a secondary obstacle course afterwards where players would get a chance to use flares. This course was set in a very small maze built into a sedimentation basin. The maze never truly felt right, and could be bypassed fairly easily due to its geometry, so the flare training was moved a room further and put into a hallway blocked by various obstacles. The placement and layout of this hallway ended up feeling awkward, so the flare course was moved back and put in a side room full of ventilation emplacements next to the original flashlight training instead, where it languished for much of development. Eventually we came to the realization that since flares in Black Mesa don’t put off much light, trying to shoehorn that mechanic as a flashlight-training supplement didn’t work, and most players would just use their flashlights in that room anyway. The formal flare training was cut entirely, relegated to a few flares on a desk in the pre-flashlight room. If players care to look near the flares, they will see a paper notice warning to keep the flares away from flammables which, due to the placement of the flares, will in all likelihood catch fire should the player interact with them-- a much more effective method of demonstrating their actual ingame use of setting zombies on fire.
 

4. Poor Time Management

    Time management was an issue for us throughout development, partially due to the fact that our development team mainly consisted of students. If we had been able to work full-time on the project, Hazard Course would have likely been done within no more than a year and a half, (And even that is a generous amount of time!) but since we had to work around full schedules, we had very little time to work during any given day. Compounding this were intermittent drops in motivation as doing extra work on top of everything we had going on in our personal and professional lives wasn’t a very engaging concept. Due to this, as time went on and our schedules became more and more busy, development became a series of lulls interspersed with quick bursts of progress. Our time was also not always spent the most efficiently (due to the aforementioned lack of planning), leading to constant cuts and reworking of areas that we could have probably avoided if we had a better development plan.

5. Personnel Issues

    Throughout development, we had a few issues with expanding our team. Two members had to step down to focus on their careers, which on a team our size was a very large loss. At one point we were in talks to bring an additional artist onboard, but every asset he showed us was in a different art style than the one we required.  When we asked him if he could possibly adapt his style to match our aesthetic, he took it as an insult (not at all our intention!) and stopped communicating with us. In addition, despite having the entire Black Mesa cast, we had some difficulties in finding someone to voice Dr. Bickford, one of the principal characters. We went through a few different voice actors who weren’t quite right for the role, and for a short while it seemed like we wouldn’t be able to make our December 2015 release date because the role was still unfilled. Thankfully, one of our voice actors was able to refer us to a colleague who ended up being a perfect fit.

    Additionally, though we had an interview and vetting process for testers, a few people slipped through the cracks who weren’t interested in actually helping out with development, instead taking the build we gave them and running. Thankfully none of the would-be testers leaked our early builds, but they didn’t contribute anything, either.
 

Final Thoughts

    When we began creating Hazard Course in 2012, none of us could have imagined that it would take so long. But for that matter, we couldn’t have imagined how rewarding the process would be, or how well-received the final product would end up being. Though using dated technology in the form of the 2007 branch of Source, the team learned quite a few handy techniques and skills that continue to be useful today, the most important of which being how to manage a project and work together. Though we had a few missteps and unconventional solutions along the way, (including uploading the release version of the mod from the back of a moving speedboat!) the experiences we had developing this humble add-on to a fan game will continue to benefit us well into the future.

If you wish to read more about the development of Hazard Course, fellow PSR Developer Ryan Lam (who was also kind enough to help edit this article) made an excellent post-mortem write up in 2016.