#technical constraints

Yes, we absolutely have these kind of established rules. We generally call these metrics and we try to establish them very carefully because they are the assumptions around which design can build levels, environments, combat, and other core gameplay. We often have to establish metrics for most core gameplay actions - how fast a player can run, how high/far a player can jump, how many party members a player can have, and so on. This also includes lots of other smaller details like the size of doors, the allowed angle ranges for stairs/slopes, the width and minimum heights of ladders, the minimum width of corridors, height for cover walls, heights for mantling/hopping over obstacles, maximum height a player can step up without getting stopped by the wall, etc. We use these limits to design our gameplay.

A large part of this is, as you alluded to, staying within our technical limitations. If we can't animate more than X characters on screen at once, then we can't have scenes with more than X characters in them. If we can't run more than Y particles in a frame, then we can't create scenes with more than Y particles running at the same time.

However, there are also user experience and design considerations for this. Imagine that the farthest range the player can jump is 15 feet after a full sprint. Any gap in the game that is 15 feet or less is jumpable. Any gap that is more than 15 feet is jumpable. Now imagine that some level designer sets a 15 foot + 1 inch gap. How frustrating do you think it would be to a player who tries to make that jump and fails because it isn't possible? How can we expect a player to evaluate whether that gap is jumpable if it looks so close to an actually jumpable gap? In order to reduce player frustration, we probably need to set up a metric for minimum un-jumpable gaps so that players can recognize them on sight so they don't have to try and fail at every gap that's pretty close to maximum length.

[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

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

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

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

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

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

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