Earlier this year, game developers across the industry weighed in on Twitter on a seemingly innocuous question: What’s the problem with doors in video games?
It turns out, a lot. A seemingly boring feature such as usable doors can be absolute hell for developers to put in their games for numerous reasons. Everything from physics to functionality, from AI to sound, comes into play while making a single door in a single video game work. And not just work, but work in such a way where the player never has to think about it. Building a working, forgettable door is an incredible game development undertaking.
But it will probably not surprise you to learn that doors are far from the only seemingly simple feature that prove to be unexpectedly challenging in the development process.
A few months ago, I asked developers across the industry the question, “What is a thing in video games that seems simple but is actually extremely hard for game developers to make?” I received nearly 100 responses representing a wide breadth of industry experience, ranging from solo developers to those who had tackled issues within teams of hundreds.
The pool of responses similarly included a number of varied problems, but also a number of similar issues popping up among many projects. Those I spoke to described challenges in making games look and sound good, storytelling, movement and interaction with objects, menus, save systems, multiplayer, and all sorts of intricacies of design that are so rarely discussed outside of studios themselves. Many noted that they’ve received angry player feedback about the topics they mentioned, with their audiences asking, “Why don’t you just do X?” The answer is, almost always: because it’s really, really hard.
So if you’ve ever wondered why the maker of your favorite game didn’t simply fix one of the myriad issues developers mentioned below, here’s why those seemingly simple problems are hardly simple at all.
Getting from place to place
As the original topic of game development headaches focused on doors, it made sense that many of the developers I spoke to had issues with other methods used to connect a person from one place to another.
For instance, elevators. Multiple developers told me about the frustrations of elevators, whether they’re taking players up a single floor in a building or serving as pseudo-loading screens between two major game areas. Bill Gardner, creative director of The Deep End Games and lead level designer on BioShock and BioShock Infinite, explained the elevator problem as follows:
“First off, you have to summon [an elevator] via a button or whatever. By calling the elevator, you open the opportunity for the player, objects, or AI to wander underneath it and get squished or trapped. So suddenly you have to deal with that. It’s an invitation to make your enemies or companions look dumb, for physics objects to go flying, or for quest items to get stuck.
“So let’s say you try to solve the AI issue by excluding them from elevators. Well, how then do they avoid looking dumb as soon as you cross the threshold inside the elevator? They’ll either stand there, or need some sort of custom behavior.
[An elevator is] an invitation to make your enemies or companions look dumb, for physics objects to go flying, or for quest items to get stuck.
“Then, if the elevator can take you to multiple floors, you have to feed back when an elevator is ‘busy’ or allow it to queue up floors to stop on. Now let’s say you decide to get off on the second floor, then jump down and hit the call button again. Suddenly you have to feed back that the elevator is busy. Even then, the player is used to having things respond nearly instantly, so there’s a good chance they’ll get frustrated and call the thing broken.
“None of this is even getting into handling the [elevator] doors and what happens when those open and close and trap the player or other objects in the doorway.”
The team at Skydance Interactive, behind The Walking Dead: Saints & Sinners, ran into a similar problem as the one Gardner describes, but again with doors, and in a VR game no less. Fortunately, they were able to turn a challenging collision problem into a fun new feature:
“One of the bugs I had was when a walker was trying to get through the door at the same time that a player was trying to open it,” said Bill Ferrer, Skydance senior AI gameplay engineer. “This is sort of like a situation when two opposing forces come against each other, immovable object vs. unstoppable force.
Every time the player would try to open the door and a walker was trying to go through that same door, we’d break the door. This created a jump scare.
“Our solution was every time the player would try to open the door and a walker was trying to go through that same door was to break the door. As a result, this actually created a jump scare moment. The result was basically a happy mistake.”
Well, if doors and elevators are too complex, why not just have players take the stairs? Josh Davis, quality assurance at Guacamelee developer Drinkbox Studios, says that’s an issue too.
“They might not be as bad as doors, but can oftentimes be immersion breaking. I was thinking how most of the time they’re just ramps people just slide along; they can sometimes mess with how jumping and movement work because of angles/collisions. And how to deal with their realism can get a lot more complicated for some styles of 2D games like ours, because we’ve had and continue to have bugs for them.”
All these means of transport are a potential nightmare, but there’s yet another mode of getting around areas that’s causing developer agony: moving platforms.
“Moving the player with a controller isn’t hard; moving the player on a platform isn’t hard,” says Kyle Donnelly, a programmer at Land of Screens studio and publisher Serenity Forge. “Putting them together you now have two things that want to dictate how the player should be moving. What should you do if the platform pushes the player up into a ceiling? Push the player through the platform? Squish the player? Stop the platform from moving? Force the player to crouch allowing a little bit more time before squashing? What about from the other side where the platform comes from the top down on the player pushing them into the ground? Should it behave the same?
“You can add multiple moving platforms into the equation too. What if the player is standing on two platforms going in opposite directions? Should the player be split apart? Ride on the fastest moving platform? Ride on the platform that the player is most on? Once you decide how the platforms should move it’s a whole other ballpark of issues implementing them with the physics system you’re using.”
With all of these forms of movement being challenging, what about just…regular old walking to get from place to place? Andi, a programmer with Unknown Worlds, said that even this could get very complicated and go horribly wrong.
“It’s not really ‘hard’ to write something and get a character to move, but it’s tricky to tune all the values so that the result feels right. It took quite some time to find our values for acceleration and drag that we were happy with [in Subnautica], considering all the speed modifiers we have in the game (sprinting, seaglide, currents, wind etc).
“On that topic, I discovered an interesting bug a few weeks ago: sometimes the player froze in midair at the peak of a jump. Turned out part of our movement code, which we used now for over seven years, had a bug that only could manifest once hardware got fast enough. Everything was fine, until you reached ~200fps.”
Anything interacting with anything else
Another problem that an overwhelming number of developers cited to me is the simple idea of any “object” in a game interacting with any other object. That means that something as simple as a character picking up an item or two characters making contact with one another is actually unbelievably complex, never mind what happens when you get into more complicated interactions between two things.
Ben Wander, designer on Airborne Kingdom at The Wandering Band, explained the issue as follows:
“The objects themselves aren’t real — they have no density or physical bounds — so if you want a character to, say, hold an apple, the artist has to go in and change the character’s fingers to wrap around the apple perfectly. Want them to hold a kiwi instead, or how about a grapefruit? Make a different animation! That’s why you’ll often see characters hand-generated quest items to other characters just below the camera, or sometimes why a character’s hands will go through a door handle or something.”
Audrey LePrince, co-founder of The Game Bakers, affirmed this in a way that perfectly captures her work on Haven, a game about two romantic partners who have a lot of affectionate, physical contact with one another throughout the game.
“Touching, holding hands, hugging, it’s already hard in cutscenes but in real-time gameplay it’s a nightmare. Haven was a great example of that. But still it seems so natural for players, and something that we should have more of in video games.”
Maebe Sewell, lead technical design animator at Gearbox, pointed out another example of this: petting the dog. There’s been an ongoing trend of excitement around games allowing this feature, in part sparked by the Twitter account Can You Pet the Dog?, but Sewell noted that this can actually be very challenging due to the aforementioned issues around two characters making any kind of contact with one another, not to mention things like AI pathing, UI, and more.
Objects and characters moving and interacting together can be a problem whether you’re aiming for realism or a specific visual style. For a very specific example, Glitch Factory artist and animator João Esse offered a problem from upcoming game No Place for Bravery, in which protagonist Thorn carries his son Phid on his back. The two characters have independent animations, where each character can perform separate actions at the same time. For example, Thorn might be fighting an enemy, while Phid is pointing to something of interest.
“The duo’s spatial relationship ends up being very complex in some animations, especially when Phid moves forward or backward in different frames. We have to go through every frame in every animation to correct each characters’ position to solve this.
“The real problems start to appear when Thorn makes a very complex movement, like the one in the GIF below:
“Phid and the Shield are between Thorn and the Hammer, and everyone’s also rotating together to create the illusion of the Hammer’s blow.”
Things get even more complex, Esse says, when Phid is absent in certain sections. Thorn can’t just be left with his animations minus Phid, because items like his shield are animated specifically to account for Phid being in the way, and look funny with Phid just taken out. So there’s an entirely separate set of animations for these sections.
“We are talking about 142 animations, 941 animation frames divided into 97 layers, all of this only in the main character!” Esse concluded.
Though not an object itself, a body of water presents another set of difficulties in allowing for, or preventing, interactions. Unknown Worlds co-founder Max explained that most players appreciate how hard it is to make cool water in games, but added that what’s often overlooked is how hard it then is to keep said water out of places you don’t want it.
“Water in the real world occupies a volume and in video games we typically represent those types of volumes with simple shapes,” he said. “In the case of an ocean, this might be an infinite plane sitting atop a box which extends downward forever. Every point inside this box is considered filled with water when drawing the scene or simulating buoyancy. Using these types of simple shapes to describe the water makes it feasible within the limits of a real-time game.
“As soon as you introduce boats, submarines, underwater bases or caves into this water world you encounter a problem. The space occupied by the hull of these objects should not contain water (unless you have a leak!) and needs to be carved from that simple water volume. Often different approaches are used for each of the systems that interact with the water. For gameplay code, there might be a series of checks to determine if the player is able to breathe at their current position. Is the player inside the ocean volume? Are they inside a boat? Is the boat sinking? Answering the question ‘is the player inside water?’ in Subnautica became a remarkably complex code path.
Telling a Coherent Story
Another easily underestimated element of making games is storytelling. The ways in which game writers and narrative designers have historically been overlooked in all but the biggest blockbusters (and even then!) is an entire article unto itself, but let’s just say it’s all a little more complicated than sitting down and writing some dialogue.
Arone Le Bray, former narrative designer at BioWare, told me a fascinating story about the challenges in making games like Mass Effect, with choices that are expected to impact the story. He says that these create challenges in “tracking reactivity,” or ensuring that if A or B happens, then C or D happens. Most of the time this works fine, but every once in a while an edge case can throw everything off.
Le Bray explained how a decision made in the original Mass Effect could cause a bizarre scene all the way down the line in Mass Effect 3, simply because of one of these “edge cases” that didn’t originally get caught. In the first game, most players would meet up with party members Garrus, Wrex, and Tali on the Citadel, with Tali joining the party along with either of the other two. Whichever one didn’t join would show up at the Normandy later and ask to join, but it’s possible for players to decline to take the third member with them at that point. Only an “extremely small minority of people” made that choice, he said.
For those who did, there might have been a game-breaking bug had BioWare not caught it very late in development. In the unlikely set of circumstances that Wrex is in the party on Virmire, Shepard doesn’t have enough Paragon or Renegade points to stop him from attacking, Liara hasn’t been recruited, and Garrus was previously rejected on the Citadel, then killing Wrex would make it so the player doesn’t have a full squad and can’t proceed.
“Luckily we caught it before we shipped,” Le Bray said. “…But we didn’t catch Zombie Tali.” he continued.
Zombie Tali refers to a romance scene in Mass Effect 3 where Tali, despite being dead, would show up to talk to Shepard just before the final mission, and it happened for similar reasons as the Wrex bug Le Bray described above. The scene, he said, triggered if a character passed a certain invisible check in which they were in a relationship with a given character, and would show the scene if they had reached a certain stage before the final mission. But what it didn’t check for was if a character was alive or dead.
“In order to encounter this, a player would have to actively pursue a romance with Tali in Mass Effect 2, actively continue the romance in Mass Effect 3, side AGAINST Tali and her race (Quarians) and watch her pass away, and then NOT pursue a romance with any other characters. We patched it, but we still shipped with it in the end,” he said.
Another narrative problem related to player choice occurred in The Elder Scrolls Online, which during its development had as a main design point a mandate that the player could “change the world.” As Matt Firor, studio director at ZeniMa Online Studios tells it, one example of this was that if a player encountered a village that was under attack and in flames, they could choose to help the villagers, resulting in a nice, peaceful, not-on-fire village. To do this, they had to essentially make two different copies of the same village, one for players who had helped, and one for players who had not done so.
The player experience quickly evolved from ‘I can change the world’ to ‘why are my friends disappearing?’
This worked out well in testing, but when the game launched, things went awry very quickly.
“As soon as real players started roaming through Tamriel, they ran into problems with this system almost immediately,” Firor said. “Players — friends, guild mates, etc. — don’t always go through content together, and it was very common that someone in your group had not done the quest yet, but you had. In this case, players who hadn’t completed it yet would ‘disappear’ as they were separated onto the on-fire version of the village, and even worse, the players who had completed the quest couldn’t help their friends because they were physically separated from them. This problem was magnified because we had quests and points-of-interest all over the game that used this technique, more than a dozen per zone. So the player experience quickly evolved from ‘I can change the world’ to ‘why are my friends disappearing?'”
According to Firor, the team had to go back over each quest that used this technique — over a hundred at the time! — and restructure them so player impact was dialed down. A few still remain in the game, mostly in starter areas where players are less likely to be in groups. But the whole process of fixing this issue took The Elder Scrolls Online team over a year.
Choice-based systems aren’t the only places where narrative and writing can create challenges. Harebrained Schemes producer JC Lau answered my question by saying, “I want to be super glib about this and just say ‘getting a single line of text onto a screen’ because as someone who works with UI/UX, narrative, accessibility, and localization, this never is as smooth and obvious as you might think.
The friends list had a little popup that said, ‘Socialize with your friends’. In Polish, that got translated to ‘Support socialism with your friends,’ which was thankfully caught.
Lau explained the very basic idea of communicating a concept to a player can mean different things to both design and narrative teams, and requires communication between the two to ensure something is clear in every way.
“When I worked on Battletech, the font pack we used for Russian somehow had all the Cyrillic characters two pixels taller than the Latin alphabet characters, and this was enough for them to break their text boxes and the Russian text just wouldn’t render and we couldn’t figure out why until UI looked at it and was like, ‘Yep, it’s because this font is indiscernibly taller than English because… reasons.’”
Issues like that, she said, are why localization quality assurance is so important.
“When I worked at Xbox in localization, it was when the console rolled out its friends list feature and there was a little popup that said, ‘Socialize with your friends’ directing people to use the friends list. In Polish, that got translated to ‘Support socialism with your friends,’ which was thankfully caught.”
Multiple people I spoke to mentioned the struggles involved with localization. Joe Mirabello, director of Terrible Posture Games, called translation “deceptively complex,” citing issues ranging from puns that don’t work in other languages to problems with words being different lengths in different languages.
“Planning ahead helps, but nothing will prepare you for German,” he said. “German destroys your best laid plans. German will defeat you. That text field you thought would only ever need a single 10-20 character word? Nope. German has a unique word for that and it’s a hundred and twelve characters long. We even have a native German developer on our team and he refuses to translate our games into German. This is all said tongue-in-cheek, of course, just to illustrate a point, and that is; whatever scaling flexibility you think you’ve planned for in your UI to account for localization? It’s not enough. It’s never enough.”
Getting the Player to Do What you Want
One nightmarish place where writing intersects heavily with design is whenever a developer needs to get a player to do something specific to progress, and has to clue them in. Kevin Zhun, creative director and writer at Young Horses, told me about the complexity of hint systems.
“Hints are surprisingly hard to get right!” they said. “You can’t just tell players what to do, you need to shift their thinking in the right direction. It takes a light touch and subtle reminders. That means rigorously testing to find out where players most commonly lose their way. And what you write needs to be very precise! I’ve seen the wrong word choice send players spiraling off into strategies that’ll never work. And then it’s twice as hard to get them back on track from a bad hint!”
Alexander Horn, narrative director at Impulse Gear who has previously worked on Kingdoms of Amalur: Reckoning, also immediately thought of tutorials when I spoke with him, saying that they tend to be so fourth-wall-breaking that he “gets physically ill just thinking about it.”
“The beginning of [Amalur] serves as a tutorial, and the first objective in the first room used to be to loot a sword from a dead body partially to teach looting mechanics. My friend, who is a pretty competent gamer, did some playtesting, and spent almost ten minutes stuck in that room, unable to find the sword and exploring every nook and cranny of the room. It was agonizing to watch, because you wanted to scream ‘It’s right there!’ but [it was] invaluable feedback. We ended up putting the sword in the door, so that when the sword was looted, the player-character was able to leave the room. It was an organic gate more easily found by players.”
Letting the Player Do What They Want
Player freedom is generally touted as a positive, but letting players do what they want, even when it’s as simple as attacking an enemy, introduces a whole new set of problems.
Måns Olson, game director for Minecraft Dungeons, echoed this sentiment in explaining what he called one of the most complex systems in the entire game: the code that lets players click on enemies to attack them.
“Ideally, a click should simply perform whatever action the player intends, without any complications. In short, it should ‘just work’. Behind the scenes, figuring out what that intent is means sorting different possibilities and often making a large number of calculations. You clicked an enemy, sure, but is there also an item nearby that the user might have intended to pick up? Did you mean to attack the enemy, or just move towards them? Are you in range? Was the mob previously pushed back by another attack, in which case we may want to add a temporary buffer to the player’s attack range to prevent them from stuttering forward? And most importantly: What did the player really mean to do? Did they correctly click their intended target? Did the timing of that click carry intent?”
To detect player “intent,” the Dungeons team put in place several layers to sort out all the different possibilities, guess what was intended from clicks that missed their mark, and more.
Remedy senior gameplay designer Sergey Mohov described how crafting Control’s gunplay led to a rabbit hole of questions the developers needed to answer.
“Do we allow you to aim down sights? Do we allow hipfire? If yes to both, what should the change between those two modes be? Do we move the camera when switching between them? Do we change the camera field of view? By how much and how fast for each weapon? How does the animation for that look? How about weapon dispersion and recoil – should those change too,” he mentioned.
“In third person, does the bullet come from the gun or the middle of the screen? If it’s from the gun, we need to display a second crosshair because there might be something between the weapon and the target. In Control, you always shoot from the camera instead. And don’t forget to add an option to switch shoulders in either case, but make sure that all the other abilities and player actions still work on the other side, or at least remember to switch back – we had a bug about this.”
This is the kind of request that is sometimes worded as ‘just add that little feature’, while on the dev side it means ‘make another game’.
Those questions are then further complicated by aim assist and how it works, as well as the fact that Control has players occasionally shooting parts of the environment not classified as enemies.
“At this point, we haven’t even fired a single bullet yet! If we did everything right, the player doesn’t notice any of this, but it can ruin the whole experience if there’s a bug or mistake somewhere.”
Paul-Emile, lead FX/environment lead on Absolver and art director for Sifu talked about giving players the ability to jump, saying it was something the Absolver players kept asking for…and made the entire team laugh.
“Seems like a simple request from the outside (just add a basic action), but it’s the kind of thing that, added late, challenges the whole combat system, and may unbalance the whole structure of the world.
“This is the kind of request that on the player side is sometimes naively worded as ‘just add that little feature’, while on the dev side it roughly means ‘make another game’.”
Saving the Game
Another group of developers came back to me with issues born from game saves, checkpoints, resetting, and reloading. Fernando Resco, senior software engineer at Armature Studio was another developer who rattled off a list of questions developers have to answer when ideating saves and checkpoints (and the bugs that they can cause).
“From a design perspective, do you allow just one save slot chosen at the start of the game? Do you allow the player to change the slot? What is the UI for that? Do you also allow manual saving? From an engineering perspective, what state do you save? Most of the time you can’t just save everything. Do you save the music state? Particle effect state? In-flight scripting? What needs to happen when loading the checkpoint to make sure that things keep on working properly?
“It is incredibly simple for gameplay scripting to run afoul of the saving system and lead to bugs. For instance, I worked on a game where if you reloaded immediately after defeating a particular boss, you would get locked into the boss room, because the door leading out of it was not keeping its open state correctly. Another instance of doors being tricky, too.”
Squidly, developer of Renaine at Octosoft, added that “People don’t think about how hard it is to make sure things that are dead don’t stay dead, and all those things you’ve already done are no longer done. It takes a lot of thinking to just put everything back to where it has to be.
I worked on a game where if you reloaded immediately after defeating a particular boss, you would get locked into the boss room.
“That’s kind of why [some of the earliest games] games didn’t have saving. Actually, original games just had a set RAM and if you ever restarted your Pac-man cabinet or whatever the entire score table would be wiped. It wasn’t until Zelda and co. rolled around that non-password-based saving became popular because it was just that hard to do.”
Remedy QA manager Arto Suominen also brought up saving games as a particular headache for the team working on Control. He said that the complexity of saving games is so overwhelming that when the team tried to answer my question, they ended up with an entire page of notes — and that wasn’t even the start of the amount of work that goes in. So instead, he gave me an example of how things can go wrong.
“After completing the Ashtray Maze [in Control], we found that when the player fast travels to the Research Sector, the walls were shifting where they shouldn’t be. We had a long back and forth between QA, level designers, engine programmers, and around and around again, to try and figure out what was wrong.
“We tried to reproduce this bug by starting the game at different points, dying at different times, restarting different checkpoints. We tried to see if it was a problem with how the game world was loading in, or how our building shifting mechanics were set up. The level designers were saying it wasn’t them, the gameplay team was saying it wasn’t them either.
“We dug into the code until one of our engine programmers figured out that our scripts were saving a restore point named ‘Research’ when the player fast traveled to the Research Sector after going through the Ashtray Maze. However, all of our save games for that sector by default went into a save game chunk called ‘research’. Because the names were case-sensitive, the game didn’t recognize what the world state around the player should be, and the walls were shifting where they shouldn’t. It took us a month to figure out that’s what the problem was. That’s how complex save games are, and how many facets of the game they can affect.”
Playing With Others
Multiplayer, whether online or local, also proved to be a recurring, difficult theme among the answers devs gave. Nine Dots Studio CEO Guillaume Boucher-Vidal said that incorporating split-screen play into games “makes every design decision a lot more complex than it appears.
“If you let players play in split screen, what do you do with your menus?” he said. “Can you pause the game for one player while it keeps playing for another? How do you handle story progress and rewards? Do you force players to always play together or does the game allow you to drop in and drop out? How do you plan every single quest with the possibility that a new player could join in at any moment? Which exploits do you let in the game in order to avoid friction for legitimate players? When both players are within the range of a sound, how does it play?
“When we started working on Outward, we didn’t really have any example of an open-world RPG with split screen, so we had to find which solutions would work for us and no matter what we’d choose, there would be players who disagree with our decisions, because there was no standard to follow. Still, in the end it was definitely worth doing. We see stories of couples, friends, or siblings playing together and it made it worth all the extra development challenges.”
People think of it like: a server can handle X players, Y people want to play, so X * Y = number of servers = problem solved, right? Simply: no.
Moving onto online multiplayer games, Phoenix Labs senior programmer Chris ‘Chhopsky’ Pollock brought up the problem of servers, and how everyone thinks adding more servers is a magic fix-it button when really, it’s far more complex.
“Every live game falls over day one,” he said. “The internet screams, ‘Add more servers,’ and the number of servers is quite literally never the problem.
“People think of it like: a server can handle X players, Y people want to play, so X * Y = number of servers = problem solved, right? Simply: no. There are at least four more layers of complexity to a live game, and each one amplifies any of the previous layers’ problems.”
Pollock broke down the various layers for me, which include issues like the amount of information each server can hold for the entire playerbase, communication issues between servers, sharding, the actual ability to create more servers, and, aggravatingly, problems created by players themselves:
“I could confirm my login service can handle 100,000 requests per minute, but what happens when that’s happening at the same time as a heap of players logging on that are all on the same database shard? What happens when that database shard tries to back up its changes, and the backup takes longer to run than the frequency it runs at?
Is it better to wait ten minutes to get a perfectly balanced game on a server in your region or to wait one minute to get a poorly balanced game quickly?
“For example, a game I know loads a menu when you hit escape. Every time you hit escape it requests the contents of the menu from a service, which hits a database, which goes to a shard, and brings the info back. It turns out, people like to spam hammer the escape key when they’re waiting in queue. So each person is now generating 30x the load you expected on the service, then the database, then the shard, and the network in between it all.”
Olly Freeman, VP of engineering at 1047 Games, brought up matchmaking in competitive games, especially ones that don’t have thousands of concurrent players at all times.
“There’s a constant balancing act of how to prioritize short queue times, low ping, and well-balanced games. Is it better to wait ten minutes to get a perfectly balanced game on a server in your region or to wait one minute to get a poorly balanced game quickly? Is it better to get a well-balanced game with 100 ping or a poorly balanced game with 50 ping? There’s no right answer, but there are many wrong answers, and it’s something we are always improving and tweaking.”
Menus and UI
Next up, independent developer and former game director at Q-Games Liam Edwards discussed main menus, something he described as a “recurring nightmare” while making games.
“You always have to consider so many factors when making a main menu. Not only is it the first thing a player will ever experience when playing your game, so first impressions are important artistically, tonally etc. It’s also the first time they will read your words, move your controls and attempt to interface with your designs and experience it. You have to be wary of the universal language of games and not making players confused by trying to be experimental or different. If you avoid using words such as ‘play’ and ‘settings’ or even ‘options,’ players won’t know how to start the game! Imagine if you changed the controls so that you used Y and B to scroll through the menus instead of the stick or d-pad? It’s weird minute changes that can literally make or break a player wanting to continue even to the game part.”
Kitfox Games’ Tanya Short drilled it down further, calling out working Settings menus as especially difficult but taken for granted “even in the jankiest Early Access title,” further complicated by adding other crucial elements like accessibility settings or hardware-specific pieces.
Think about every button frame, background…icon, gizmo and do-hickey in a UI. Somebody has to make all those!
Multiple developers including Eastshade creator Danny Weinbaum and Panache Digital Games user experience director Etienne Beaulieu mentioned overall UI as troublesome because of how seamlessly players expect it to integrate into their experiences contrasted with the amount of information it needs to convey.
“Think about every button frame, background, gradient, drop shadow, border, marker arrow, icon, gizmo and do-hickey in a UI,” Weinbaum said. “Somebody has to make all those! And then each one is brought into the engine, and carefully hooked into the UI.”
A type of menu many games have is inventory systems, and senior technical designer at Firesprite Fred Horgan explained how difficult these can be, not just for letting players interact with them easily, but also for when they translate to the rest of the game world, like when a player wants to throw an item away.
“Dropping items in the world can be super tricky,” Horgan said. “Depending on the game it may not even have the concept of saving the world outside of the player character…If you can just drop things into the world wherever you want we need to make sure those items are dropped safely so they can be recovered, maybe we’ll just opt to have some items flagged as ‘undroppable’ if they’re items critical to a main quest or whatnot. Do the items that are dropped have physics enabled? If so, can they be used to do crazy things like build stairs to otherwise out of reach areas or used to blockade areas to prevent NPCs from getting in or out of somewhere? If this isn’t behavior we want, how far are we willing to go to restrict what the player can do to ‘preserve the vision of the game’? If these items don’t have physics we need to make sure that when dropped they abide by specific placement rules so they don’t all occupy the same space or start clipping into terrain, etc.
“Now let’s consider the actual look of these items. They should represent the item being dropped, right? What happens if hundreds of unique models are now dropped in the world? All of these models and their textures need to be loaded — does the game have the overhead for all these extra models suddenly, is this data even handled in a way that allows them to easily be loaded/unloaded just for the sake of being thrown on the floor? But if we have all items looking like little bags then there’s no way of differentiating from all of these things now sat on the floor without inspecting them.”
Putting It All Together
These and many more developers I spoke with offered a varied, complex, and expansive look at just how difficult every facet of game development can be, in ways players may have never thought of while affecting both the biggest and smallest aspects of the games we play. Three of the many fascinating anecdotes I received may best sum up the clash between player expectation and reality.
The first comes from Johnnemann Nordhagen of Dim Bulb Games, behind Where the Water Tastes Like Wine, who answered my question about what game development challenge players underestimate with a very simple answer: what happens when a player pushes a button?
“Something I’ve spent many hours on is player input. It seems simple — you press spacebar; you jump. But then you start to fall into all the special cases. What if the player is crouching? What if you want the spacebar to also activate items that the player is standing near? What about players using controllers instead of a keyboard? What about letting players remap their control scheme? What happens when the game is paused, or in a menu? What if, God help you, this is a networked game and you need to send that to a server? It turns into a system that requires multiple layers of abstraction to be able to handle all the possible things that might happen in a game when a player wants to jump, or presses the spacebar.”
The second answer is from Mitch Dyer, a writer on Gotham Knights and Star Wars: Squadrons, who found a way to answer my question about game development challenges that somehow encompassed just about everything. (Disclosure: Mitch Dyer is a former IGN editor.)
“Imagine you’re writing a scene for a AAA game where two characters just need to meet and exchange some information. The boring version is them standing there doing nothing but talking to each other. Baseline, this is still expensive and difficult to make, because you still have to have facial animations for believability and performance capture so they don’t look like robots,” he explained.
“To make it more interesting, you decide this scene should be set in a cafe. They meet to discuss something over coffee, great. As a writer, you’ve now just created an entirely new set — the coffee shop needs assets like chairs, tables, menus. The server is a unique outfit, and if it’s a themed diner (say, 50s diner, like Pop’s in Archie stuff) now you’ve got new textures for your checkerboard walls, your vintage coffee machines, etc. etc.
“’Hang on,’ the art team says. You want them to actually DRINK coffee? We don’t have liquid simulation, so if you wanted the waiter to pour a cup, or see the coffee behave believably in a mug, forget about it. Never mind we need steam VFX, maybe some decals for the table to show coffee stains or tattered cushions in the cafe booths.
Every single action a character makes in every moment of the game needs to be thoughtfully considered before committing to make anything.
“Decisions that seem small — two characters discuss an event at a location — can have MASSIVE downstream effects. Sometimes you can afford to build the diner (and by god if you can reuse those assets elsewhere, DO IT), and hire the VFX and animators to make a ‘simple’ scene like this work. Sometimes you can’t!
“None of this is PLAYER FACING in a meaningful way…but that kind of rocked my world. Every single action a character makes in every moment of the game needs to be thoughtfully considered before committing to make anything…because it’s a lot of work, from a lot of disciplines, to allow a character to just drink a cup of coffee.”
And finally, there’s the answer given to me by Beans co-founder Gabriela Salvatore, who opened her response to me by telling me that when she posed the question to her team, “Art more or less just said ‘teeth’, followed by a bunch of crying emojis. Production added ‘getting an artist to open JIRA’ (our task tracking and project management software).”
But the bulk of the Beans response via Salvatore so perfectly embodied the spirit of the original question: What is a thing in video games that seems simple but is actually extremely hard for developers to make?
Her answer? Fun.
“It’s hard to make something, it’s harder to make something that functions, it’s even harder to make it fun,” Salvatore said.
It’s hard to make something, it’s harder to make something that functions, it’s even harder to make it fun.
“When something feels good in a game, it’s because 1000 micro-decisions are working together to create a seamless experience for the player. When talking about it with friends, we tend to boil this down to the most obvious description of the mechanic: jumping as Mario feels good — it’s fun!
“But how much of that fun is impacted by the level design, or by the metrics that define the maximum height and distance that Mario is able to clear with his jump? Does just barely making a jump feel better than easily clearing a huge gap? How much of the fun comes from the game-feel? The controls? The controller mapping and inputs? Is pressing ‘A’ to jump more satisfying than pressing ‘B’? Is long pressing to jump higher more engaging than pressing the button twice to jump higher? How much of the fun comes from the animation? From the design and look of the character? From the height of the character? What about the air time? The jump height? How much of the experience is enhanced by the sound of jumping? The interaction of jumping like landing on a Goomba, or hitting a block? The pause in air when you’ve jumped into an item? What about the enhancement of a super jump? Running into a jump?
“If you were making a game and one of your main mechanics was that your character could ‘jump,’ what are all the questions you’d have to answer to be able to make it function, let alone feel good? Every mechanic starts a long list of questions like the above, 1000 micro-decisions that have to fit neatly together and when it’s working properly players aren’t supposed to notice — all this just to create the experience of a satisfying jump.”
Rebekah Valentine is a news reporter for IGN. You can find her on Twitter @duckvalentine.
