3. Iterative Process

From day one, everyone on team played the game -- even before we had any art assets or game-specific code. The first thing we did was create a basic level, coded a rifle and an alien bite, and ran around a small box attacking each other. There wasn't even an interface or menu -- you had to know the right console commands to start or join a game. You can see here the Skulk view model from NS1 and an untextured placeholder Infantry Portal model.

Our first playable prototype in Spark.

These tests were great for boosting our morale, and getting us in the right frame of mind: shipping. We had a game, albeit an ugly and boring one; now we just had to make it fun. Instead of the end goal remaining amorphous and undefined, we simply had to shape what we had into something great.

As development progressed, we played more and more, until in the beta the entire team was playing a couple hours a day. It's quite difficult to ignore gameplay or implementation problems when you're hearing or seeing their exasperation about some aspect of the game. Many features were reworked multiples times and/or cut to fit our tastes.

By the time we released, NS2 had many thousands of games played, so we didn't have much to fear. Through this iterative development, I came to understand just how important it was to take feedback from non-designers, and the game was so much better because of it.

4. Open Development

As a small company without a marketing budget, how do you build an audience? We decided to take our fans "behind the scenes" and open up our development. We blogged, tweeted, recorded video footage around the office, and otherwise became as transparent about our game development as possible. When we didn't have game footage, we showed screenshots. When we didn't have screenshots, we showed concept art. Before concept art, we wrote about what we were planning to create, and why. Even the most mundane aspects of game development can be interesting for people outside the industry.

The first time we did this was in 2006, when we released our "dynamic infestation" prototype. It ended up getting linked all over the web, which felt incredible. We worked with one of our "super fans" who was a video whiz to create development videos about design and technology decisions. These regularly got tens of thousands of video views, and gave us feedback much earlier than we otherwise would've gotten. We even cut our "taser" weapon after we showed the concept art and basic functionality: our fans hated it so much we just dropped it.

Our early infestation demo.

Besides the PR benefit and the early feedback, open development had another bonus for us. When we were almost out of money (the first time!), we thought: "Why don't we ask our community if they would pre-order our game?" We put together a polished video that shows the technology, and a first look at the new game, and launched it with our preorder program. It ended up making over $1M over the next two years of preorders, saving the company and buoying our morale.

Open development helped us again when the Overgrowth team suggested that we do an unprecedented "preorder bundle" of our two games, and make it a PR event. We thought it was a great idea and we generated another $40k each in just a couple days. It worked so well that they then formed Humble Bundle, Inc. and turned it into a profitable venture-backed business.

Another way we leveraged open development was way before our playable alpha. We didn't have any maps yet, but we did have assets for making maps. So we released these props and textures, along with a document describing how to build a map and our barely-functional editor. Some of our pre-ordering folks started making maps right away. We asked the most promising community members to work on official maps for the game, for a share of the eventual revenue instead of our sparse cash. Without releasing our assets to our community, I'm not sure how we ever would've built our first map.

Early community mapping shot using our released assets.

Open development helped us in countless other ways. We used it to assemble a die-hard group of volunteers that performed all our QA and gave us tons of valuable feedback. We hired a key game programmer from the community -- he had never worked on a game before, but proved his worth with dozens of gameplay videos he assembled using the source code we distributed with the beta. It's now clear to me that we would not have shipped the game without him.

At every step of the way, we would release what we had, talk about what we're building and why, and listen to feedback. Whenever someone talented emerged from the community, we did everything we could to work with them. Whenever we created anything of value, we would release it, and hope it would grow momentum in the form of revenue, talent, audience, or buzz.

5. No Crunch

One of the reasons we started Unknown Worlds is because we believed making quality games and having a great life went together. We view game development as a marathon, not a race. So we made sure to keep fit, have a life and not crunch. There were times when we did work late nights and weekends, but only when our company situation or funding was dire. Looking back on those times, I do believe we did the right thing to work extra, but we probably would've been better off had we taken a step back and figured out a way to raise more money instead of working harder.

Now we are actively trying to improve our ability to both hit deadlines and make outcomes and goals clear for everyone. We want to constantly improve our efficiency, as well as give more work flexibility to our employees. At the end of the day, employee retention is the most important success factor for us, so we never want people to crunch.