#game development cycle

[askagamedev]

Highguard got announced and released after Concord’s legendary failure, and it currently is sitting at a few hundred players. Releasing Highguard after Concord’s launch seems questionable. How often are games canned in light of the failures of similar games in the same genre and design space?

The ease of cancelling something is proportional to how close to the beginning we are. When it's still just a small number of devs coming up with an initial pitch, it's super easy to cancel because it doesn't cost very much. We haven't done that much work on it, so at most we lose some documents and maybe some prototypes that we built. Remember, the majority of the cost of any development project is proportional to its team size. During incubation and early preproduction, the teams are a lot smaller - we're only building prototypes and coming up with proof of concept, not building out a whole world/system/game. This means that things are relatively cheap, so the executives are less afraid of throwing out what we've built.

When we're fixing the last cert bugs after spending years of dev time and millions of dollars building and marketing a game, it's more rare to pull the plug and eat all those losses rather than try to put it out and see if we can get some return on that investment. This typically applies regardless of the game genre. Most bigger publishers already have a good idea of what the expectations are for their projects by the time they get the green light for full production. Any game that gets approved for production and its increased costs is usually expected to release.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

What do other developers do while an engine is being developed? I imagine it takes a while before a "first pass" with the engine + game is possible, so does everyone have to become an "engine dev" when trying to build prototypes?

An engine is not in a binary state - it isn't all on or off. Game engines have a set of features that come online as the engineers build them, test them, and fix the issues with them. Before the engine is ready to do real work, the team is typically the smallest - we're still figuring out what the game is going to be, which necessitates thinking about what kind of engine features we will need to build. As such, the non-engineers can start doing work in engine once the parts of the engine they need come online.

While we're waiting for the engine features we need, the artists are coming up with rules for the game's intended visual style and rules for the visual language. The art team comes up with concepts and general rules for main characters, environments, world locations, factions, nations, and so on. Their goal early on is to come up with the rules that will govern the visuals for the entire game.

The designers are coming up with concepts and prototypes for the gameplay. As you may have realized from reading last week's posts about prototyping, gameplay prototypes don't have to be in the game's engine to qualify. Many times you can prove things out using pen and paper, or even in other easier formats. A good friend of mine would use Game Maker to prototype gameplay in 2D before getting it into the real game because he could make gameplay entirely solo with placeholder assets in a short amount of time. Our goal is to come up with the rules that will govern the core gameplay for the entire game.

The hope is that the needed engine features come online as the major conceptual work and rule creation approaches completion. Getting consensus and decisions locked in on how the game will look and play is as important for future development as getting the core technology stood up and working. Remember, [decision commitment] is absolutely one of the fundamental requirements for any development project to go anywhere. If the team leadership is unwilling to agree on where the game is going, then the development process will go in circles either until a real direction is decided or it runs out of fuel and the project is cancelled. It doesn't matter how good the technology is if nobody can agree on what kind of game they're building.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Why do some companies keep studios working on in-development games that are almost eight or nine years in instead of just cancelling them?

The only times I have ever seen this happen has been under one of three sets of special circumstances:

The game is an executive's pet project

Somebody with a lot of influence at the studio or publisher really really believes in the game and so is able to find some space in the studio budget and headcount to keep the project alive. As long as that executive is there, the project is safe. Conversely, as soon as the executive leaves for whatever reason (resignation, finds another job elsewhere, etc.) the project is likely doomed.

The game has already been cancelled and we just don't know about it

The game has been cancelled internally and there is no active development happening on it, but we just haven't told the public about it for whatever reason. I was working at a AAA studio that was building a smaller-scope lower-budget title when the publisher had an executive leadership shuffle. The former VP in charge of our division was replaced and the overall mandate was changed to focus on projects with larger scope. The team tried to pivot to increase the game but the new executives gave the new direction the thumbs down, so the project was cancelled. Even though the title had already been announced, the marching orders were to change the subject if ever asked about it in public and we were told that they would quietly announce its cancellation a year or so later. I never did follow up on whether they actually announced the cancellation, but such things do happen.

The game is being yanked around between publishers/executives and is probably going to be cancelled

Before the previous game I was talking about was actually cancelled, it was in this weird purgatory-like situation where the goals had shifted and they were trying to change the project's overall direction to get executive approval and continue development. In this kind of situation, the project is on life support but not quite dead yet. You may remember how Anthem went on life support just before it was cancelled - this situation is a lot like that, except the game is still in development, rather than trying a post-launch change. Usually the attempt to pivot to something different is just too difficult with the resources and time available, so most projects in this state often turn into quietly cancelled games.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

How long does pre-production last for a triple AAA game? Also sorry second question do developers start working on another game right after they finished launching?

It really depends on the game. For a game within a franchise that has a strong release schedule like FIFA, preproduction can be as short as 4 months as the developers figure out what they have the time to do. For other games, it can be longer - the dev team can spend up to a year in preproduction figuring out the core gameplay for most games, with more time needed for games with really massive scope (e.g. MMOGs). AAA dev really tries not to spend that much time in preproduction because the plan should already mostly be in place by the time we begin - we know what kind of game we're making and we have a solid idea for what kind of gameplay we're trying to build out. The goal of preproduction is to build out to the vertical slice of gameplay, a playable example of all of the game's features and systems working together.

It's worth repeating - the vast majority of AAA games with 5+ years of dev time aren't usually being fully built from start to finish. Most games with long dev cycles get started, things don't evaluate well, the progress gets thrown out, and development gets restarted. Only a handful of game franchises are exceptions to this - Elder scrolls, GTA, whatever Riot or Valve are doing, etc. Most studios just don't have the financial freedom to burn money for multiple years without anything to show for it.

As for your second question, it also depends. After the post-launch vacation time, the dev team usually gets split up. Some of the dev team members usually continue on with the launched game to work on additional DLC content, cosmetics, and so on. Some of the devs can get moved onto another project that's already in progress, usually as part of a ramp-up into production. A few of the more senior team members might be tapped to go work on really early development for new game ideas. And some of the dev team will inevitably decide that they've finished their last hurrah and tender their resignations to go seek greener pastures elsewhere.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

what does it mean when jobs ask if you’ve “shipped a title” in a game?

They want to know whether a product that you worked on was commercially released to the public. They specifically want to know that you've participated in the finishing process of development. The game development process changes over the course of the dev cycle. At the start, things are all about ideas and prototyping. At the end, it's about prioritizing issues, fixing bugs, and maintaining both project stability and consistency of experience quality. The finishing part is quite difficult - it's where the majority of crunch occurs and lots of projects don't manage to make it through the process. It’s the last step of polishing and improvement that a game has before it is released into the wild.

Ideas are cheap and plentiful. Prototypes to prove ideas out are not hard to build. It is the refinement process, the burning away of the stuff that isn't working and improvement of things that are, that is difficult. Shipping a game means catching all of the edge cases and fixing all of the cert bugs. It means optimizing and hardening the codebase so that it can run at frame rate when you need it. Bringing content up to the quality bar for end users to play with it, making that gameplay reliable enough to work in the worst-case scenario is extremely difficult. This is what it means to ship a game. This is why hiring managers ask for it - they want to know that you've been through that trial by fire and have come out the other side with a project you've finished and released to the public.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

How do companies decide how many people are needed to build a game that's been greenlit?

The team’s leadership (with input from the publisher) figures out how much time the project needs and how many people it will need to complete it based on the feature list and the targeted release specs. Let’s try a breakdown as an example of this. 

Imagine that we’ve just been given the green light for a third person single player looter shooter. Our approved prototype has one player completing one quest in an environment where there are a few enemies and a handful of different guns and gear. Now’s the time to figure out what our team will look like (and our budget). Let’s take a look at the things we’re going to need for a basic looter shooter. Necessary assets to create include:

Environments/levels for the players to shoot through (How many environments for the launch game?)

Guns/weapons for the players to shoot with (how many guns/gun variations for launch?)

Items/equipment for the player to equip (what kind of non-weapon gear? How many of each type?)

Different abilities for players to equip/choose (how many abilities?)

Quests for players to complete (how many quests?)

Enemies for the players to shoot (how many enemies?)

Characters for the players to choose as playing (how many characters?)

UI for choosing/displaying your character, equipping weapons, using abilities, engaging with quests, health and damage

There will also be work needed on building how the game feels to engage with:

A level-up system that keeps the player feeling powerful

Enemies that feel challenging and rewarding to fight

Weapons and Gear that make the player look forward to trying/using them

Quest objectives and scope that feel engaging

A combat system (including stat calculations) that is intuitive for the player to understand and engaging for long term play

A reward system to determine reward quality for a given task difficulty

We basically construct a requirements list and a systems list for the entire game. And then we can break it down. So, for example, let’s start with environments:

How many people do we need to construct one environment? This would include concept artist, environment artist, lighting artist, texture artist, prop artist, producer to keep track of it all, QA to test it, etc. Let’s say it takes ten developers total to construct one environment

How long will it take for this team to complete one entire environment? Let’s say it takes this strike team four months to complete an environment from concept to finish.

Let’s say we have a production schedule of two years (24 months). This means that one team of ten environment devs can expect to complete five environments over the entire production schedule (imagine the final four months is set aside for for polish, bug fixing, unforeseen problems/holdups, etc.). 

Lets say that we want 20 environments/levels for the final shipped game. This means that, in order to get this many, we will need (20 environments / 4 environments per strike team for the project) = five environment teams to finish on schedule, or 50 developers in total here.

How much can we expect to pay people in each of these roles? Each person on the strike team has an estimated cost - salary, benefits, workstation, software licenses, internet, utilities, and so on. Add them all up and you’ve got your (rough) environment budget.

That takes care of the rough headcount and budget environment assets. Now repeat this process for the other things we listed above - guns, items, abilities, quests, enemies, characters, and UI. That will take care of the assets we need for the game. Now we need to do the same for each of the systems - leveling up, enemy behavior, weapons and gear, quests and objectives, combat, and a reward system will all have design, programming, and validation requirements to make sure they work. All of those developers need to be tasked and paid. Then add in some additional headcount for general QA, certification, and production support. Congratulations! Now you’ve got a rough budget and headcount for an entire project! Now it’s time to come up with a plan for the post-launch schedule!

This is why team leadership of games tends to be experts who have a lot of experience in their respective fields. A lead developer generally knows how long it should take developers of varying skill levels and expertise to complete tasks, as well as what kind of specialists the team needs for each task. The leadership collaborates to figure out which and how many specialists are necessary for each phase of the project including the rough budgeting.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Regarding the DLC question. I know that these games released DLCs. I just wonder why they still develop new games so fast? For example Fifa still releases a new game every year, even with the Dlc. And Mario Kart 8 Deluxe hasn't seen a DLC at all. It was a re-release of the WiiU Version with the DLCs and some extra drivers packed into it. The Switch version hasn't seen a DLC in 3 years. Maybe I should reframe my question. When do Developers decide to stop making DLCs and make a new entry instead?

There’s a couple of major reasons for building a new game, both from a developmental perspective and a business perspective. Let me try to summarize them for you.

The good thing about building DLC content is that it uses the tools and systems we’ve already developed for the game to make more content. This means we don’t have to build new systems and features to support this content, we just make more of the same. Getting the first working weapon into a game can take weeks or months of development time, but getting the hundredth weapon can take days or even hours. This is why DLC is so much cheaper to build in terms of development resources than the original games - it’s easier to use tools and systems you already have than to build new ones.

This also serves as an ongoing constraint on content development - if we didn’t already build support for this new big feature into the game before launch, it’s really really hard to add it in as DLC. For example, FIFA 17 added a story mode to the game they called “the Journey”. Adding support and content for something like this via DLC to an existing game that did not already have the code systems and assets in place to handle, track, and play story content like this would have been nigh impossible. Many of the core game systems would have to be changed in order to support a new system like this; the scope of a change like this would be far too large for it. Franchise games like FIFA or Call of Duty have a constant need for both adding new features and overhauling/improving old features. We have limited development time for the core game, which means that we have to pick and choose which some new features get added and which some old features get overhauled or improved. Then, when the next game rolls around, we have to choose a new slate of new features to be added and a slate of old features get overhauled/improved. In this effect, things are cyclic - we improve/overhaul systems A, B, and C in Franchise Game 2020, improve systems D, E, and F in 2021, and so on. Thus, we need to make a new game when we want to add new core features and upgrade/overhaul old ones. Incidentally this is why, if some players only plays Franchise Game for system A and/or B while ignoring E and F, they’ll only see roster changes - they aren’t looking for the big changes the devs made. 

There’s also the business reasons for periodically releasing a new game. When we launch a new game, it has an accompanying marketing push. Whenever a new game launches, new players who haven’t played the game before will be persuaded to buy the game. This does not hold as true for DLC content releases. When we sell DLC, we aren’t targeting new players with it - we’re targeting players that have already bought and continue to play the game. Adding a single new character to a roster of two dozen is a lot less compelling to players who don’t already own the game, but adding a new playable character is really exciting if you play the game every day. Unfortunately, we naturally “churn” (lose players over time) for a variety of reasons - players get older and their priorities change, they get bored of the game, they find new games they like to play better, and so on. This means our customer base for DLCs is constantly shrinking over time. This is also why many long-running games will periodically release large expansion packs (e.g. Monster Hunter Iceborne, Street Fighter V: Champion Edition) to try to entice new players to give it a try and old players to return. These large expansion packs are generally like a partial lerp (interpolation) somewhere between a DLC and a new game release depending on the expansion pack’s scope. 

That’s generally why we stop building DLC and build a new game. From a development perspective, we want to add new big/core features and improve old ones that are too large or problematic to fit in a DLC. From a business perspective, we’re constantly bleeding players from the player base and DLC doesn’t often bring in fresh blood. New games do. Big expansion packs fall somewhere in between DLC and new games. 

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Do you have any tips for pre-production? What things should be decided on before coding starts? What percentage of time and to what depth would you suggest going into with pre-production?

Preproduction is the period you go through when you take your high-level concept (e.g. “Pokemon crossed with Metal Gear Solid”), figure out what that will actually play like (”We’ll allow players to sneak around a large open world, capture enemy soldiers, and then use them to crew their own bases”), and then prove it will work with a demo showing the game systems interacting (build part of an open world, let the player capture enemy soldiers, let the player use them for crewing a base). When you’re finished with preproduction, you should have your [Vertical Slice] ready to show.

Clearly, this means that you have to start coding during the preproduction process. It just means that the code that’s being written is more exploratory - build the infrastructure for what you will need down the line and get something working relatively quickly that may not have all of the bells and whistles, but does what you want. The systems that are being written should establish a solid foundation for the future. This is not the time to be hacking stuff together, there will be plenty of that later. This is the time to be building the most solid foundation you can for the game.

Pre-production also includes figuring out the general scope of the entire game - how many different levels/environments are we planning for, how big are they, how many different enemies, how many different animations, how many characters, how long is the game going to be, how many weapons, how many armors, etc. These don’t need to be exact, but it does need to be a ballpark figure so we can start planning for the production schedule. We need to know how much we need to build, and how much time we have to build it because we usually have a targeted release date and we have to make sure the whole production fits within that time frame.

Your goal is to have the major elements of your game established and set by the end of preproduction. You should know what the game will play like, what the core systems are, how much stuff still needs to be done, and roughly how long it will all take. You should have a demo of the absolute minimum that you need to show off to prove that your game is fun and worth building. You should have a framework for the rest of the game built. You should have a production schedule that shows what still needs to built by when. All that really should be left to do by the end of preproduction is to put the plan into action.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ