Ask a Game Dev

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

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

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

Let's remember that one major goal in game design is to keep players within the flow band. If things are too easy, the experience becomes boring. If things are too difficult, the experience becomes frustrating. We need to keep the player experience between these two major goalposts or players will quit playing the game. As such, we have more wiggle room with single player than multiplayer content, but we still have to do a balance pass to make sure that the single player build options don't fall into boredom or frustration for most of our player experience. Different single player choices/specs/builds/etc. can be notably and visibly stronger or weaker than each other, but they cannot be boring or frustrating or too many players will drop the game and not come back.

[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