Sidhe Interactive
Starting Up
Scenes from Sidhe Interactive's GripShift game (Click to enlarge)
The raw process of producing a game is always the same. Once the winner of a pitching round is decided the team starts scoping out the project, which essentially means building it down from the top. At this stage of the development process Sidhe would use money from other projects to fund the current project.
An executive producer is appointed plus lead coders and lead artists and they start shaping the project as required.
The team is always butting against constraints of hardware: the Playstation Portable has only got a certain amount of Random Access Memory (RAM), its Central Processing Unit (CPU) is not as big as would be ideal and the disk only holds a certain amount with slow seek times. All these factors must be considered when working on a project.
A game like Gripshift is fairly light in animation so only needed a couple of animators working on it, as opposed to other projects the company has done which required more – such as Rugby League.
Developing a game using in-house IP is different from developing one using an 'outside' idea or theme. The company can't just develop any original game as it has to be something they think will sell.
Unless it's going to something like the Live Arcade market place a game can't get out to shops unless it's attached to a publisher. So there's a balance to be struck on how far a game is developed before a publisher is brought on board. (Gripshift was co-published by Red Mile Entertainment.
Generally the process is the same for making an original IP game or a licensed product. The team comes up with the design document, a technical requirements document and then works through the project with a producer overseeing the development. The producer liaises with the lead designer, the code leads, the art leads and the publishers.
Any project will run into problems if it's not clearly defined and specified from the outset. Game development is a very specific discipline and the fundamentals need to be known from the outset: what the buttons are going to do, what the risk/reward pattern in the game is going to be, what's different/exciting about it, why it's going to be fun, how and where it's going to be played. There are a lot of things that need to be clearly defined before anyone begins writing a single piece of code or putting a single piece of art in it.
A very well defined pre-production period is important. This is essentially from when upper management decides to 'green light' a game and the different heads start considering the various aspects involved.
The technical director will be taking into account the risk of the project, considering such questions as "What are we going to write it in?", "Are we going to do it in proprietary code or get some middleware and do it in that?" and 'What's going to best serve our needs for this project?".
The producer will be looking at it in terms of bringing the whole thing together – how will it be done on time and on budget? His job is to steer and track the development of the project.
There is no way to really get everything right on paper and the game will be 'tweaked' many times through the development process. Everyone in the team will at some level end up contributing, it is very much a team based production.
