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.

I thought your target audience was the small / first time team?

My target is the smaller team, typically high school/college students getting together with friends to try making a game. I teach classes on this all the time, and haven't been too satisfied with the books I find on the market to match up with how I teach my classes. So the book is for my classes. The previous draft, though not published, has been used in sections by my students. The book is designed to support my classes.

perhaps the way to slice it is first by listing the tasks/roles common to all types, then the tasks/roles required for various specific types of games.
so all games need designer, coder, artist, tester, and may need level designer, etc, etc.

EXCELLENT! That makes a lot of sense. Then, for the sections, I can post it more by size of whats covered/general. I.e. a programmers section, then an AI programmers section, etc... that at the end, include a list of tasks that are more stand alone, one task roles. So far, I think I'm going to use this approach. (unless I hear something that sounds better to me)

The opposite extreme is the large team

I thought your target audience was the small / first time team?

sorry, got my posters mixed up.

yes, contrast and comparison is a good method of analysis. probably the only one if you think of it. measures of fitness must be measured relative to something. after all. and comparing small studio organization to large studio organization will give the reader some insight as to how it works in the "big time" - and what their shop should be evolving towards..

comparing small studio organization to large studio organization will give the reader some insight as to how it works in the "big time" - and what their shop should be evolving towards.

Absolutely agreed. One of my first chapters is "David an Goliath" which discusses the common differences in resources/experience between typical Indie teams and game giants. Particularly focusing on how to develop against them in wats that don't compete directly, but takes advantage of features that the Game Giants did not use in their popular genre matching games. (games in the same genre as you are working in)

Well, that reinforces the idea of making organizational decisions primarily on tasks, once again.

Absolutely agreed. One of my first chapters is "David an Goliath" which discusses the common differences in resources/experience between typical Indie teams and game giants. Particularly focusing on how to develop again that doesn't compete directly, but takes advantage of features that the Game Giants did not use in their popular genre matching games. (games in the same genre as you are working in)

I my have useful information. I'm one of the last of the lone wolf developers. In 1988 I invented the Star Trek flight simulator genre with my first game SIMTrek, which was a top 10 download on AOL (10,000+ DL's the first week). I've now been building games on and off for 25 years. I'm intimately familiar with the tactics and strategies a David needs to survive. needless to say, as a lone wolf, I do it all, AI and animation, i write the sales copy, and the shopping cart software. register the trade name, and take out the trash. Write the music, and field the tech support calls from users. What you don't know, you learn, or give up on your project.

I'm intimately familiar with the tactics and strategies a David needs to survive. needless to say, as a lone wolf, I do it all, AI and animation, i write the sales copy, and the shopping cart software. register the trade name, and take out the trash. Write the music, and field the tech support calls from users. What you don't know, you learn, or give up on your project.

Seeing as that is another are in my book I wanted to address, I've posted a forum question on David vs Goliath. I'd love to hear your take on it, http://www.gamedev.net/topic/638733-david-and-goliath-how-do-you-compete-with-a-game-giant/

EXCELLENT! That makes a lot of sense. Then, for the sections, I can post it more by size of whats covered/general. I.e. a programmers section, then an AI programmers section, etc... that at the end, include a list of tasks that are more stand alone, one task roles. So far, I think I'm going to use this approach. (unless I hear something that sounds better to me)

Probably the thing to do is get the list of tasks together first. Once you have that, odds are: "how to divide it up into sections and subsections" will be pretty self evident.

Casual thought brings to mind obvious sections like:

coding

artwork (i like the umbrella/generic term "video" - all the stuff you see on the screen)

sound and music (generic term: audio)

other content (level maps, mission orders, storyline text, etc)

testing

marketing

support

and obvious subsections like graphics, AI, physics, and simulation/modeling for coding,

level designer, modeler, animator etc for artwork, and so on.

Dan,

it occurred to me you might want to slice it as tasks, and skill sets, where the basic skill set would include things like designer, coder, artist, writer, etc.