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.

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.

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.

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.

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,

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

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.

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.

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.

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.