Introduction

When starting a mod or a side project it’s easy to jump straight to the action. It’s just for fun so why bother with the boring stuff right? Black Mesa will be 10 years old next year… 10… years…  and now we are retail on Steam! We never expected to be here, and as a result we ended up creating a lot more work for ourselves by not keeping good records, and by not setting up our systems to be both accessible, and easy to navigate. So here are some quick tips for starting a mod or a side project!

Source Control

Set up stable version control as soon as possible. There are a lots of options out there, research them, and see what is going to work best for your team. Give your project room to grow. If you just get the minimum, you are going to have to upgrade it later. It may cost some money to get a decent source control in place. If you can not afford this, maybe try a project with a smaller scope first.

We have had many source control changes throughout Black Mesa. Our lack of foresight (and extremely limited funds) forced us to have to re-download the game a bajillion times. We primarily used Tortoisesvn throughout the project, and tried a brief stint in GIT, but it just added to the confusion and didn’t like our ridiculous file sizes.

Naming Conventions

Establish naming conventions that are well thought out and ENFORCE THEM. There’s no real secret to naming conventions. Open a document and start to flesh out your file structure as detailed as humanly possible. Show it to other people, get their opinions, and feedback. Are you going to use “_” or camelBacks to separate words? Are you going to use “_d” or “_diffuse” for your texture maps?

Once you define your conventions, make sure you and your entire team are committed to using the outlined naming conventions. You very well may have to adapt your convention as you get further into your project, that’s OK! It is infinitely better to have some out of convention legacy files than it is to have an entire directory that is impossible to navigate.

I grind my teeth just navigating our file structure…

Source Files

Make sure everyone on the team is uploading their source assets. Down the road you will need them, and zero hour is not the time to harass people for the one file you need to fix the game and make it shippable. This is just like the naming conventions, you have to make sure everyone, including you, are committed to uploading their source content religiously.

Legal Documents

Speaking of source files, think about asset ownership and NDAs early. Even if your project is planned to be free and all volunteer, get everyone to sign paperwork that they will not disclose confidential information AND that everything they make is owned by the team.

Roster

Keep good track of your team members and what they do. Keep a record of how to contact all developers past and present. This is very easy to overlook on an all volunteer project, but even IF you never go retail it’s important to know who implemented what, and just how much they contributed to your project. Got a system that was implemented years ago and you have no idea how it works? That’s not a problem because you kept great contact info for all your current and past members… Right?

Imagine, completely hypothetically, if a project went retail after 9 years of being an all volunteer project, and now you have to figure out how much each individual gets paid. How much of a cluster would that be to sort without good records? …I bet I can guess and it’s worth it to just keep up on the damn records.

Centralize Development

Don’t let one person handle web development, one person handle source control, and so on. Eventually one of those key members is going to leave, or go MIA. How do you access that critical system when they haven’t signed into Skype for a month? Get multiple people on each branch of development, even if they are not experts in the field. This way if someone makes a disappearance you can hand over the keys to someone else. The leads (if you have them) should have access to all branches of development for redundancy.

It may not be possible, but try and think of ways to keep your accounts as divorced from individual members as possible. Maybe create a new email for the project, and use that for all the service logins. That way you can give multiple people access to services without also giving people access to someone’s personal account.

Don’t Get Burned

It’s important on any project, especially if it’s a side project, to have fun. Balance your work:life ratio so that you are a well-rounded individual. Walking away from your computer when you have a big deadline can be hard, but you’ll come back better, more refreshed, and more efficient. Simply taking a walk around the block can do wonders for your ability to get things done. Reading a book, or watching a movie that is related (or even unrelated) to the project you are working on can give you inspiration that you otherwise would not have had.

Us at Black Mesa NEVER imagined we would be where we are today. If it weren’t for the commitment of many, and the awesomeness of Valve we would not have made it this far, and I want to personally thank EVERYONE who helped us along the way. Every single vote we received on Greenlight made me proud to be a part of this project. Some of these tips may not be possible for your project, or maybe some just aren’t relevant. If I saw these 10 years ago I probably would have thought “Yeah seems like good advice” and then promptly forgotten everything listed. We made some mistakes during our development of Black Mesa, many in fact, I hope these help you avoid as many as possible!

Black Mesa is now available on Steam Early Access for $19.99. We are currently working on Xen because we know how much people want those chapters. Please be patient with us while we focus our efforts on getting them done!