Voice acting has a lot of associated costs. Specifically, getting the voice acting requires us to pay for:

• The voice actor's time
• The recording studio time
• The voice director's time
• The developer time

These can add up - we pay union voice actors about $2000 per day each according to the current [SAG-AFTRA interactive media contract rates], and we spend at least that much for studio time. We also need to factor in the time the developers are away from the development studio and are at the recording studio because they aren't doing their normal tasks while taking care of this. It isn't uncommon for voice recording to cost over $10,000 per day, all things considered.

In addition to this, voice actors are often quite busy. They often have many roles already scheduled that they have committed to. This means that they might have only one or two days they can commit to recording, then be unavailable for months after that. In such cases, it means that we can't make any modifications or changes to the script after the recording is done because the voice actor isn't available to do those lines anymore. For example, take a look at [Aleks Le's IMDB page]. He did a lot of voicework for games like Persona 3 Reload, Street Fighter 6, Octopath Traveler 2, etc. I count 18 separate projects he recorded for in 2023 alone. If he's one of my voices, I probably wouldn't be able to get him back in the recording studio for several months since his schedule is so packed.

SWTOR is especially difficult to record for because player voice lines need to be recorded once for each character class. That means aligning eight different actors schedules before a hard deadline, and that can be extraordinarily difficult. Anyone who's tried to schedule events knows this - things happen, people change, agreements fall through, things get pushed back. As such, it's a small miracle they're able to keep putting out fresh voiced content like they do.

[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

I think you have the wrong idea about what game designers do. We're not project leads that pitch entire games, we're [content creators] that build the bits of specific content in games - the spells, the monsters, the fights, the classes, the races, the quests, the environments, the stats, the companions, and so on. Your typical AAA dev team has hundreds of developers, including dozens (or even hundreds) of designers there to create the items, quests, abilities, enemies, fights, crafting recipes, and other content that players engage with.

There are times when studios will solicit pitches from the rank and file, but these are few and far between. Everybody from the oldest of the old to the newest of the new have their own game ideas that they want to get made. Only those who have amassed sufficient experience and influence with publishing executives are typically given this opportunity, often because anyone who leads a new game's development is being trusted with hundreds of thousands, if not millions, of dollars.

[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

In-game economies are entirely different beasts than real-world economies for one major reason - total currency is not zero-sum. In the real world, it is (mostly) zero-sum - individuals cannot create money out of nothing, so any amount of currency I spend is transferred to someone else and the total amount of currency in the system is preserved. No individual can buy real gold bars infinitely, they'll run out of money to buy the bars eventually and the price of the gold bars will increase as the cheaper sellers are bought out and remaining sellers raise prices. At the ultimate end, there is only so much gold on the planet, which means that even an individual with effectively-infinite money has an upper limit on the total amount of gold she can buy.

In most games, a player character can typically sell as many wombat testicles to the NPC vendor as she might have, creating new currency out of thin air for each testicle sold. There is no limit to the number of wombat testicles she can sell and there is no limit to the amount of currency the NPC can generate for her. Similarly, any currency spent on NPC vendor goods or services (e.g. training costs, equipment repair costs, resurrection costs, consumable costs, etc.) is completely removed from the system. This is called a "faucet to sink" design. The NPCs that generate currency are the "faucet" from which the money comes, and the NPCs that remove currency in exchange for goods and services are the "sink" in which the currency is removed from the system. When the faucet and the sink are generating/removing roughly the equivalent amount of currency from/to the system, the system is in balance. When the faucet outproduces the sink, more players have an ever-increasing amount of currency which is inflation - too much currency chasing too few goods. When the faucet underproduces the sink, we have deflation (which is much rarer) - too little currency chasing too many goods.

In order to reduce in-game inflation, the solution should be fairly obvious - the designers introduce new "sink" options to remove additional currency from the system. This usually takes the form of new consumables, gear options, or benefits from NPC vendors that cost a lot of currency to utilize. Since players will want these new benefits, they'll start spending more currency instead of hoarding and inflation will fall.

[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

Steam could do that, but that would make it a much more strongly-curated platform similar to the game consoles. This would ultimately result in games that had a higher quality bar, but also a lot fewer games in general because there's no way to automate testing games like that. Further, it would also significantly raise the cost of publishing games due to needing workers to do the vetting and quality assurance - they would have to test every game that gets submitted to make sure they comply with Valve's theoretical regulations and either pass or fail those games. Paying for those costs would have to come from somewhere, either cutting into Steam's margins or raising Steam prices.

[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

Any company that wants to release a premium game console basically needs to make an enormous investment that will probably not pay off for years. There are three major requirements for this process.

First, the company must develop gaming hardware. This is generally an expensive process - building anything physical is costly, time-consuming, and is a moving target because competitors aren't stopping either. The hardware must be manufactured and factories equipped and set up for mass production.

Second, they must develop software development tools for both themselves and for external developers to use in order to build games for that console. This requires a significant internal development team to build drivers and software interfaces. Beyond this, they likely need to develop their own flagship game (or more) to launch with the console. That generally costs at least $50 million for a AAA-fidelity game and at least two years of lead time to build alongside the hardware development.

Third, they must secure investment from third party developers to build games for that console. Using that $50 million price tag for a game, we'd need at least four or five additional games to launch with in order to entice players to buy in - no one buys a game console without games to play on it. If they want four launch titles to go along with the console launch, that requires at least $200 million in investment from others.

There are only a handful of companies in the world that have the kind of money, technology, and resources needed to make such a thing happen and some of them already have game consoles. The others look at the market, at the cost of entry just to compete (not necessarily even to pull ahead), at the expected returns on investment, and it's no surprise they choose to invest their money in other opportunities that seem more likely to bear fruit.

[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

For those who haven't read it yet, here's my old post on a [typical day as a game designer]. When we're crunching, we just have a longer work day. Tasks don't really get more difficult or time-consuming when we're crunching; we still need to be able to complete each task in a reasonable time frame. Instead, during crunch the number of tasks we need to work through increases significantly, so the "identify the problem, iterate on solutions, try and test solutions, submit a fix" process just happens more often each day.

Normally, I can get called in to prioritize new tasks as they come in, get assigned a new task, or ask/get asked for help about an existing issue during the work day. During crunch, that time frame increases into the evening (e.g. late breaking bugs/issues) and sometimes into the wee hours of the morning. In addition, the bugs that must be fixed during crunch get a little weirder because not everyone is around or available at all times, so I would often fix bugs outside my area of expertise. There have been occasions where I got assigned a critical issue for the sole reason that I was still awake and at the office. That kind of trial-by-fire experience is what hiring managers are looking for when a job description asks for shipped 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

You're correct about how developers getting promoted or moving to other studios can affect things, but it goes further than that. Honestly, it is because whole teams and individual team members change over time. People age and grow, life priorities shift and move. Becoming a parent, for example, radically shifts a person's priorities. Any of the game's major decision-makers becoming a parent can drastically alter the direction of the game. The longer a game or franchise runs, the more difficult it becomes to maintain the singularity of vision.

If we hire somebody completely new to take over, we lose that singularity of vision because the new leader will bring a new perspective. Even if we hire longtime fans of the game to work on it, the ascended fans' decisions will emphasize what they liked about the game and de-emphasize what they didn't. This can take a game in a direction that portions of the playerbase dislike - the players who don't share the same likes as the ascended fan. Think of what would happen to the Dark Souls franchise if the new leader was only a fan of the difficult boss fight aspect and chose not to spend those resources on the ambience and world building aspect of the game.

To some extent, yes - developers and influential stakeholders will move around as part of their careers or lives. Developers will grow and change over time, they'll take new jobs, retire, have kids, and their lives and priorities will change. New decisionmakers will join the team and will have different visions for the franchise than their predecessors. Beyond this, even player tastes will grow, change, and evolve over time as well. The old stuff that was super popular before won't cut it again if there isn't anything new to offer. If the directional changes meet the collective players' (both new and returning) tastes, the franchise will continue to see success. If they don't satisfy, the franchise will struggle.

[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

If keeping the beat is the most important thing in the game, then you build the game around keeping the beat. There are many different ways to approach the problem, but if I were building such a system myself, I would start with a system to handle a data-driven beat (e.g. this level/song sets the beat to X, that level/song sets the beat to Y) and then build all of my visuals and gameplay on top of that. The key component to making this work would likely be an animation system that could scale animations faster or slower in order to match the timing of the music.

On the data side, this would mean all animations would be built so they could be sped up by dropping frames, or slowed down by holding certain frames for additional length. All animations would also need to be the same length (or a multiple of a standard length), so that I can ensure the animations will fit into a standard musical measure. If I wanted to have a variety of attack animations and hit reactions, I would probably also establish a set of rules that each attacking and hit reaction animation must always be the same number of frames. I could further standardize each attack and hit reaction active frame happening on the same frame each time.

The code side would then play my animations to those musical measures along the beat. It would do so by scaling the animations longer or shorter based on the beat. The system could add or cut animation frames so that each animation can play in sync with the music. Once I've got the animation system integrated with the beat-keeping system, I can then ensure each animation should start playing on the appropriate frame to keep the beat. As long as the animations are scaled to the musical measure and the music keeps the same beat for its entire duration, the animations should always sync to the beat of the music.

[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

While it's true that many game developers are tech savvy, there's more to IT than just keeping a workstation running. IT at game companies does the same thing that IT does at any tech company - they set up, maintain, and make decisions about tech solutions for an organization. That might mean choosing whether to use Discord or Slack, Jira or Trello, Zoom or Teams, and integrating all of the various elements into each other, like being able to launch Zoom from Slack, or integrating Slack bots to pull data from Jira to post it in the chat channel. They are also key in operational security by setting up software solutions for protecting against (and taking care of) viruses and malware.

Basically, having some experts to give direction helps free up the rest of us from having to think about IT and able to focus on our own work. We might be able to do some of this, but it's better to have it set up for us consistently across the studio than leaving us to each try our hand at countless inconsistent versions of the same workflow, especially since screwing it up could sacrifice a lot of productivity while the IT issues get ironed out.

[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

Production makes the final call on bug prioritization, but they take the advisement of the other departments under consideration while making those choices. You are correct that the bugs that stop people from working are the top priority. Below broken builds, live issues that allow players to exploit or grief others are often top priorities. Other than that, it's a jumble of completing the remaining tasks that need to be done for our next release (especially those that allow others to work) and fixing the bugs that come in. Things that are mission critical are more important than things that are good to have, which are more important than things that are nice to have, which are more important than wishlist items. These get ranked against bugs that ruin experiences, bugs that bother players but don't ruin experiences, bugs that are annoyances but not real bothers, and so on.

[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

Even in walking simulators, there's still the active element of moving around the environment and examining each item. The player retains agency in exploration games, even though there aren't too many other overt actions to take.

Consider a "walking simulator" like The Talos Principle. The actions that the player take include exploring environments, collecting puzzle pieces, avoiding obstacles, jamming obstacles, moving boxes, climbing boxes, using boxes to obstruct enemies, and that neat time recording feature. The Talos Principle primarily interweaves the exploration and narrative elements with puzzle solving.

Another "walking simulator" is The Stanley Parable. In it, there's really only exploring and interacting with the environment, but the presence of the narrator enables two major actions the player can take - obey or disobey the narrator and see the results. It is these decisions and actions that provide the engaging gameplay - the players get pulled in by seeing the results of their choices.

The important thing about the actions that the player chooses to undertake is that every action a player does must cause the game to react to that player's specific actions. Moving from point A to point B shows the player more of the world. Choosing to interact with a door means the door opens, revealing what was behind it. Allowing the player to jump should allow the player to reach places that would otherwise be unreachable without the jumping. The actions a player can take must be acknowledged and recognized by the game. This creates a sense of agency and ownership that places the player in the game world. The player experience changes from "Kratos pulled the head off of Helios" to "I pulled the head off of Helios". These active choices cause a sense of self-insertion that would otherwise not exist if everything just happened while the player passively watched the scene unfold.

[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

If we're developing a cross-platform game, we aim for the best performance we can squeeze out of our lead platform. If we're targeting PS5 as our lead SKU, that's 16 gigs of RAM, 8 cores at 3.5 GHz, and so on. We aim the majority of our dev time for that first and then we adjust up/down for the other platforms we're building for to stay within reasonable performance specs.

If the game is targeting PC exclusively or as the lead platform, I've seen two different general approaches. The first of these is the "enthusiast" approach where the team is purposely aiming for high visual fidelity and high spec machines as a selling point. Crysis is probably the ur-example of this approach, though it has somewhat fallen out of favor recently. This approach usually aims for near the top of the line when we're finishing up pre-production, which usually means it'll be targeting hardware specs about a year older than the latest by the time we launch. We can't really keep moving those goalposts because top of the line is always a moving target. Instead, we need a target set during production where we're doing the majority of asset creation, so we generally lock in our goal around the time pre-production ends and stick to it.

The second approach is the "broadest possible audience" approach where the target spec is good performance on the common spec at PC cafes in Asia, because that is the largest number of potential players. Blizzard was pretty famous for adopting this approach to their PC game development. By making the game able to run well on potato settings, we remove barriers to entry for as many players as we can. This generally means we can't put in as many pretty effects and visuals, but it also means we have a broader target audience.

[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

The most common answer in all of game dev is always "it depends". Most game development falls along a spectrum with one extreme end being "well-oiled machine" (i.e. a project where almost everything is already well-established) and the opposing end being "no idea where they're going and holding on for dear life" (i.e. everything is new and vision/direction is constantly changing). Qualities like clarity of vision, team leadership, and total team experience will determine where on this spectrum each project falls.

If the development process is disciplined and things are proceeding to plan, the demos we show to the executives are not far removed from the final versions we release to the public because things are proceeding as expected. The better-established the game and its feature set, the easier it often is to develop. Franchise games like Madden, COD, or Assassin's Creed, or long-running games like World of Warcraft have a well-established formula, very experienced teams, and a deep tool chest that allow games and game content to be built very quickly and efficiently. They are well-oiled machines that don't often have to reinvent the wheel because they've been using and improving on that process for many years already. They know exactly what they are building and are very good at delivering it. Any demo they build to show off work in progress will be very close to what will be shown in the final version of the game. Very little work will need to be redone.

If development is troubled and the team is having difficulty hitting their goals and milestones on time for whatever various reasons, then the demos will reflect that. Most troubled development executive demos tend to be smoke and mirrors, with a lot of hacks and demo-exclusive assets that are held together by bubblegum and a prayer. These kind of demos can cause the team to enter into a death spiral because cobbling a bunch of hacks together for a demo actually puts the team even further behind schedule because we can't use those kind of hacks in real production. This means that these teams need to build almost everything twice (at least) - a hacky rushed way for the demo and then the "real" way. They constantly need to "catch up", but the hacks they put in place often cause instabilities and [technical debt] that must be addressed later on, which puts them further and further behind. This is commonly known as development hell.

These are, of course, the two extreme ends of a single spectrum. Most game development projects fall somewhere along that spectrum. More experienced and established franchises lean towards the "well-oiled machine" side because they've had all the bad practices beaten out of them over the years. Most new IP and experimental gameplay tends to lean more towards the wild-and-crazy side of the spectrum, because there are too many [unknown unknowns] on projects like that. If you ever find yourself repeatedly behind the 8-ball crunching to put together many demos in a row with lots of hacks, you may wish to consider parlaying the firefighting skills you've learned into a job 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

• Spend money on paid DLC and microtransactions if they have any.
• Talk to your friends about the game
• Post about the game and any new content that comes out on social media.
• Engage with fan and official posts on social media.
• Leave a user review of the game.
• Draw and post fan art and/or fan fiction.
• Make and post cosplay.
• Play the game a lot

Basically, what every dev is looking for are players who will spend on the game and players who will continue to engage with the game content outside of the game itself. The more people the game can reach organically, the more likely they'll get more players, more paying players, and more overall success.

PS. Conversely, if you want to do your part to kill a game, just don't engage with it at all. Let it rot, pay it no mind, and don't engage with it even if you hate it. Hate posting is still engagement. The only way to win is not to play at all.

[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

For developers in the trenches like me or my team, it's a fairly common occurrence that individual contributors will not be able to finish certain tasks by a given deadline. Sometimes the estimates and the actual work needed are nowhere near congruent, sometimes there are dependencies that took longer to work out than expected, sometimes there are unpredictable events like system outages or developers needing to take a medical leave of absence. In such situations, we adjust what we're delivering for this milestone and that task and any of its dependencies usually gets "punted" to the next milestone. Individual tasks can often shift back and forth without affecting the overall milestone too much.

It is actually possible for an entire milestone to slip as well - if the mission-critical deliverables for the milestone aren't done in time for whatever reason, the milestone isn't going to be accepted by the money people. Remember, the milestone schedule is originally pitched by the studio and agreed to by the publisher. It outlines exactly what the studio needs to deliver and demonstrate at each milestone and when each milestone should be there. Independent developer studios are often paid by the milestone, so missing or delaying a milestone delivery can mean that we don't get paid until we deliver.

When studios start missing milestones, the publisher often steps in to "meddle". Missing an entire milestone by a significant time frame is a big deal and often means the entire delivery schedule needs to be re-negotiated and re-planned. It's a sign of development hell and a project in a lot of trouble. From the publisher perspective, this is saving the project - things are already off the rails and need fixing or the entire project will need to be cancelled and the studio cut loose.

[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

They're not wrong in that building such things isn't free. However, you're also right in that we on the dev side should be thinking about better ways of doing this - there isn't only one solution to these problems. Whatever final solution we implement doesn't have to be the most expensive means of doing so. It's actually up to us to think of better/more efficient ways of doing the things we want to do. Adding accessibility options is often a worthy goal, not only to the players who need those options to be able to play, but also for general quality-of-life. If we're making changes after the fact, of course they're super expensive. If accessibility options are a production goal that we plan for, they're much cheaper because we don't have to redo work - we do it with accessibility in mind in the first place.

For example - let's say that we're working on UI and we have this system:

Let's say that we want to improve things for colorblind players. If we wanted to make this more accessible, instead of just using color to differentiate the choices, we could also add different border visuals to provide additional context.

In such a situation, the difference in choices is still obvious if you're colorblind and it helps legibility for non-colorblind players as well.

These kinds of UX changes can be expensive if we decide to do it after the fact, but if it's something we decide is important to us from the jump we can compensate for those costs by creating efficient and smart solutions early. Remember, the cost of any change in game development is directly proportional to how close that change is to shipping the game. The earlier the change is made, the cheaper it is. Furthermore, we make resource allocation choices based on our goals. If we want to make a game more accessible, we will figure out a way to do so that fits within our budget and provides a good player experience. Players don't really have a say in how we allocate our resources and that kind of armchair producer talk isn't particularly constructive anyway. Telling us what's important to you and why (including accessibility requests) is really the best kind of feedback we can hope for. Don't sweat coming up with the solutions or fretting about where we spend resources, that's our job.

[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

The good news is that the PS5 and the XSX aren't too far away from each other in terms of hardware power and architecture. Further, developing on XSX also mostly works out of the box with DirectX, which means it is easy to also get the game running on PC. It's relatively easy to build a game out of a generic system and task our engine programmers with getting that generic system working on each of our target platforms.

The difficulty in multiplatform development comes from trying to get the same generic system to run on drastically different hardware power profiles or architectural differences (commonly known as the Nintendo problem). If we have a game that assumes the player's hardware have at least 16GB of RAM and an 8-core 3.5GHz CPU and we suddenly have to fit that game into 4GB of RAM and a 1GHz 4-core CPU, we've got to make a lot of drastic changes in order to get the game running at all. I'm fond of saying that porting PS/Xbox games to Nintendo hardware is trying to get an entire Honda Accord to fit inside a Mini-Cooper.

The general rule when estimating the cost of making a change is how early during the process the change is made. The earlier in the process the change is made, the cheaper the cost of the change. Making a change to a movie before it's cast and shot is much easier and cheaper than making a change after the filming is complete. Making the decision for a project to go multiplatform from the jump means that the entire project will be built with maintaining multiplatform stability as a major goal. This means that further decisions will be made with that goal in mind - the team might spend those resources elsewhere instead of optimizing for certain platform-specific hardware features.

As for why Square-Enix decided to go platform exclusive with FF16 and the FF7 Remakes, it is likely that Sony offered them a seemingly-better deal. Most third party publishers get a standard deal with the platform - the platform takes a 30% cut of all of the game's revenue, the game must pass certification, the platform gets some kind of exclusive content for that version of the game, and so on. If the platform wants to get an exclusive, they offer a better deal than that - maybe Sony agrees to pay for some of the marketing of the game, maybe Sony takes a smaller cut of the revenue, maybe Sony waives the certification costs on the publisher's next five Playstation games, and so on and so forth. These concessions and incentives are certainly worth considering. Sometimes they work out well for the third party, like Insomniac's Spider-Man games. Sometimes they don't.

[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

Chances are good that they had considered it at some point and decided against it. It's important to remember that there's both a money and a timing issue at work here. It's no coincidence that it's been almost 3 months exactly since the last round of Microsoft gaming layoffs. The accounting numbers don't look so good this quarter and Microsoft must keep its shareholders happy, so they are looking to save money in some way, but they need to change those money numbers within a specific time frame in order for it to count.

Any number of possible results could have happened, but the general decision making criteria is to choose the solution that results in the most money saved within the time frame to help make the numbers look better. Perhaps they tried, but couldn't find a buyer that was willing to commit. Maybe the prospective buyers didn't offer enough. Maybe they found a buyer, but that buyer couldn't get the money together fast enough and bailed. Maybe the studio leadership didn't want the studio to be sold. Studio founder Shinji Mikami left Tango Gameworks about a year ago after shipping Hi Fi Rush; there may have been difficulty finding studio leadership to take over.

Ultimately, this is all just speculation. Only those within the affected parties are truly privy to the details and it is unlikely anyone with real knowledge is going to spill the beans on this. I feel a great deal of sympathy for those affected and hope they are able to find something new soon.

[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

Despite the common myth that publishers are evil vampires who exist to make things work, publishers really do serve a legitimate purpose that makes them valuable. What publishers do is provide logistical support to the development studio. Beyond the obvious of providing funding to build the game, publishers also generally handle things like:

• Providing QA support
• Providing technical support/code/back end for console development
• Providing tool support
• Providing network/back end support
• Handling game marketing
• Handling the business negotiations
• Handling physical media and delivery

All of these things both cost a lot of money to establish and require specialized staffing to handle. Most game studios don't want to do these things because it means the studio leadership has to step away from overseeing the game development and focus on setting up all of those logistical elements. As always, there are negotiations made in the contract between a publisher and a developer - the publisher agrees to do all these things and provide X moneys to the developer over this period of time, and the developer promises to deliver a game based on this schedule with these requirements.

One key thing to remember is that attacking your partners in public is never a good idea from a business perspective. Even if the relationship was strained behind closed doors, being anything but supportive of your partners in public will be remembered - not just by the partner who may choose not to work with you again, but also by other prospective future partners who will want to avoid getting burned in a similar fashion. The temporary internet points from players for being "on their side" just isn't worth it, especially because players are fickle and will turn on you in an instant, but potential business partners have elephant memories.

[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

Every major studio I've worked at generally has their own automated build system. These build systems are not shared between projects at the same publisher. This is because each game has its own file structure, asset list, and scripts that must be processed alongside building the code in order to result in a functioning game build. The larger the project/franchise, the more elaborate and powerful these build systems tend to be.

The Call of Duty team, for example, has a build system that allows developers to build the game with a shelved changelist against the current depot on multiple platforms (PS4, PS5, XB1, XSX, PC), and run a full suite of tests on the result in order to validate the changes. The devs are required to run this build and validation process before being allowed to submit their changes in order to ensure stability in the game. The build system is also constantly running in a cycle to compile all of the game's maps and packages for QA to test.

[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

I don't think there's a term called "memory loss", but you're probably thinking of a "memory leak". A memory leak is when a program grabs more memory for use while looping than it releases. This results in the machine using more and more memory over time, thus having less and less available memory to use. This causes slowdown and eventually crashing once all of the available memory has been used. When you reboot, all of that claimed memory gets released and becomes available for use again. That's why your games run faster after rebooting, the games have access to more memory after the reboot.

[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

Cinematics are mostly for storytelling purposes, but they also hid a very real secondary purpose - we would do a lot of game setup during cinematics, like streaming data off of a physical disc while the cinematic is playing so that we can load what comes next. If we need to load a bunch of assets, it's much better to hide that in a cinematic than pop up a loading screen or force a decompression area like a tight locked corridor to hide the new environment popping in. This kind of thing is less important now that we can install the full game to the hard drive and most gaming devices are now running SSDs, but it was a real concern before ~2012 or so when we still needed to read data from optical drives.

[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

There are certain things that studios and companies can ask us not to do but have a real hard time preventing, especially if the company is going through a death spiral process. Keeping a personal copy of stuff I worked on, especially in an age of remote work, is one of those really hard-to-prevent things. If the company or studio is going under, almost everyone is losing their jobs and the motivation to maintain operational security is very low. Nobody in security cares when their main priority suddenly shifts to finding a new job. In these situations, leaked stuff happens a lot more often since there's little motivation for enforcement.

It's much harder for workers who are let go from a company that remains alive, since breaking NDA would result in being liable for a bunch of damages. However, if I don't disclose anything and just keep stuff private, the studio cares a lot less about whether I have those files. They don't really do much forensic analysis of the workstations of former employees, they mostly just wipe them clean in order to protect the company from potential liabilities from accidentally finding left-behind personal files of the former workers.

The thing about old game projects (especially for cancelled games) is that there's really only so long that the old stuff is even viable. The inevitable passing of time will decay any knowledge of the project and its workflow. If we release information and development stuff about games that were cancelled, say, two console generations ago, it is unlikely that the current IP holders and leadership would be super angry about it because so much time has passed. This is considerably different from releasing information about a game that was cancelled this year, where things are still raw and legal action is still a very legitimate threat.

The main benefit to holding on to old projects is primarily for personal education. There's a lot to be learned if one can go back and study the way things worked on an old project. How did they set things up and why? How can I learn what decisions my seniors and leads made, and why did they make those decisions? How did they solve these problems? Can I use those same techniques? There might be some element of internet influencer points if old stuff gets released to the public, but that typically gets glossed over the way trivia is treated. In my opinion, the real value in old project assets is in the educational content it can provide.

[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

You're talking about downtime. Whenever I have downtime I try to be productive if I can, but the type of downtime determines what I can do. There's two main types of downtime - when my workstation is still usable and when it isn't.

If my workstation is still usable (e.g. the build is broken but I can still look at code/script/assets/etc.) then I notify my team that I've got some bandwidth and downtime to help out as a second set of eyes on any tasks my team might need help with. I can do code, design, or asset reviews for teammates and I can look over the various Slack discussions on other in-progress bug fixes and features to comment if I feel like I can contribute something helpful. I might not be able to run the game to test or validate anything, but I can still contribute my skill and knowledge to others who aren't having downtime.

If my workstation is unusable (e.g. all system resources are dedicated to building the game, building assets, compiling a level/lighting/etc., network or VPN down, etc.) then I really can't do much. I can't do reviews or join those conversations. In those situations I've traditionally done things to pass the time like listen to music or a podcast, scroll through social media, or think about what to write next on the blog. More recently, I've been focusing on leaning away from the social media scrolling and being more mindful so I have been taking the opportunity for mental and emotional "digestion" by not focusing on anything external and allowing my mind to process the normal emotional experiences in my life. It was difficult to start, but has definitely helped with my focus and my attention since I've started doing it.

[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

It has certainly happened in the past, though not necessarily specifically the narrative part of the game. Many games are pushed to launch without development being as far as they want it to be due to reasons like hitting their budgetary limit and needing to recoup some of the investment. Our estimates are only estimates after all, sometimes we run into unforeseen problems and things take longer than expected. We can't stop paying the developers when we hit snags like that, so certain features end up more costly than others, which eats into the budget that was earmarked for other stuff instead. Most games in this situation have a lot of other launch issues too for the same reason - when you're pushed out the door to make the deadline due to running out of budget, things that should have been fixed are often not.

When World of Warcraft launched in 2004, there were several entire world zones that were incomplete and (mostly) locked off from players. Some players were able to sneak in through various exploits and take screenshots of those areas. Most notable were that the zones were primarily unpopulated by anything - no mobs, no quests, empty towns and buildings, just environment geometry that had been built out. This accompanied other incomplete bits of the game like quests that still had XML code in them. It would take years before players would finally see the incomplete-at-launch zones in some form or other.

Cyberpunk 2077 famously launched after multiple delays with numerous bugs and weird issues. Notably, the dev team also completely cut the multiplayer mode of the game that they had been building in order to consolidate resources to ship the single player game. The game came in super hot and had a huge number of launch issues that were eventually (mostly) ironed out, but the multiplayer mode was never resurrected.

The most famous example of this is probably Knights of the Old Republic 2. The publisher famously moved the deadline up and Obsidian scrapped the in-development ending since they didn't have the time to finish it. Instead, the story was wrapped up super quickly to ship the game. Notably, the partially-finished original ending was left on the disc and modders eventually discovered (and later restored) it.

[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

I've actually worked on and shipped more than one annual sports title over my career and I want say for the record that the idea that annual sports titles are "mostly minor tweaks and roster changes" is absolutely and categorically false. Annual sports titles absolutely do not have the same scope as AAA games with multi-year dev cycles, but they do absolutely have significant breadth and depth of scope each year beyond "minor tweaks and roster changes".

The majority changes that occur each year are spread out because they must be - there simply isn't enough development time within the ~11ish calendar months between launches to rebuild everything, so decisions must be made about what gets added/updated this year and what waits for next year. That means that, besides roster updates and minor tweaks, this year we're committing to change our animation system, these eight specific stadiums/arenas, these three game modes, update the commentary system, and rework the stat simulation. Next year, we're committing to these other eight stadiums/arenas, these other four game modes, the physics system, the VFX system, and the AI logic. This sort of round-robin approach is necessary - the dev team often isn't large enough to sustain working on everything each cycle so we need to pick and choose what we can do each year within the time we have. It also means that players who only engage with some of the game likely don't necessarily see (or notice) all of the changes we make each time around. This doesn't mean that we didn't do it or that the changes aren't there, but it can certainly look like not much has changed if the player isn't playing those parts of the game.

To your main question - The primary reason that annual sports games haven't transitioned to a live service model is because of inertia. There is a well-established and financially sustainable annual sales model that works. There would need to be a significant and tangible gain to be had by switching to a live service model other than novelty - all of the current existing tools and systems are built with the expectation of delivering a new retail game each year, and all of the dev experience built up is for delivering a new retail game each year. Switching over to an ongoing service would come at tremendous cost. There must be a gain to outweigh that cost in order for the publishers to do it.

[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

It's really hard to say because every project is different. The kind of games that have the least cut content are annual sports titles - they have the most stringent schedules and know exactly what they are committing to with each annual cycle, so they have significantly less wiggle room than a project with a longer schedule and bigger scope (e.g. GTA6). The games with the most cut content are often those that manage to make it out of development hell, the kind of games that are lucky to get released at all.

The other thing is that cut content often comes in various degrees of completion. Some cut content never goes beyond existence in documents, let alone a prototype. Most gets a few iterations on a prototype before the plug gets pulled, often because we can't find the fun in the idea within the time we've allotted to it. Rarer, we have nearly-finished content that gets cut for other reasons - the senior developers pushing for the feature get laid off or leave the company, there's a big leadership shake up that changes the game's direction, the senior developer working on it is needed elsewhere more mission-critical for the game to ship, additional funding for the project falls through, and so on. This kind of content is what the data miners are often able to dig up.

Also, it can vary based on technical constraints - if cut content eats up a whole bunch of disk space and we need to shrink the install size, we have to remove it. If the cut content is shared by a bunch of load-bearing assets, it will probably stay with those assets so that we don't accidentally break the game. Generally, we leave stuff there unless there's a good reason to remove it. It is often tough to know whether something is load-bearing so removing anything is always riskier than leaving it inert.

That's basically it - the amount of cut content that players/data miners can possibly discover depends primarily on the kind of game, the kind of content, and the circumstances of the game's development.

[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

The importance of the narrative depends primarily on how important the narrative is to the game. For a game like Overwatch, where the core gameplay is team pvp, the narrative is a lot less important and things like relationships are generally prioritized. It matters more that each character fills the specific gameplay needs of a team-based pvp shooter than it matters that these characters are brothers or that group has a rivalry with this one. In a situation like Overwatch, the narrative tends to be more like the glue that holds the bigger parts of the game together - it's decided on later once the big decisions have been made (e.g. we are locking in a flying rocket character and a fast teleporting character).

The important thing to think about when it comes to development is that we can't build the game sequentially, we have to build as much of the game in parallel as we can. This means we have to start work on the things that take the longest as early as possible (e.g. building environments, creating animations and rigs, building the technology), and then do the things that take less time to complete later. For features like cutscenes, it depends on how much difficulty it takes to build the cutscenes. In the original FF7, the FMV sequences were set in stone. Making changes to pre-rendered FMV was untenable, so everything in the FMV sequences had to be locked in very early on in order to get it all done on time. The in-game bits - the low-poly characters moving, talking, and animating - were cheaper and easier to build, so they could be changed significantly later in the dev cycle. Today such things would be much more difficult due to the necessity of voice acting and the difficulty of getting the voice actors back into the recording booth.

When we're in deadlines, we have deadlines - this is the last day for us to make changes to the feature we're working on. That could mean combat, it could mean itemization, it could mean summoning magic, it could mean narrative, it could mean cutscenes/cinematics. After that deadline passes, we commit to fixing bugs with what we have and not making any more changes or additions, no matter how good the ideas are. If we can always make changes forever, we'll never ship the game. As the inestimable Dolly Parton said, "Sometimes you need to to tinkle or get off the potty."

[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

A good rule of thumb when answering questions like "Why don't companies do X anymore?" is to think about what X will cost them and what X will get them in return. The purpose of doing things is ostensibly to generate value - no one does X without a reason. There needs to be a method to determine whether the returns of a choice are worth the costs of that choice in order to make a decision. Let's consider the bigger costs of recording "Making Of" videos, and then consider the gains from releasing those "Making Of" videos.

Producing behind-the-scenes "making of" video requires getting a film crew, recording developer interviews, and setting up + filming B-roll footage of the developers doing things (most commonly animators moving wireframes around). Recording the interviews isn't off-the-cuff either, the developers being interviewed need to think about their answers and prepare as well. The time these developers spend recording these interviews is time not spent doing their assigned tasks or fixing bugs, which comes at a material cost when there's a deadline. These interviews are coming at the cost of bugs not getting fixed.

Next, consider what these videos earn in exchange. When the publisher puts them out, what is the gain? Who will be most interested in behind-the-scenes videos? How can the publishers convert these videos into tangible value? Making players feel good or "exposure" isn't really worth very much. We're giving up a significant quantity of work, we need to get something equally or more valuable in return. One possibility would be making these videos a Collector's Edition pack-in bonus for a retail game. Another value gain could be offering them as a stretch goal for a crowdfunding drive. A third possibility would be paying for this as part of the marketing budget, but this still only really targets the extremely invested audience already and is difficult to convert to tangible value gain.

Ultimately, it's a cost-benefit analysis. Look at the studios and games that are doing such videos and consider what circumstances they're doing them. There's usually some reason that the production of such is a tangible value add and there aren't a lot of them.

[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