27 August, 2015
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.
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.