From Black Mesa: Wiki

The update of this page is ongoing. Soon all the entries of the original DevBlog will be uploaded here.

--Conti 03:10, 26 May 2010 (UTC)

Contents 1 Introduction 2 2007 2.1 Christmas 2007 Media Release 2.2 The Very First Devblog!! ...Kinda 2.3 Adding Spaces 2.4 Voice Actors Inbound 2.5 Welcome to the "The Dam" 2.6 2007 Retrospective 2.7 Undertow In The Making, Part 1 3 2008 3.1 Black Mesa Bumpercar AHOY 3.2 The Dam - Sizing It Up 3.3 Residue Processing in the Making: c2a4b 3.4 On a Rail-y Goodness 3.5 Outtakes and Bloopers 3.6 The Dam - Feature Presentation 3.7 The Dam – “I say Clip it, Clip it good" 3.8 Our Steam Community Group Is Awesome. 3.9 The Dam – Coffee and a Rant 3.10 Gasworks, Gameplay, Caustics? 3.11 The Dam – Seeing The Forest Despite The Trees 3.12 I'm Such A Tease 3.13 The Dam – Needles in the Haystack 3.14 The Dam – What's your angle? 3.15 The P.I.T. - New style, same structure 3.16 On a Rail 2 - The Wedding 3.17 The Dam – Hammer time? Can't touch that 3.18 The Dam – A focus on the convex 3.19 The Dam – Water in depth 3.20 C-LOS UP IN THE HIZZY 3.21 Blast Pit Modeling

Introduction

The Developer blog was the primary platform of the developer team for releasing new media before the creation of the Wiki, YouTube, and Twitter channels, and was removed when the website was updated in late 2009.

2007

Christmas 2007 Media Release

(on 24 Dec 2007 by NateDGreat3)

Merry Christmas Black Mesa fans! We're proud to bring you some new media and updates on development progress!

First off, we'd like to draw attention to the fact that voting is taking place for Mod of the Year on the ModDB website! If you want to vote for us, visit this link, scroll down to Best Upcoming Mods, and click on our banner to vote!

Development has been going great and proceeding steadily towards completion. The team has really settled into an efficient development pattern, with very few bottlenecks arising in development now. Internal milestones have been organized to ensure a timely release, and we've been doing a great job of hitting those milestones. It's been very exciting to see so many different elements of development come together and make a playable game!

And now, to the media! We've decided to do a complete overhaul of almost all the previous screenshots, as well as offer them in a higher resolution, widescreen format. Previously released areas have undergone many changes during the course of the year, weapons have been tweaked and reanimated, and we've also got some new, previously unseen areas from both singleplayer and multiplayer to unveil!

This is not all, however, we've got a surprise in store that is currently in late stages of production and will be done very soon, we'll be sure and release it, as well as some other image-based media, when they are finished!

In an effort to keep the community more up to date with our progress, we've implemented a whole new "devblog" section to our website. Very WIP screenshots and informal text-based updates will be added to this section on a regular basis. Keep in mind that this is NOT to be considered official media, which is extremely polished and what we consider to be a glimpse of the final game. Rather, this is a look into the day-to-day workings of development structure and the community will be able to witness sneak peeks of different areas of development.

And finally, Black Mesa is seeking the following applicants as top priority:

• Compiling Technician
• Faceposer/Choreography Technician
• Character Artists

Details are available in the Jobs section, if you think you've got what it takes, don't hesitate to apply!

Until next time, we appreciate your support as we continue to work hard on Black Mesa!

The Very First Devblog!! ...Kinda

(on 24 Dec 2007 by NateDGreat3)

Why hello there

So on Christmas Eve, it dawned on us that we were touting this great new devblog feature as a way to keep the community updated on our progress, and we forgot to put something up here for the launch. To save us from looking like complete idiots I have been assigned to create a block o' text for your reading pleasure.

When this tr--uhh... the surprise, comes out (and trust us it will be soon) it'll showcase a great new graphical feature that's been pioneered by one of our LDs over this past year. It's even better then the "dynamic shadows" in the Blast Pit maps that were shown last year. Which LD? What feature? Patience.

But for now, I must cruelly tease your brain with the following mercilessly blurred image. I swear, this is the only time we'll do this in the devblog ever again, don't go getting any wrong impressions or I'll smack you

Adding Spaces

(on 26 Dec 2007 by Atrocity)

During the development of Black Mesa a lot of level designers have ran into areas in which the environment has little purpose or could use some serious thought. In some of these cases we have been adding additional space, however it may not be space that you can access. These areas are now making the level feel larger and more life like. I cannot speak for everyone but I have come across this on Gasworks more often than not. A lot of square hallways and tight spaces, now opened up to make the player feel like he is in a much large facility. Here is a reference shot, and a shot from in game, keep in mind it is not final at all.

[Incase you are wondering, this is the lower hallway in gasworks that is by the RPG in the main underground zone]

Voice Actors Inbound

(on 29 Dec 2007 by debeerguy007)

If someone told you that you were gonna participate in a highly anticipated HL2 mod in the service of a voice actor, would you have believed them? I know I wouldn't have. I guess that shows you how much faith I had in myself a year back.

But, here we are. Almost a year later.

Friendships have been made, development has shifted into the next gear, and a lot of recordings have been submitted. I had no regrets whatsoever from having submitted my crappy ass demo to the team. But to have them come back a day or so later and say, "We like what we heard, you're in" really was a surprise. I've never voice acted in a serious capacity before until now, so they must've heard something in that demo that said,"hey, this guy has the potential", and that means alot cuz I never expected this to happen.

Over this year I've had the opportunity to speak and interact with many people on this team ranging from the various other voice actors, level designers, prop modelers, texture artists and animators, whose passions for this project is clearly unquestonable. Their encouragement and support have really helped to not only improve on my ability to voice act and submit quality performances, but to also go beyond the call of duty and help in other areas.

My name is Kevin Sisk, I play the security guards, and I'm proud to be one of the voice actors for Black Mesa, as well as the Assistant Dialog Editor for the project.

In assisting sound designer Joel Nielsen in his audio efforts, it is my hope to help ensure that Black Mesa will be one of the most excellent sounding HL2 mods to come to pass.

So stay tuned, you're gonna start hearing more from us voice actors from here on out.

Coming Soon: OUTTAKES!!!

Welcome to the "The Dam"

(on 30 Dec 2007 by Angry Beaver)

Hello and welcome to what I'm dubbing "The Dam", this is going to be my WEEKLY (yes you heard right) comment/tip/trick/rant about mapping with source, it wont be about the state of development (so don't get your hopes up), more about the state of the developer and how to develop. To non mappers the only intrest may be my vauge hints as to how the designs going for my maps and listening to me rant about what got me worked up this week.

First I figure I'll introduce myself, I'm David "Angry Beaver" Gillen I've mapped for pretty much every game I've owned and have a good 6+ years experince doing so. I'm a relativley unkown mapper because I've released very little work, mostly unreleased because it never met my standards to show to the public. I admin the Level Designer group on the steam community and love to help, I do more than map but my main focus on Black Mesa is and shall be mapping. I came onto the team around mid Novemeber 07 and I have been assigned Bounce as my first map.

To keep this intro short I'll leave you with a simple image that will be my first peice of advice about mapping.

Don't Carve.

2007 Retrospective

(on 31 Dec 2007 by cman2k)

Hello there, I'm Carlos, Project lead

What I would like to do is explain some things about our development over the last year. We've made some big changes to how we've been working, all for the better. Unfortunately this stuff is often invisible to you guys, and what I would like to do is give you a sneak peek into what it is we've been doing exactly.

We implemented milestones.

We are no longer working on the whole game at once. We focus on small milestones that are major accomplishments in and of themselves, before moving onto the next milestone. This has included a change in development where multiple level designers, modelers, and texture artists will tackle a chapter together to push it forward to completion on a much smaller timescale than in the past. In actuality this has been a huge boon our development, and I've never been more proud of our developers for banding together to get shit done when it needs to be, as much as in recent months.

We've implemented a wiki and have become extremely organized.

This may seem like a small step but something like this is a great help to development and in general can make everything run much smoother. it's much easier for us to share and iterate upon our plans, scripts, and various documentation.

We orange-mapped the whole damn game.

This is important because you can go from level-to-level through our game, even if sections are barely blocked out. This is like laying down a rough draft that you iterate and improve upon over time. This was a big deal, and took some work for us to get done, but it was worth it and has proven to be a positive additon to development. Being able to play and walk through chapter, to chapter, to chapter, is an amazing thing.

We've been scripting and recording

Lots and lots of stuff for various chapters, as well as just for NPCs, and working with faceposer to get all that in-game. This was something we hadn't even touched until last year, but it has proven to be a challenging (and often humourous) endeavor. Unfortunately, this is another one of those areas where tons of work can't really be shown to you guys, and won't really be able to be appreciated until we have a final product.

We've been finishing entire chapters

The screenshots that we showed last year were of sections of chapters that were shiny at the time. Most of those chapters that you've seen updated now are essentially DONE. When we showed them to you last year, we picked a pretty part of one level out of the chapter. Now we have entire chapters that are COMPLETE, checked off the list. Again, this is the kind of major accomplishment that is really hard to relay to you guys, without ruining things for you, or having 20+ screenshots of all the levels that make up an individual chapter.

We have a lot we haven't shown you, on purpose.

We have modeled, textured, animated, in-game NPCs with AI that we haven't shown you. We have weapons with awesome effects that we haven't shown you. We have lots of stuff that we haven't shown you, on purpose. We can't really show you the weapons / enemies / environments from the end of the game, without ruining things for you. We also have an internal media blackout list of items/environments/npcs that we cannot and will not show media of, until after release. This was something we discussed at length internally and decided would be best quite some time ago. Sticking to our guns with this means we have done a lot of work that we simply can't show off.

There is a large volume of material completed now that the entire team is so proud of. Everyone involved wants to show their work off to the public. It drives us crazy not to be able to share it, but when it's all said and done we want this material to be as fresh and exciting as possible when the mod is released. We carefully pick the things that can be shown for each media release, and only show those things. This is in direct contrast to what most of you seem to think, which is that what we have shown is everything we have done. That is simply not true.

For those of you that frequent the forums, I'd hope that what you have noticed around the forums in the last year is that we have changed our tone a bit. No longer do we say things like "we are considering that" or "we may do that in the future". Much more often do you hear things like "If we have time we may do that", or "Due to time constraints that will probably never happen". This is due to a large shift in our mentality over the last year, folks. We don't just have milestones, we have dates. Deadlines. TIMES. We are actually looking to finish the game at the time we mean to, and we have long been cutting corners and pushing ourselves to meet these goals.

When you have goals like this, interacting with the public starts to seem a whole lot less important. You realize that you could do that, or you could keep working because you need to hit this deadline. Because if we don't hit our deadlines and we don't stick to our schedules, we'll never release. That is our mentality now, and we can only ask that you guys understand that. We have some lofty goals here, and while we have never conceded to sacrificing our standards, we have conceded to sticking to our guns, locking down our vision, and focusing on achieving our goals.

Ask anyone here on the team and they'll know what i'm talking about.

-Carlos

Undertow In The Making, Part 1

(on 31 Dec 2007 by Cpl. 1nsane)

When I re-applied for Black Mesa Source around summer this year I didn’t expect to get back in, but to my surprise a reply! Not long after that I was assigned the task of remaking one of the original Half-Life Deathmatch maps; Undertow.

I thought it might be a nice idea to post a blog about the development of Undertow and all the changes that have gone on through this process. To start things off I decided to split this blog into three parts so to speak, each covering the three main areas of the map to help organize it a bit.

Central area - Outside part of the map

So to start off and to refresh your memory here is a shot of the original area taken from Half-life 1 Deathmatch:

From the start I worked on the central area, mapping out the rough shape that it was going to be and starting to add in some details in the orangemap to finalize it. Although from the first shots it was much larger than the original it got shrunk down a great deal later on.

When working out this area I wanted to keep allot of the original features of the map so I tried to keep the same feel to it, you can see it in how the top floor outcrops slightly from the one below and with the small indents at the lower floor with hold health charges at opposite ends.

Once I had got the basic layout with some extra details done I moved onto playing around with adding materials and some props to get a better feel of how it may look. I had already though about what kind of theme I wanted to use within Undertow, basing the map off a waste/water treatment plant that was part of the larger Black Mesa Facility.

With that in mind I used some of Abe’s work on residue processing to get some inspiration as well as treatment plants in real life for my texture choices:

Above decal made for this area was to help add a little more detail to the area. As well as working on the main central outside area I had also work on the inner parts, from the upper floor areas to the surrounding corridors.

The upper floors at the start kept the original design with ladders to gain access to them but I found it to be a bit clumsy and a bit confined, so I developed into these spaces the steps instead as you can see above. And towards the last few shots a bit of material/pop development. Since the map has in both the original and this version those long corridor's I wanted to keep the conveyor belts in to help speed up movement with an option to switch the direction that they push you in to also make for some interesting fights.

That about concludes part one of this blog into Undertow's development, but to as a last treat here are some near final shots of the area as it currently stands.

2008

Black Mesa Bumpercar AHOY

(on 13 Jan 2008 by cman2k)

We were contacted recently by DeathToll_David from the Bumpercars 2 mod. He wished to make a bumpercar tribute for Black Mesa, so we obliged by giving him our Loader model.

Here's the bumpercar he came up with. It came out great, and we personally can't wait to bump the crap out of you guys with it once his mod is released.

See we got those arms, and we'll sneak up on you when you least expect it. I only hope he can animate them so they are "grabbing" all the time, not unlike some of our mod team members. Then it will be a true tribute.

Best of luck to the bumpercars mod though, we were fans of the original and we highly anticipate it's release. Check it out if you have the chance.

Peace out homeys.

The Dam - Sizing It Up

(on 13 Jan 2008 by Angry Beaver)

First things first, I said weekly and I'm writing them on a weekly basis, whether they get posted weekly depends upon whether or not they pass the media release specifications so please bear with me sometimes. I have a job during the week so I don't get much chance to pre-write the articles, but by the end of Sunday I will have finished writing one or an excuse.

Now onto the topic, one thing most beginner developers have tendency to get horribly wrong are sizing and scaling, the first real rule to realize is that real world measurements mean NOTHING in source. Technically, and this is technically, 1 unit is 1 inch. This in practice doesn't work. I've taken blueprints that buildings were built to and recreated it in Hammer so I know what I'm saying. It doesn't work. The entire room looks too small and feels cramped, and nothing aligns easily anywhere. I've always had much more success building from real world measurements if I throw them up to 130% of the size, but still there are problems with that.

Source works on the BSP file format, (Binary Space Partition), this means it likes powers of two and similar number numbers so 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024... are your friends. Another thing to note is that it handles bigger numbers much better, so from about 8 upwards is the optimal range. Keep brushwork on a 16 unit grid and other optimal values does a lot of things. Textures are easier to align, the compile tools finds the area easier to process, and you are less likely to cause overlapping and leaking brushes, this usually only matters with world brushes. With fine details where you start to need the lower grid settings you almost always need to use a func_detail to save it causing problems.

Now the two previous paragraphs are two separate points to the same argument "Build it so it looks right". We know real world measurements don't work and we know what numbers we should be using for measurements. So when building something, we build it so it looks and feels right we don't measure things we approximate and align it to the largest grid we can. A good tip to making sure it feels right is to use player starts as your measuring blocks, see where a players head height is, use that to adjust your ceiling so it feels right. This is a main reason why Orange mapping is important so you can get the scale right before you've done too many details for it to be easy to change. With time you develop a second sense for it and there are measurements on dev textures for the express purpose of getting the scale right in that early stage. One resource that helps me pin it down sometimes is here.

To summarize I'm not saying don't add detail but make sure it is a func_detail and don't expect to be able to directly build something "real" in the source engine. Architecture is an art, one you can’t simply measure and copy into to source.

Residue Processing in the Making: c2a4b

(on 13 Jan 2008 by Abe)

Before going into my blog, I'd first like to introduce myself. My name is Abe Robertson and I've been designing levels for the Black Mesa team for a little over a year and a half. When I first joined I was truly overwhelmed, not having been exposed to that many exceptional artists before. I felt it was my duty to hone my skills and achieve the level of quality that every one of them was injecting into their own work.

I eventually did get a lot better at what I was doing, but not without falling flat on my face hundreds of times in the process (as seen below).

After becoming a full team member I was promptly assigned to work on Residue Processing, which happened to be one of the most hated chapters in Half-Life. Because I didn't know exactly what I wanted stylistically, it was inevitable that I'd have a plethora of failed attempts.

This was the first time in my mapping career (I call it mapping because there wasn't much level design involved at the time) that I felt I should step back and reevaluate my level creation process. I started drawing hundreds of concepts and planning out exactly what it was I wanted to see from this chapter. I concluded that it takes place inside (and briefly outside) a waste treatment facility.

I had to get a little more in-depth than that, however. There were some features of the original that wouldn't necessarily appear in your typical treatment plant, but were too iconic to remove, so I really had to get imaginative. What I did was break the facility into chunks: chemical waste processing, the aerated grit chamber, municipal solid waste, and finally an area for composting. The art style differs slightly for each one.

The level that I'm going to briefly discuss today is c2a4b, the chemical waste processing area. The most memorable item of this particular level would probably be the radioactive sludge. We chose to keep it in, simply because it wouldn't be Black Mesa without it.

The first room went through about five iterations before I liked what I was seeing.

The room that caused me the most grief was the one that originally had nine vats of toxic waste and vertically moving pistons that the player had to jump on. Not only did the puzzle go against the laws of water displacement, it also looked like it was constructed solely so people could hop across the platforms gleefully to sweat out whatever they'd had to drink on that particular day to compensate for the lack of restrooms. For the life of me I could not get this area to work out. I would try creating these complex puzzles where you'd have to exit the room and operate a crane, or turn on a power generator so you could rotate a catwalk, but it all just seemed like overkill. I decided that for this instance, simplicity should prevail. I just made it a horizontal puzzle.

I was really doubtful when I started working on this map. Ultimately what I wanted was a fun, good looking level that made sense. I didn't think I'd ever be able to do that, but I did, and it was good enough for me, which was a great feeling.

Here are some extra screenshots for enduring my endless droning. Sorry for the low resolution.

On a Rail-y Goodness

(on 14 Jan 2008 by PogoP)

Hey guys!

I'm Liam "PogoP" Tart, recently appointed level designer for Black Mesa. I just thought I'd write a dev blog to introduce myself.

You may know me as the level designer behind the 'Ctf_quarry' map for TF2. Or maybe not. You may also know me as one of the first people in the world to have roller-skated for 24 hours non-stop... Naked. But probably not, because I just made that up.

I was brought on to the team sometime last week and was assigned to work on the chapter, "On a Rail" with Danielle "Talia" Keptres and Chuck "Atrocity" Wilson... Or as I like to call him, Chuckie Gee.

During the orange-mapping process of On a Rail (OAR from now on!) sometime last year, Talia made a lot of significant design choices. The original 5,263 OAR maps (A rough, probably inaccurate estimate), whilst an optimal number for the now aged Goldsource (Half life) engine, seemed a little too many for the newer Source engine, so she condensed those 5,263 down to a respectable 5. That's no mean feat, I tell you. Talia also found that a lot of players were confused with the layout of OAR, myself included. Whenever I played On a Rail I felt like crying as I drove by the same platform with 2 dead Houndeyes on for the 17th time (Again, a rough estimate. Though this one is a lot more accurate). Thus, to remedy the confusion, we added a satellite navigation system. OAR now features fully functional GPS, with directions spoken by Ozzy Osbourne, who offered his services sometime last year. (Disclaimer - The truth may have exaggerated in the previous sentence. Exaggerated or completely bent entirely out of proportion. Particularly the latter).

Ok, serious time. OAR was a very confusing chapter for many players, and thus the decision was made to show the player where he should be going. You follow the rail round after having gone down the first elevator until you reach a crane. The player's train will now follow the path into the crane, instead of carrying on straight forward. This means that players realise the obstacle they must overcome, and with clever use of lighting and huge "CRANE CONTROL ROOM!" signs, they should see where they have to go to move the crane. This room has also been opened up so that players know exactly how to get to the crane control room.

Anyway, this is all old hat. The maps were finished in their most basic forms, but me and Chuckie Gee (Of Gasworks fame) were brought on to OAR to begin detailing. Talia established a theme of lighting in c2a2b, so me and the Gee-ster (incorrect grammar, but sounds damn cool) took parts of this theme and established it across the other maps, whilst Talia did the same.

I'm working on the first map of OAR, c2a2a, which starts out flooded. Therefore the theme of the start of On a Rail starts out quite grungy and sewery looking. Then it progresses into the theme established by Talia.

Here's an early screenshot or two to whet your appetites:

Stay tuned (I've always wanted to say that) for more updates folks! Hopefully, my next blog will go into more detail about showing the player not to go in the water at the beginning of OAR, as it will turn them into a Charcoaled HEV suit, seeming as the water is electrified.

-Liam

Outtakes and Bloopers

(on 16 Jan 2008 by debeerguy007)

Believe it or not, voice actors are not perfect. We're human. We mess up occassionally, and sometimes during the process we become lightheaded or even frickin' delirious. And sometimes we just have really bad days. I know I have. But occasionally we'll have a day or session where we just have to let loose and have fun with it. It's either that or punch someone in the face, and that's not very productive unless you're Mike Tyson.

Oh wait a sec, he bites pplz ears off. Nevermind.

Anyway, because of this (not Tyson biting ears), the amount of bloopers and outtakes that happen during the course of a production can be abundant. Here's a small selection, some from the earlier months when we were still trying to find our way. Ah the memories.

Now, having said all this, being all loosy goosy doesn't always help depending on the material and context of a scene.

Think about the last scene in HL2 EP2 that Merle Dandrige (Alyx Vance in the HL2 franchise) had to work on. I won't spoil it for those who haven't played the game(s), but this scene in all likelyhood didn't evolve a sizeable amount of laughter or fooling around (no not that kind, yeh perv). I don't see how it could. Sometimes you have to find a place mentally for this type of scene and channel that raw emotion through. Thankfully as the security guard voice actor, all I have to do is on occasionally spurt out corny one-liners... but in a good way.   ^ _ ^

When it comes down to it, we'll put on our "serious" hats and get the work we need to get done, but sometimes you gotta to have fun with it every once and a while, otherwise you're gonna be in bad shape at the end of the day.

And Mike Tyson will bite your ear off.

And now, for the sake of adding a special bonus, here's an clip featuring Mike "cornettheory" Hillard (http://www.onlyintheory.com), one of our scientist voice actors at his best, reciting lines from the infamous "Don't let it overcharge" scene. He does 3 takes all the way though, reading his scientist lines in proper, while deciding to read my guard lines in an... interesting manner. He also seems to have a knack at narration, apparently. Everyone on the team found it rather humourous. Myself included.

(Disclaimer: Any and all materials presented within this webblog are work-in-progress and, as such, are merely presented as approximations of the final ingame product. HL1 and HL2 sound effects used for nostalgia purposes only.)

The Dam - Feature Presentation

(on 19 Jan 2008 by Angry Beaver)

Last week’s article was criminally devoid of Black Mesa content so this week will remedy that. This week I’m going to be talking about adding a map feature and the process I used to create the bounce pads found in bounce.

First lets define what I consider a feature, as far as I’m concerned that is any map specific setup that is not a part of regular game play, in this case the bounce pad, your regular DM maps don’t all feature them and their implementation is based solely on the map and its needs, their a feature to enhance the map. When deciding if your map needs a feature or whether you want to add one the biggest question is always “Why” and “What does it add/change”. Simply adding a feature because it’s cool and it doing nothing quickly relegates it to the realm of a gimmick, something fancy for extra attention that really does nothing, and we all hate gimmicks, right? So I basically answered the following: Why are the bounce pads there? “To keep an open structure to the level but allow multiple and dynamic routes through the level”. What does it add? “A degree of freedom and interactivity that cannot be achieved through simple slopes or ladders… plus its cool”.

Now we know why were adding the feature and what it’s supposed to do let’s get down to the mechanics. An understanding of the game engine usually helps this process go faster but if you are lacking the experience or don’t know how it will work EXPERIMENT and explore your options. So the first point to consider with our bounce pads is that it’s supposed to throw the player up in the air, checking available entities gives us two options phys_explosion and trigger_push.

- The phys_explosion is highly uncontrollable force that covers a radius and is a very sudden effect, this doesn’t seem reliable.

- The trigger push is only in one given direction but is a very smooth force, this seems quite reliable so it’s my choice.

As noted I went with the most reliable effect, bugs generally happen when an unreliable approach is used and bugs can either be exploited or ruin the game play so their rarely what the Mapper wants. Testing however revealed a problem, the pushing force only pushes the player upwards when he is not touching the floor. This is basically a physics hack you find in source, you’re glued to the floor and not effect by upwards pushes. This mean the player would always need to jump which is un reliable and hard to explain to the player until they see it once. Your feature should always be simple so to keep things simple for the player we need to figure out how to detach the player from the floor. The simplest way to do this is either to bump the player up or let the floor drop out from under him, a quickly moving brush would do the trick so we take a look at the candidates: func_movelinear, func_door, func_tracktrain, and func_button.

- The func_movelinear is designed for this type of situation, just a quick movement in one direction nothing fancy; however, this is also why I’m disregarding it, it has little or no output so it’s hard to tie other effects into its movements.

- The func_door seems like an ideal candidate, easy quick straight movement and lots of outputs to tie things in!

- The func_tracktrain while meeting the input and output criteria is going to be disregarded because it specializes in complex movements and I only need a simple movement, plus the door is easier to set up with the same level of input and outputs.

- Last but not least is the func_button and it gains use in the final version of the bounce pad, it provides nearly all the outputs of a door but it also has some more inputs that make it a better choice than the door.

Early revisions of the bounce pad used the door until I decided the func_button gave me features I was after *wink*, so don’t be afraid to re-evaluate the plan. Now the final problem to setting this up is triggering the un-sticking mechanism so the player is affected by the push and turning the push on. The choices are either using the “Touch Activates” flag on the button or simply using a trigger_multiple. I opted for the trigger multiple so the bounce pad could sense objects other than the player *wink*. The shot below is an exploded version of the bounce pad, it shows how each component is put together into the final version (and that’s just a temporary placeholder you’re seeing for the bounce pad model).

1. The trigger_push: It’s turned on for a very short period of time so the actual size is just the area of effect for it.

2. The trigger_multiple: This is for sensing objects the bounce pad should fling and sits just above 3.

3. The func_button: This is made up of 2 parts but basically un-sticks the player so they can be pushed and triggers associated sounds and effects. A: The player needs a very flat solid reliable base to be flung from for reliabilities sake. B: The other objects a bounce pad could fling do not need such a directly upwards push, tapering the edge gives the other objects trajectories other than a boring straight up.

4. The ‘model’ and associated effect: Nothing but eye candy, and with this place holder not good eye candy at that.

5. The assembled device in Hammer showing you how all the effects eventually overlap.

Now for those who missed the *winks* that’s a hint at some of the things I’ve changed up in bounce to take advantage of the new source features. Bounce is still maintaining the tricks, features, and ninja like action of the original so don’t worry; however, I did make it more beginner friendly so likewise I added more tricks for the pro’s and I’m sure your going to enjoy it.

The Dam – “I say Clip it, Clip it good"

(on 27 Jan 2008 by Angry Beaver)

As all Mappers know players are tricky people, they have ways of finding things in your map and doing stuff you never intended. Map exploits are always found by that one player and every time the Mapper has to release a fix to solve the problem that’s ruining the map or rely on Admins to deal with the players who abuse it. A little bit of fore thought and player control helps prevent this problem.

The player clip textures is one of the Mapper’s best friends when it comes to player control and also conversely the players best friend when it comes to map flow, let me show you with a shot of the crossbow nest in bounce (of course the shot is non final).

As you can see there is clearly a large amount of player clipping going on in the area, some of it to stop the player from doing what I don’t want and some of it to stop the player from getting hung up. The clip above the wall is because the player is not meant to get up there and the cliff is to be shear. The sloped brushes above the objects are so the player cannot jump on top, or if he is falling that he falls to the ground itself. If the clips were not there players could climb the wall and get to unwanted places. The ledges would not be physically wide enough to support a human; however, as any ledge can support a player in game its up to the Mapper to enforce it. On the same token if the player plans to move in a direction, the player shouldn’t be stopped from doing so unless there’s a wall directly in front of them, a common situation is detailed below.

The green player is running down the side of the hall when the red object appears in front of him, the player plans to back away to deal with it. In the first picture there are no clips and so the player gets stuck on the pillars in the hall, this stops the player’s movement and more often than not kills him causing him to dislike the experience. In the second shot we add some clips that simply bump the player round the detail, the player keeps moving the way he intended and feels no animosity towards the game or its designers. For that purpose the rest of the clips were added onto the sides of the objects, clips to allow the player to brush past the door without getting stuck on its frame or its button, clips to hide the complex prop indented in the wall so the player can keep flush to the wall. While it may not be an issue the 10x you play the 1 instance where it is will leave that sour taste in your mouth regarding the area.

Spending time to analyze how a player might move round the map and adding in clips to ensure the players movement will be smooth is often overlooked by the Mapper themselves as it never directly concerns them, but it’s one of the touches that make your level more enjoyable and should be considered by all that want the player to enjoy their work every time they play it.

Our Steam Community Group Is Awesome.

(on 29 Jan 2008 by cman2k)

Our steam community group hit a wonderful milestone today.

Need I say more?

The Dam – Coffee and a Rant

(on 02 Feb 2008 by Angry Beaver)

I’ve warned you that sometimes I may rant and this is going to be the first, quite simply it’s going to be about what it means to be a Level Designer. Please remember these are my personal views, and if you have problems with them address them to me, not to the rest of the team.

Watching a re-run of X-Play (A computer game review show for the un-initiated), they had one the interviews with an industry professional who simply introduced himself as a “Background Artist” with mounting distaste as the interview progressed it became apparent to me that he was supposed to be a Level Designer. This astounded me in many respects because of quite simply the difference the terms imply. A “Background Artist” is simply one who makes the surrounding pretty and interesting, they do nothing more than a special kind of art that’s not even really noticed that well just because it’s the background not the action itself.

While the position itself deserves respect and I’m not trying to take away form that it’s like the difference between a writer in a newspaper and TV newscaster. Both of them do the same thing, report the news, but the actual way and method about it are drastically different. Level Designers and Background artists both make maps but in completely different ways. A Level Designers job is to understand game play, analyze the action (players and AI), develop an interesting fight that takes advantage of all the weapons, allow tricks and features for each weapon or class, to build the game play from the tools the programmers have given them. They must also then construct a visually stunning and interesting environment using this framework for the game play they have developed. Being a Level Designer is more than simply creating a pretty world, its understanding how a player moves, how an enemy moves, developing a world that convinces you both are right and allows the player to have fun inside of it. A level designer’s job is to basically ensure the game play for the game is fun and interesting.

Because of everything a Level Designer is expected to do the best are usually part Programmer, part Story Teller, and part Artist. Programmer skills are required to control entities and add features and effects to a map, the Story Telling skill are required to ensure the map has a feeling and progression, and the Artist skills are required so that it can be stunning and beautiful. Now do not get me wrong here Level Designers are only as important as the rest of the team, no more, no less. What Game Play would there be for a Level Designer to use without a coder to create it? How would he create a believable and interesting environment without Sound Techs, Texture Artists and Modelers? A Level Designer cannot stand on their own without a team to give them the tools they need but it is still their job to ensure the tools are used to the best effect as the players opinions of the tools is so often shaped by the game play in which their used.

Looking at the community for Level Design it is unfortunate how many Background Artists I see, and I want that to change. I’m always willing to teach those willing to learn, so don’t think of this as an attack; instead think of it as a wake up call. I’m hoping you wake up and smell the coffee because the community deserves fun maps to play their games and for that we need Level Designers, not Background Artists.

Gasworks, Gameplay, Caustics?

(on 06 Feb 2008 by Atrocity)

I decided today would be a good day to post a new dev blog about Gasworks. Mainly because you deserve to know what is going on in the world of BM.... if we want you to

That being said, when we begin work on level we obviously go through the orange mapping phase, and in some cases areas have to be added to levels to begin to make them look remotely realistic. [See gasworks before, and below] The whole front facade to gasworks was made to make the whole factory seem more interesting, and used lots of reference from a trip where a few BM guys went to an abandoned power plant.... good times....

Anyways, when working on gasworks I decided I wanted to try to have some more balance in the gameplay on the surface. It was a lot of fun holing up the top floor of the 3 story building, but I wanted to add some new dynamics to the gameplay which are under testing. [Please understand they are UNDER TESTING, so please do not flip out]

Some of these changes range from small things like adding small traps in here and there to spice the game up in duller areas, and some are as far as the main change to the front of the 3 story building. Originally it housed a rocket launcher, and the player could trip mine the ladders, secure the top and camp away. Though this was fun and I did do it myself, I thought what if I make it a little harder to camp by keeping the rocket launcher indoors, but the extra ammo outdoors. So what I decided to do, which is barely visible in this screenshot, is that if you are on the top floor you may run out the right side [facing outwards towards the level] and go down a set of steeps to the stoop of a smaller building. This area has 2 rockets, and I think I added a small battery for a little extra bonus. This now forces the player to show is ugly head in the heat of battle, potentially making this a lot more fun. However it could also make it too hard to camp and no longer fun.... play testing will prove this true or false.

Another thing you can notice in this shot is the additon of the catwalks and pipes as compared to the loading crates. When working on this area I decided it needed a change from the cargo crate yard feel to something more industrialized. I went in and took the footprint of the old objects and added brushwrok in to fill the old footprint. Then I modeled it out in 3ds max, after which it was passed back and forth between artists until we got that final prop. This provides a different look and is a bit taller then the normal crates which may provide extra protection, but it should be enough to still make navigating this area fun. One thing that will be tested for sure is the catwalks on top of this area. Though they do look nice, it was added for extra vertical combat, but may make this area have supreme protection from snipers and rockets from above, which lets face it is no good. More to come on this later.

On to new things like caustics. We of course haven't implemented real caustics, but we have a very convincing approximation made by our rockstar texture artist, Mark "Jenn0" Bing.

I decided it would look nice if Gasworks had some of this effect in the bottom area due to the fact that it is filled with awesome water. I got our sweet ass texture and applied it to invisible planes, and wrapped them around. I am still currently tweaking visablility values and colors so it is by no means final, but something I wanted to share.

Keep in mind ladies and gents, these are VERY wip shots. I am still working on this level while helping with other chapters, and have work to do to visuals and gameplay, but hopefully some finalized shots will surface in the future.

The Dam – Seeing The Forest Despite The Trees

(on 10 Feb 2008 by Angry Beaver)

When taking a map to the level of detail found in Black Mesa the biggest problem is usually visibility. Now anyone with the slightest knowledge about mapping is going to think this is on optimization and well, they’d be wrong.

Above is a picture from my application to the team, this pictures is NOT from Black Mesa and NEVER will be. The reason why I include the picture is because what it shows is quite simply a mess. Imagine trying to pick out details in the 2D views and work with them, even while the 3D view is much clearer it’s still really hard to get at some details because of everything in the way. With views like this that contain so much detail how does a Level Designer actually ever see what he’s working on? That’s what I’m going to provide some tips in today.

There are two basic tools for cleaning up your view inside of Hammer; the most commonly used being the Visgroups located on the right and the other being the cordon tools located at the top.

Visgoups are Hammers way of keep track of objects, there are two tabs for the different ways it tracks them. The Auto tab is the one Hammer automatically upkeeps and determines what goes into what area, and the User tab is for ones you create yourself. To enable or disable a Visgroup simply click the check mark. Empty means not shown, black means all shown and grey means only some are shown possibly due to other Visgroups. Entities can belong in any number of Visgroups and they are very practical for thinning out what you’re viewing. Take a look at the picture below, to see how useful it is in some situations.

• The first is what the scene looks like in Hammer with everything visible, this is what you need when compiling as hidden Visgroups don’t usually compile.

• The second is what I would be looking at for brushwork optimization, only world brushes, hints, and area portals are visible as nothing else affects the world brushes.

• The third is what I’d look at for NPC interaction, nodes and major obstacles only. This is only world brushes, func_details, props, nodes and NPCs only.

• The fourth is what I might look at for rigging entity I/O systems, This one is a little trickier: I enable the point and brush entity groups and then disable things like lights, props, area portals that wont be involved in the I/O system to clean it up a bit more.

You may of noticed the approach isn’t perfect but that was only done using Auto groups, creating your own groups allows you that extra degree of control that’s missing from the auto groups. To make and edit what brushes are in you own Visgroups simply select an object and bring up its properties and go over to the Visgroup tab. There the check means it’s a part of that group.

The other thing to mention is the use of the cordon tool. At its base all it simply does is ignores whatever part of the map is outside the box it draws. This is true in Hammer and in the compiling process, most often used for error finding or cutting down compile times using it while working on a map can significantly reduce the complexity of an environment so that the 2D views are clean and useable. Below is a before and after of using the cordon tool.

Still not perfect but with Visgroups as well it can be definitely be good enough. Hope these tricks help you all out.

I'm Such A Tease

(on 23 Feb 2008 by cman2k)

Apparently you guys get a little impatient when we skip a week without a new blog.

This last week has been a busy one, for me personally as well as many others. We got people working hard in preparation for graduation from school, a few of us were very busy this week with GDC and GDC-related activities for our jobs, etc.

Regardless though, we've been working hard as always. It's easy for everyone to think that just because they don't see the new characters, features, levels and models we make everyday, that we aren't doing anything.

So I've come up with something! I'm calling it a tease frame. You will probrably either love it or hate it, but every now and then i'm just going to take a bunch of screenshots of stuff we're working on and give you a little thumbnail preview gallery. The thumbnails are to serve as a sneak peek of sorts, of things that are in-progress and that you would normally have to wait for to see.

Hope you like it. Speculate away. If you like butts, shout it out. I LIKE BUTTS.

The Dam – Needles in the Haystack

(on 24 Feb 2008 by Angry Beaver)

The Blog for Feb 17th was skipped for those that didn’t notice. I did not get the chance to pre write that weeks article as I had some things that needed doing for Friday and after that I spent the rest of the weekend enjoying the fact I had recently been let go from my job

This week I’m going to be dealing with how to find things with Hammer, be they compile problems or rouge entities. There are several utilities and methods that can be employed to track things down so first we’ll start with the tools built into Hammer and then cover so ways you can manually track down problems.

First we’ll start with the simplest two which are Goto commands. Both are available under the View menu “Goto Brush Number” and “Goto Coordinates” Often you receive a message about a brush and this coordinates or brush X without these commands you’d be fishing around the map but both will take you to directly what you’re after. Next is an invaluable utility the entity report, found in “Map -> Entity Report” it appears as shown below.

This shows every entity in the map grouped by type and allows you to filter them using the options below. The “By key/value” is a useful one as with it you could find every entity that has a specific model or every light with the same color. Another useful tool is Alt+P, this scans the map for problems and pops up a message, most you can usually ignore quite easily but there are a few to take note of.

Running this occasionally is a good thing as it can show problems before you know about them. Often there are things you need to find without enough information to dig up.

Most problems are found at the compiling stage and in that window it tells you how your compiles going it’s a report of what went right and what went wrong. The untrained eye often skips over the problems telling everyone their compile went fine but they still have an error. The folks over at Interlopers have developed a great tool for making sure you don’t miss any errors; Interloper's Compile Log Checker post your compile log in there and it will find a good 99.9% of them. One approach is the inclusion/exclusion this is easiest done with visgroups. If an error occurs hide the suspect visgroup, then recompile. IF the problem goes then you know its one of the entities inside that visgroup. If it doesn’t keep hiding more till you think you have it pinned down to one group which you can then look through. Sometimes though you know the problem but have no clue where it is and without any reference information you can’t track down where it is on the map, in this situation its best to turn to the Isolation Method. By halving the map with the cordon tool it pins down what part of the map the error is occurring in so you can look for it more precisely.

Between all these methods and tools you can usually pin down an error pretty quickly, resolving the error is another matter altogether.

The Dam – What's your angle?

(on 02 Mar 2008 by Angry Beaver)

There's one thing that several mid range level designers will tell you to stay away from; the carve tool, angles, vertex editing, and others. Occasionally they're right but one thing a Level Designer should never be afraid of is angles as it will do nothing but start to make your maps boxy. This week is about how to do angles properly.

The biggest thing with working angles in source is to forget them, 10°. What's that's? 22.5°. I don't know what you mean. So what do you use instead of angles? The answer is simple Ratios. Specifically rise:run , how many units you go across compared to how many units you go up.

These are what I consider the cardinal angles for level design, there's only a few of them but as you can see they cover most major types of angle. With brushwork angled like this you can line up vertices onto the brush part way along easily, this means you can easily create areas that are on a good slope without worrying about making everything func_detail, see below.

As you can see a lot of the map is at odd angles, granted this picture is from it in a very WIP state. I scrapped the map eventually because of how much custom content it needed and the fact that the sizes of a few things were off. I assumed wall sizes were constant through the building whereas they were not causing sizing issues. Regardless of that it’s still an excellent example of using ratios over just rotating things. It could be nowhere as neat or detailed if the ratios were not used. Another thing is that it is much easier to keep shapes valid when using ratios. If one were to make a cylinder then want to slant some of the edges, for those who don't know what their doing it is simply impossible as invalid brushes are created without fail. If the sides are kept on a ratio, it becomes much easier to deal with. Ensure both the top and bottom of the slope use the same ratio and you will be able to slant that face as much as you want, using the same ratio doesn't mean the same length so it can work easily for you; however you may find to line things up easily you need to go down several notches on the grid size.

Anytime there's a slope or an angle in your map whether your fitting a doorway or just throwing on a decal you should try align it to a ratio so whatever work you have to do with is made easier for you. Ratios won't always save you though so resorting to triangulating brushes is a valid option.

The P.I.T. - New style, same structure

(on 04 Mar 2008 by xTc)

My name is Kilian Henkel, mostly known under the nickname 'xTc' and I'll try to introduce myself with this devblog entry as Liam did. Don't expect funny jokes or comments like he did, I'm a German, definitely NOT funny and fully concentrated on the stuff I am writing right now.

Let me think... I was brought onto the team about 3 months ago as a full-time Level Designer and directly assigned to Snarkpit. Don't remember? C'mon... you know this map... with those snarks coming out of the pipe (for some reason), traps n stuff.

So I spent my time with creating the layout, adding textures and putting in props. Since Snarkpit hadn't a real theme with those blurry, reddish walls I had the option to come up with an entirely new style. The only thing I was bound to was the structure. That's what the headline says. So what to do, if you have thousands of possibilities to how the map could look like later on?

At the beginning I must say, I really had no idea what to comply with so I built towards a target, and I didn't even know what it was. After a few days it was about time to figure out a plausible theme to continue work without making unnecessary decisions. And in fact, I made up one!

After a big "opening" of the map I think it's quite hard to recognize this level in some cases. Snarkpit isn't done yet, but due to the beginning of March I'll pause work here and start with Office Complex, my new chapter under the development of Johnathan 'Cpl.1nsane' Welsh.

But how much actually is snarkpit done? See for yourself.

Recognize this area? If not, have a look at the picture below. You'll realize the raw structure like the walkway on the right or the healthcharger. That's exactly what the headline says.

So what does P.I.T. actually stand for? I'll leave you to figure that one out.

Greetings

Kilian 'xTc' Henkel

On a Rail 2 - The Wedding

(on 04 Mar 2008 by PogoP)

Hey guys, this is my second devblog since I joined the team a couple months ago. It’s been a really crazy few months, with exams and other commmitments, but work on OAR is coming along nicely by both Talia and myself.

It’s been a really good experience working on BM. The team is very professional and gets stuff done efficiently, and everything they make is of a very high quality. My level design skills have really developed and had a chance to flourish whilst working with these guys; I’ve picked up a lot of tips and tricks.

Anyway, the real point of this blog is to focus on the elusive ‘On a Rail’ chapter of Half-life, not to brown nose the team. I’ve played OAR literally dozens of times since joining the team, and I now know it better than the back of my hand. If ever there was a question about OAR in a pub quiz, I’m your man. (or a questionabout ‘On A Gondola’ as ‘Bluseychris’ christened it – that quote is in my signature on the dev forums. Congratulations!)

I really like the atmosphere portrayed in OAR in HL, it really had a gritty, abandoned feel to it. It is this quality that I really wanted to emphasise in the BM version. Lighting is key to the gritty atmosphere, so I retained most of the colours from the HL version, whilst layering new schemes over the top where appropriate.

The one thing that I foresaw as a problem in OAR is how much ‘tunnel’ there is in the chapter. There’s literally miles of abandoned tunnels, which was left very bare in HL. In the days of Goldsource, this was acceptable. However, times have moved on, and with new engines comes a higher requirement for detail. Therefore, I broke a lot of the tunnels up by having little walkways and alcoves off to the sides that show this transportation network was actually thriving and used for something at one point in time. I also added a plethora of ventilation ducts and piping systems along the walls and ceilings of the tunnels, which really helps to break up repetition.

Here’s a couple of screenshots that show what I’m on about. There will be a HL screenshot followed by a BM screenshot. Please do bear in mind that these shots are still WIP and are likely to have a lot more detail added to them in the future!

That about wraps up my devblog for now. I’ll finish it off by showing you guys progress on the area I first showed when I joined the team. On the left is before, on the right is after. You can really see how my time on the team has developed my skills.

The Dam – Hammer time? Can't touch that

(on 10 Mar 2008 by Angry Beaver)

Firstly apologies for the late post but as Brawl was released Sunday I’m sure you can forgive the delay as I needed to teach all my friends to fear Yoshi again. But I digress this week I’m taking a page from the MC Hammer rather than the Valve one.

This week is all about the work you should be doing before you even open Hammer once. Now to be clear I’m saying “should” not “need to do” sometimes I don’t even do the prep work myself but on the whole it helps and “should” be done. This topic could cover a hundred blogs itself so I may revisit in the future and may be a little light on some of the details today.

First were going to address the important questions when dealing with anything; who, what, when, where why, and how. Making a map without knowing what you’re making will result in either a terrible disaster or a flash of inspiration that will probably need you to restart the map anyway. Whether it’s a game play idea like fighting off a horde of enemies, or a location idea like a roof top area, or even a storyline idea like painting a tragic hero you need to know what it is you’re trying to map. To take an example I knew what I was going to be mapping for BM first was Bounce, the dm level.

Once you have that basic idea you then sit down and expand on any of the questions you didn’t answer with the original concept. Figure out who your player is what he’s doing, how he’s going to get it done. A level should be planned front to back before Hammer is opened, with multiplayer maps that means sketching it out, with single player maps that means having points notes of the story and everything that’s supposed to happen to the player. In my case with bounce I already had the layout and that was the one thing I was going to change very little, but there were problems that needed addressing.

Once you have the expanded idea and are thinking about Hammer, stop and go back to your notes. You should be doing what I call “Rationalizing”. Make it make sense, for example when I started work on Bounce I sat down and said “What the ****!” Everywhere I looked bounce made no sense. It was just a collection of passageways looped around a recycled part of the tram ride with a couple of bounce pads thrown in to mix it up. So how did I explain it, quite simply really it was a water collection and distribution facility from before the dam was built for BMRF. The wall in the center? It separates the area where water is collected from where water is pumped out of. The room above the wall? That controls the gate inside the wall. The high ledge with a ladder? That leads to a control room built into the cliff overlooking the canyon. The wide pipe leading to the pool room? The main flow from the collection areas. The pool area? An open air collection area to collect surface run off and water from several other collection sites. The rubble in the pool area? The pool is topped by a walkway area that has some collapsed pieces. The tall thin room? Sewer access and drainage for several incoming pipes. The thin pipe from the tall room back to the main area? No longer a pipe, instead a flow monitoring station that’s quite cramped inside. The ledge with the rocket launcher? Now an overpass to allow incoming road traffic. You look at the layout and its barley an inch different, all the thematic changes with very few material differences in the floor plan, and that’s what I mean by “Rationalizing”. It makes sense now but I barley changed a thing and explained a million reasons for detail and made the map something more than a collection of interesting cliffs. Rationalizing doesn’t mean scrapping your idea because its outlandish, just how to bend it to common logic so it feels more real.

So with all this talk about what I’ve changed in bounce I feel its only fair to give you a little teaser shot of what the level looks like, of course this is still a WIP so nothings final.

The Dam – A focus on the convex

(on 16 Mar 2008 by Angry Beaver)

Get it? Cause convex lenses focus light… man I wonder if anyone has picked up on half the puns I keep using for article titles. This week is simply going to be on invalid brushes: how to recognize, common causes, common symptoms, and ways to avoid them.

When it comes down to invalid brushes there are really three categories: holes in the mesh, multi planar faces, and a concave shape. Below is a picture showing all three in practice with how they would look in Hammer.

While the implementations vary a lot the problem always stems from one of these issues. For those unsure of what a plane is, think of it as 2D grid. It can be any rotation in 3D space and is infinitely large, that’s a plane. On one brush each face is supposed to have a unique plane for several reasons. Getting a hole in your mesh is the most difficult error to create but excessive complex off grid brushwork is a good a start to getting there.

Almost unanimously the cause for invalid brushes is the vertex editing tool and complex primitives. Using simple primitives like arches, cylinders, and blocks; and simple tools like clipping, resizing, rotating it is impossible to produce an invalid brush. The reason complex primitives suffer this problem is that they snap vertices to a grid of 1x1. This is usually disastrous as to maintain the shape properly vertices would need to be placed on decimal locations like 12.4 54.2 64.3. When rounded the vertex’s movement almost always causes a multi planar face. The reason the vertex editing tool can cause them is nothing more than inexperience. Properly used the tool will never cause them, but used the wrong way it can create them in an almost guaranteed fashion, this is why some other level designers advise against it.

Generally there are two main symptoms for invalid brushes, changing shape and disappearing. Either can appear to happen once inside the game or when re-loading the map into Hammer. This happens because Hammer saves the map file and that saved file is what’s passed to the compiler. So the root causes of the disappearing and misshapen brushes is the saved file, the reason is very simple. As I mentioned earlier each face is supposed to have a unique plane, Hammer saves each plane for the brush and then defines the faces, edges, and vertices for an object from where the planes intersect. Doing it this way exponentially saves file space for storage and processing; however, it’s what causes the problem. If just the planes are saved lets look at what that does to the types of invalid brushes.

Holes in the mesh – Some faces will be infinite, if there’s a hole in the mesh some of the planes may not ever touch, and there’s no way a valid brush could have infinite size.

Multi Planar Faces – If multiple faces have the same plan how does the equation handle that, do both planes constantly intersect creating infinite amounts of edges or do they not intersect each other and have duplicate faces. Neither sounds valid, so how about a face with multiple planes, well only one will be stored. This means that the brush won’t retain it shapes and will be entirely different when loaded and is pretty much the sole cause for that type of problem.

Concave shapes – A concave shape bends back in on itself, so how are the intersections for that handled, a plane could intersect other planes before they intersects the planes they were meant to, there’s no way to tell the valid shape any more as there’s a million possible shapes to be made depending upon the order processed, none of them right. The faces of concave shapes sometimes appear to jump outside of the object and other issues causing weird shapes changes.

So now we know what invalid brushes are, how exactly do we avoid them? There are four approaches I use: Triangulating, Measuring, Resizing, and the Line Approach.

Triangulating – So I’ve talked a lot about planes but never actually mentioned how one is defined. As far as source is concerned a plane is defined by 3 points. Think of it like this, you have a piece of cardboard and 3 long sticks. No matter where you move the 3 sticks or what height you make them you can rest the cardboard so it touches all 3 sticks. If you used less sticks, there’s lots of ways of it could rotate all or fall off. If you used more sticks then you can’t have them anywhere you want as the cardboard may not touch every stick. So with 3 points you can ALWAYS get a valid plane, and there’s where triangulation comes in. If you face is triangular it’s impossible for the face to be invalid, if every face of the brush is triangular it’s impossible for the brush to be invalid. So why don’t we triangulate everything? Simply because the source engine batch process polygons, if 1 face has 12 polies it will render faster than 12 1 poly faces. So by triangulating brushes you’re preventing source from batch processing the faces and making your geometry more expensive to render.

Measuring – The main thing behind measuring is simply keeping track of the shape your building. If you’ve put the top at an angle, remember that ration, then when you have to slope or adjust the other side you can match that ratio and keep it valid. Going back to the stick analogy, if you know the exact heights and positions of the first three sticks you can add a fourth that touches the cardboard if you measure where it should go. So by keeping track of the plane your face is on you can create many sided faces on really odd angles, this is my preferred method despite being the most time consuming and requiring the most experience to do effectively.

Resizing – This method is one that’s mostly looked down upon as it always creates off grid vertices but if its func_detailed then it’s tolerable. The premise is simple, build really really big; say a good 20x bigger than you want it to be if not more. Then once source has sorted out the invalid brushes and nudged things (reloading the map if needed) so they fit then you simply scale it down to size. The only time you ever catch me using it is with the sphere primitive as that snaps to a 1x1 grid, so with it being oversized that means smaller errors when first created than it would at the correct size. I do not advocate the use of this method, but it is something you can do.

Line approach – This method only really works for concave shapes and holes but it basically goes like this, if you draw a line though your object at ANY angle it should only enter and exit the brush once. If it does less or more your shape is invalid. Mentally that may be a little hard for some people to grasp so the way to do it visually is to cover the brush in a transparent texture. Then when you look at the one brush if the texture ever appears to double up you’ve got a concave shape.

The Dam – Water in depth

(on 23 Mar 2008 by Angry Beaver)

Well something took the website down for a couple of minutes and that apparently seems to of killed all the previous comments on the blogs, sorry bout that guys were seeing if there’s a way to restore them but onto the topic. As an aquatic rodent I know a few things about building with Water so this week I’ve decided to impart some of that specific knowledge. I’m going to talk about the different types of water, how you can use them, special waters and typical problems.

Realistically there are two types of water Expensive and Cheap. Expensive water refracts, reflects, reflects dynamically, is partially transparent and looks pretty. Cheap water well… it uses cubemaps, deforms them a bit, and only its mother could think it’s a pretty effect. The actual mechanics of the water is the same but the top surface differs drastically between the two. People sometimes wonder why there’s the two of them, basically its performance. Cheap water is called cheap rather than ugly because it renders much faster than the expensive water effect.

Now there’s one thing that makes using expensive water all the time require a little bit of skill. Expensive water basically takes the top of the water, flips what’s there and puts it into the reflection; however, because of that you cannot have the top of the water at several heights inside the same Potential Viewable Set (PVS). So what does that mean? Basically you can’t be able to see two faces of expensive water if one is higher up than the other, the engine can’t determine what top face to use to approximate the reflected geometry so it ends up causing a graphics glitch in the waters surface itself. The PVS is what’s used to determine if you can view the waters surface and the basically refers to what the game thinks is visible and is rendering rather than what you actually see in front of you. The error only appears when your PVS includes both water heights, until then the engine doesn’t notice the problem, so something like a waterfall cannot have expensive water at both top and bottom because a player would be able to see both and in some areas, unless you constrict the player rather specifically to prevent them from seeing both ends you will see visual glitches.

Now the basic way to create a water brush is to texture a brush all in nodraw and make the top a water face. Simple enough but that doesn’t explain func_water_analog. There’s 2 main reasons to use a func_water_analog, when the water needs to move, or when you need a volume to be water or you want to force a cheap water effect from an expensive material. The func_water_analog can’t take a proper expensive water texture and will turn it down simply because this water can do simple movements like a door and even be attached to parent hierarchy, an expensive water texture on a func_water_analog doesn’t count as cheap water unfortunately. For a water to render properly you MUST compile VIS, if you don’t compile VIS it cannot determine your PVS and the geometry that it might reflect meaning the waters surface wont render. Simply selecting VIS isn’t enough you should ensure there are no leaks or other errors preventing VVIS from being run.

C-LOS UP IN THE HIZZY

(on 25 Mar 2008 by cman2k)

What up.

First off, I've seen some of you complaining that we haven't been "proffesional" enough in our blog posts. Stuff isn't spell-checked, hard to follow, etc. SCREW YOU GUYS.

I believe the intention of this blog is to give you guys more regular updates. If you want that, then I aim to deliver that by giving my team a place to post that isn't polished & proffesional. A place where they can feel free to joke, misspell words, show WIP stuff and in general communicate with you guys, without the air of proffesionalism that surrounds every other aspect of the mod. That shit gets stressful, and time consuming, and while we are committed to it, it doesn't belong here, on the blog. That's certainly not what I made it for.

With that out of the way, onto the fun stuff. Development updates!

Someone let the cat out of the bag that we have indeed switched over to the EP2 or "Orange Box" version of the source engine. Smooth move buddy. We meant this to be a surprise but now that you guys know, we might as well tell you a little bit about it.

It ended up taking about a month of time to do it and do it right, and it has gone pretty smooth since then. I've personally had the recent privelege of playing through the first two chapters of the game, in the EP2 engine, on my 47" TV, hooked up to my laptop, with an xbox controller. It is sweet. The new particle effects, shadowing, tools, and all the of the improvements the engine brings were definitely worth the extra work to make the move.

Besides that we've been making some awesome progress elsewheres. One of the very cool things that we've been doing is hooking chapters up together, so you can transition between them. It is a really awesome feeling to walk from one chapter, to another, and into another. It really starts to feel like a game, you know?

We recently brought on a new programmer and a new choreography guy, who we were in desperate need of, cause choreo is no joke. It's a lot of work. We're getting some of the weapons actually finalized which is AWESOME, with sound and ammo sprites and FX and everything. It really takes forever to bring all those pieces together and have them all work well with each other.

As many may have guessed, the "big surprise" we had planned has been delayed, pretty much entirely due to the fact that we decided to switch engines, and now the surprise will be that much sweeter. We shouldn't have put the teaser-image up the way we did, and I apologize for that, but rest assured that when it comes it will be mind-blowing, and the wait will be worth it.

And that about wraps it up for now. I typed this on my lunch break just to appease you. I will be hungry all day now. I hope you appreciate that.

Peace out homies.

Blast Pit Modeling

(on 26 Mar 2008 by [BMS-Dev]Frank)

Hey guys! My name is Frank, texture artist for Black Mesa. In this short blog I will discuss the process of prop creation and how level designers, 3D modellers and texture artists work together to turn a game level into an actual world.

Detailing the environment is one of the more important aspects in level design. It creates a plausible environment, assuring players to be immersed into Black Mesa.

Details can be all kind of things, from generic junk (like coffee mugs, trash cans, crates, power boxes etc.) to more specific models, such as structural supports, oddly shaped railings or the AMS found in the Anomalous Materials lab test chamber.

Items from the first group are usually created by our 3d and 2d artist without much collaboration between them and level designers. Once created, the models are uploaded to our build, allowing level designers to choose from a large amount of generic props to detail their worlds.

The second group asks for much more collaboration between level designers and prop artists. Models need to fit in with their surrounding geometry, and textures need to blend in perfectly with the art style of the level.

To explain this I'll show you an example of the opening level of Blast Pit, which is being created by Chris 'Stormseeker' Horn.

Because of the odd shape (a huge train tunnel going in a semi-circle, I'm sure you remember it ), a lot of new props had to be created from scratch to fit the circular design. Stormseeker designed the level and created ALL detailing with brushwork in Hammer. He out so much detailing it, the maximum number of solids was exceeded and he was unable to compile his map. Here's a hammer-shot of the start of the tunnel, the train platform area:

To bring down the number of solids while remaining the level of detail , complex brushwork needs to be converted to models. In this case it's pretty obvious where all the detail went: the tunnel supports, the pipes, the tracks and the railings.

To convert them, all objects are exported to DFX, a format that can be loaded in a 3D program.

The objects are then recreated by the modeller (in this case, me) using the DFX as a guide. Finally it is textured to fit the style of the rest of the map. Here's a couple of renders of the props made for this part of the map:

Once compiled and committed to our build, they can be placed in game. As you can see, they fit perfectly.

One of the drawbacks of this technique is the sheer amount of level-specific props being made for Black Mesa. So far we have made over 650 (that's right, six hundred and fifty) unique, finalised props! This does not include cumulative props such as gib parts for crates/machines/mugs/etc. This builds up to a fairly large installation file that all of you need to download when release time comes. However, I think we can all agree it's worth it .

I would've liked to show you some in game shots of this particular area, but unfortunately the map can not be compiled yet, a lot of converting still needs to be done in this map. But I'm sure Stormseeker will show you something when the moment is right .

As a bonus, here's a sweet picture of a prop for Residue Processing. This was featured earlier in a blog by Carlos, but it only showed a small 150x150 pixels image. Enjoy the highres picture.

Well, that's it for today! The blog turned out to be quite a bit bigger than I had planned, but I'm sure none of you mind. I hope next time you see one of our level shots you think of all the 2D/3D artists involved in the design process, not only the lead level designer. We feel underappreciated.

*****