29 replies to this topic

[Dan Violet Sagmiller]

I have a book that I'm rewriting right now, that relates to game design and team management. Since I'm rewriting it, I'd like to get more outside opinion this time.   I have a section on Roles and Tasks.  It is intended for a free lance team to review:

 

1) To see the common roles (Game Designer, Level Designer, Graphic Designer, Programmer, Administrator, DBA, Mathametician, etc...), and compare what there team has, and what tasks are commonly associated with those roles.  I.e. if someone comes into the group and takes on the role of Marketing or Programming, it lists what they and their team should expect from them, and give them the change to include or subtract things as needed to keep everyone on the same page about their responsibilities.

 

2) For roles that the team doesn't have covered (which a single person can be multiple roles), they can see the types of tasks they would be expected to do, and make sure they look what they need covered.  I.e.  a lot of indie teams don't have any one on marketing, and so will push off all marketing until the last possible time to work on it, when marketing should help shape the GDD in most cases (making sure they are targeting salable features for instance, instead of white noise.)  

 

 

Anyway, my question to you is to name a role in a game development team and what responsibilities that might include.  (Its normal for different places to assign different titles to a person with the same set of tasks, or the same title despite having different common tasks)  I'm just looking for what your experience has showed you.

 

Thanks.

[Dan Violet Sagmiller]

I'll get this started.

 

QA/STE/MT (Quality Assurance/Software Test Engineer/Manual Tester)

 - This role typically helps to identify testable features of the game.  Typically basing their tests off of business or logical requirements, and sometimes ad-hoc testing.

 - Often this role is active VERY early in the process, helping to ensure that the requirements, features etc, are written in a way that they will be testable later.

 - It is often good to have fresh eyes here through out the process, who are unafraid to say, "... was not very obvious.  I had to ask someone else how to do it."  etc...  which is terrible for a typical video game.

 - They will often play test, targeting areas that were previously broken, newly developed/altered, or of high importance.

 - They typically must have the ability to clearly present the bug, and shrink it down to the most obvious/minimal repro steps.

 - Often considered an exciting career by those not experienced, that tends to fade quickly as they find they have to repeat the same area over and over and over again, and often lose all character earnings.

 - In most places, the Tester is answerable to the business/Product Owners, and not the development team.  The development team should be writing unit tests, and in general making sure it works, but QA should be checking for special cases, non-happy path testing, etc...

 - It is often good for QA to have some insight into programming and game development, so they can relate bugs in a more programmer-centric way, and identify patterns that may have contributed to the bug.

 - Depending on the studio, this is often a graveyard shift job, as the developers will work during the day to produce the next evenings build/bug fixes for testing.  But can also be found to sit side by side with development.

[Dan Violet Sagmiller]

Level Design (Not Game Designer)

 - This role belongs to a person who will look at a level at a time, identify the anticipated characters ability/resources/available features at that point in the game, and design a level to enhance their abilities, maintain interest, and not stress out the player.

 - This role will often be laying out the level map, particularly in relation to Obstacles, Route, Enemy Placement, Upgrade/Health Bonuses, Goals, and secrets.

 - This person will be tasked to make sure that newly introduced abilities are presented in a way that is easy for the player to try and survive with, while gradually enhancing the difficulty/accuracy/complications involved in getting past an obstacle or completing an objective.

 - This person will be tasked with making sure the level matches up with the Story and helps move it along or clearly present active components of it.

 - It is common for this person to ask for specific new abilities, that will greatly support the story or the additional abilities, such as asking for doors that open and close on level placed triggers.

 - Often this person will have scripting knowledge, which will be based on the technologies used in the Game Engine.

 - This person will be comfortable with placing graphic/game objects to help layout the nature of the game.

 - This person will often also be tasked with identifying the clear objectives, opportunities and obstacles that a level should provide.

[Dan Violet Sagmiller]

Mathematician:

 - Not commonly realized role in game development, as the programmers are usually take this role on.

 - Another game development model occurs on intense 3D engine/feature development (or other task) where the math involved is incredibly complex.  Often a Programmer will simple create a function name, and give a logical explanation of what it is supposed to do.  

 - The Mathematician then figures out the equation(s), by discussing the easily available variables with the programmer, particularly focused on creating the math function in a way that requires the least amount of processing. 

 - The Mathematician often dictates the precision needed in the game to make it look good, I.e. equations can use floats instead of doubles, the precision is only required 2 decimal places, a table with common angle equations can be used instead of actual large math, etc...

 - I've seen this used, where the larger math was left out of the programmers hands, so they can focus more on logic and architecture.

[Dan Violet Sagmiller]

Writer/Story Designer

 - This person usually addresses the game from a plot and character development perspective.

 - They are often tasked with creating a story to take advantage of existing game play features, or planned abilities

 - Designing Emotionally engaging content, so you care what happens to an NPC/I.e. want to see what happens next.

 - Engineer significant key plots, plot twists, and cross dependencies.

 - Create and shape Companions and Enemies with interactions.

 - Generate a list of sub events leading to key plots points.  Typically interacting with level designers to provide ways to move the plot in levels.

 - This is typically a very early role in the progression of the game.  After the key features are selected, and how they should work.

 - This role may commonly request methods of interjecting story elements into the game, such as action breaking for conversation, ability to talk to NPC's, 

[3Ddreamer]

Well, there is a lot of room for flexibility.  Experienced people can help you once they are on the team.

 

Take a look at this:

http://en.wikipedia.org/wiki/Game_Development

 

Really there is need to keep things simple as possible.

 

 

Clinton

[Dan Violet Sagmiller]

Experienced people can help you once they are on the team.

 

??  I don't understand what this line has to do with my post.  

 

Take a look at this:
http://en.wikipedia.org/wiki/Game_Development

 

Not a bad link, but particularly vague.    

 

The reason I'm asking, which I must not have been very clear, is because I'm rewriting a chapter in my book on Roles/Tasks on a game dev team, and the idea is to help teams that don't have all the roles covered to at least be able to see what types of tasks each of those roles would take on, and most importantly, get an idea of what skill sets/task coverage they are missing.  Its to help a new team, or even experienced but incomplete team identify tasks that might be important and figure out what to do about them.  The Wikipedia post didn't really list off much in the way of responsibilities and tasks for those roles, mostly just 1 liners.

 

While I have my own persepctives and experience, a couple of the roles I've posted, I'm hoping to see other people knowledge of this, and what roles/responsibilities for them exist in their own game dev teams.  Obviously I haven't worked for every game company and team, only 4 or 5, which leads me to expect that other teams/companies may have different expectations of roles, and tasks.  I'd like to make sure my book is covering more than my own beliefs on this.

 

Thanks.

[3Ddreamer]

These issues are relatively blurred in the industry.  For example, I recently did a 2 + year gig with an organization that had the game developer doing all the programming, the game designer did almost all the game design with a lot of art asset creation too, there was a small team of artists and another team for testing.  Roles evolved and input by members had a huge influence on the ever changing roles.  One guy finished with completely different role than he started and others added or subtracted responsibility. It is good to define things at the beginning, but game development always evolves into something different than the formation of it.  Typically but not always, the game development company is very fluid in tasks and roles by the members and often the start is quite different than that planned.

[Norman Barrows]

1) To see the common roles (Game Designer, Level Designer, Graphic Designer, Programmer, Administrator, DBA, Mathametician, etc...)

 

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.

 

I would recommend that you be clear about whats required for all types of games and whats required only under certain circumstances or for specific types of games, too often when compiling such lists, people come to the table with a certain mind set (cognitive baggage) usually based on their role in some large game company. Its often easy to tell exactly the types of projects they've been involved in based on their list of the roles and tasks. I have yet to see anyone who took a more general approach to the topic or even acknowledged that their view might be just one small piece of the big picture of how things can be done.

 

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.

[Dan Violet Sagmiller]

One guy finished with completely different role than he started and others added or subtracted responsibility.

 

That brings up a very good point I should probably include, that roles change.  I had originally written it from the perspective of establishing your roles, but hadn't really discussed change.

[3Ddreamer]

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 

Edited by 3Ddreamer, 13 February 2013 - 09:34 AM.

[Norman Barrows]

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).

[3Ddreamer]

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.  

[Dan Violet Sagmiller]

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.

[Dan Violet Sagmiller]

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.

[Norman Barrows]

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.

[Dan Violet Sagmiller]

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.

[Norman Barrows]

The opposite extreme is the large team

 

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

[3Ddreamer]

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.

[Norman Barrows]

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.