Game designers come in all shapes and sizes. We've got generalists that work on everything as well as highly specialized craftsman put in charge of a single system. Creative leads often work on a high level, maintaining a cohesive vision for the game and shaping it through feedback, with typically little to no hands-on involvement.

There's no universal distinction, with roles and responsibilities varying between companies, but game designers can be roughly divided into:

• Generalists: Junior and senior game designers, as well as lead designers and creative directors. A generalist will often take care of (or feedback on) all areas of game design not already covered by someone else on the team.
• Economy designers/monetization specialists: A role very likely to be encountered in the mobile games industry as nearly all products require someone with expertise in designing and implementing a fitting monetization strategy, as well as balancing the game economy.
• Level designers: Often a crossover between a designer and a 3D artist. Some level designers only take care of the gameplay side of the level, while others are capable of delivering a finished stage.
• Mission/content designers: Rather than working on new features and game mechanics, these designers specialize in adding and balancing in-game content, from buildings, vehicles, NPCs, and weapons to quests, puzzles, achievements, and more!
• Narrative designers: Tasked with writing, designing, and implementing narrative elements in games. Often work hand-in-hand with level and mission designers to help craft a playable experience.
• Systems designers: A catch-all term for all designers focusing on the more high-level design of game mechanics, loops, and systems rather than content creation and balancing. Big game projects will often have a specialist taking care of multiplayer game modes, player progression, or combat.
• Technical designers: A term usually reserved for highly qualified mixtures of a gameplay programmer and a game designer, or used for a game designer empowered by tools and scripting languages. They design and implement new game features and mechanics, be it independently or by bridging the gap between design and programming teams.

More specialized positions only make practical sense in a big team or a large company that can support them. Look carefully at the opportunities available to you as well as your interests. If you have another passion, explore it; there's a high chance it will become useful or inspiring. An interest in creative writing and storytelling can lead towards a career as a narrative designer. An artistic aptitude and interest in 3D modeling and world-building will naturally lead you towards level design.

On the opposite side of heavy-specialization lies T-shaping: broadening your skill set and the spectrum of tasks you can handle. Developing a broad range of skills (even at an entry level) is always a good idea.

Ultimately, your job is not to design the perfect gameplay system and walk away. You are there to help realize the game's potential, turning it into the best possible experience for your players. Sooner or later on a project, you'll find an area outside of your core responsibilities that you'd like to improve, and often it's much faster and easier to just work on it yourself rather than to create a ticket in the system for someone else to eventually (if ever) address. For the record, I am not advising you to be a rogue agent who constantly messes with other people's work and tries to sneak things past the quality assurance team. I am simply asking you to be very proactive and constantly seek opportunities to improve things. The difference between good and great is that extra attention that often wasn't planned for and isn't necessarily part of the original specification. When things are good enough, derailing other team members just for a tiny improvement is not warranted or productive. In these situations, a wide skill set can enable you to turn great into excellent. Just make sure to share the changes you've made with others—leave the surprises for the players, not for your team!

A variety of skills will turn you into a more helpful and independent team member, allow you to communicate more effectively with experts from different fields, and even improve your creativity. One of the most coveted ones is programming. However daunting it sounds, taking even the most basic scripting courses and tutorials will be hugely beneficial. It will improve your understanding of how games work (including the constraints and possibilities at hand) and perhaps even allow you to create or tweak parts of the game without having to rely on programmers. Just make sure they review your work and decide it's up to their standards!

When it comes to tools, word processors, spreadsheets, and presentation software are absolutely essential, but don't forget about the powers of pen and paper! Even the most basic drawing can help clarify your ideas and avoid confusion. On top of that, having a working knowledge of popular game engines such as Unity and Unreal is highly desirable, and both offer easy-to-follow tutorials. Any generalist should also look into learning 2D and 3D art software, audio and video editing suites, as well as looking into the VFX (visual effects) editors built into the aforementioned game engines.

As for personal growth beyond tools and game theory, I suggest self-studying in psychology (especially cognitive science), creative writing, physics, and economics. But remember, you learn most when you're having fun. Focus on something you enjoy or wish you could do. Take things at a manageable pace and stay on the lookout for new tasks and opportunities to jump on. Experiment, stay curious and don't believe everything you see or hear.

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.

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?

We'd like to help you better understand the production process and the path a game project takes. To achieve that, let's take a brief look at the two most common software development models, Waterfall and Agile.

Waterfall, as we understand it today, is a sequential approach to production with no space for iteration. The product is supposed to go through six rigid phases in a specific order (always trickling down, such as a waterfall):

1. Listing all software requirements
2. Analyzing requirements
3. Designing the whole product and its architecture
4. Writing and implementing all of the systems and content
5. Testing and debugging
6. Operations, support, and maintenance of a completed product

Since this process allows for no iteration, its use in games development is highly limited. It can, however, be applied on a small scale, be it on a part of game's content (asset production) or a single game feature with already proven mechanics and rock-solid specification. Applying waterfall on the whole product (with unproven mechanics and systems) would most likely result in a broken game that ticks all the boxes but is not fun to play at all.

Creating a highly polished and fine-tuned work of art is not easy, which is why games benefit greatly from extensive iteration. These iterative cycles are at the core of the Agile methodology of software development. The Agile Manifesto (http://agilemanifesto.org), which popularized the movement, has led to the development of several frameworks; Scrum is one of the most popular in the games industry.

Scrum is traditionally best suited for teams of 10-15 people; for larger teams, there are modified versions such as Large-Scale Scrum and Scrum of Scrums.

Scrum itself usually relies on sprints (development cycles) that last a few weeks (usually between one and three), as well as short daily standup meetings (where relevant progress is being shared). Longer development cycles can be used but anything spanning more than four weeks hampers the iterative process and becomes very hard to plan. Flexibility is a core tenet of Scrum, and it has to be preserved by adhering to short (but still meaningful) sprint cycles.

In Scrum, a product owner (usually the producer) represents the interests of an end user and ensures that all development tasks are divided into a set of comprehensive tickets.

A task to create a resource trading feature would probably take the shape of a user story (a task that's described from the point of view of the end user), starting with As a player, I can easily trade resources with my guildmates... and would be followed by a detailed set of functionalities and acceptance criteria, and possibly paired with a user interface mockup or a link to a relevant design document. These tasks are placed in the product backlog and wait for the end of the current development cycle. The backlog itself is a database of all tasks and bugs. It's usually handled by tracking software such as Jira and requires regular oversight from the production staff (including the designer).

On top of using software dashboards, many teams opt for a physical sprint board often placed on an actual office wall or a large whiteboard. The sprint board is where all relevant tasks end up, often in the form of sticky notes. Bugs rarely live on these boards as they are too small to track with such scrutiny. Moreover, bugs rarely follow the workflow of new feature and improvement tickets.
A physical sprint board is a great visual indicator and serves as the epicenter of daily standup meetings, where people working on each task share their progress and move the ticket across the board to reflect their progress. Commonly, sprint boards are divided into four columns: to do, in progress, testing, and done.

The sprints themselves can consist of multiple phases. For example, in a game that has already been released, a three-week sprint might have two weeks of development (after which all features are locked into place) and a week fully dedicated to bug fixing, testing, and a store submission of the improved version of the game. Each sprint formally ends with a retrospective and starts with a planning meeting. During sprint planning, any upcoming tasks are pulled from the backlog, estimated by their respective disciplines, and slotted into the newsprint.

Due to their ever-changing nature, game projects are incredibly difficult to plan. By now, most gamers are very familiar with the frustration of having their most anticipated game delayed and pushed back multiple times. In such situations, no one suffers more than the developer; publishers rarely pay for extended development.

Games vary in size, and teams vary in velocity. Still, the main production phase can span anywhere from several months for some of the smaller mobile games, to three or four years for big PC and console titles.

Game projects are divided into specific phases and milestones, and each milestone has a set of criteria that has to be fulfilled. If the project is being funded by a publisher, the developer will only be paid once the milestones are delivered, reviewed, and approved by the publisher.

The production process allows for better structure development, estimating its costs and increasing the chances of finishing the product on spec and on time. Unfortunately, big design pivots, unforeseen technical issues, licensing problems, and financial pressures are commonplace in our industry. Experienced producers always push for a buffer of an additional 15-25% development time on each milestone, and quite often that still isn't enough.

As we already know, game development is risky and expensive. To minimize the risk, during the life cycle of a project it will likely have to go through at least one greenlight gate—a point at which the fate of the game is being decided. A failure to greenlight will force the team to go back and iterate on the idea or result in the game being canceled altogether.

Before real production starts, game designers work with their producers to create and present the initial greenlight documentation to the key stakeholders in the company, hoping to convince them that the concept being proposed is a wise investment of time and money.

Once development starts, a version of the game itself is what's being shown. It's a common practice to start the project with the aim of spending the first several months on creating a so-called Vertical Slice. Vertical Slices are essentially demo versions of the main game hoping to showcase its potential, prove the artistic vision, and validate basic gameplay mechanics. Think of them as vertical slices of a cake: it may cover a very small area of the final product but contains all major ingredients (game systems are essentially horizontal layers). It serves as a good indication of whether it's worth the commitment to make the whole cake/game.

It's not uncommon to use Vertical Slices to present the game to the press, create teaser trailers, as well as to try and get external investors or publishers on board with funding the project. However, at diligent studios, many games will get canceled before they get that far.

While each studio and game producer can have their own way of running a project, a variation of the traditional set of milestones and production phases (borrowed from the movie industry) is employed by most:

• Concept phase: An idea is born! A concept document (usually in a form of a 5-20 slide presentation) is created and pitched to key stakeholders. If the project is given the go-ahead, the initial preproduction team is assembled and tasked with expanding the concept.
• Preproduction: A crucial period where the most important design decisions are likely to be made. Core gameplay mechanics are being validated by prototyping. The game's scope, art direction, technical requirements, production schedule, and team size are all being established. At the end of preproduction, the GDD should be finalized by the designer and approved by key stakeholders.
• Production: The team begins to execute on the agreed design, writing production-quality code, art assets, and content. As a rule of thumb, the further the game is into production, the harder it becomes to make large changes in product design.
  • Pre-alpha: Depending on the length of the project, several interim production milestones are usually set, with the aforementioned Vertical Slice often being one of them. These give the team a defined mid-term goal to work towards and are useful even if there is no publisher (and therefore payment) associated with them.
  • Alpha: At the end of the Alpha stage, the product should be feature-complete, meaning the game is playable from start to finish (should it have one) with all functionalities and content roughly in place. That said, the quality will be far from final, with many bugs left to be fixed and various improvements and changes to be made, often based on the results of playtesting.
  • Beta: Beta represents a much more complete version of the game. In theory, all of the content is locked in place and the only changes being made from there on are bug fixes, balancing changes, tweaks, and polishing. Some companies will conduct public beta tests that are either closed (invite only) or open to everyone.
  • Gold candidate: Once all important issues have been addressed, a release candidate can be approved by the publisher to put the game on the path to distribution! The gold status itself goes back to the old practice of creating a GM (Gold Master)—a version of the game that would be signed off and used for mass duplication of the final product.
  • Release: It's time to celebrate! Your game has beaten the odds! Making games is hard and expensive, and the vast majority never see the light of day.
• Post-release: Depending on the post-release support plan, the team will either drop the milestone structure and handle improvements and additions on a sprint-by-sprint basis or create additional milestones around the creation of DLC (downloadable content) and larger expansions.

Let us delve into a slightly less traditional and more experimental approach to game production. While most game studios avoid talking publicly about unreleased and failed game projects, companies such as Supercell and Wooga often talk about the huge amount of games they have killed (canceled) at various stages of their life cycle. Some projects get canceled as late as during a soft launch that is, a test release in one of the smaller market such as Canada, Australia, Philippines, or the Netherlands.

Isn't canceling 9 out of 10 games hugely wasteful? And why would a nearly finished game ever get shelved?

Companies that adopt this model often operate in the mobile market, where the costs of marketing and user acquisition far outweigh the entire development cost. As the mobile market is a hit-driven one and studio resources are limited, to release a poorly performing product would mean to not work on something with a potentially much bigger upside—an opportunity cost, you may say.

The process of gradually culling less promising projects is what validation funnel is all about, and there's much to learn from it, no matter the type of game you work on and the markets you operate in. For one, games are never sure-fire hits. To allow for a high cancellation rate (especially in the early stages of the development) is to enable your team to take more risks and be creative. It's also important to give the teams the power to kill their product, rather than to have that decision flow from senior executives—the former is empowering and inspiring, the latter antagonizes and demotivates. If the decision has been made well into production, a postmortem presentation should follow. The aim of the postmortem is to analyze the production process, explain the reasoning behind key decisions, and share any learning from the project across the entire company.

The following is the validation funnel and game development process employed at Space Ape games at the time of writing. At the core of the process are small teams supported by shared company resources and outsourcing. While this funnel is focused on free to play mobile games, a similar approach could be taken with any digital product:

• Ideation: At Space Ape games, roughly a day per month is dedicated to an initiative during which the company can come together to form self-directed mini-teams that collaborate on something outside their day-to-day duties. This initiative often has a set objective and creative constraint; it may be around T-shaping, branding, improving existing games, or coming up with new ideas and prototypes. If new games are the focus, the lineup of game concepts and prototypes is voted on by the wider company. Ideas that are popular and deemed viable are then expanded upon and taken into preproduction, or put in the backlog awaiting a more suitable time. The key differentiation here is that new game ideas are not dictated by the executives or creative directors; they form and gain traction organically from within the whole company.
• Preproduction: A team is formed around the idea and works on its design. Core game loop, game pillars, target audience, brand, art, and technical direction are all being defined. The preproduction phase of Space Ape games is kept short and often ends with market sizing.
• Market sizing: This validation phase usually includes market research (looking into industry trends and competition) as well as testing our idea for a brand and potential user acquisition costs. To do the latter, we will often create a set of test advertising campaigns using a few potential art styles and brands for our game. The game will only pass if there's space for the product in the market and potential user acquisition costs are acceptable. It's possible to delay market sizing and begin the work on the internal prototype, but ultimately, all games need to make sure they can acquire an audience if needed.
• Internal prototype: The game concept is now ready for execution and a more polished and feature-rich prototype is being created. The team will now extensively iterate on gameplay and gather feedback from internal and external playtesting. At the end of this phase, a company-wide test is held. If the team is satisfied with the feedback and believes in the product, and if there are no red lights on the horizon, the game idea will live on!
• Alpha: The team switches over to writing production-quality code and continues to develop and playtest the game. The difference here is that Alpha builds can be used to gather external validation. This only happens if the team itself decides to seek real-world insight into certain aspects (such as experimental controls or multiplayer code). In such cases, a test version of the game will be released in a small territory, often with a placeholder name and under the umbrella of a brand new publishing name. The only way to test unknown quantities is to release the game to a real market and see how it fares. As everything is subject to extensive changes and most of the game will still be missing, these early versions of the game do not allow for any in-app purchases and are not ready to provide real insight into important stats such as user retention.
• Beta: A natural expansion of the Alpha stage with production going full Steam ahead. As always, company playthroughs, playtesting, and external validation help to push the game in a more refined direction. At the beta stage, the metagame should be validated (at least internally); this means the inclusion of long-term progression and features focused on improving player retention. The game is still likely to undertake major changes and will abstain from including any in-app purchases.
• Soft launch: At this stage, the game is released in a few territories, with the official title and branding. The game will remain in soft launch for several months as the team works on additional features, balancing, and polishing the product and improving the KPIs (Key Performance Indicators). Such KPIs include user acquisition costs, player retention, purchase conversion rate, estimated LTV (lifetime monetary value of a retained user), game session length, and frequency.
• Release: As the game is nearing worldwide release, the company will work on the game's marketing and user acquisition strategies. By then, the platform representatives (in this case Google and Apple) might already be aware of the product and its upcoming release, increasing the chances of receiving the ever-elusive featuring (for example, a prominent promotional banner on the virtual storefront).
• Live ops: The worldwide release of a free to play game marks the end of the official development phase and the beginning of the live operations era. The game team will continue to work on designing and implementing new features and content, and the game's live operations managers will ensure a steady stream of engaging events. In this world, the release is just the beginning.

Thanks to market sizing, frequent playtesting, and multiple stages of internal and external validation, teams at Supercell and Space Ape games can take risks with their ideas, yet minimize the unknowns when launching a finished product. It may be difficult for a game to make it to the end of the funnel, but once it does, it's much more likely to become critically and commercially successful, warranting ongoing support and investment.

As always, it's important to note that no process is set in stone. While every phase described here is important, the funnel approach is likely to shift and evolve along with industry practices, the company, and its culture.

It's possible that a game project you'll be working on will have a publisher other than your studio. The relation between the publisher and the studio can either be internal (in which case they own the developer) or external (the publisher is connected to the studio).

Whatever the relation to the developer, the publisher will not only release the product under its own name and market it, they are also very likely to cover all of the costs of development. Deals and royalty structures vary greatly, but in most cases, publishers are the ones who keep the cash flowing between all involved parties and are the ones who are set to gain (or lose) the most. Publishing can get very complex; sometimes more than one studio will work on a single game, other times an external owner of an intellectual property (IP) will be involved (the IP itself can be a brand, a book, video game, or movie universe).

When a publisher is engaged in the project, the detailed milestone structure mentioned previously will be of paramount importance as it will carry financial outcomes for the developer. Publishers will have to approve the GDD and provide feedback on each and every milestone; this can, of course, limit the flexibility of the developer, but it will also help ensure the project stays on track and has a chance of being released. Sometimes, publishers also take care of initial ideation and seed the game pitch to the developer.

As you surely realize by now, game development is quite complex and game design itself can be a very broad and elusive subject...

We might have just scratched the surface, but so far we've looked at how games are being produced, what kinds of teams make them, and what responsibilities a designer can assume within a development team.

Some games might have no real ending, but every game project has a start! We'll now put some of that industry knowledge into perspective, and start looking at how to work on a game idea and turn it into a presentable game concept.

And remember, your job is not to design the perfect gameplay system and walk away. You are there to help realize the game's potential and turn it into the best possible experience for your players. Put your personal preferences and biases aside and focus on what's good for the project, even if it requires you to scrap ill-fitting ideas and throw away weeks or months of work in the process.