On Halloween of 2002, Cory Strader and I released a free Half-Life mod called Natural Selection. It blurred the lines between shooter and RTS, in a wildly asymmetric, harsh and fast-paced sci-fi environment. It became the most popular independent Half-Life mod, and I became forever hooked on independent game development. I lived off my $40,000 of savings during its development and I became highly motivated to turn this into a living.

I moved to San Francisco to find investors and teammates, and to start a new life: one that I hoped would include a sequel to Natural Selection and enough income for me to become self-sustaining. After a few false starts, I started Unknown Worlds, and convinced my new partner Max McGuire to go in for half. At the end of 2006, we started working on NS2 in earnest. We lived off our own savings until we got some angel funding in 2008 and then carefully started growing the team.

This past Halloween, in 2012 -- 10 years after the release of the original Half-Life mod, and after almost going out of business multiple times -- we released Natural Selection 2 using our own "Spark" engine on Steam. It went right to Number One and has since sold around 300,000 copies. This article hopes to summarize what we learned during this epic period of toil.

What Went Right

1. Unstructured Development

We had no producer, no schedule, no milestones, and no meetings. We also had no design document, no technical plan and no business plan. Anarchy? Not exactly.

Our core team was seven people in a room, but we also had many critical remote contractors and part-time community contributors. Every time we tried daily meetings, we ended up deflated and demoralized. It made no sense why spending 10 minutes a day talking about our work made us so unhappy, but at least we were smart enough to stop. No status meetings naturally extended to no meetings at all.

We did try to have a schedule, but we found it was inaccurate and out of date instantly. It didn't seem worth maintaining something that was perpetually wrong, so we stopped doing it. After writing a business plan, I realized that I learned almost nothing writing it. A year or two later I realized I never looked at it, either. If I wanted to describe "our plan" to someone, it was easier to send along a couple paragraphs by e-mail. Very few people will get through a 40-page business plan anyways.

What we did do, though, is have lunch together every day. Anything important came up then, and the time there was naturally bounded, so talking didn't go on too long. The daily ritual of breaking bread was a powerful one for our team cohesion and happiness. And not having structure meant we could adapt to changes very quickly, and that we could spend all of our time working on the game, instead of planning it.

2. Empowered Design

One reason this unstructured approach worked for us was due to our design process. Instead of a design document, we used four "pillars" to describe the game. Each pillar is the name of a feature, described in specifics by a short paragraph. Imagine the bullet points on the back of your future game's box (even if it won't have one). All decisions about high-level features were compared to these four pillars.

This let everyone on the team have a set of "beacons" for the game direction, which allowed everyone to vet new ideas, have discussions and cut long conversations short if they weren't advancing one of these high-level goals forward. Having the pillars be high-level allowed us to be as flexible as possible, while still keeping the "spirit" of the game intact. You can see that these pillars are the main topics on our game page.

At a lower level than features, we kept artists, level designers, programmers, and animators working together cohesively through a set of design principles. These principles are "rules" that I implicitly followed when making decisions about balance and goals for the game. Examples include "No hard counters," "Public vs. competitive play," and "Non-obsolescence."

For each, I included a paragraph or two of reasoning and examples. I felt bogged down explaining my reasoning behind balance and design decisions, so I needed a way to quickly get everyone on the same page.

For instance, the marine team can research generic weapons upgrades, which let them do more damage. The aliens have no analog (following the "Two Unique Sides" design pillar) -- so in the late game, aliens can be ripped to shreds by even starting marine weapons.

Someone made the suggestion that aliens automatically have their armored shell able to take more damage, the more hives their team has (this was present in the original Natural Selection). But the design principles include "No Magic Numbers" -- in other words, hidden modifiers that are not readily apparent to the player shouldn't be in the game. This principle immediately changes the conversation away from any variant of hidden scaling armor, and towards adding new specific traits that could be used to compensate (extra speed, cloaking, etc.)

The specific goals in the document don't matter, but they shouldn't change much. I wrote these design principles in one sitting and they stayed throughout the rest of development. Embodying these cultural design principles in a public document empowered not only our employees, but our community members, and allowed everyone to contribute their art, sound, code or design that "fit."