What Went Wrong:

1. Prolonged Dev Cycle. As we mentioned above, TimeShift was in development for more than four years. We went through a publisher switch. Even at that moment, the game was somewhere around beta and was already undergoing serious QA at Atari, and a demo was already out on PC and Xbox 360; a year later we had to clear up the confusion when people were downloading the OLD demo and thinking they are playing the new one.

A total of four executive producers, two writers, and a large number of creative people worked on the game. By the time we finished, we were operating under Amendment 17 of our initial contract. An insane number of piecemeal two to four month extensions never allowed us to neither bring the game to the finish line, nor make a big enough overhaul. The game as it was in September 2006 was a mishmash of way too many creative visions.

Certainly the last extension was an exception to this and allowed us to bring the game to the level of quality it deserved, piecing the elements together. It worked out for the most part, but the story came out relatively weak.

We were constrained by the fact that we could not really take the game through a proper preproduction and planning phase, and could not change a lot of levels to accommodate to the final creative vision. Certain members of the gaming press criticized us sharply for that.

Another negative effect of the game being so long in production, and being close to the finish line so many times, was that by the time it was getting close to being released it had already been shown to the press over and over again.

How many exciting stories can you tell to the same journalists who've seen the title three or four times already? The surprise factor was totally lost, and Sierra's PR staff had to overcome a lot of skepticism. Because the game was shown primarily to the U.S. press, PR efforts were easier to carry out in Europe where the game was fresher. That's probably one of the reasons we are getting consistently higher review scores in that region.

2. "Not Invented Here" Factor. At Saber, we strongly believe that it's absolutely essential to rely on our own technology. TimeShift is built using our proprietary Saber3D engine and toolset. Having full control over the entire production pipeline has allowed us to accommodate new features easily and to optimize our production processes.

We fully believe that we would be unable to implement one of the most challenging technical features of the game -- time reversal -- had we not had built the game on our own engine. Having said that, we realize that there's a great value in using engine components provided by third parties. For TimeShift, the primary components included GameSpy for networking needs, Fmod for audio support, Bink for video playback, and Havok for physics handling.

Adopting these systems was a great idea which allowed us to focus on the game rather than on pure tech. All of them are tested solutions, utilized on a large number of projects in the industry. We therefore expected them to be as reliable and robust as the CLIB base library. Unfortunately, that was not the case.

Sometimes the issues were known and there were pre-existing workarounds or fixes available, but every once in a while we were stumbling upon an untested piece of code, or an unanticipated use of a subsystem, or a lack of a vital piece of documentation which made some concepts unclear to our engineers.

What came as a surprise, though, was that whenever an issue arose with any of these components it oftentimes required massive efforts to nail it down. Conference calls were scheduled, mini-apps that demonstrated the problem in a testbed scenario were built and sent to the providers, and support trips were set up to bring the engineers on-site to address the issues "right on the spot".

All of that slowed down the development somewhat and was always a "scare factor" to the senior management. What if an engineer from one of these middleware providers would not be available for a quick trip to our offices?

At the end of the day, though, we were able to address all of the issues and ship on time. Many kudos go to all of those middleware providers who helped us by going that extra mile, flying in from all over the place to St. Petersburg, or making themselves available at odd hours to talk to our team.

The lesson learned is that it's certainly a great idea to utilize third-party solutions, but because those providers don't work for you they may have other priorities, so enough time needs to be allocated to deal with the possible issues. It's also crucial to integrate and test all third-party components as early in the dev cycle as possible to be able to accommodate to any contingencies.

And it's essential to get the source code for all the components so your engineers can at least see exactly what's happening at the source code level and report specific info such as callstacks, the values of registers or variables back to the middleware support team. Establishing direct relationships and lines of communication with tech support people is invaluable, with real-time communication means such as ICQ or other IM services being preferable to slower email or web-based ticketing systems.