Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Realtime Worlds' Crackdown
View All     RSS
April 22, 2021
arrowPress Releases
April 22, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Realtime Worlds' Crackdown


September 7, 2009 Article Start Previous Page 4 of 6 Next
 

What Went Wrong

1. Scope and Change Control

We got a couple of milestones past our first playable demo (which went down really well but was held together with paperclips and sticking plasters) before feeling the sinking sensation that the project was out of control.

In the face of a great deal of pressure to continue making incremental progress, the production team agreed to immediately derail the entire team from chasing short-term disconnected goals and instead embark on a full-scale project audit.

Much of the team was tasked with breaking down the complete design with implementation information so that it could be processed and converted into a simple and solid plan.

A multi-disciplinary panel was charged with reviewing the extensive detail of each component in turn so there could be no more complaints that, for example, audio wasn't being given due and timely consideration.

With a pass to add development estimates, resource groups, and stakeholder priorities, the resulting project scope spreadsheet was incredibly cumbersome. The team at large resented it bitterly. Unwieldy as it was, it was still an invaluable tool for at last conducting a meaningful triage of work against available time and resources.

Another shocking reality was that the number of coders yet to be hired was expressed in the order of tens. In a pragmatic development environment there would have been three choices: 1) increase the budget, 2) lower our ambitions, or 3) pull the plug. Unfortunately, the stakeholders were far from pragmatic, and rather than moving to jettison anything that wasn't in direct support of the clearly defined "project pillars," they used the scope discussions as a forum to add yet more ideas.

Several deep cuts were eventually approved (some creeping back in over the remainder of the project), but it still wasn't enough. At least we finally had a handle on the stakeholders' definition of "minimum content."

2. Renderware Graphics and Changing Hardware

Changing the target platform caused serious problems for Crackdown. Over the course of its four-year development, Crackdown moved from PC (where it was prototyped), to Xbox (where it was initially intended to stay), back to PC (in preparation for move to Xbox 360), to Xenon Alpha, then Xenon Beta, and at last to Xenon/360 Final.

Even on the final hardware, we continued to take hits from significant system software updates every few months. When at last the platform stabilized during the last year of development (post hardware launch), development efficiency increased massively.

With a relatively small development team to begin with and difficulty in recruiting experienced staff, the policy was to bring in middleware solutions wherever possible in an effort to reduce development time. By far the most significant of these was Criterion's Renderware Graphics and Studio.

However, we hit the wall full speed when the project shifted from Xbox to Xenon. Criterion opted not to support Renderware Graphics 3.7 in the transition, forcing us to move to an early beta version of 4.0. Not only was version 4 an unfinished product, but some features that we had come to rely on were not (and would not be) present at all (though in some cases Criterion did provide special code).

Since the middleware was suddenly a work in progress, each update came with a whole new set of bugs, transforming us overnight into hapless beta testers. Technical documentation was insufficient and in some cases inaccurate.

In hindsight, we realize that we simply did not adequately investigate the suitability and potential pitfalls of this new version of Renderware. Had we done so, we would have known that the correct decision would have been to back out and replace it all with our own technology. Yet with mounting pressure from the publisher to get on Xenon Alpha hardware (in itself a mistake given its tenuous relationship to the Xbox 360 proper), I'm not convinced the politics would have allowed it anyway.

Crackdown was already in development hell when it was blindsided by Electronic Arts' acquisition of Criterion. Initially, the EA takeover was transparent, but before long the well of excellent onsite support dried up, and we had no option other than to become the world's leading experts in the middleware.

Throughout the Xenon development phase, we had to take new versions of Renderware 4 in support of latest system software releases, which were never backward compatible. Eventually, we stopped taking new versions and rebuilt it ourselves. At long last we had a stable platform.


Article Start Previous Page 4 of 6 Next

Related Jobs

Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[04.22.21]

Head of Project Management
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[04.22.21]

Animation Programmer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[04.22.21]

Senior Audio Programmer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[04.22.21]

Senior Engine Programmer





Loading Comments

loader image