Attention to Detail
One of the biggest challenges facing videogames today is attention to detail.
As in, there’s way too much of it. Or, more specifically, the precious time and limited resources that could have been spent far more productively on details that matter got completely wasted on tinkering with details that ultimately have little to no impact on the player’s experience. Most detail winds up in areas where the player doesn’t notice or care, which I’m asserting here on the basis that the player doesn’t actually notice or care about most of the game.
The classic 80 / 20 Rule, for anyone unfamiliar, is the idea that 80% of the value comes from 20% of the content or work. I might even theorize that some of the most unfortunate games out there suffer from a 95 / 5 problem – that 95% of what makes it unbearable comes from what the developer spent 5% of their time on: poor controls, bad camera, level 1 is too hard, unclear user interface, one item being way out of balance, etc., even if everything else about the rest of the game is perfectly fine. Either way you slice it, the more closely developer priorities align with player priorities, the better off everyone is.
The problem arises most often from specialization. Even when working alone on a project as a hobbyist or indie developer we are almost all still mostly a specialist in one or two areas, and a dabbler in the others to fill in the cracks, so we’re definitely not immune to these dangers when going solo.
Let’s look at two of the most common causes:
1: Specialist Chasing an Arbitrary Ideal
Example Scenario: Programmer is spending a ton of time designing and implementing an elegant, optimized system to accurately model a requested behavior, where a crude simulation or surface-level approximation of that behavior would serve the same purpose to the player and team. This can happen with weather, particle effects, background animal AI, or trying to write a collision system that supports 100,000 moving objects when the game will never have more than 20 alive at a time.
Example Scenario: Artist is pouring their heart and soul into getting the zippers, bolts, engravings, imperfections, texture offsets, and scratches just right on models or materials that will be on screen for a few seconds in just a couple of levels.
Example Scenario: Game designer is filling spreadsheets with numbers and equations in an attempt to tune abstractly, when actual tuning will inevitably come from iteration on game parameters since AI movements, animation timing, visibility, and countless other factors will dramatically influence a unit or weapon’s actual effectiveness.
Example Scenario: Producer is writing, rewriting, and rehearsing a powerpoint that lost touch with the actual gameplay hours ago.
2: Specialist Blindly Filling Inflexible Request from Different Specialist
Example Scenario: Producer requests level behavior from designer that isn’t currently supported, and making it happen will involve a lateral request to a programmer to awkwardly or inefficiently hack in functionality that won’t be used anywhere else in the game.
Example Scenario: Designer requests a very particular animation or model from an artist, when with a few minor modifications the asset could be created in far less time or with dramatically lower poly count (due to tighter or looser fitting clothing, change in hairstyle…).
Respecting Differences in Domains
Different specialists can offer unique insights as to what are relevant considerations in deciding a course of action – including whether any course of action even seems necessary.
It’s normal for people to define intelligence and talent in ways that line up with their own strengths. This isn’t just a matter of narcissism, but it’s also because those definitions play an integral part in which paths people chose to develop their current skills. Consequently it’s natural for programmers to quietly think of designers, artists, audio specialists and producers as less knowledgeable of important considerations; frustratingly those other positions can feel exactly the same way, since they see things the programmer doesn’t.
That tendency for artists to see other positions as second-rate artists, or for designers to see other positions as second-rate designers, causes Source 1, because someone assuming that they know best doesn’t turn to others for their insights.
The Wrong Way to Fix This
One unfortunate but common way for a company to deal with this source of conflict is to establish a culture of service and obedience. That takes the form of seeing designers as servants to producer requests, programmers as servants to designer requests, and so on. This sweeps potentially helpful knowledge under the rug – knowledge that literally is right there hidden in the chain of command – and causes Source 2 of the problem, since it creates an environment where people have to pretend that what they know is useless to experts in other fields.
The Value in Fixing This
I am definitely not trying to suggest that designers ought to tell the artists how to do their jobs, or that producers ought to direct a project around a data structure a programmer created to serve an earlier need. What I am saying is that taking a few minutes to discuss another specialist’s concerns or ideas about a feature may illuminate simple alternatives that achieve similar results, or provide context and insight into how the piece they’ll be working on ties in with everything else.
As an added benefit, solving this can boost morale by fostering a sense that people’s unique vantage points are valued, while minimizing the jading frustration of feeling, “My boss (or partner!) asked me to do the stupidest thing today.” It creates a healthy outlet to bounce back, “Have we weighed the costs of doing X, Y, or Z? Those can be done in a lot less time since they play off the strengths of our codebase…” – even when the answer is sometimes, “Good points, thank you, although in this particular case we think it’ll be worth the cost to special case it.”
A Right Way to Fix This
An actionable way to foster that sort of atmosphere is to pair up a designer and programmer, audio specialist and artist, or level designer and prop modeler. Pairing up might be done by stationing people next to each other in the same space while they work, or trying to get team members of different disciplines to eat lunch together.
The other aspect to avoiding these issues is to afford more autonomy to others on the team whenever and however much is possible. This is accomplished by openly discussing the problems and purposes being faced, to share in thinking through a smarter solution (in terms not just of end effect but also in time or effort saving which can then be allocated to other needs), accounting for different team member knowledge and values, as opposed to deriving the solution needed then simply tasking someone else to follow those orders while concealing the task’s real purpose.
This includes, as difficult as it always is, remaining open to the possibility of pushback along the lines of, “Are we sure this is really a priority? From my perspective it seems like my/our time this week could be better spent on…” Maybe they’re not 100% right, and maybe you’re not either, talking through it though is generally going to yield a better direction than either one person could have since it accounts for a broader range of understanding about the game’s current implementation and the development challenges involved.
Illusion of Progress
Getting stuck in solving problems that do not need to be solved can really bog down a project. What feels like measurable progress to the specialist often isn’t, it’s just burning time on solving a narrow problem invisible to others, while other higher priority (and often less inherently interesting to work on) issues get put off. In short, going off to work on this sort of matter unchecked is often just another form of procrastination, getting lost in doing what we’re comfortable doing rather than facing a potentially harder or at least less familiar problem that’s more in need of attention.
The worst part is that this kind of mistake feeds on itself. The more time gets spent on it, the more stuck someone becomes in believing it’s worth putting in what surely must be just a little more time into getting it just right. The more time someone spends trying to solve a problem that’s ultimately low-priority or not really a problem, the harder it is to step away from it far enough to admit that, yeah, ok, maybe it could have been – and still can be – sidestepped entirely.
Reach Out for Perspective
Like quicksand, the best way to escape this mess is to reach out to someone else that isn’t also stuck in its pull. More often that not, it’s best to reach out to someone in a different core discipline, since someone within your own may share the same exaggerated priorities adapted to your shared field’s focus.
This is also some of the most important value of getting input from an outside tester that hasn’t seen or heard much about your game before: sometimes an entire team (and on a solo project, this is always the case!) can share a common delusion that such-and-such is the most important thing to address… yet it turns out that a real user not prompted or primed about that doesn’t notice it, thinks that aspect seems just fine the way it is, or inversely feels like something else that you previously thought seemed fine is so totally out of whack that that’s where your immediate attention is most needed.
Remember the above point that different specialists tend to spot and prioritize issues differently? An outside tester is a very particular kind of specialist, capable of doing something that no one on your team can: they’re able to see the game as your players will. A game looks very different to a first-time player than it does to a programmer, animator, designer, or producer, and at the end of the day, which of those people are you most concerned with satisfying? Here’s a hint: the majority of people that will play your game, ever, are not among the developers involved with your team. (Or, rather, if that’s somehow not the case, well then you’re probably doing… something… quite wrong.)
Of course, as one last caveat, the second risk of misplaced attention to detail also comes up in the case of enlisting a tester for feedback: a specialist (programmer, designer, artist, even an all-in-one solo developer) blindly pursuing an inflexible request from different specialist (outside tester!) can burn through a lot of time from failing to capitalize domain knowledge to figure out more time effective ways to address the same need. That a tester says there’s a problem (or visibly experiences a problem) means that there’s most often a problem worth addressing, though don’t get bent out of shape feeling bound to some solution they may suggest in a knee-jerk reaction. That’s a path often leading to as many errors as it patches up. However be nice to your tester, they’re just trying to help! Distill, but don’t defend, playtesting feedback.
Many Details Are Distractions
True, some details definitely matter. Those details matter a lot. “Attention to detail” in concept like a great thing, though in practice when we say it we’re often referring more to attention having been paid – or more accurately, allocated – to the right details, those being the things that people actually notice and care about, the features that are central to gameplay, or the aspects that really help set a game apart. Giving those details the attention they deserve requires not getting lost in the distraction of countless other details, chasing the things that maybe seem important to us but under the scrutiny of outside testing or honest peer input maybe aren’t so important to worry about after all.
(Originally posted as GameDevLessons.com Vol. 2 Sec. 3)
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!