Yeah, I agree with you, Norman, that each list should be game type based. Even in the same genre there are variations. Looking at it from the personnel viewpoint rather than the games need viewpoint gives too much over to a kind of "shape shifting" on the part of the members who would like to influence what they will do based on their preferences a lot of time rather than game needs. Game issues are primary and personnel issues should respond to the demands, not the other way. Any team member worth keeping would be able and willing to adapt to the demands at hand. Concept! Concept! Concept! Concept>Tasks>Personnel

off the top of my head...

tasks:

Design:

1. design

Building:

1. code

2. artwork - meshes, textures, models, animations, bitmaps.

3. audio: music and sound effects.

4. other content made by humans like level maps, story lines, mission orders, etc.

5. testing

Marketing:

1. marketing

2. order fulfillment

Infrastructure:

accounting/payroll/finance/money stuff

clerks/secretaries/gophers - day to day paperwork staff

lawyers

human resources

Roles (who does what)

the lead designer is usually the one who came up with the game idea. all members naturally tend to make design suggestions. In the end, the design is usually a collaborative effort by the team with major influence from, and final say by, the lead designer.

in small / first time teams, the lead designer is often the coder. less frequently its the artist, and even less frequently its a dedicated designer who often does code and or artwork as well. I think this has to do with the amount of work and therefore the level of commitment required for the various tasks. Its probably easier for a skilled designer/coder to find a like-mined artist willing to invest the required labor, than it is for a designer with no skills to convince a skilled coder and a skilled artist to take a chance on their idea.

who does what in general tends to be blurry, often members take on more than one task:

designer/coder

artist/designer

level designer/coder

level designer/artist

level designer/sound guy

and of course:

all of the above / tester.

everybody tests (or they should <g>).

often times admin stuff is take care of by the team lead or founder.

note that this description is for your start-up type teams, and is based on the history of teams such as ID software (just 3 guys).

in small / first time teams, the lead designer is often the coder. less frequently its the artist, and even less frequently its a dedicated designer who often does code and or artwork as well. I think this has to do with the amount of work and therefore the level of commitment required for the various tasks. Its probably easier for a skilled designer/coder to find a like-mined artist willing to invest the required labor, than it is for a designer with no skills to convince a skilled coder and a skilled artist to take a chance on their idea.

The more skills that the initiator of the concept has, then the greater the appeal to attract others, no doubt. This demand is strongest in small startup teams, so I agree totally on that, too. The opposite extreme is the large team with several developers, designers, coders, artists, and so forth - sometimes each of these groups having a lead in that field. In this case, then the lead developer often makes the general design concept and divides areas of it to teams each under a designer. (Example: Character designer, level designer, vehicles designer, and so forth, with each of these groups having dedicated developers, coders, and artists) There are many variations of game development organization because mainly they follow the needs of the game concept. Some room for preference is there, but the more adherence to needs of concept by tasks then the more efficient and profitable the organization.

careful, you may be making implicit assumptions here.

if you're trying to catalog all possible tasks for every type of game, then yes, level designer should be included.

note however that a game which does not use level maps has no use for a level designer.

This is a good point. I hadn't expressed it here, but it is covered in the existing chapter. The essential idea is to look at things and figure out if you even have need for them, and if you do, who is covering it. If you have no one to cover it and it seems needed, then it suggest how to get help, and particularly to try finding it.

In fact a list based on game type might more appropriate, as the tasks tend to vary less within a genre and more between genres.

Though I won't use it as a major section, I can see that some tasks/responsbilities as related to genre in specific in notes on the task.

Yeah, I agree with you, Norman, that each list should be game type based. Even in the same genre there are variations.

And the can of worms is open. This is a really good point. I don't agree that sectioning the chapter by Game Genre is a good idea. I can't imagine a single genre where it will have tasks that aren't repeated in other genres. Graphics Designer for instance would have similar tasks in any pretty much any genre, with some variations depending on where. Same thing for AI Programmer or DBA. But I'm also starting to think that splitting it appart based on "Role" is not a good idea either, as this post has pointed a lot to the chaotic flowing nature that these roles usually go through.

It seems like it might be better to come up with a list of tasks relatively ordered by technology or training needed. For instance many types of programmers, many types of designers, etc... But essentially a check list of tasks and responsibilities, that a team can go through to determine if its even useful to them, and who can cover it.

Additionally, a list of common role titles and what they include in general, but very vague in nature.

Any team member worth keeping would be able and willing to adapt to the demands at hand

Agreed. I usually find myself as the task taker for everything until someone with more skills and/or interest comes along to take it over. I think this would be valuable to cover in the book. I think I mentioned this line earlier, but I originally had my book talking about things from more of a static role, and hadn't discussed the changing nature of what is involved. I've tended to think of it as what you end with for a role is what your role should have been to begin with, but that's not always the case, and change is often needed.

a good way to organize it might be by the different phases of development.

the tasks change during the different phases of development.

the first phase is the what to build phase. here the tasks are about coming up with game ideas, and evaluating them for popularity, competition, and man-hour cost.

once the question of what to build is answered, there's a lot in the way of design work, concept art, writing of test code for mission critical routines that will be required by the game engine, etc. figuring stuff out. smart teams do this first. most teams don't: "stay calm - keep coding - it'll all be alright".

then things start getting built. at first usually a quick and dirty prototype.

then nature takes over.

like a living creature, the software take on a life of its own. it evolves, get tweaked, features are added. sometimes entire subsystems are upgraded to newer stuff (like switching to a new graphics engine when you're already half way through building it with the old one). The design evolves. As the team works with the product, they think of improvements. Eventually, the design and software evolve into the final product.

testing should be a continual and ongoing process, constantly feeding back into design improvements. at the end, a final phase of mostly testing with few changes puts the final polish on the product.

these are the basic phases of the manufacturing process.

concurrent with these activities, the marketing department should be performing their own duties, such as press releases about the new title in development, creating a web presence for the company and title, including fans sites, developer blogs, and anything else that will build pre-release "buzz" abut the product. The big ad campaign kicks off at an appropriate amount of time before the final release date, and is continued as long as the cost of leads generated is favorable. Marketing should also constantly be searching for new channels, bundle wrap deals, way to licence the company's assets, or any other way to increase revenues.

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.

Oh yes, forgot tech support in the previous list. that phase comes after release (obviously). "After sales service": this might include expansion packs, downloadable content, bug fixes, patches, mods, etc. A lot of companies neglect this, but its crucial to building fan base, and turning your one hit wonder title into a franchise.

needless to say, as the tasks change, the personnel requirements change as well. but its probably better to think of it in terms of tasks than job titles.

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.

take a look at the history of some of the early small teams that first made it big like ID software. This will give you a better idea of what needs doing and who does it on a small dev team.

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.

Something I haven't seen yet, but I included in the books first draft, is IT/Techsupport. While most of us are perfectly capable of repairing our own equipment, having someone who is willing to head out to someone elses house to fix something for them, so they can focus on a more important task related to their skill set, this is a good thing. In general, it seems almost an unspoken rule in indie teams that you should be able to take care of your own Help Desk Support.

The opposite extreme is the large team

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

Comparison and contrast is a useful technique for better understanding the relationships and proportions.

Being a 2D/3D artist, IT consultant, and coder, I see things in terms of satisfying the need with a value task or item. In the long term, being able to project the current startup needs to the horizon of future growth is important for understanding how to best create the organization. Part of the need is to prepare for growth. This is very IT and management intensive. The management is the strategic thinking in it and the IT consulting is the tactical conception toward implementation.

Something I haven't seen yet, but I included in the books first draft, is IT/Techsupport.

yep, that's another one for the infrastructure / admin tasks list. internal IT support.

so you need internal tech support for the team, AND after sales tech support of the product for the users. 2 different systems being supported for two different customers.

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.

i like the idea of breaking down the tasks into things like graphics coder, AI coder, etc. these types of coding skills are rather unique and non-transferable to other types of coding tasks. this could apply to other skill sets as well, such as musician vs Foley artist vs composer, or modeler vs animator vs 2d artist.