a good way to organize it might be by the different phases of development.
the tasks change during the different phases of development.
Good point. Not only would this establish a bit of a time line, but for young indie groups already diving into a later phase, it can help point out things they might have missed in the first phase and so on.
if a company is REALLY savvy, they have some kind of feedback from marketing and tech support to design. marketing and tech support are the departments closest to the customer, and its often they who hear the customer's feedback.
I absolutely agree with this.
another thing to do is be careful of the movie industry model. many larger companies tend to be organized along these lines. But they are forcing a set of roles (assumed
to be required) down from above, instead of defining the roles form the bottom up based on the tasks required.
Thats a very good point. I've worked at several game companies, where everyones "title" was already assigned, and then the original design team decided that they needed certain titles on it. and most of the time, the lines were blurred, because the skill sets didn't perfectly line up with the projects needs. Usually pretty close, but seldom balanced.
from your other posts, i see this is the second edition, and that you seem to have based the first edition mostly on personal experience. based on your questions i take it you've never been lead/only designer, lead/only coder, or lead/only artist or all of the above on your own project? Just marketing on larger projects (big enough to have a separate marketing person)? if this is the case you'll want to pay extra attention to your research into areas of game design and development where you own hands-on experience is limited. believe it o not, there's a certain amount of us vs them mentality in game development on the part of designers, coders and artists (and between them too!). the two sides are: 1. the designers, coders, and artists, in the trenches, slaving away 18 hours a day on Coke and Pizza's, playing foosball while they wait for the linker, etc. and: 2. everyone else (often referred to as "suits"). this is everyone not directly involved hands on in designing or building the game. if you don't come from group #1, but from group #2, you're better know what you're talking about if you want to reach anyone in group #1. it is all too common for folks from group #2 to tell group #1 how to do their job when they have no clue, cause they've never done it.
Not a bad guess from the clues, but not too close. I usually end up as a programmer as my primary role, but I've been on plenty of smaller teams where my roles had to work in all areas. There is not really an area I haven't worked in; Programmer, Level/Game designer, Artist/modeler, marketing, Tester, Automator, Manager, AI/Physics engineer, AI Scripter, DBA, HelpDesk, Architect, site builder, etc... and several in Senior/Lead roles. I've tended to believe that if I need to work with an area on my team, I should have a pretty good idea of how they operate, so I can get the most out of my interactions and better understand their needs.
Essentially this post, is me doing this again, but on a larger scale, I.e. with people and groups that I haven't even worked with before. So I certainly intend to listen to people perspectives here, and see how it works for them. thanks.