#technical constraints

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

A podcast recently talked about how some games, like Contra Operation Galuga are struggling to run on Nintendo Switch, because they developed it for higher end systems(PS5, Xbox series, PC) first then port it to Nintendo Switch. They suggested it should have been done the other way around, so every platform has a version of the game that runs perfectly(barring AAA high quality titles like God of War and Spider-Man). How true is this?

There are always tradeoffs when making decisions like this. It's true that developing with the Switch as the primary platform would make it work well on the Switch and perform well on other platforms. However, the tradeoff is that the game would look like an upscaled version of a Switch game on the higher-end platforms. The source assets like animation rigging and motions, textures, character and environment models, and so on would be built at a lower fidelity. The world created using those assets would be built with those assets in mind, meaning that things would lack the sense of visual cohesion that one would expect, even if they built high resolution textures and ran at 4k instead of the Switch's native 720p.

Consider a game that launched on Switch first and later came to other platforms is Monster Hunter Rise. Take a look at that game and you'll see what I mean. Rise runs at a rock-solid 60 fps on higher end PC, but you can still see the kind of visual style built with lower poly models in place because we just don't have the time to rebuild everything. It really depends on the kind of game and visual fidelity the developer is aiming for - games with highly stylized visuals like Octopath Traveler work out just fine because of the visual expectations set, while MHR's more realistic visual style is what holds it back.

Comparison screenshot taken from [Digital Foundry's excellent comparison video].

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Is/was space ever an issue with games in discs? I heard cartridge games like the older pokemon had to find hack-y solutions to make room

Initially, transitioning to discs actually left us with too much space. Games weren't anywhere near big enough to fill up a whole CD, but the nature of a spinning disc actually means that the outer part of the disc spins faster (and can be read faster by the laser) than the inner, so we would actually pad the disc to full with dummy data in order to get faster game data reading speed. EA actually had to recall a game once because the engineers padded it out with Simpsons episodes.

Space on disc eventually became a larger problem as game sizes increased. We eventually had to start splitting games across multiple discs (if you'll recall, the original Final Fantasy 7 launched with 3 CDs of game data) to make them all fit, as well as technology to allow the same game to load itself into memory and remain resident while players swapped discs. There were also technical issues that arose from streaming data from the disc that we had to solve, since disc access is a lot slower than reading memory or a hard drive.

Game dev tends to grow to fit its environment. If you give us more processing power, somebody will figure out clever ways to use it. If you give us more space to work with, we'll figure out ways to use it. If you give us more memory, we'll figure out ways to use it. We'll hit the upper limits and then, since we still want to make things cooler and better, we'll figure out clever ways to optimize that we hadn't before.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

why is it so difficult to animate convincing interactions between two characters in a video game where they are making any kind of physical contact without using those motion capture suits with the balls on them and then going from there? it seems to end up looking awkward a lot of times, or you will end up with bugs where the models freak out and start bending in weird ways or one model will touch another model and send it hurtling across the screen.

It's a combination of two primary reasons. The first reason is because there's no physicality or collision inherent in video games. Animating physical action without being able to touch anything is like miming - believable miming is really quite difficult. The second reason is because we humans are intimately familiar with physical touching. We're going to notice any subconscious visual oddities, so it sets the bar of acceptability incredibly high.

When we render 3D models, there's nothing that can physically stop them from interpenetrating each other. The only way it works is when the program does the math to figure out whether the polygons actually penetrate at that moment, and too many of [those calculations can get really expensive]. For animations of two or more characters physically touching for longer than a single frame, we cannot depend on procedural collision detection. The animators have to make the characters to look right similar to making shadow puppets "physically" interact with each other with no real physicality. Try making two shadow puppets touch each other believably (e.g. have one punch another) and you'll see what I mean.

The other issue is that humans in general are extremely familiar with what touching things and people look like. We've seen it constantly for our entire lives. We've seen our own bodies touching things and we've seen other people touching things. We know how clothing is supposed to hang on peoples' bodies. We understand how skin deforms when pressed. We know which joints can bend in which direction. Anything that doesn't obey all of these little rules at all times will trigger alarm bells in the viewers' subconscious. You might not be able to explain exactly why, but the motions will seem awkward, stilted, and just... off somehow. This is a variation on the uncanny valley effect that we see quite often with CG in movies and television. We’re so used to seeing natural motion that small errors become magnified. Even if the image looks ok when frozen, it’s the motion that gives it away.

Using motion capture circumvents both of these problems to some extent because motion capture must take the physicality into account when capturing the animations and has the added benefit of being able to capture all of the motions involved with the action (including the small secondary and tertiary movements). It isn't a perfect fix - as the various off-putting CG that was built from motion capture can attest - but it can get us closer to our goal.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

On the topic of open world movement, how do designers decide how fast a player can move from location x to location y? Is the highest speed generally limited to constrains of the game engine/hardware, or do developers decide to hold the player back from that potential hard limit?

There really isn't a limit on movement speed in development. A game character's position is really just a few numbers. If the character is at (156, 0, 150) this frame and I change that to (156, 0, 10150) between frames, I've moved 10,000 units along the Z-axis in a single frame. That move distance could easily be 100,000 units, or a million units as long as the map itself supports it. What that looks like reflected on screen is an instant teleport. Most games have debug commands to allow us to teleport anywhere on the map we want to go so we can get to where we need to so we don't waste time traveling unless we have to. The upper limit on player speed we allow in game tends to be the intersection of two factors - hardware constraints and human reaction time constraints.

Hardware constraints are things like maintaining frame rate and the speed at which we can stream data off of either the hard drive or the optical disc. Transferring data from disk is much slower than transferring data from memory, and we need to load things into memory from disk like models, environmental geometry, textures, animation data, and so on. The faster the player moves, the more things tend to need loading and unloading. Since we have frame rate requirements, we have upper bound caps on speed such that the loading time of new assets doesn't cause significant pop in or sacrifice frame rate.

The other (and much more common) constraint is just human reaction time. Our brains and our reactions can only process information so quickly before we get overwhelmed. Players moving at a speed beyond that comfort zone feels bad - it can cause frustration and anxiety because you're literally out of control - you can't move where you want because things go too fast. We want to keep it within the band of fast enough to get players where they want to go, but not so fast that the players don't feel comfortable anymore.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Why don't we see as many desert levels in video games compared to say... forests and sewers? What's so challenging in implementing a desert level compared to the other environments?

Deserts have a number of things going against them as environments in video games. Here are two major challenges that must be addressed for a desert level off the top of my head:

Deserts Lack Landmarks

The prototypical desert in your mind is often just long reaches of sand in all directions. This tends to be bad for players who are looking for their next objective - they'll get turned around and get lost in a featureless desert, making it feel frustrating. In order for a player to learn where things are, they need major landmarks as reference points, which goes against the prototypical desert. This can be done (like how every Star Wars game must have a Tatooine level), but it does take a little away from the feeling of being lost in a desert. If you can see the giant mountain over there, the oasis over there, the ravine over here, and the city in the distance, it doesn’t feel much like a desert anymore.

Deserts Lack Obstructive Terrain

This is more of a technical constraint than a design constraint. If a player can see a long distance away, they expect to be able to see those details - an approaching caravan, a town with lights at night, and so on and so forth. This, unfortunately, runs into the problem of having to draw all of those things. One standard graphics trick is to avoid drawing things that are very far away - if you don’t have to do rendering calculations on these models, you can save a lot of CPU and GPU time. This works great for sewer and forest levels because there’s a lot of walls, pipes, trees, etc. in the way that can block your view of things in the distance so the GPU doesn’t have to render them. Deserts don’t really do that - once you get to the top of a dune, you expect to see really, really far, which can cause severe performance hits. 

These two specific challenges make desert level design more difficult to implement than many other environment types. The lack of landmarks affects most forms of traversal unless you’re playing some kind of game with scrolling advancement (e.g. a side scroller or shoot-em-up) where the navigation of the environment isn’t as important. The lack of occlusive geometry makes for a technical challenge that must be overcome (often through the placement of large occluding rocks or heat shimmer vfx in the distance). It’s not impossible to do, it’s just some bigger challenges that make them harder to do than other environments.

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

as a follow up to the question I asked before about game patches, are game patches once applied actually the size the download says it is (specifically on console)? I play elder scrolls online and a lot of those patches can vary from 60-80gb on the download. is each patch actually eating up that much MORE of my hard drive on my console? if that's the case how do consoles or pc's avoid ending up in a situation where one game ends up consuming all of your hard drive space? and for that matter why do so many console patches tell you that you need so much more space for the download than you actually end up needing?

There are two answers to this - the short term and long term issues with install size.

The short term answer is that we generally only need the hard drive space for a single patch temporarily - once the patch is applied and your game is up to date we can safely delete the patch since its purpose is fulfilled and it is no longer needed. If the patch contains replacement assets, the patch can delete the old assets and replace them with the new. However, many patches add new content - new assets, new environments, new textures, and so on - and they do so permanently. While this won’t necessarily be the same size as the entire patch, they will take up additional hard drive space. This leads us to the long term issues.

As live games mature and new content gets added to them, their installed size tends to increase in order to support all of the permanent post-launch content in addition to the launch content. This can cause a mature game to take up an much larger amount of hard drive space than when they started. Higher end mobile games (e.g. Genshin Impact) are especially susceptible to this problem due to the increased processing capability of mobile devices outpacing their relatively small storage capacities. Most mobile games in this situation will selectively delete old/unused assets to save space and then re-download them on demand if the player decides to engage with that content. It's also one reason why mobile games have so much seasonal content - once the season is over, most of the assets can be deleted in order to make room for the next.

Bungie actually had to deal with this very problem for Destiny 2 - their old expansion content took up many gigabytes of hard drive space but the vast majority of players (~99.7%) didn't regularly play that old content. They took the mobile game solution - they created the "Destiny Vault", where they would "retire" old and unused expansion content on a regular basis in order to keep the game's install size manageable for current players. Then, as the case warranted, they could periodically bring back popular old expansion content (and even update/retune it for modern gameplay paradigms) and still keep room for new content.

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

I was planning making a more visual text game, with some images, but events happen at random, using Unity with twine tool. Unfortunately it and other similar tools seem to be locked to being linear, even if they can branch off as much as possible, it seems they can't have a random event feature. I don't want to have to make up a whole detailed code system for something I'm trying to make basic like a text game. What would you recommend?

Welcome to your first major technical constraint. Most projects come across them eventually. Constraints require change of some kind, since they are obstacles in your path to project completion. As the main decision-maker on your project, you have a choice to make. You should probably gather information and weigh your options carefully before you make a decision. Your options include: 

Spending the development time to build out your own solution

Changing your design to accommodate the existing technical restrictions 

Researching a third option yourself

At the most basic level, fixing the problem yourself is always an option. It doesn’t depend on anyone else to have done the work for you, and you can tailor your solution to be exactly what you need it to be. It doesn’t have to be a whole detailed code system - it can just do exactly what you want it to do and no more. Sometimes a fairly simple solution exists. However, it also means that the code system is entirely on you and your team to maintain and support for the rest of the project. If you discover that the system is missing necessary features, you’re going to have to build them yourself. 

Sometimes there are technical limitations that just can’t be avoided. If you lack the resources to formulate a solution or the technical limitations are set in stone (e.g. console hardware constraints), it becomes necessary to change the design, rather than change the technology. Game dev is always a series of tradeoffs. If you can’t build the content you want with the tools you have available, maybe you need to take a step back and think about how you can achieve something similar to your goal with the tools you have available.

The last option is usually the easiest but also the most likely to fail - you go out and look for a solution to your problem. You might be able to find one - a unity marketplace plugin, for example, that may cost some money, but may also solve your problem. Or you can find a programmer to join your project and work on it with you. If you’re lucky, you can find an off-the-shelf solution that works immediately. Or you could come up empty, in which case you’ve lost the time spent on research and still gotten no closer to solving your problem. The worst case scenario is spending on a partial solution that ends up not working - that ends up wasting both time and resources.

You need to decide the best solution based on what your priorities are for your project and your own gauge of your development ability. Most game dev projects will run into obstacles like this at some point during development. Overcoming these obstacles is often both frustrating and rewarding. Such challenges are opportunities to gain valuable problem-solving experience. I do hope that you can figure out a good solution to your problem and I wish you luck.

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

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ