Hello, this is Ben Truman. I'd like to explain my role as writer/designer on the Black Mesa team .
I received this opportunity by attending the Art Institute of Pittsburgh for Video Game Art & Design, where I met many of the team members. When I first came aboard, I had a lot of wild ideas concerning how I would make Black Mesa the perfect link between Half-Life, Opposing Force, Blue-Shift, Decay and Half-Life 2. I wanted to throw in Dr. Breen, Dr. Green, Dr. Mossman, everything and everyone. The further I went along with these ideas, the more it seemed that I was hijacking the original story rather than improving upon it. I went back and retooled (or removed) those scripts after realizing that this wouldn't be true to the computer game that everybody remembered so fondly.

As for a lot of gamers, Half-Life's form of storytelling was the games biggest appeal. The original scripted sequences have all been preserved, but enhanced to utilize the tools that the Source Engine provides for producing dramatic scenes. Since the generic security guard and scientists have evolved into their respective roles as Barney and Dr. Kleiner in HL2, I've tried to maintain the essence of those personas. Kevin Sisk and Mike Hillard have tapped further into these characters and brought tons of personality to every scene. No longer will NPCs stand around waiting for the player to arrive. They will be involved with their surroundings and establish their individual context in the game world. They interact with their environments, realistically express a wide range of emotions and talk with each other and the player while following him around the facility.

There will be additional scenes, though. The height of the development experience for myself has been creating new scripted sequences within the original narrative framework. I've included an audio-demo from one of my favorite chapters, Office Complex. Once a script is finalized and the scene is recorded, Kevin will assemble a radio-play so that we can get an advanced preview to help visualize how the scene will pan out. You may recognize where this scripted sequence originally takes place. The player comes across a security guard beckoning for help behind a locked gate. Upon approaching, both come across a frightening discovery:

Dead Zombie Storage

It took a while for me to find my groove, but it allowed my style to mature immensely. Hearing the scripts voiced, edited and implemented has been extremely rewarding as each character within the facility has been brought to life. The new and extended scenes also fit organically into the story. They serve to increase the excitement and drama without jarring the sense of nostalgia that makes this mod so great. Each sequence stays true to form, true to character, and - most importantly - true to Half-Life.

Howdy, today you're in for a treat as you get to take a small peak inside the programming world of Black Mesa.

Lets start off then, shall we?

The source sdk even with its "What the Fracks" is a thing of beauty which allows modders and programmers to achieve quite remarkable things. Hell, it even comes packed with plenty of helper classes, functions, and interfaces which allow us programmers to create nifty gadgets in remarkable time. The only thing stopping or pausing your development is finding those hidden tools needed to achieve your goal. Of course, its best to know what your looking for so you can search reliably. This is fine and dandy if you know or have some idea of game programming, but if your new to it and you just dive right in then prepare to cringe. The sdk was/is built in the mind of those who understand gaming programming and its components ( yes, this includes the graphics, game logic, and fun math! ).


A case in point happened to yours truly a few days ago where I had to search deep inside the sdk for something which was vital for the project. It started off when we decided to rework the cockroaches so we can have more then just 4-5 on the map. The roach was composed of an entity, and entities are quite expensive quite a few of them are used. Also, only a certain amount of entities can exisit before the engine alerts you with "WTF you went over the entity limit" then explodes. We want a crap load on a map at a given time, so the roach had to be a non entity class which would be cpu cheap. I ended up wrighting a new cockroach prototype and it worked fine and dandy. The roaches would climb all over the world and was rather cool. However, they where bit more expensive then I would have liked tem to be. The roaches would fire off a ray or "traceline" too often, but was needed to perfect their movement so they could climb on any surface.

I was not too pleased with how the roaches functioned internally and knew I could squeeze more numbers with optimization. After thinking it over and looking over a few of draft papers I was pleased with an new idea. Basically I would have the cockroaches precheck the surrounding area with rays or "tracelines" and get a list of planes near by. For each plane found the code would lookup the edges of plane using Point-Plane Distance formula. The roaches would then precede to one of the given points or edges. Only when the roaches are at that given point will they update with those evil expensive "tracelines" instead of almost every other frame. "Voila", I said!


The logic sounded good, but oh how would I code the logic of finding the edge of a plane? Well the sdk provides the "traceline", so I can find the end point or point which hit the brush. However, I needed a way to get a hold of the surfaces of the brush for the trick to work. I went on a scavenger hunt in the sdk. Alas, my good friend Paul finds the very interfaces which I needed...behold the almighty functions and interfaces:

and


With these bad boys I can achieve what I dreamed and have a crap load of roaches with only a small expense...just a quick note that if you notice that GetBrushInfo(...) returns a list of Vector4Ds. This includes the normal vector and the distance from the origin. I don't expect many to understand why this is without preexisting knowledge of plane/math logic. However, lets just say it lets us find the edge of the plane given a point where all the surface points close to the test point are calculated. In the picture below, the middle bottom circle is where the roach hit the brush, and the other three spots are points located on the other surfaces of the brush. Thus, I'm able to find the edges on the brush or surface, and scream with joy! Oh, and the texture you see or white dots are TEST/Development Textures which will be replaced in the final game. (Yes, the white dots are representing silly roaches)


Oh the shrill of having a ton of these guys running about on the map in an overwhelming number should bring plenty of fans screaming "ew!" or "cool!".


Oh, you can step on them and shoot them....

The sdk can provide some useful features to help get the job done while other times not so much. As in the case with the flying npcs in the sdk (specifically the scanner) where valve wrote code which deviated away from their usual organized ways. You see, most of the hl2 NPCS use a class called AiNavigator to, as the name implies, navigate through the world by selected nav paths. Now there is code inside the navigator to handle flying AI and valve uses a part of it for the scanners. However, valve decided to just code in how the scanners fly in the NPC classes itself rather then let the AINavigator handle all of it. A little odd, though I can understand for the reason of having each flying NPC handle its own way of flying a bit easier then having to mess with the navigator. Valve's basefly class works great, but considering we want our flying AI to be pretty bad ass, more interesting, and not to mention more cleaner code, we needed a revision...

So instead of using valves flying code, we wrote a our own class to handle the movement for the Alien Controller, Ichthyosaur, Leach, Osprey, Apache, & so on. With an all new fly class we where able to control how we wanted each of these npcs to move through the air and attack. You will find a video below demonstrating the work in progress controller movement with his attacks disabled. As you can see, the controller will be constantly moving around the player to keep the player on his toes. Also, you can note how his hands, feet, and body react toward the direction of flight and speed - he also blends his angles (slightly buggy, but remember its work in progress....). Anyway, the sdk is great with somethings, and other things its a load of blop. Though its what we are using and so we will push it to its limits and carry on kicking ass....

Controller Movement preview video

Please note that you may see his hands twitch every now and then, this is due to the controller trying to attack.
Since his attack fails ( as I disabled his attacks for the video ) he twitches.

we're working our butts off. thats right, butts.

The article intended for this week has been postponed due to technical issues, not that any of you knew what it should be, but vague hints must be extended to imply future dates instead. And anyone who doesn’t know what I’m talking about just smile and nod as I’m going to move onto some of the fundamentals of Texture Alignment.

So the first thing to address is why bother, why should texture alignment even be an issue. You’ve got the texture right and you’ve got it on the wall so you’re done, wrong. Proper texture alignment really is nothing more than a detail and polished but it’s the kind of detail and polish that makes the difference to a finished product. Let me show you a room made by someone who doesn’t do any texture alignment compared to someone who does everything needed. As seen below the difference in spending the 15 second to align the textures makes a world of difference. The area still looks low quality but that’s just due to lack of detail what’s there looks infinitely better and that’s why you should spend time aligning textures.
http://members.shaw.ca/dvdgillen/BMS/Dam_TexAlign.jpg

So there are some essential things when it comes to texture alignment, and pretty much every single last one is found in the Face Edit Panel, (The multi colored cube on the left, the one you really should know by now). Realistically their all self explanatory fit, stretches a texture to fit, L makes the textures left edge align to the edge of the brush, rotation rotates the texture. It all applies to texture alignment. The only tool valve is hiding form you is one of the best. Alt + Right Click. When you have a face selected Right clicking will apply all its attributes, when holding down Alt it will apply all the attributes and also align the texture so that it matches up with the other texture to looks seamless. In the previous picture you can see how the texture looks continuous round the corner, that’s what the Alt + Right Click did. As you can see a valuable time saver to align textures, the only drawback it has is that it creates a custom texture projection direction.

Now the term “Texture Projection direction” Is probably one most people haven’t heard of and when they figure out what I’m talking about they’ll probably realize they didn’t know what to call it before then. There are 2 default projections, World and Face. The world projection means that the texture is lined up in the X Y or Z axis and then just put onto the face. Think about it like a projector. If both are lined up neatly you get a nice square; however, if you slope the screen then the image looks stretched. The same thing happens to the textures in Hammer, it even goes so far as projecting on the back of the screen sometimes. The Face projection ALWAYS aligns the projector and screen up properly. So no matter what way you rotate the screen it’s projected from the right angle, so text is never backwards and the image is never stretched. To World is useful when you wish to keep things lined up, for example a concrete floor that has several rises and falls that needs to look continuous. When aligning toFace the slight slopes in the edges would show up as the textures slowly become misaligned. But a toWorld projection means that while they are technically stretched that they will still line up. Displacements take the base projection of a face then map a vertex onto that layout. So you should always align your faces properly before displacing them. Below is an example picture of what the difference is between toWorld and toFace.
http://members.shaw.ca/dvdgillen/BMS/Dam_FaceWorld.jpg

So really let’s address the biggest point of texture alignment, and that’s what we’re aligning it to. Alignment is all about the edge of the brush and the transition to the next brush/face/texture. A texture with no discernable edges or details cannot really be aligned because doing so serves no purpose; however, add an adjacent face with the same texture and they should be aligned to each other for appearances sake. When a texture has a trim for the top and bottom, align the bottom of the texture to the floor and the top to the wall. If the rooms too high then use a version without trim or make the wall out of several brushes for each section of trim with top/middle/bottom textures. If you’re using a tile on the floor, align it so the tiles line up with the walls. If you have a metal edge around something pick a metal that has a pronounced ridge and align that all the way round the edge. Take the time and make sure that the edges of the texture make sense with what you’re aligning them to, don’t simply slap on a texture and call it done. There will be more specifics on alignment in the higher classes of texture alignment. Class dismissed.

This Week I’ve got absolutely nothing of interest or irrelevance to say beyond the blog itself so lets get down the fine art of breaking things.

Firstly we’ll deal with the most common type of destroyed objects, pre broken environments. They were like that when you got there, honest. Now there’s several ways to achieve a pre broken environment with Brushwork, Models, Displacements and various other smaller effects.

The oldest version of broken objects comes from brushwork; this used to be done back in the GoldSource days and is usually used by those who don’t know any better. The results often take more work than should be needed and look sub par in today’s graphics world; however there are a few times when it’s required.

With the appearance of source models became a much bigger part of broken environments, models themselves were allowed to break and shatter creating interesting and detail destruction of props, also props like broken walls existed with a perfect premade hole, so long as the texture matched what you were making. While speeding the process up dramatically the problem with the models became their appropriateness as often you would have to design the scene around the model and make it fit so you don’t have problems. This and the prefabricated look of the models is why I put all my weight behind Displacements as the way to do destroyed environments.

In order to displacements you first build the brushwork to mark the hole, and then establish the quadrilaterals you need to displace and displace. The fine adjust displacements allow will let you create and interesting broken edge to any shape and any texture you desire. Now Displacements aren’t without their problems Displacements have a nasty tendency to light annoyingly or incorrectly. Displacements smooth light and light from the vertices as I’ve mentioned before, this leaves them with an annoying tendency to pick up stray pieces of light and amplify the effect or to have smooth corners on what should be a harsh edge. To deal with the stray pieces of light a block light brush near the vertex can work wonders, to deal with smoothing problems you need to break the brush into multiple brushes and then adjust them a micron. To do that, hold down Alt to turn of grid snapping and scale the brush a tiny bit. The tiny bit will be enough to break the smoothing but not enough to visible show. If you are worried about it showing then you can always paint geometry on the vertex pulling it left and right and the other vertex will settle to a near identical position due to the way the soft edge works on paint geometry.

The last thing to help show broken objects is several minor effects. Things like decals have some concrete or plaster damage then can help out, overlays which show cracks can help when brushwork would be too much, dust and dirt in the area can add to the atmosphere of debris, and even having broken popes vent steam or drip water, broken electronics spark. The little touches to the already broken can go a long way to finishing the effect. Below is a picture of exactly how I employed displacements and a few other things to make a broken environment.
http://members.shaw.ca/dvdgillen/BMS/Dam_boom.jpg

I’d of loved to of talked about dynamic breaking and letting a player see it but that’s useless without some form of animated video showing how it happens. Who knows what I’ll have for next week.