|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Startopia What Went Wrong 1. Early Emphasis on Look Rather than Feel. The early development stage of the game focused far too heavily on the graphical look of the game, and almost entirely avoided any thought as to how the technologies used would impact gameplay. While this proved influential in securing a strong publishing deal with Eidos, it had repercussions in the later stages of the project, resulting in unwanted game design restrictions to avoid re-writing code. And in other areas, a forced re-write of code that just didn't lend itself well to the gameplay systems we needed to make the game playable and enjoyable. One particular area that would have benefited from some greater forethought, would have been user-expandability. As we later found out, the system we originally coded was quite narrow in scope, and required extensive code updates whenever a new object needed to be added to the game. It made third party expansion of the game practically impossible, as well as proving a pain for us to use.
Ideally, the technical aspects of the game design should have been started right at the beginning of the project, well before any models were built or code was written, and would have taken into account expandability as a primary factor. 2. Lack of Custom Editing Tools. The amount of work required getting animations and special effects working in the game was severely underestimated. As such, no tools were developed for the artists or designer to easily insert and tweak models, animations, or objects. Almost everything had to be coded manually for it to work as we intended it to in the game. This led to an excessive amount of programming resources being spent tweaking animations and fixing models (often with code bodges), rather than leaving it to the art team, who found themselves under-tasked during the latter half of the project. Again, this probably stems from a lack of design forethought on the part of the original team, and an underestimation of the sheer number of models and animations that would eventually be required to realize the game. 3. Code Ownership. One of the obstacles faced when developing this type of game was the way every system and element of the game interacted together in a vast and complex manner. Very few elements could be considered stand-alone, and as such the programmers began to find that they often needed to jump into someone else's code in order to get their own systems working correctly within the game. This originally began as an informal activity, as the code wasn't yet particularly complex, but as time moved on and each programmer found they had more and more individual code elements to maintain, the changes made began to creep in without everyone's knowledge. This lack of communication and tracking led to several areas of code being rewritten or duplicated by different programmers, each unaware of the impact it would have on the others code. While the editing of code by someone other than the original author meant less time wasted on communicating the required changes to the original programmer and waiting for an update, in the long term it resulted in less streamlined systems, and unnecessary rewriting of some areas. If there is a bug in person A's code that person B spots, A must fix it. Otherwise, if B fixes it, (a) a higher chance of bugs and (b) A now doesn't know what the code does, and will refuse to touch it again. But B doesn't completely understand the code; they just know the tiny bit they fixed. So now, no one knows what that module does. The result is chaos. Ownership of code can change, but it must be a well-defined handover, and B must be happy that they understand what the code does, and are happy to own it.
In the future, we will be looking at making the code as modular as possible (to minimize overlap of programming tasks), and having a stricter view on ownership and editing rights. 4. Front End. The design of the game front end was left till late in the development process, and on reflection was far too complex (read: arty and fancy) for it's own good. Where a simple set of menu items appearing on a static backdrop would have sufficed, it was decided to wrap the front-end system up in a clever 3D model, with a hinged body and extending screens. We seemed to have been suffering from some memory loss at this point in development, because the difficulties in trying to get other complex models working correctly in the game seemed to have been forgotten. With little time left for redesign, and a stubborn will from both programming and art to finish the damn thing, it finally was completed — but at an excessive cost in resources, and without the polish or functionality we would have liked. We have since learned the advantage of economy of design, and will be implementing it in future projects. 5. Lack of Exposure. There seemed to be little exposure of Startopia among the gaming press, and no hype surrounding its release, even though it was developing some unique and cutting edge technology, particularly in the game engine and it's AI players. While in part it was the responsibility of our publisher to market and publicize the product to the consumer, the blame also rests upon us in naively believing that just developing a good, solid game would be enough to ensure sales. To our cost, we've found that the market just doesn't work that way any more. We should have been far more active in proclaiming that Startopia was the next great event in gaming, releasing snippets of information about the fantastic gaming opportunities it provided, and how it would redefine the God-sim genre. With so many games being released across so many formats, and a much broader audience to sell to, it's no longer the case where the majority of gamers can seek out and decide for themselves, which titles are the best — you need to shout loudly to be noticed by the consumer. We were far too quiet, and as such were drowned out by other less accomplished games who where far more vocal about their release. ______________________________________________________ |
||||||||||||||||||||||||||||||||||
|
|
Features
