I get quite alot of say on design, and it works very well. Our designers will have a plan, but half the time when your writing something you find better ways of doing things, or making things behave and it becomes a team thing. I've been forced to impliment features I thought were completely stupid, but on the flip side I've veto'd my share of things the designers thought would be "soooo cool" but which really were quite bad and not worth even trying.

But it also comes down to a personality thing. I work with quite a few programmers who will blindly impliment exactly what the designers write no matter what, then there are those like myself who will take the designers plans as a guide and write something thats good. My moto is "give them what they want, not what they asked for". Our designers aren't precious about their idea's, they'll come talk to the coders and artists and love playing work in progress builds and giving feedback. I'd hate to work for a company where design was law - I have too many of my own oppinions for that kind of enviroment!

Quote:Original post by BlindSide
Another thing was the step by step process involved. In Hodgman's case the workers are cogs in a streamlined machine, and they must work sequantially on each part in the construction line. Due to my lack of exposure to programming in the business world (And over exposure to the independent scene :P ) I failed to grasp the idea that in a business environment things will likely have been planned and re-planned many times, and things have to be set in stone before a finger touches the keyboard (Ok maybe this is the case on extremely organized indie projects too, but to a lesser extent.). I'm also guessing larger companies would hire consultants to work alongside the designers to help them avoid any implementation issues, so when comes crunch time, the programmers already have their pre-digested work layed out for them.

I'd be careful generalizing here. In my case (which I describe above), I work for one of the largest and well known game companies in the world, and my team (at least this year) has been afforded the freedom to go back and iterate on everything until we were happy enough. Things are different from company to company, from studio to studio, even from team to team. Hell, even year to year can be vastly different depending on who you're working with. Rigid schedules don't work most of the time. Ideas that seem good often turn out to be stinkers, and if you don't allow yourself to have breathing room to iterate and investigate during production your game will suck (or just seem much too shallow due to cutting features). Having a loose schedule doesn't necessarily mean you can't have very well defined job roles. Sometimes programmers could care less about having any input into the design of something (I'm not refering to the design or architecture of the code itself). This would simply have one side (designers) driving all the work for the programmers (more like an assembly line, but not necessarily in the same way as in the next paragraph).

Personally I feel that assembly line type models are way too process-heavy and stifle creativity. It's like a 600 pound gorilla. Once the gears start going, it's hard to course correct.

I've worked on teams at both end of the spectrum (all for the same company). I actually really feel that managers who lean away from an assembly line model have to spend less time micro managing schedules to make sure no one is left hanging for too long, and they can instead work on more important areas of their job.

This sounds common from the other replies, but I'll chime in too.

The most productive teams I've been on are those where the designers have a good fun design up front. They have discussed the game with many people, including the programmers and artists. They have gathered all the input they can to help build a fun game. All the programmers and artists should have some buy-in at this point. Everybody should contribute to the design, commenting about what they think is good, what they think is bad, what they think is difficult and what is easy, and so on. You may not agree that a feature is good, but you should have been able to discuss your thoughts freely during pre-production.

Programmers and artists are generally given a lot of latitude on the actual implementation. We're told to make an object behave in a general way. The job of artists, animators, programmers, sound engineers, and everybody else is to take those fun ideas and implement them in a fun way that fits the game. Often there isn't much variation available -- for example, code for blending animations doesn't require a ton of creativity. Other times there is a great deal of free reign, such as implementing portions of the AI, or the mechanics of how objects interact with each other.

As was mentioned, when anybody sees something that looks like it will add fun to the project they should immediately bring it up for discussion. The exact chain of command varies by team size, but generally it is easy to fire off an email to the development director and to the designers asking them "Have you considered this idea? I think it would be great." Include with the suggestion an estimate of the amount of work/cost involved, and the risks as you see them.