4. The Act of Balancing and Tuning. As we approached beta, we started to show the game to focus groups and to Sierra's internal balance team. The results were pretty stunning. In the first interaction in our demo level, where we only had three opponents with the weakest weapons -- people kept dying over and over again.

Not a single member of Saber team thought this section was at all challenging. That was indicative of the major problems we had with balancing and overall accessibility of the game to the general public.

Our solution to the problem was to conduct more focus groups and refine the gameplay. We brought people in both at the Sierra and Saber offices and had our level artists and scripters watch people play and make observations. The experience was very painful. We could not believe that people could not figure the way out of a room with three doors, two of which were permanently locked.

They just kept bumping into those two locked doors forever, and eventually gave up. The solution was to clearly mark the permanently locked doors with large visible locks, or red signs. James Bonti, a Sierra AP working out of our St. Petersburg office, compiled a bible of "things frustrating the player", which included instant deaths, unusually difficult areas, clunky controls, objects which were placed in the player's path and confused people who did not know where to go, unclear objectives, and other similar things. After the fixes were made, a version was presented to the next focus group, and the cycle continued.

We also listened to the members of the press that saw the game the year before and could compare the two versions. One of the biggest criticisms we were getting was our simplified time control.

In 2006, the user could select any of the three time controls at any time, which not only took up a lot of buttons on the controller, but also made the learning curve much steeper. After the extension it was decided -- after yet a few more focus groups -- that the users learned how to use just one time control function and never experimented with the other two.

Therefore a decision was made to automate the timeshift selection -- now there was only one button to press, and the game (or rather the player's AI-controlled suit) would choose the function automatically.

This not only allowed for easier controls, but also allowed the designers to designate certain areas of the game where specific time powers were made unavailable (the biggest challenge of TimeShift circa 2006 was that the user could press Time Reversal at any moment, which significantly limited our ability to include complex scripted events, and affected even simple things such as opponent spawning).

However, this also frustrated a lot of people who felt that the primary feature of the game -- the ability to freely control time -- was taken away. This made us get back to the design board and figure out a solution which would combine both schemes. The end result certainly pleased the more knowledgeable members of the press, as well as the gaming public.

5. The Proverbial Crunch Mode. Nobody likes overtime, especially when it happens during the summer. The three months of the summer in Russia is the only time when the weather is good and it's nice to be outside.

This is the time when most people take holidays. Unfortunately, summer also happens to be the "high season" at work when the project is being wrapped up for Christmas release. Because of the extension, our team had to spend two summers in a row in the office.

Saber's senior management knew that crunch was coming, and it was inevitable. We also knew that the last thing we wanted to happen was to burn the team so much that somebody would snap in the middle of the project and quit -- so the goal was to make this crunch feel reasonable.

We also had to come to terms with a few over-zealous people at our publisher, who "expected" the team to go into crunch ideally sometime in January, knowing that the project wouldn't end until mid-October. That certainly wasn't an option. Mandatory 55-hour work weeks for most people at the team were finally established starting in May.

The primary tools we had at our disposal were proper planning and established production processes. We knew that our primary "peopleware enemy" was the frustration factor, and we tried hard to minimize it. Luckily, we learned the lessons of the previous "wrapping-up mode".

There's nothing more frustrating than to work overtime and then not be able to leave the office when your work is done because a new feature was implemented just before the build is due to go out and it needs to be tested.

Our team leads established a weekly schedule with strict cut-off times for code and data check-ins. A build for each SKU was compiled nightly and tested the following day, so if something was wrong with the code, assets, or the build tools -- we knew about the problem right away, and there were few surprises when the time came to make an "official build" for Sierra.

Every Saturday we sent a number of weekly builds on all SKUs back to Sierra QA for testing. Mondays, Tuesdays and Wednesdays were dedicated to "normal work", with features being written and bugs being fixed. Towards the end of the week, we would go into "wrap it up" more.

On Thursdays, we did the code branch and made a "build candidate" which went into thorough internal testing. Only essential bug fixes could be checked in into the "release branch", and only with the specific approval of the leads. The same applied for art changes. This way we had two or three days to test the build internally and stabilize it.

But because assets and code were fully branched, those people who did not need to do fixes for that week's build could fully focus on other things working towards other goals and maintain high productivity.

This branching system also allowed us to "break things" in a big way when needed to make major fixes or improvements without affecting the stability of the overall build. A lesson we quickly learned was that it was of utmost importance to consistently send quality builds to Sierra. Not only did it greatly increase the efficiency of testing, but also helped to cement belief in us hitting the final dates.

At the height of this "build pushing" we had 12 QA people, including Saber and Sierra team members, working on-site. These were the guys who were hit the worst with the crunch. They had to leave late, oftentimes after midnight, having tested the build, and come in early to report the bugs and be available to team's requests.

Kirill Morozov, the head of Saber QA and our "Build Master", setup remote access from home and was monitoring and tweaking build assembly processes through the night, sometimes getting frantic calls from QA guys in LA at 5 AM when something was going wrong.

We also did a few other things right when managing this unpleasant crunch period, ranging from proper financial incentives to serving lunches and beer on Saturdays. The team morale was holding up pretty high, and we achieved our goal -- nobody quit -- either during the crunch, nor after it ended.