Working in a Game Development Team: The Pros and Cons

So you have a great idea for a game. Although it’ll be a big task, you feel ready to take on the challenge. But before you tackle a project on your own, have you considered working on your project with a team? Of course, this comes with its pros and cons, as all things do. Here I will highlight the advantages of working in a small team and also discuss the best way to mitigate the difficulties associated with group work.

“Starting a game is easy – it’s finishing one that takes a lot of time and dedication.”

The most obvious benefit of working in a team is that you can produce games more quickly. Two heads are better than one, so the saying goes, and having several pairs of hands on board can help get a project developed in much less time than if you were to go it alone. This can be particularly important because of how quickly technology develops and becomes obsolete. If your Playstation 4 game takes five years to develop, who can guarantee that there won’t be a Playstation 5 by then? Working in a timely manner can help ensure that your game isn’t already out of date before it even hits the shelves.

Secondly, working in a team can give you the kick up the backside that you need. Starting a game is easy – it’s finishing one that takes a lot of time and dedication. By working in a team, you can keep each other motivated. Seeing that your partner has spent six hours on the game’s UI might just give you the push you need to finalise the character select feature, for example. Not only does game development progress spur you on, but the small pang of guilt associated with seeing your team work so hard can be just as motivating.

Thirdly, when working on a solo project you need to be a jack of all trades. Working in a team allows to delegate responsibilities. Members of your group can specialise in areas where they shine, be it in composing, coding, story-writing or level design. Allow your team members to work to their strengths, and allow others to pick up the slack in your weaker disciplines.

It is also worth mentioning that it can be highly beneficial to bounce ideas off one another when you are developing ideas. Creative blocks happen to the best of us, and being able to talk to another informed designer can set you back on track.

“What if I’m wrong?”

However, working as a team isn’t all puppy dogs and rainbows. Sometimes it can be difficult to make decisions that take everybody’s opinions into consideration. There will be disagreements – it’s a natural part of the creation process. It means that multiple voices are passionate about the project and that’s great, but conflicts have to be resolved somehow, as working both suggestions into a game is rarely an option.

Personally, I know that I can particularly stubborn, so for me the best solution is to ask myself “What if I’m wrong?” Any designer knows the exact reasoning behind every conscious decision in their creation process, so any form of critique offered to the creator can be met with great resistance if they are unwilling to listen. Put yourself in your team member’s shoes. Ask yourself “Am I wrong?” Listen not only to the suggestion, but the reasons behind it. Having someone turn around and say “I think this boss room is too big” after you’ve spent a lot of time on a design can be frustrating, but sometimes a compromise is easily found. If your programmer thinks your boss room is too big because of performance issues, then there may be other ways to solve the problem, such as reducing render distance or number of bad guys per wave. Make sure to listen very carefully to the comments your team make to ensure that you’re both on the same wavelength. After all, you and your team are working towards making the best game possible, and a second opinion – a specialist opinion in particular – can make your game even better if you know how to respond to such critique.

“If your team feels like they share ownership of your game, they will feel more passionate about and dedicated to the project.”

Trust your team. When designing parts of the game, don’t feel like it’s necessary to fill your designs with an incredible amount of detail. As long as you have a general idea of how you want a feature to be implemented, feel free to leave some blanks. Your specialists are likely to have excellent ideas when implementing and developing your ideas, but if you force them to follow your instructions to a tee you are likely to stifle their creativity. Compare “I need you to create this red pulsing teleport with closing metal doors that glows white when you use it” to “I need you to design a teleport that fits in this space.” By removing all these restrictions, your design team can feel that they are making a real contribution to the game instead of just following orders, and if your team feels like they share ownership of your game, they will feel more passionate about and dedicated to the project.

On this note, I should add that it is important to be very precise with your design specifications. There’s nothing worse than coming back to a team member a day after passing on some designs to see that a piece of ambiguous wording has led to the complete opposite of what you wanted. This could be something as fundamental as the difference between a top-down and a side-on perspective. While it is important to leave some space for creativity when passing design work between teams, being clear about the aspects that cannot be changed in your design specifications is just as important.

“Play to the strengths of your team.”

Undeniably, the most important pillar of teamwork is communication. The more closely you work together, the earlier you will catch a misunderstanding between your teams, which can save lots of time, money and grief in the long-run. Make sure to play to the strengths of your team and, most importantly, respect their ideas and opinions. Be the team member your colleagues can talk to when a conflict arises.

All in all, working alone is certainly a valid possibility where game development is concerned, but don’t rule out working in a team. It certainly doesn’t make your project any less significant, but it might just make your end product that much better.