2 replies to this topic

[olblue]

Sometimes GameDev isnt fun. Frankly for people that work on developing games, a lot of them develop a twitch and a stammer at the thought of even looking at a game outside of their appointed working hours after a while because, lets face it, the time you get to enjoy games isnt shared with actually developing them most of the time. This is especially more true once you leave the confines of making that fun mod you enjoy and moving into a corporate whoredom office that is full of angry line managers, all of which will be happy to eat your balls in front of you.

What Im saying here is - you dont get to create what you want, when you want to. And you have to ensure 'Compliance'.

Compliance is a term that the buzzword enthused game development PR and Management weasels LOVE. That is because papertrails and compliance with quality methods and all that sort of thing, whilst being boring as hell, is also essential in order that your work can be consistent and that it can be assessed and signed off on.

Ok, so you are probably bored here just reading this - however lets put these bananas in context by using our dearly beloved UTWipeout (RIP) as an example.

In UT wipeout, it was set up on a "Chums all dicking about" basis, however; each person was allocated a role in a team so that they knew what it was they were doing, or supposed to be doing anyway. The problem however is that in this kind of a scenario, papertrails and QA are essential and its about the last damn thing that you would want to put in place in something that is supposed to be a fun project...

Ok...eg. Lets look at a design of a track. Who works on it?

A 3d Artist.

No.

The game designer (boring sheets of badly written A4) produces a specification (DOC 1. Synopsis on a managed document storage) for level (in this case FASTLEVEL1) which is then passed on to the conceptual designer.

The conceptual designer takes DOC 1 and with that produces an annotated design document with sketches and roughs for FASTLEVEL1 (Doc2 - again on managed document storage) which gets passed to the Level Designer

The level designer reads DOC 2 and creates the mock up of the level. Accompanying this is DOC 4 which is the breakdown of the assets used in the level, any issues that are coming through and any notes the level designer thinks should be looked at.

DOC4 is passed to the conceptual designer at this stage. He looks at it with the game designer and the project lead. They produce DOC5 - A revision of DOC4 which is passed back to the level designer containing a list of changes by priority with an estimated completion date. He will then work down that list until complete or until the time runs out and pass it back up the chain again.

On DOC4 being passed, the DOC5, which becomes the design sign off document is then passed to the art director for the project. He will produce the asset dictionary. This lists each asset that the game level is going to need before the actual level can be compiled and signed off on.

The Art Director produces DOC6 - the asset list. From that he also produces DOC7 - 3D Assets and DOC8 - Audio Assets and DOC9 - Code and Tools

DOC8 goes down to the team leader for Audio
DOC7 goes down to the 3d Asset team leader
DOC9 goes down to the Code and Tools department

In between EVERY one of these stages there is an assessment of the document by the next person up the rung.

So - so far we havent even created a pipe... However for anyone organising a project I think we are starting to see how complex this project is going to get... which is why large projects ran independently are VERY hard to make work.

I will continue soon

[olblue]

Forgot to mention - doc 6 is related to the initial concept art for the entire project - assets needed are checked against the existing concept art. Additional art concepts will be requisitioned where needed at this point (REQ1).

[ChrisPerr]

Depends who youre working for, where you are on the totem pole, what type of person is in charge.

Whats this project for?