In the past decade a lot had been said and written about Black Mesa. This re-imagining of Half-Life, built on the Source engine, has gone from vaporware to a commercial release on Steam Early Access. Instead of repeating the most commonly heard questions, I wanted to zoom in on the technical aspects of recreating a classic. We are a design community after all. Luckily for us, the fittingly named Crowbar Collective, was kind enough to talk with us about the making of Black Mesa. You guys are spread all over the world. In terms of development, how did you share files, made sure everyone was up to date and most of all, how did you communicate especially considering the time differences? It's one of the toughest challenges we've had to face. All the actual game development happens on SVN/Version Control, that's absolutely critical. Before you start work, you update the game build with the latest changes and when you’re finished working, you commit your changes and source files. Not everyone wanted to follow this system, but those who kept lots of source files on their personal computers or tried to upload their files through dropbox or some other way would almost always cause us additional problems. As far as communication goes, we have a development forum where we divide up tasks, sort responsibilities and post progress. In the last few years, we've transitioned a lot to Skype, where there is usually at least a half-dozen team members on calls and chats at any hour of the day (the most important information from the Skype chats are still posted on the forums). The programmers also have a bug tracker where bugs get ticketed and prioritized. Though it's inconvenient, you do eventually get used to the lag in communication when talking to someone on the other side of the world. You learn to phrase your questions/needs very clearly so you can get what you need with as little additional replies as possible. Original comparison shots by Deathmonkey7, edited by me. Development has been going on for over a decade. Props and textures have been remade several times. How did you keep track of this? How did you oversee all of this content? Much of the remakes were driven by our artist's own judgement. Prop Artist Brian Dale took advantage of an extended break in his position (while we were porting the engine) to remake many of the Anomalous Materials and Computer Console props on his own. When he was done with one, he simply overwrote it. This was relatively clean and easy to keep track of via our development forums. Where the endless remakes got really messy was with our first person hands and weapons. Because those had been developed by so many artists over such a long period, there was no consistency built into the rigs or the models. Some weapons were hacks upon decompiles upon hacks. When we decided that our mod-released weapons were generally underwhelming, we also knew there was no hope in trying to iterate upon our current system. So Lead Animator Nate Ayres went back and did a massive restructuring of our weapons from the ground up, then went back again and re-animated most of them. It was a huge cleanup but we feel it really paid off in the end... and we'll be sharing our setup in detail with the community soon. Original comparison shots by Deathmonkey7, edited by me. Was the team divided into roles similar to 'real' game development? In other words, did you have an Art Lead or a Senior Level Designer? Yes, we have at least one "Lead" per department, but it's still an extremely flat structure. No team member is in direct authority over another, but instead the Leads are responsible for always being up to date with the status of their department and coordinating team members to achieve the department's goals. We don’t micromanage or order anyone around. Most people play multiple roles on the team. Level designers double as Community/PR managers. Voice Actors lend their talents to choreography or character design. Animators also rig, weight and compile. All this is driven organically by team members seeing a need and filling it. How did you balance the old and the new? It has to look familiar but still feel fresh. What methods helped in that process? Our level designers have done a tremendous job with re-imagining the Black Mesa Research Facility. We started with all the base levels from Half-Life, but then really started to unpack them. Why is this room here? What might this scientist need in his office to do his job? We really tried to make Black Mesa feel like a logical, livable place and not a collection of rooms and corridors. Then on top of that, we pushed everything to be bigger, grander and bolder. We know that some of our fondest memories get rose-colored over time. That's why when people go back and replay a childhood game they're often surprised by how bad the graphics look. They don't remember them being that bad. We wanted Black Mesa to be Half-Life, but as you remembered it to be. Original comparison shots by Deathmonkey7, edited by me. I've read that you've customized the Source engine for the official Steam release. What motivated the decision to go your own way. Why not use the latest version of Source? What challenges did you have to overcome? Our first instinct was to snap up the latest and greatest version of Source and port to that. However, it went pretty poorly. Almost everything in the game was badly broken. After spending months trying to fix it, our programmers came to the conclusion that simply too much had changed between Source 2007 and CS:GO. To fix it, would basically be redoing the entire game. Therefore, we decided to go with the TF2 engine instead. It had just enough of the new features, but with the foundation of the old engine. Even so, it was a monolithic effort to port. I'd imagine very few game studios have ever had to switch engines with 80% of their game content already completed. Every single Source model, NPC and prop needed to be recompiled. Our facial creation system had to be rebuilt. Various custom systems we had working in Source 2007 broke in the TF2 engine. It took years and was an exhausting process, often feeling like we were taking two steps forward and one step back. Even in Early Access, there are still a few dangling threads we have yet to tie up neatly. It’s clearly visible that lighting has had the biggest overhaul. Did you implement the lighting of CS:GO into the engine? We did not implement CS:GO’s lighting engine. The most striking feature of CS:GO lighting, which we were examining, is called Cascade Shadow Mapping, or CSM. This refers to the beautiful dynamic shadows generated at runtime in outdoor environments, present in most modern engines. Implementing CSM was an initial consideration during the engine port process, but CSM touches nearly everything in the engine. Its reach is far more pervasive and complicated than you might imagine at face value. For example, CSM breaks lightstyles (named lights in Hammer, controlled via I/O logic), which would in turn completely affect a significant portion of our game's dynamic lighting effects, requiring reworking or further programming effort to fix. On top of many other considerations and the large amount of work required, the scope of such a change was deemed to be prohibitive. Our programming department is relatively small for such a project (4 programmers). So their time has to be managed and prioritised carefully, and this change was out of scope. However, we did upgrade our lighting engine in other ways. For example, we implemented baked ambient occlusion into our version of the engine, which significantly improved the depth of the lighting, particularly in corners and darker areas. Our version of Ambient Occlusion, when used in the compile, also greatly increases the number of bounce calculations done on displacements, which fixed a lot of the weird lighting bugs/inconsistencies you can get on natural landscapes and just generally improved the qualities of shadows on landscapes. These things make a subtle, but noticeable difference to the quality of the lighting, making it far less harsh and more lifelike. We also have a few improvements to VRAD of our own, written by our programmers (and some written by voice actor Mike Hillard!), though these are more complicated and trickier to explain. We have some nice support for texture lights and colour bounces too, written by us. There was also a large lighting pass done across the game in level design that significantly increased and refined the definition of lighting throughout the game. We took feedback from the mod release and subtly changed the lighting design and styles in quite a few areas, to further refine parts of the game. Finally, we have some new lighting features that we’re developing that will be implemented into the engine in some upcoming updates, and will continue to further improve the quality of lighting. We do not want to spill the beans on these just yet, but they are exciting! Original comparison shots by Deathmonkey7, edited by me. Why isn’t Surface Tension and On a Rail Uncut included? Chon Kemp, creator of ST and OaR Uncut is now part of the team. When he was hired, it was discussed whether or not to include OaR and ST Uncut in the Steam release. It was decided that the ST/OaR Uncut mods weren’t at the same quality of the game at the time, and that Chon’s time would be better devoted to MP level design, rather than updating ST and OaR Uncut. However, we are still exploring the possibility of getting these maps into the game, particularly ST Uncut. The original plan was to include that ST map in the mod release, however the mapper assigned to the map did not end up delivering it. For OaR Uncut however, we made the decision to deliberately cut that map because the chapter felt like it was dragging on for too long. What plans do you have to support custom content going forward? We'd like to support the modding community as much as we are able to. We’re going to be implementing entities that would allow modders to make new game modes for multiplayer, which gives players more to play with than just Death Match or whatever else we are releasing. We plan to improve AI in multiplayer environments so that modders can create co-op campaigns and other modes. There are loads of customizable features that we’re working on for modders to play with. Not only are we planning to support creators with game features, we’re using our regular twitch livestream, The Test Chamber as a place to show off community content; regardless of its stage of development. And on top of all that, we have multiple community events we’d like to do, solely directed towards content creators. Original comparison shots by Deathmonkey7, edited by me. Will the team stick together for future projects? Why or why not? Hard to say. The fact that this isn't our full time job, always working remotely, the years of extended development and the Source engine in general, have all contributed to burning out a lot of team members over the years. A few have even said this project has killed their desire to work in the games industry. Some team members have expressed their desire to stick around after Black Mesa and potentially make their own game. However, we're still too focused on bringing Black Mesa over the finish line to have talked about it in depth. Wrapping up! I understand that you guys will have your hands full with finishing Black Mesa. Having said that, I hope to see new projects in the future. I would like to thank you for taking the time to talk with me and share this information with us. I can guarantee that it will be appreciated. I wish you good luck with the further development of Black Mesa. I for one, can’t wait to finally revisit Xen and see your take on the final chapters of Half-Life. To our readers, please support the Crowbar Collective by buying your copy of Black Mesa on Steam Early Access.