|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Startopia What Went Right 1. Design.
The design of the game systems (object interactions, peep attributes,
interface, level structure etc.) was done in a few months, and hardly
changed at all during the development cycle. The only changes were the
removal of a few game elements near the end of the project due to scheduling
restrictions, which had no impact on the fundamental way the game played.
This required a lot of faith from the team in the ability of the game
designer to get it right the first time, as the game could not be realistically
prototyped or tested for playability or balance until a vast majority
of the elements had been coded and were in place. This trust in the designer's
ideas and systems working as written wasn't blind. A past history of successful
games did much to strengthen the belief that Startopia's design
was an accurate blueprint for a fun and enjoyable game. This highlights
the importance of a strong credible design blueprint at the early stage
of game development. 2. Scripting and Tweaks. A flexible yet simple scripting language was developed to build the missions that appear in Startopia. Stored in a simple text format, it allowed quick and easy editing of each mission without the need for any special tools. Missions could be updated on the fly, and required no extra compiling or processing before they could be tested. If a specific action was required in a mission, and it couldn't be adequately described with the current script commands, it was a straightforward task for a programmer to update the scripting language with a new command and provide support for the action in the game with no disruption to existing scripts.
In addition,
this simplicity made the game ideal for the modding community to build
their own custom scenarios that could be easily slotted into the existing
game, and distributed as just a set of small text files. 3. Compatibility. Compatibility is incredibly important to reach the widest possible audience. It's hard enough making people want to buy your game without sneering at them because they have an obscure and/or old graphics card. Our solution was composed of three parts:
The system in action: OK, so we've shipped the game, and someone emails us with a problem. One example was "some of the game objects keep flashing green and black blobs". This we diagnose as an effect known as "impostors" failing — a known problem with a wide variety of cards. Because the system is designed with scalability, we can disable them if they don't work, and use an alternative method. This alternative may not be quite as pretty, and may not be quite as fast, but it is guaranteed to work on all cards. So we ask the user for the "your gfxcard.txt" file, and from that find out what card and driver version they are using. We update the CardID.tom file with the data that "impostoring" should be disabled on this card with these drivers (and usually all previous drivers as well), post the new CardID.tom file to the user, and check that it works for them. Then we post the updated CardID.tom file on our website. In this way, the very first thing we recommend to people is to download this new text file — it's like a patch, but it's only about 50k in size! And it's easy to keep it incredibly up to date, since changes to the file are only enabling/disabling stuff that testers have already checked, so it doesn't need much re-testing. 4. VAL/ARONA Characterization. When developing the advisor character (VAL) for the game, we took the unusual step of basing the character around our ideal voice actor, rather than deciding on a character type and searching for a voice to match. We listened to a series of example voice actors using a variety of accents, listening for one that we thought would match our perceived image of the game. The casting of William Franklin as both the voice of VAL the computer advisor and Arona the trader was a great step in enhancing the humour and tone of the game. Once we had chosen him and confirmed his participation, we began writing our scripts specifically with his voice in mind (which reminded us of the archetypal condescending British butler). In some respects VAL isn't played by William Franklin — VAL is in fact based on William himself! A distinguished and very professional actor, Will took our scripts and brought them to life in a way even we didn't expect, making VAL, and eventually Arona (with the help of some digital manipulation) seem like flesh and blood beings rather than software-run scripts.
The professionalism of Will allowed us to record all the material used in the game over two day-long sessions, which were set a few weeks apart to allow us to review the scripts and add or update them as required. Where the script seemed a bit vague or perhaps contained grammatical errors, Will would record alternatives for us to use, often producing a better flowing sentence or paragraph structure than the original material. He could also read the scripts cold yet produce a perfect recording on the first take, which is one of the main reasons we managed to record so much material in a relatively short period of time. This kept costs down, which was a bonus considering the premium you pay for quality voice actors (a premium definitely worth paying I may add!). 5. The
Team. Probably one of the most important aspects of the game development,
and the one most often overlooked by publishers and public, was the commitment
and stability of the Startopia development team. While the team
began with only four members, and finally grew to 15 full time staff,
it never lost any of it's number due to the usual industry pressures.
This resulted in a strong bonding and level of understanding among the
team of how each member worked and thought, allowing a high degree of
informal decision making and sharing of tasks with little or no reliance
on management to approve actions. Indeed, there was none of the usual
slew of managers when it came to Startopia — if there was
a particularly thorny executive decision to be made, then the team Lead
programmer or Artist could make the call, handily also being two of the
four company directors. Even the concept of a 'producer' was somewhat
alien to us, the position being provided on a part-time basis by our publisher. Conclusions Overall,
despite it's flaws, Startopia is probably the game that members
of the team are most proud of working on. It looks great, sounds fantastic,
and is eminently playable, even among the developers who worked on the
game for so long. It has garnered many great reviews in the press and
on the 'net, and has been nominated for a BAFTA award in the UK. Despite this, the game has unfortunately failed to be as financial a success as we had hoped. While we understood that the muted marketing that the game received would mean a slow uptake, we had hoped that it's qualities, as a good game would help it achieve a respectable number of sales after it's release. We wont be making the same mistake next time. Our next project will not only aim to be better than Startopia, we'll also ensure that every man and his dog knows it!
 [Back
To] Introduction
|
|||||||||||||||||||||||||||||||||||||||
|
|
Features
