Psychochild's Blog

A developer's musings on game development and writing.

27 August, 2015

Building a game: forming the team
Filed under: — Psychochild @ 6:33 AM

Blaugust, day 27

Now that I’ve discussed the fundamentals of the game, it’s time to put serious thought toward the fundamentals of the people making the game. Time to form the team.

Note that I would probably start thinking about the team before making solid decisions about the rest of the game. The game is going to be made by the entire team, not just me, so I would want to get a good team together and have them provide input.

This is also one of the most important decisions I will make, because salaries and benefits will almost certainly be my largest expense. In order to maximize my budget, I will need to get good people.

The trinity

There’s a trinity of developer types: Programmers, Designers, Artists. Not quite like the MMO’s holy trinity, and I don’t feel like torturing the metaphor to make it work right now. ;) But, you need all three roles filled.

Of course, some people are good enough to cover multiple positions. For example, I’m a Programmer/Designer multi-class character. But, Art is often well beyond my capabilities. So, you can often get away with two people filling out the roles, often a programmer and artist sharing some of the design roles. In extreme cases in indie games, you have one person doing it all.

There is also other business-related people needed to get the game into the hands of the players. I’ll talk about those later.

The goal is to start small and grow as you need. So, at the beginning, I might want one programmer, one designer, and one artist. If I were leading the project, I might step into one role myself at the very beginning. Eventually these people will become the leads of their respective departments. Initially their role is to give feedback on the fundamental questions already answered in my previous posts this week, and to consider the consequences of those decisions. The artist might create art that appeals to our target audience, the designer might start coming up games we could analyze in the same market, and the programmer would start looking at software and limitations on the platform(s) of choice to help guide further decisions.

As the team grows, I’ll want to bring on more people who can help out with vital tasks. On the art side, I’d probably want to bring in some concept artists early to start getting a feel for the art style. Once the technology is established, I would want to bring on artists to work on simple assets for the prototype. I’d likely want a modeller and a texture artist along with an animator if the game is going to be a 3D affair. For design, I might bring on a writer to help establish the basic story for the game in its setting, and more designers to help flesh out individual systems that the lead designer has planned out. For programming, I would bring on generalists at the beginning, and get more specialists (such as engine programmers, or rendering savants) as needed.

Unfortunately, there is no one-size-fits-all guide to the number of people you need. Some groups have lots of artists to generate a lot of eye-catching concept art, while others have lots of programmers to have a good technical foundation for the game. In a larger company, you might want to focus on getting something actually playable to demonstrate the core gameplay. In a startup, you might focus a bit more on something flashy and impressive looking to wow potential investors who may not understand a simple squares/cubes prototype.

Structure and hierarchy

As the team grows, you start needing a fourth type of person to complement the trinity, Managers. (They’re kinda like crowd control, literally. No need to even torture the metaphor.) Eventually the team will probably grow past the point where everyone can stay in touch with everyone else. Communication tends to fall by the wayside when people hit their stride and focus on producing stuff for the game. Plus, it’s generally a good idea to have someone keep an eye on how things are progressing and to make the final decision when there is a dilemma. “Development by committee” is fine if you have a flexible schedule, but few teams have that luxury.

As the team grows, it’s time to start thinking about the management structure. Is it better to have managers who offload a lot of the day-to-day concerns, or is it better to have a flat structure? Again, there’s no hard and fast answer here. A flat and egalitarian structure seems to work pretty good for Valve, although you have issues such as the much-anticipated Half-Life 3 possibly never coming out because it’s seen as a risky project to work on. Hierarchical structures have clear lines of authority, but sometimes the structure can be restrictive to people who aren’t easily categorized. And, sometimes the people who make good managers aren’t the same ones who are able to contribute to the project as a developer.

Ultimately, the most important thing is that everyone has to buy into the common vision. Having a clear vision of the type of game you’re making is important for getting the team excited about making it. It also avoids problems down the road where someone joins the team, only to get disillusioned later because the game isn’t developing as they expected, or and they don’t have a strong vision of what the game will be like in order to keep them focused.

Getting them paid

Here’s the big question: what do you pay them? Again, there’s no universal answer. You can use tools like the Game Developer Salary Survey to get an idea of what payment will be like. Keep in mind that a business will also have to cover payroll taxes and benefits for the employees.

At a larger company, the appeal is a steady paycheck and nice benefits. The company probably has guidelines for how much each position is paid and how raises are handled. The big focus is likely on benefits, which is a big advantage the smaller companies may not be able to offer. Health insurance, vision insurance, dental insurance, spending allowances for… research. ;) A public company might also have an employee stock purchase program (ESPP) to allow the workers to benefit from increased stock prices.

Smaller companies have the opportunity to for big growth, but also have more risk. The smaller company can allow for partial ownership options for employees, so that when the company is acquired or maybe eventually goes public, the employee’s little slice of the company is worth a lot of money. But, as people say, sometimes you have to kiss a lot of frogs before you find a prince. My job would be to get people excited about the game and about the company’s future in order to draw them away from the steady paychecks and nice benefits of a larger company. But, the reality is that small companies and startups just don’t suit everyone. On the other hand, they can suit other people better than the larger companies.

Again, the team is the most vital element of this whole process. A failure in building the team will almost certainly mean a failure for the entire project.


  1. Oh, man, personnel. Your last sentence is the big one: nothing is ever guaranteed, and external stuff happens, but choosing the right people for a project is huge.

    Some things I’ve noticed as a long-time programmer and software project manager:

    1. Being a great programmer doesn’t always translate to being a good systems architect. I’ve known some who could do both well, but not many. For starting up a project — especially one of any substantial size — I’d suggest finding (maybe contracting) a software architect who has experience working with your target platform. Once they’ve developed the framework of data and tools, and possibly work pipelines as well, then you can unleash the programmers whose skill lies in persuading computer languages to produce the desired results.

    2. One of the biggest challenges in software is keeping highly skilled technical people from throwing punches at each other. These are folks who’ve spent years gaining competence, in some cases to the detriment of social skills, and they can be incredibly tetchy if they think someone’s questioning their competence by disagreeing with them. Someone who is respected (more or less) by all parties will regularly have to make judgment calls on technical disputes. A team without someone filling that role — possibly the lead designer, or a producer — will have a much harder time delivering on the vision for the project.

    3. I think you meant to refer to the mythical Half-Life 3. ;)

    Comment by Bart Stewart — 27 August, 2015 @ 10:25 AM

  2. Yeah, I could have went into a lot more detail about about the specific skills needed. As I’m cranking these posts out one per day, there’s not a lot of time to go into the subtle detail about different types of programmers, architects vs. code slingers, etc. ;)

    But, yes, your first programmers will need to be the one doing a lot of the top level planning. Architect types are likely what you need rather than some brilliant programmer completes individual tasks rapidly.

    As for keeping people from punching each other, I think if you run that risk with your initial team then that shows some fundamental disagreements in the vision of the game. Since you also have to deal with creative differences in addition to technical differences, finding people who can work well within a team is probably of paramount importance. If you have a leader who is ready to throw punches, that’s going to be potentially toxic for your entire programming culture as you grow. Yes, maybe you might hire on a brilliant programmer who has that type of attitude, but that type of person might not be good as one of your first few hires.

    And, yes, I typoed a 3 into a 2. Hooray edits! :)

    Comment by Psychochild — 27 August, 2015 @ 10:14 PM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:

Recent Comments


Search the Blog


November 2019
« Aug    



Standard Disclaimer

I speak only for myself, not for any company.

My Book


Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on