Development teams

In tiny independent teams, there can often be no space for designated product people (a term used to describe producers, game designers, and live operations managers). In such situations, game design responsibilities are distributed between the artists and programmers.

However, while a team with no designer may work well on a small indie scale (one to four people), the prospect of running a game team of more than five people without a designated designer is a very risky one. With the freedom of distributed design (colloquially called design by committee) often comes a lack of ownership and accountability. Making good design decision becomes increasingly difficult as the game is being pulled in different directions and lacks a cohesive vision. In such teams, even the most pressing gameplay issues can go unaddressed. Everyone loves to chip in with their ideas, but nobody feels compelled to work on design problems, be it for the fear of associating themselves with them, or the conflict of going against the rest of the team.

You're most likely going to be a part of a small or mid-sized team. Anything with 15 to 30 people would be considered a medium-sized team, and this number will always fluctuate depending on where you are in the development cycle and includes a total of two to four design-oriented staff members. A smaller operation has a headcount of 5 to 12 people, and one or two other design-oriented people at most. It's also quite common, especially for a senior designer working on games with a relatively manageable scope, to be the only designated game designer on the project.

Each company has its own approach to managing human resources. And while various artists and even programmers jump in and out of projects to help the teams around critical milestones, designers are often in it for the long run, that is, from preproduction until the game is released, and most likely some more after that. This is not only because of the importance of having a unified design direction but also due to the sheer amount of time and effort required to get to know the game and make meaningful design decisions.

While bigger teams have hugely varying structures, with space for a very low-level specialization, medium and small teams usually share a similar setup across the industry. As a great example of the strategy of small teams, let's look at the creators of Clash of Clans, the Finnish game company Supercell, who by definition are an assembly of independent cells. Each cell is a small team consisting of a producer, a few artists and coders, at least one tester, a generalist game designer and potentially a monetization/live operations-oriented person. People rotate in and out of their cells slowly as games are kicked off or killed (canceled). Each team can also count on support from a stable of people who work for the whole company, taking care of player analytics, finance, social media, operations, customer support, marketing, user acquisition, and more. The goal of Supercell's structure is to create an environment that facilitates creativity, and gives each team the power to make decisions on a game's design and direction.

Responsibilities of a game designer

The tasks and responsibilities of a game designer vary dramatically and are affected by the team structure, project type, and the development phase.

To shed some light on what you might be required to do, let's look at a real-world example. Here is a list of tasks I undertook when working with a mid-sized team at a London studio, Space Ape games, on a mobile game, Transformers: Earth Wars. The game could be classified as a part of the Build & Battle genre—similar to Clash of Clans, but with a multitude of unique characters, all with their own attacks and abilities.

In the two and a half year period (one year to soft launch, half a year to polish the game, and a year of live operations), my tasks included:

• Writing the GDD (game design document) and most of the subsequent feature specs (smaller documents explaining game features and content required).
• Communicating the design vision (face to face, and in writing) and overseeing the implementation of game mechanics, features, and content.
• Creating user flows and sketching user interface designs.
• Prototyping, designing, and implementing new gameplay systems and content including characters (with varied classes, stats, behaviors, weapons, and special abilities), game modes, achievements, buildings, and defenses.
• Level design and creation of single-player campaigns.
• Planning, scripting, and tweaking tutorials, achievements, and cutscenes.
• Balancing gameplay with dozens of special abilities and over 100 unique characters.
• Writing and integrating in-game text and dialog.
• Requesting and integrating new VFX. Over time, I also started doing more and more particle effects on my own by tweaking and combining existing ones (thus enabling that artist to work on other games).
• Planning a future content roadmap: new characters, game features, and story developments.
• Managing an external writer and audio engineer, creating a list of tasks for them, feeding back on their work, and integrating it.
• Addressing the community via weekly Twitch Live Streams, YouTube videos, Q&As, and more.

Now, this sure sounds like a lot to handle! Fortunately, I had another senior designer working with me during the first year of development. We also had the entire game economy handled by our monetization specialist. This included setting up and fine-tuning the income and spending of in-game currency, level up and upgrade curves, building timers, in-app purchases, and more. We also had a live operations expert who joined later and took care of our weekly special events, in-app purchase promotions and content rollout. All of these tasks can, and often will also fall on the game designer.

Do not worry though! Throughout this book, we'll shed light on these confusing terms and technical jargon, and build an understanding of how to approach your daily tasks as a game designer! First up, how are game projects run?