Ask a Game Dev

I make games for a living and can answer your questions.

[askagamedev]

Why don’t games slightly over estimate their budgets so they have extra “flight time” (per your older metaphors) to make up for inevitable bumps in the road? Like, if they estimate a game will cost 90 million to reach the intended experience goal, why don’t they try to seek it an even 100 million budget so even if they are “over” budget they still have an extra 10 million to play with.

We do. We always plan in additional budget and scheduled time for unforeseen problems. The difficulty comes from more innocuous-seeming problems that creep in during early development that get worse over time if not addressed immediately, but there's a lot of additional factors that exist that can compound this issue.

Let's go through an example. Imagine that I'm working on a new game idea that my AAA studio is pitching. My small incubation team is doing this because the majority of the devs at the studio are working on the current AAA game that will be launching in 6-12 months. Our goal is to get our next AAA game into production by the time the development on the current project winds down, so that we can keep everybody at the studio employed and productive.

Let's say that we run into some design issues with the initial idea. The fun is kind of there, but there are some real problematic issues that must be ironed out. This idea probably needs another few months to iron out, or might even need to be scrapped for a new one. However, this would put the entire studio behind the 8-ball - there would likely need to be layoffs because we'd need another several months to come up with a new pitch that may or may not work out, and we wouldn't have any work for the majority of the dev team to do while we were still trying to figure out what to do next. Instead, we put our faith in the dev team, leverage the good name of the studio and push the pitch through, even though we know the pitch has problems with it.

Let's say the publisher sees the same problems, but gives us the green light anyway. They know we're veterans, they believe in the studio and our skills, they trust us to continue. We expand the team, we continue to build, we push hard, we manage to dig up some gold in our experimentation and expansion. The team grows, we increase production value, the game heads towards the vertical slice and the gate to production. The next green light meeting comes and we fail - the game isn't fun enough. Now what?

The project must go back to preproduction and fix what's wrong, there's no question about that. But what can we do with the devs who aren't part of that process? Nobody wants layoffs. Instead, the leadership desperately pitches an even bigger scope. Even more stuff, even larger revenue estimates! We'll get the rest of the devs working on high quality assets for the game we'll eventually need anyway while the core team fixes the problems in our second preproduction! The publisher is dubious, but still believes in the name and the pedigree of the studio. We get additional budget, we get to keep going. We're burning a ton of money because we're now paying for a full production team during preproduction, which means our revised revenue targets are now astronomical.

We manage to get through the vertical slice green light the second time, we increase scope, but the core problems still plague us. The game is pretty good - it basically hits all of the original targets we expected - but there's no way it can match the ridiculous expectations we set for ourselves the second time around and isn't anywhere near on target for the increased scope for the second vertical slice pitch. We're over on budget and must release something. At this point, we're basically doomed. If we delay the game to fix the problems, we must increase the game's scope to justify the increased cost. If we release now, there's no way we'll hit our targets.

Do you see how budgeting some extra wouldn't really have helped in this kind of situation? This is the complicated and scary reality of game development - making good games is really hard and the road to failure is paved with good intentions. Throughout this entire hypothetical story, both the studio leadership and the publisher continued to put their faith in their developers to come up with something great. The harsh reality is that sometimes the best choice for the studio (early layoffs) can also be the most unthinkable.

[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]

If you work at an outsource/co-dev studio and a project you're working on while under NDA is cancelled, what is the general practice for your resume/portfolio when looking for new work as you're not allowed to mention that you've spent the last x number of months/years on this big project?

I'll preface this by saying I am not an artist. Obviously, any art done for a studio is owned by that studio and that makes it difficult to use in a portfolio when the art is still covered by NDA. If this is your quandary, I suggest reaching out to an experienced artist in the industry. @axl99 is an experienced veteran artist in the game industry, she can probably answer your question if this is art-related. For a designer or engineering role, read on.

I've worked for more employers than most. As a corollary, I've also been through more layoffs and project cancellations than most as well. One lesser-known but important skill I've learned is how to describe the work I've done without crossing any legal boundaries. This is where understanding the boundaries on intellectual property is very important. The line I don't cross is that I don't talk about the specifics.

You may have noticed this if you've read this blog for a while - I've written plenty about systems I've seen and built, but I've never mentioned any specifics like which game, which circumstances they'd work, and so on. I never post any specific details, just generalized examples and hypothetical implementations of a general system or idea. That's partially due to keeping my secret identity intact, but it also protects my former employers' IP and breaks no NDA.

The other thing to remember is that my resume isn't about the games I previously worked on, it's about what I did while working on those games. Prospective employers aren't looking for a new game to play. They don't care about which IP it was. What they care about is whether the experience I earned on those projects will be applicable to the project they are currently working on. It doesn't matter to them if I was working on Assassin's Creed or Mixtape, what matters is the work I did on those games. If I've built the kind of game systems the prospective employer needs in a professional, they'll probably be interested in me as a candidate. As such, any resume/CV should be able to talk about the game mechanics I built and design/technical duties I handled while working at these previous employers.

For example, I could list "Unannounced First Person Shooter Game" for the project and "Built dynamic automated AI spawning and battle system" for the duties. I could list "Unannounced MMOG Expansion" for the project and "Designed customizable socket-based housing system" for the duties. You should get the idea - it isn't about what the game was, it's what I did for them. Find a way to describe what you did without using using any specific nouns - no names, no places, no settings, no characters, just generic descriptions.

[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]

25% of my coworkers got laid off this week and I’m somehow one of the ones who didn’t get laid off. This is the first layoff I’ve gone through at a studio and it’s absolutely devastating not being able to see them every day anymore, and constantly getting reminded of that whenever I work on something that they did.

Have you gone through one of these before? Does it really get easier like some of my coworkers say? :(

Survivor's guilt is a real thing. This is one of those things that you really have to work through on your own. The only thing I can think to say is that they aren't gone forever, they're just doing their own thing. If you work with people you like, you can always make an effort to engage with them and build relationships outside the workplace. After several of my coworkers all got let go in a big teamwide layoff, we held some resume review and interview prep sessions and then we started a D&D campaign that lasted the better part of a decade. Beyond that, I also ended up working with some of them again at different companies later on in my career. I ran into several devs at my current employer that I worked with at a previous employer as well.

It's fine to be sad that your friends have parted ways, but you do what you can. Our day-to-day jobs [shouldn't be our identity] - if you ever lose your job, you'll lose a large part of who you think you are, which can cause you to spiral. Instead, look at your work and your office as a meeting place where you hang out and do activities together. If you can't meet up at this place, you can always arrange to meet up for drinks or dinner or a game night elsewhere. You aren't limited to doing this limited set of things with your friends. Keep your work and your identity at arm's length. Build relationships with people you care about outside the work place. Touch some grass and stay healthy, both physically and mentally.

[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]

I'm taking a database management class this summer, and it's been way more complex than I assumed. Do many games use straight up databases (Oracle, Access, etc)? Are real database admins necessary for larger scale development teams?

Most MMOGs (and MMO-related games like looter shooters and such) use them to store game data. On the MMOGs I worked on we had separate tables for account, character, world, guild, bank, and item data, along with other needed data. Columns in the character table would be things like most recent login, character name, account name, current equipment, stash ID, guild ID, quest variables, quest history, and so on. Items would have creation dates, any randomized variables (e.g. +X% to stat Y), visual modifications, slots/sockets, items socketed into those slots, applied skin, and so on. Basically, the database holds all of the necessary data to recreate the character's appearance and gameplay information between sessions.

We also need to build queries and scripts to interface with the database so we could look up things like items that were accidentally destroyed in order for customer service to restore them, and a front end tool to allow the service reps to run the appropriate queries without needing to learn SQL (or accidentally break the table/database). All of these tasks generally need database engineers, and the maintenance of the database requires DBAs to keep everything up and running. They aren't super necessary during the development process, but they are absolutely needed when the game launches so we need to make things work from the jump.

[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]

Same guy that asked the latest GTAVI question featured. I feel like I didn’t get an answer beyond “moving on”, which I’ll reiterate is not an acceptable answer. Just to be clear, I personally have little personal stake in the whole thing, but I feel for those that do. Hence, me wondering what can I do if I don’t see “moving on” as a healthy option, and think that “this game just isn’t for me” is not a good idea, considering the implications it could bring if it succeeds.

In a situation where the loudest feedback of all is the willingness to pay for the product, you really only have one option for success here - you must persuade enough other people to agree with you and forgo the new game. This is not a small task - it is voting with your wallet and lobbying others to do the same. This isn't as "simple" (difficulty notwithstanding) as getting a majority, however, because it isn't a majority vote.

The basic requirement for any game to be considered successful is that enough players decide to spend and play the game. It doesn't really matter if seven billion people choose not to buy the game. As long as there are enough people willing to pay $80/100 for the game, the publisher is happy with its performance. This means that your effort to convince them to forgo the game must be successful enough to nudge the number of spending players below the publisher's targeted numbers before they really start to care.

This isn't to say it's impossible - the Stop Killing Games initiative has managed to reach a lot of people and has been pretty persuasive about getting them on board. The larger your reach and the more numerous your collective voices, the more likely change can be effected. Getting larger influencers on your side to spread the message is probably your best bet. However, you also run the very real risk of finding out that your coalition really isn't large enough to move the needle. You can rally as long and hard as you want, but if the game still reaches sustainability numbers and players are actively engaging with it, your efforts likely won't be successful.

[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]

On the topic of GTA 6, what about the idea of precedent? For example, companies who see their competitors raising their prices and the amount of business being unchanged will often raise their prices to match it. Won’t GTA 6 “getting away” with $80 price tag likely lead to price increases, making the $80 the new “normal” for AAA games?

To paraphrase, you control the things you buy. Players must make their choices - if their budgets don't increase (and there's no reason to think they would), it means they buy fewer games by necessity. Franchises with large audiences like GTA will be prioritized by buyers over smaller and less popular titles like an unfamiliar new IP. There will be those who test the waters to see how many people are willing to pay the higher prices. Some games like GTA will probably be fine. Some games will not. Similar to the [Laffer Curve], there's a certain pricing point where the seller can maximize earnings. Too high and the earnings go down. Too low and the earnings go down. That sweet spot is what the publishers are looking for.

The thing you have to realize is that this has all happened before. Back in the 16 bit era, we already did this entire song and dance. Players were livid about having to pay higher prices for games, but they did. Some games sold at the high prices. Some didn't, and those prices eventually came down.

The prices back then were even higher, relatively speaking, because inflation was a lot lower and the buying power of the dollar was higher. Some people paid those prices. Many did not. Those of us who played games would save up and buy the games we wanted most. That behavior will probably not change. Here's a few more ads from the time:

It's really a question of sustainability. If the market can sustain itself with prices that high, then that's the new normal. If only some franchises can get away with higher prices, that's the new normal. And if there aren't enough sales to justify the higher prices, those prices will necessarily fall. These is the overall collective results of voting with your wallet.

[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]

Not the same guy, but regarding the GTAVI Situation, your answer to the latest GTAVI question brought little, if any comfort or reassurance. What if I DON’T feel like “accepting the loss and moving on” is an acceptable solution? What if I truly feel what I feel about the GTAVI Situation and feel like I MUST push back for the public’s own good? If I can’t rely on others or gather others to win over the opposition, what can I do, as an individual, to guarantee the results I want? And they HAVE to be guarantees, no matter what. Assume that anything less is unacceptable.

I caution against going down this path. Enacting some kind of crusade against a video game publisher over a video game is basically "jilted lover" behavior. In situations like this, it's common for a person to feel hurt over something that's got a lot of emotional energy put into it over a long time. That built-up emotion needs an outlet, so people in those situations often end up in the franchise hatedom - they cannot give up the emotional investment so it metastasizes to become bitterness and anger instead. Rather than doing the healthy thing and move on, the hatedom continues to invest their time in following the franchise they hate, doing everything they can to hate on every aspect and element as it gets released. It's a lot like going through a bad one-sided breakup, resulting in being the person who can't get over their ex and stalks them on social media constantly.

The saddest thing about this is that there's no winning in this situation. The publisher doesn't really care about the hatedom's opinion because they aren't players. The publisher cares whether they have enough supporters to keep the game afloat and about keeping those players happy. If the game succeeds, there's no reason for the publisher to pay attention to the hatedom. At best, the hatedom gets a pyrrhic victory - the game flops, the publisher goes under, and the hatedom loses the franchise they loved for years, if not forever. The hatedom gets to say they were right, but the ultimate result is still the same - everyone has to move on, because there's no game anymore. This is why we don't really bother with the haters on social media or official channels - there's no point in engaging.

Instead, I think it best to recognize that a particular game may no longer be for you and that it's ok. Life is short and resources are finite, I would much rather spend my time playing games I like than hating on the games I don't. I try to spend as little of my time upset at things beyond my control as I can. there really is no benefit to it. Instead, I focus on the changes I can affect and the things I like. My quality of life has been much improved because of it. I really hope you can take a breath, touch some grass, and join me.

[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]

Do you think Unreal Engine's technological advances are going to lead to worse, generic games? It seems that whenever people think of Unreal Engine games, they immediately go to realism and open world, and I find that unfortunate.

The answer is both yes and no. As we get more of a particular thing, it almost always naturally pans out as a bell curve distribution. That means that, as you get more of it, you'll find more and more extreme examples, while most of the things (~68%) will fall within one standard deviation of the mean.

What this generally means is that, as we get more Unreal Engine games, we'll see some really amazing stuff at the top end (> 2 standard deviations from the mean) that we never would have seen before as a small number of dev teams go above and beyond to eke out things not thought possible before, and a whole lot of really mid stuff.

I believe this observation tracks with most popular media for consumption in general - most stuff is mid, with the really good stuff being a fairly small percentage of the total offerings of the market. Whether it's games in general, Unreal Engine games, books, movies, television, or whatever else, the bell curve tends to hold true as the total number of offerings increase. Teams that use Unreal Engine will tend to gravitate toward what Unreal Engine is good at and avoid what Unreal Engine isn't good at. Some will push boundaries and a small number will hit it out of the park. Don't judge a platform, a toolset, or tech by what the mid result is, judge it by the best results they have.

[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]

the unfortunate reality of the GTA 6 situation is that consumers will buy it just based on the hype around the game, and it paves the way for companies to keep pushing and pushing until it stops working. then consumers and developers will both ask what went wrong. boiling frog effect.

"voting with your wallet" is hard to do when the majority just shrug and say, "it is what it is."

Unfortunately, voting for something you want does not necessarily mean you're going to win the election. You cast your vote as best you can alongside everybody else and hope for the best. You may not like the result, but that doesn't mean that the election wasn't fair or that plenty of others can't have a different opinion than yours. The fact they are willing to pay that much shows that they can and do. Lots of things that I am not willing to pay for succeed financially and plenty of things that I like also fail financially. I'm sure we can all think of examples of this.

When you vote with your wallet and lose, it's best to accept that you don't hold the majority opinion and move on. The real win here is recognizing that you didn't spend money on the thing that wasn't worth it to you and you didn't give your money to people you didn't want to have it. It's just one video game among thousands of other options.

[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]

How do animation systems blend authored animation, physics reactions, ragdolls, procedural motion, and play control without looking jank?

This is why good riggers (sometimes called technical animators) and animation engineers are among the more well-paid roles in game dev. The animation engineers work hand in hand with the riggers in order to set up animation systems and rig constraints such that the skeletons move believably, rather than "jank". Jank is what you get when a joint moves in a direction that isn't believable, like a knee or elbow bending the wrong way. The constraints on range of motion placed on the bones in the animation rig and those translations to the game engine are the primary means by which we ensure animations consistently look good in game.

[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]

Do AAA studios have a parent engine that is constantly under development, or is it always a fork of the parent engine for each project?

Some studios have an in-house engine they continue to develop. Whenever a game is set to launch using that engine, there's an established cutoff date after which they will no longer take new engine updates from the mothership unless those updates are crucial bug fixes, and even then the engineering teams will collaborate to bring over only the absolutely necessary changes. This is because game stability is the highest priority as we approach release. As the cert submission and launch date approach, all changes are disallowed by default unless vetted by the engineering team for impact and potential instability. This includes engine changes.

Imagine a major engine change in an engine with ongoing development like Call of Duty that completely changes how AI do their pathfinding - the new methods are much more efficient than before, but require new design principles and have a bunch of additional edge cases that need ironing out. Now imagine that this engine change gets pushed to this year's COD in beta a month before launch. QA suddenly logs a ton of AI pathfinding bugs in every level that has AI in it because of this engine-level change. The COD team could go back to the levels to fix all of the AI pathfinding issues, but that would be months of development and iteration time that they don't have because the game has to ship. The changes are simply too unstable to allow in to a game that close to release, so the team can't accept 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

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

When discussing performance issues in games, how much blame should be put on the game engine that a developer is using? A while back, Unity had somewhat of a bad reputation among people online due to its wide use in a lot of low quality mobile games. However, game developers were quick to point out that that was less of an issue of Unity itself and more about how people were using Unity. Does the same idea apply to UE5? Or are there legitimate issues with the engine that hurts the end product?

The real answer here is the practical approach - you do what you can with what you've got. It is entirely possible to reach out to the engine developers and make requests, but they have their own priorities and not beholden to each licensor for quick turnaround on bug fixes and feature requests, so it is up to the individual dev teams to recognize what they can and can't do within the time they have. When this is the case, developers must pivot to working within the areas that they can work - our own code, our own assets, our own resource usage - in order to bring things back to the needed performance levels.

I actually found a bug with one of UE5's systems a while back. It was a broken system that couldn't be used the way it was. I reported it to Epic via their Unreal Developer Network and they acknowledged the bug and said it had been prioritized for a fix, but that it would likely not make it to a public engine release for at least two version updates. That put the coming fix several months away, which was too far away for our needs - we couldn't table development for several months to wait for their fix. Instead, we had to come up with a different solution that would work within our time frame, which we did.

If we can't fix the engine, we must work within the framework it provides and do what we can. Players aren't going to accept unperformant gameplay and accept the nuance of engine issues, they'll stop playing the game out of frustration and the game will likely not do well. It behooves us as practical developers to work around the issues as best we can and produce the best game we can within our circumstances. Every engine is a big batch of tradeoffs - they are really good at some things and not so good at others - this is why we evaluate what kind of game we're trying to make, what kind of technology we need to make it, and what kind of engine would best suit our needs. We have only so many development resources and development time, so it is up to our leadership to make judicious decisions when determining where and how to spend our developer resources.

[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]

I'm sure you're getting bombarded with GTAVI questions. To me, this whole announcement and release does not bode well for developers or players. I feel strongly that Rockstar Games are setting a dangerous precedent for the future of AAA. The game itself is essentially $100 for the "full experience," and they are not even doing a physical release—just a code in the case.

I don't see how AAA studios think this is a good idea, nor do I see how any team members—many who are gamers themselves—think this is okay. I feel that AAA games and consoles are on a death spiral, and Rockstar has just accelerated it.

As not only a gamer but a AAA developer, how does this all make you feel?

I generally take the stance of letting companies try things and observing the results. If Rockstar and Take Two think that they can sell a lot of copies of GTA 6 for $100, then let them try. Players are always free to choose whether they buy or not - nobody must play GTA 6; it's just a video game. It might be disappointing, but that's ok - if it's too expensive, I'm fine with waiting a while for the price to fall. If Take Two manages to sell a lot of copies at that price, then they will be right and people will have shown themselves willing to pay that much. If they do not manage to sell copies at that price, then they will be wrong and will probably drop the price to entice more players to buy the game similar to other high-profile releases that didn't sell well at launch. Gamers choose the purchases they make, similar to how they choose the buttons they press.

As a consumer, I certainly don't like paying more for something, but it is up to the consumer to make informed spending choices for themselves. If developers asked a consumer if they wanted more content or less content, the answer is always obviously more. If developers asked a consumer if they wanted to pay a higher price or a lower price, the answer will always be lower. Developers obviously can't make everything free or make infinite content forever - it takes significant time, money, and effort to build and test things - so we must be judicious in the things we choose to build.

Consumers will make choices based on their own priorities and so must the developers. These priorities are not always perfectly aligned with each other, but it is important to set up enough alignment that any sustained development is a virtuous cycle - players get the kind of content value they feel is worth it at a price they are willing to pay, while developers are able to build the content sustainably and pay for their own development along with a reasonable profit margin to bankroll future development projects.

[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]

On the issue of performance. All optimization that does not impact any departments portion has been achieved. The game been run. The performance is not good enough. Something needs to be cut somewhere. Either graphics need to be toned down so they are visually worse, the AI has to be simpler, the level has to be smaller, or some other departments work has to be made to be worse. How is it decided whose work is made worse, and whose work is usually on the performance chopping block first?

This kind of hypothetical situation isn't really feasible. There really isn't a "fully optimized with no possibility of improvement" state, that's like saying "a perfectly written paragraph" - that's not something that actually makes sense to any writer. Instead, let's go over how we actually do performance optimization and how the process works.

We begin by adding profiling code into our various features. This means that we have opening and closing markers when specific code begins and ends execution, similar to markup language tags in HTML or XML. By storing off how long execution takes for each code path, we can see how much of the frame time was taken up by which code - pathfinding, VFX processing, AI aiming and shooting, rendering shadows, lighting calculations, and so on. This profiling is generally only kept in non-final builds, writing this much data to logs can eat up a lot of disk space and memory, so profiling will affect performance itself.

After we've gotten our profiling code added, we store and analyze the reports after playtesting the game. We especially pay attention whenever playtesters report hitching or frame drops. Usually, the profiler can show us which particular systems are misbehaving during the frame drops and why. It might be that there are hundreds of weapon shoot attempts happening on the same frame. It might be that there's just too many VFX all playing at once. It might be packet loss from the server. It might be too many AI spawning and despawning across the world. It might be a combination of some or all of these at once.

No matter what the issue is, the engineering team (often the senior engine programmers or the tech director) will call in the relevant stakeholders, present the information, and demand fixes be made. The performance engineers often don't care exactly how the optimizations are made, they just want the resource usage to go back to within acceptable parameters during the frame. It is up to the stakeholders to look at what's happening and figure out a way to achieve the desired player experience without breaking the performance requirements. Maybe that means reducing the overall number of VFX, spreading out the AI spawning and despawning over several frames instead of all at once, fixing a bug that tries to fire all of the turrets every frame, or even all of these. Regardless, it is mostly up to the team to figure out what the best things to change are for the experience they wish the players to have. As you may guess, that can vary significantly based on the context - the type of game, the type of level, the story, the characters, the resources available, and so on and so forth.

[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]

rockstar seems to take forever to develop games. how are they surviving? is the amount of profit their games bring enough to sustain their prolonged development cycles? it feels like if it was any other studio, they'd be dead in the water by now

The reason that Rockstar was able to keep things running for so long was because GTA Online still earns around half a billion dollars annually. At its peak, they were pulling in over a billion per year. That kind of money buys a lot of development time.

[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 is the most frequent technical limitation you have come across in current gen consoles?

The limitation we face the most often is the same limitation that I've had to push against for my whole career - performance. We always want to push as much as we can while maintaining a frame rate. One reason that it remains this forever is because specialist developers who work on games always want to improve their individual areas. It's like your Resident Evil inventory management mini-game - you always have more stuff that you want to include than you have room to fit it all, so you fit in the most important stuff. As hardware and software improve, we naturally try to fit more in to the inventory.

Graphics programmers especially want to improve lighting and rendering fidelity because that's what they care about - they always want things to look better and prettier and performant. If they can squeeze better performance, they can fit in more cool stuff - more VFX, better looking models, better animations, better visuals, better shadows, and so on. The artists who work on this stuff love being able to put in higher-fidelity stuff too - they get to work at higher fidelity and approach the visuals in their imaginations.

AI engineers want more and smarter AI. Every AI needs to have some system to choose and play animations, pathfinding, and so on. We want better decision-making, better pathfinding in dynamic environments, and so on. When an AI is moving through a large world and must consider many different factors when finding a path, it can require a lot of simulation to figure out where to go. If we want more AI running around while moving intelligently and visibly, that means as many pathfinding threads happening and re-evaluating as we have AI, and we always want more AI if we ever want to do cool things at scale.

All of these tasks must be performed and handled in under 17 milliseconds if we want the game to run at 60 frames per second. We are eternally trying to fit more and more evaluations, improvements, and fidelity into these 16.6 milliseconds with each successive generation. This is one reason that our performance teams are constantly capturing performance profiles while we're in development to catch performance issues - maybe there are too many VFX playing here, or there are too many gunshot simulations there, or too many pathfinding calls here for AI, or whatever. It's their job to note when performance gets bad and figure out what's causing the issue so that we can fix it as we go.

[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]

You talked about limitations due to read/write speeds. What are other niche technical limitations devs had to deal with in older generation of consoles and what are fun ways they got around it?

The most interesting and wild stories tend to be the sneaky ways that developers were able to squeeze the most out of memory limitations on really old hardware from back in the day. Some of the oldest tricks in the books include reusing the cloud sprites for bushes in Super Mario Bros, faking parallax with clever sprite work and pixel shifting in Sword Master and Metal Storm, or even "stealing" memory that was supposed to be allocated for other uses (e.g. using the sound buffer to hold texture data). One of the early Call of Duty games infamously used their string table to stash some animation data to get around some animation memory caps.

One of the wildest stories was Andy Gavin's wild hack to stream level data for Crash Bandicoot on the original PSX by loading chunks of the level at a time, rather than the entire thing at once because the PSX didn't have enough RAM to fit all of it. I've linked the video below, it's fantastic if you're into old programmer "make it work no matter what" stories.

[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