Choosing Your Team (that ol' team spirit)

Name: Game Development Series
Author: Peter Dwyer
Date: January 25, 1999

Description: This is my second article on games designing. In my first, I briefly covered the need to create tools for your level, character, sound and texture design. This second article covers the need to create a balanced team of individuals and how to ensure that communication between team members does not become a project stopping problem.

This series of articles were originally posted to the alt.games.programming newsgroup and I felt the might be useful. They are reprinted here by permission of the author.

Choosing your team

When choosing a winning team, it is best to take your time. Make sure you have people on your team that will not have personality clashes and that you know will be able to follow YOUR game plan and not wander off on some totally unrelated talent of their own. This may sound like obvious advice, but with so many teams now being created purely over the web, it is very easy to end up with a totally useless team.

So how do you go about picking that award winning team? The answer is strangely enough, to ask the right questions when selecting the people you need. Below are a list of questions that I have found very useful in assertaining if someone will work well on a project.

1. Do you mind working on a single project for a long period of time?
2. If you had to choose one of the following, what would you find most fun to do? *Coding *Graphics *Sound *Design
3. Have you worked on a programming project before?
4. Have you been involved in the design of a game before (even if it was one of your own creation)?
5. How do you feel about working in a team?

How someone answers these questions will tell you a lot about what they want to do on the project and more importantly, wether they will be of any use to you at all.

Another important thing to do when selecting a person to work on your project, is to get them to send you an example of their work, wether this is a .mid file from a potential sound person or a small graphical demo if the person wants to work on your engine design. For potential level designers, a simple doom level or a quake map will tell you if they have what it takes to create the type of levels you have in mind for your project.

I would also caution you to be very careful when selecting programmers. Make sure that any programming code sent to you is of a high enough quality and that the work is that of the person sending it in. This is quite difficult to do so I usually get the person to send in a description of the code. It is pretty easy to tell if someone wrote the code, as they will be able to explain what it does quite thorougly. Someone who is using a piece of code they downloaded from the web will have a hard time explaining to you what it does or even how it does it.

Who do I need in my team?

Your team should start small. About five people should be enough. If more people are needed (usually when you near the completion of the project), then you can hire them as needed.

The people you should be looking for are:

• One lead designer/lead programmer. This is your title and job so learn it well.
• One graphics artist/level designer. This person will be handling most of the games graphics.
• Two programmers, primarily a tools designer/coder and an engine coder/designer.
• One sound fx/music person.

Of these positions, your job will undoubtedly be the hardest. Not because you are the lead programmer, or even because you are the lead designer, but because you will need to supervise everyone else. It will be your job to ensure everyone does what they are supposed to be doing and within a reasonable time frame. Telling others what to do has never been the most popular pass time and is almost guaranteed to get you into an argument with your co-workers at some point.

You can of course decide that you do not need two programmers for your project (if for instance you decide to code the tools yourself) and have someone else code the engine or visa versa. Then again you may decide that you need an extra programmer or graphics artist etc.

This is a decision that you will need to make based on your perception of the difficulty of the project. I would however, causion you against having too many people in the beginning. The old addage about cooks and broth applies equally to programming teams so beware.

With this team, or one reasonably close to that, you should now be ready to get underway with the coding side. That is assuming, you have a stable and sufficiently detailed project description available.

What you don't know if your project description is detailed enough?

This leads nicely onto my next article, in which I will cover project design and job allocation.

Until then I hope this article helps

Peter Dwyer (software engineer, designer and sometime whip cracker)