A shipped feature is almost never written by one person start to finish. A designer decides what the feature should do and why it matters, a programmer builds the system that makes it work, an artist builds what the player sees, a technical artist makes sure what the artist built runs inside the game's budget, an audio designer makes it sound right, QA proves it survives contact with a player who does not know the "correct" way to play, and a producer keeps track of all of that so it actually finishes on a date someone can plan around. You already know how to write the code. This chapter is about everything the code sits inside of: the people who hand you work, the people who receive it from you, and the process that is supposed to keep all of that from turning into chaos.
None of the Git workflows from 17.1, the CI pipelines from 17.2, the patterns from 17.3, or the testing habits from 17.4 matter if the team cannot agree on what to build next, describe it precisely enough for someone else to pick up, or catch problems in each other's work before it ships. This chapter is the social layer the rest of chapter 17 runs on top of.
Here is what each role actually does day to day, before watching one feature travel through all of them.
The producer's job is not making creative calls -- it is making sure creative calls turn into a finished game on a date people can plan around. Day to day, a producer runs planning meetings, tracks which tickets are blocked and why, chases down whoever is blocking them, updates the schedule when reality disagrees with the plan (it always does), and negotiates what gets cut when there is more work than time. A good producer's most valuable sentence is "we do not have time for all three of these, which two matter most" said early, not "why isn't this done yet" said late.
A designer decides what the game's rules and moment-to-moment feel should be: how high the jump arcs, how much damage a hit deals, how a level teaches the player to use a new ability before it demands they master it. Day to day, a designer writes short specs describing intent, sits in the editor tuning numbers (jump height, cooldowns, drop rates), and watches other people play their level or system in person, taking notes on exactly where they got confused or bored. A designer's raw material is not code or art -- it is player attention and player fun, both of which can only be observed, never calculated in advance.
A programmer turns a designer's intent and an artist's assets into a system that actually runs, at a frame rate the game can afford, without crashing when a player does something nobody expected. Day to day, that is writing gameplay code, exposing tuning values so a designer can adjust them without asking a programmer to change a number and rebuild, reviewing teammates' code, and fixing bugs QA files. Most of what you learned in chapters 1 through 16 lives here.
An artist builds what the player actually sees: characters, environments, props, and the animation that brings them to life. Day to day, that means modeling, texturing, rigging, and animating, then iterating hard on feedback -- a first pass on a character is rarely the shipped version, and an artist can expect to redo the same asset three or four times as direction settles. Artists work against a moving target more than any other role on the team, because "does this look right" is a judgment call that changes as the rest of the game comes together around it.
A technical artist stands between art and code, and the role exists because those two disciplines' tools do not naturally talk to each other. Day to day, a technical artist writes shaders, builds editor tools that let artists work faster without needing a programmer (a script that auto-generates LODs, a validator that flags a texture that is too large before it ships), and profiles the GPU and memory cost of what artists are building so a beautiful character does not quietly tank the frame rate. A technical artist reads as half artist, half programmer, and is usually the person who translates "this needs to look better" into "here is the specific setting that is costing you visual quality," and back again.
QA's job is to prove a build survives contact with a player who was never told the intended way to play. Day to day, that is playing the game -- deliberately, methodically, and often adversarially -- filing tickets for anything wrong, verifying that a programmer's fix actually fixed it, and running regression passes (replaying old, previously-fixed bugs) before a milestone to make sure nothing broke again. Automated tests from chapter 17.4 catch what you thought to test for; QA catches what nobody thought to test for, including the exact sequence of button presses that breaks a system in a way no programmer would have imagined writing a unit test against.
An audio designer builds and implements sound: recording or sourcing sound effects, composing or licensing music, and wiring both into the game so the right sound plays at the right moment, usually through middleware like Wwise or FMOD (audio tools that sit between raw sound files and game code, letting an audio designer set up how sounds trigger, blend, and react to gameplay state without a programmer writing custom code for every single sound). Day to day, that is editing and mixing sound, hooking up audio events to gameplay triggers, and, like every other role on this list, iterating once the feature is actually playable and the first pass sounds wrong.
Watch one small feature travel through all of that. Say the design calls for a double jump -- the player can jump again, once, while already in the air.
Nobody on that list touched the whole feature alone, and nobody's pass was the last word -- the designer came back twice, the programmer came back twice, and the loop only stopped when QA stopped finding anything worth a ticket. That back-and-forth is not a sign the process failed. It is what the process is supposed to do.
A compiler can tell you code is correct. Nothing can tell you a jump feels good except a person jumping and reacting to it. That is the core fact this whole chapter's process exists to work around: fun is not something you can derive on paper, in a meeting, or from a design document, no matter how carefully it is written. It can only be observed, by building the smallest version of the thing that can actually be played, and watching what happens when a real person plays it.
This is why game teams do not design a whole game up front and then build it once. They build a rough, ugly version of one piece, play it, learn something true that no amount of discussion would have surfaced, change it, and play it again. That loop -- build, play, learn, change -- repeats until the thing is good, not until a schedule says it should be done.
Two habits make this loop practical instead of endless. The first is a prototype (a rough, fast, throwaway version built only to answer one specific question, not to ship). The second is a grey-box (level geometry blocked out with plain untextured shapes -- boxes, ramps, cylinders -- so a designer can test whether a layout plays well before anyone spends art time making it look like anything). Both exist for the same reason: art, polish, and final code are expensive, and none of them tell you whether the core idea is fun. Building cheaply, testing early, and only spending real production effort once the core idea has already proven itself in a prototype or a grey-box is what keeps this loop from being infinitely slow.
Here is a small worked example. Say the double jump from section 1 first ships with a jump height of 2 meters, matching the first jump exactly.
iteration log -- "double jump feels weak", playtest round 1
round 1: height = 2.0m (same as first jump), no forward arc
playtester note: "I can barely tell I double-jumped. Feels
like the same jump twice."
change: add forward arc, keep height the same
round 2: height = 2.0m, forward arc = 1.5m
playtester note: "Better, I can feel it move me forward, but
it still doesn't feel like a SECOND jump, more like a dash."
change: raise height instead of arc
round 3: height = 2.6m, forward arc = 0.5m
playtester note: "Yes -- now it feels like a real second jump,
I can use it to reach ledges the first jump couldn't."
change: none -- ship these numbers, move to animation and VFXNothing in that log involved a compiler telling anyone they were wrong. Every single change came from watching a person react and adjusting one variable at a time. Notice, too, that round 2 changed the wrong thing first -- forward arc, not height -- and only round 3 found the actual fix. That kind of wrong guess is normal and expected, which is exactly why cheap, fast iteration matters: a wrong guess that costs an afternoon in a grey box is fine; the same wrong guess discovered after three months of final art and animation is a disaster.
Scrum is the most common way game studios organize the iteration loop from section 2 into a repeating schedule. It is a fixed set of meetings and a fixed length of time (usually one or two weeks, called a sprint) that the whole team commits to together, so that "what are we building next, and are we on track" has a predictable, regular answer instead of being asked at random.
Five pieces make up the system:
Two roles keep the system running. A Product Owner decides what is in the backlog and in what order -- usually a lead designer or producer, someone with the authority to say "this matters more than that." A Scrum Master runs the meetings, removes blockers, and protects the team from scope being added mid-sprint -- not a manager in the traditional sense, more a referee whose job is keeping the process honest.
Here is a stand-up as it actually sounds, three people into a ten-minute meeting, on day 6 of the double-jump sprint from section 1:
STAND-UP -- day 6 of 10
PRODUCER (running it): Okay, quick round. Mina, you're up.
MINA (programmer): Yesterday I finished the jump-count logic and
opened a PR. Today I'm picking up the hit-stun bug QA found
yesterday. No blockers.
PRODUCER: Nice. Dao?
DAO (artist): Yesterday and today are both the second-jump pose --
it's taking longer than I estimated, the silhouette wasn't reading
right at speed so I'm redoing the arm position. Should be done
tomorrow. No blockers, just slower than planned.
PRODUCER: Got it, noted. Fon?
FON (QA): Filed three tickets yesterday, the hit-stun one Mina
mentioned plus two smaller ones. Today I'm running the regression
pass on last sprint's fixes. One blocker -- I don't have a build
with yesterday's PR merged yet, so I can't verify Mina's fix until
that lands.
PRODUCER: Mina, can you ping Fon once that PR merges?
MINA: Yep, will do right after stand-up.
PRODUCER: Great, that's everyone. Ten minutes, back to it.Notice what that stand-up is not: nobody explained how the hit-stun bug works, nobody debated whether the second-jump pose is any good, and nobody spent more than about ninety seconds talking. Those conversations are real and important, but they happen afterward, in a smaller room with just Mina and Fon, or just Dao and the designer. A stand-up that turns into a design discussion or a debugging session stops being a ten-minute status check and starts eating everyone's morning -- keeping it short is not a formality, it is the entire point of the meeting.
Most teams track a sprint on a board: one column per state a ticket can be in, one card per ticket, moved left to right as work progresses. Here is the double-jump sprint from section 1, a snapshot on day 6 of 10.
Read that board the way a producer reads it in stand-up: five tickets are still open with four days left, one of them (the second-jump animation) is already running long, and the burndown line (a simple day-by-day count of how many tickets are still not Done, plotted against where the team hoped to be) shows the sprint is a little behind pace, not badly behind. That is useful, boring information, exactly the kind a two-week check-in is supposed to produce early enough to still do something about it -- reassign a ticket, cut scope, or just let Dao take the extra day since everything else is on track.
Section 3 described scrum the way a textbook describes it. Here is how it actually goes wrong often enough that it is worth naming each failure by itself, so you recognize it happening around you instead of assuming your team is uniquely broken.
Kanban keeps the board from section 4 but drops the fixed two-week box entirely. There is no sprint, no sprint planning meeting, and often no story points -- just a backlog, a board, and a rule about how much work is allowed to be "in progress" at once, called a WIP limit (work-in-progress limit). Work flows continuously: the moment a ticket finishes, whoever finished it pulls the next one off the top of the backlog, instead of waiting for the next sprint to start.
The WIP limit is the whole mechanism. Without one, everyone starts five things at once and finishes nothing, because starting feels like progress even when it is not. With a WIP limit of 3 on "In Progress," a fourth ticket physically cannot start until one of the three current ones moves to Review -- which forces the team to actually finish work instead of spreading itself across everything in the backlog at once.
Kanban tends to fit teams whose work arrives unpredictably and needs a fast response more than it needs a two-week plan: QA triage (bug severity does not wait politely for a sprint boundary), live-ops (an event or a server issue needs attention today, not at the next planning meeting), and tools teams supporting the rest of the studio (whoever is blocked needs their tool fixed now, not in ten days). Feature teams building something large and coordinated -- like the double-jump example running through this chapter -- usually still prefer scrum's fixed rhythm, because a two-week checkpoint gives everyone a shared, predictable moment to show work and re-plan together.
A ticket is the unit this entire process runs on -- it is what sits on the board in section 4, what gets estimated for a sprint, and what a programmer, artist, or QA tester actually opens to know what to do. A bad ticket costs everyone who touches it real time: someone has to track the reporter down, ask what they meant, and wait for an answer before any work can start. A good ticket answers the obvious questions before anyone has to ask.
A good ticket, whatever kind of work it describes, answers four things: what should happen, why it matters, exact repro steps if it is a bug (the precise sequence of actions that makes the problem happen, every time), and acceptance criteria (a short, checkable list of conditions that must be true before the ticket counts as done).
Here is a real bug, written the way it usually first arrives:
Title: jump is broken pls fix
the double jump is broken sometimes, please look into it. happens
a lot when playing. kind of urgentNothing in that ticket tells a programmer where to start. "Sometimes" and "a lot" are not repro steps -- there is no sequence of actions to follow, no way to know if a fix actually worked, and "kind of urgent" carries no real information about how bad it is. Whoever picks this up has to go find the reporter and ask three or four questions before they can even begin, which is exactly the cost a good ticket is supposed to avoid.
Here is the same bug, rewritten:
Title: Double jump cooldown does not reset if the player is hit
mid-air during the second jump
WHAT: The player's double-jump cooldown fails to reset after
landing, if the player was hit by an enemy attack while airborne
during the second jump. The player is then stuck unable to double
jump until the level reloads.
WHY: This blocks players from progressing past any encounter that
expects a double jump right after taking a hit -- currently makes
the boss fight in Level 4 unwinnable without reloading.
REPRO STEPS:
1. Start Level 4, reach the boss arena.
2. Jump once, then jump again (double jump) to trigger the
second-jump state.
3. While still airborne in the second jump, let the boss's
fireball attack hit the player.
4. Land normally.
5. Try to double jump again -- BUG: second jump does not trigger.
EXPECTED: After landing, the double jump should be available again,
same as any other landing.
ACTUAL: The double-jump cooldown stays "used" permanently after
this specific sequence, until the level reloads.
ENVIRONMENT: build 0.14.2, PC, reproduced 5/5 times.
SEVERITY: High -- blocks progress in a required encounter, not a
crash, has a workaround (reload level) but the workaround is not
obvious to a player.
ACCEPTANCE CRITERIA:
- Double jump becomes available again after any landing, including
a landing that happened after taking damage mid-air.
- No new regression in the normal (not-hit) double-jump case --
verify against BUG-799's existing repro steps too.Every part of that rewrite exists to save someone else's time. The repro steps mean a programmer can reproduce the bug on their own machine in thirty seconds instead of waiting for a reply. The why means whoever prioritizes the backlog in section 3 can tell this apart from a cosmetic bug at a glance, without needing game-design context loaded in their head. The acceptance criteria mean QA knows exactly what to re-test before marking it verified, and the programmer knows exactly when to stop -- without acceptance criteria, "done" is a matter of opinion, and opinions are exactly what a ticket exists to remove from the equation.
Code review is where a second person reads a change before it merges -- the same pull request workflow from chapter 17.1, now looked at from the human side instead of the git-mechanics side. Its job is to catch what the author cannot see because they are too close to their own code, and to spread knowledge of the codebase across more than one person's head.
Update(), an unnecessarily expensive call inside a hot loop -- the kind of cost that is invisible in a code diff but very visible once two hundred of these are running on screen at once.The single most useful habit is aiming every comment at the code, never at the person, and phrasing it as a question or an observation rather than a command. Compare these two comments on the exact same line:
BAD:
"This is wrong, you forgot to check for null here."
GOOD:
"What happens if `target` is null when this runs -- e.g. the
enemy despawned the same frame this fires? Might be worth a
null check, or I could be missing a guard earlier in the call
chain that already handles it."Both comments point at the same real problem. The first assumes carelessness and states it as settled fact -- there is nowhere for the author to go except feel criticized. The second assumes there might be a reason the author sees that the reviewer does not, asks rather than declares, and offers a concrete next step. It takes five extra seconds to write and it is the difference between a reviewer the team trusts and one people quietly start avoiding.
Two more habits matter almost as much as tone. First, separate blocking comments (this must change before I approve) from nits (nitpicks -- small, optional style preferences, worth flagging as "nit:" so the author knows they can ignore it without a second round of review). Second, say something when the code is good, not only when it is wrong -- a review that is one hundred percent criticism, even gently worded criticism, still reads as one hundred percent negative.
BAD (a review of nothing but problems, no nits marked):
"Rename this variable. This function is too long. Add a null
check here. This comment is out of date. Use the existing
DamageCalculator instead of writing this by hand."
GOOD (same concerns, prioritized and separated):
"Nice catch reusing the existing hit-stun timer instead of adding
a new one -- one less thing to keep in sync.
Blocking: this reimplements damage math that DamageCalculator
already does a few lines up in CombatSystem.cs -- worth calling
that instead so both paths stay consistent if the formula changes.
nit: `x` -- maybe rename to `hitStunRemaining`, only if you're
touching this line anyway.
nit: the comment on line 40 still describes the old cooldown logic,
might be stale now."A review comment is about the code, not a verdict on the author, even when it does not feel that way in the moment a red comment appears on a line someone just spent an hour writing. The useful response to a comment that stings is not to defend the line immediately -- it is to ask what the reviewer is actually worried about, since most defensive replies turn out to be arguing against a concern the reviewer never raised. If a comment is genuinely wrong, say so plainly and explain why, with the same question-first tone from above; reviewers miss context constantly, and a good reviewer wants to be corrected more than they want to be right.
A sprint answers "what did the team finish in the last two weeks." A milestone answers a bigger question: "is the whole game, as a whole, on track." Game production is organized around a handful of named milestones, and knowing what each one actually means -- not just its name -- tells you a lot about what state a project is really in when someone mentions it.
Notice the shape: each milestone removes a category of allowed work, it does not just add a deadline. Before alpha, new systems are still fair game. Between alpha and beta, new systems stop but new content keeps coming. After beta, both stop -- the only thing left is making what already exists correct and polished. A team that is still designing new mechanics after beta is not slightly behind schedule; it has skipped a milestone's actual meaning, which is usually a much bigger problem than the calendar alone shows.
Crunch is sustained overtime -- long stretches of nights and weekends -- worked to hit a deadline, usually concentrated in the weeks before a milestone from section 9. It has a long history in game development, and for just as long, it has been talked about as if it were a personal virtue: proof a team cares, a badge of dedication. It is worth being precise about why that framing is wrong.
A deadline has exactly three variables that can move: scope (how much gets built), schedule (how much time there is), and people (how much capacity the team has). When scope grows -- new features get added mid-production, or the original estimate for existing work was simply too optimistic -- and neither schedule nor headcount moves to absorb it, the only variable left to bend is how many hours each person spends per week. That bend is crunch. It is not a mysterious force that appears near ship dates; it is what happens, arithmetically, when scope outgrows schedule and nobody with the authority to change either one does anything about it.
That is why crunch is correctly described as a management failure rather than a team failure or an inevitability: scope and schedule are decisions producers, leads, and studio leadership make, not decisions the engineers writing the code get to make for themselves. A team cannot "just work harder" its way out of a scope problem it did not create and has no authority to fix by cutting features. And the research on sustained overtime is consistent and unflattering: productivity and code quality both drop noticeably past roughly 40-50 hours a week, and the drop compounds the longer the overtime continues -- so crunch does not even reliably buy back the time it costs. A team that crunches for six weeks to hit a date often ships a buggier game than a team that cut scope and shipped the same date rested, because tired programmers write more bugs, tired QA misses more of them, and tired reviewers catch less in section 8's process.
What healthier studios actually do differently is not a secret or a trick -- it is discipline applied earlier, when it is cheaper:
Programmers spend most of their day talking to other programmers, in a shared vocabulary built over years. Designers, artists, and producers do not share that vocabulary, and explaining a technical limit to them in programmer language usually lands as "the computer says no" -- true, but useless, because it gives the other person nothing to work with. The fix is translating a technical constraint into the terms the other person actually thinks in: what it costs, in units they can act on, and what the realistic alternatives are.
Say a designer asks for a battle with a thousand enemies on screen at once, each one running full pathfinding, physics, and individual AI decision-making -- the same kind of per-enemy cost this curriculum's AI and physics chapters cover in detail.
BAD:
"That's not possible, pathfinding is O(n log n) per agent and
physics broad-phase doesn't scale like that, we'd blow the frame
budget instantly."
GOOD:
"A thousand enemies each doing full pathfinding and physics every
frame would drop us well under 10 fps -- unplayable. Here's what
IS realistic: about 30 enemies actually fighting with full AI and
physics, plus hundreds more in the background doing a much cheaper
fake version -- simple movement, no individual decision-making,
close enough that most players won't tell the difference unless
they're staring right at one. Would that get you the 'overwhelming
horde' feeling you're going for, or does the fight specifically
need a thousand enemies the player can individually engage?"The bad version is not wrong -- the complexity numbers are real -- but it answers a question the designer did not ask and leaves them with nothing to decide. The good version states the real cost in a unit a designer already thinks in (frame rate, "unplayable"), offers a concrete number that does work, and, critically, ends by asking what the designer's actual goal was. Often the honest constraint ("a thousand fully-simulated enemies") and the real goal ("this should feel overwhelming") are not the same request at all, and the cheaper version satisfies the real goal completely.
The same pattern works in the other direction. Say an artist delivers a prop with 500,000 triangles for something that will appear as background clutter, thirty of them at once, on a mobile game with a very tight budget:
BAD:
"This is way too high poly, it's going to kill performance."
GOOD:
"This looks great up close -- but we'll have about 30 of these
on screen at once, at a distance where a player will mostly see
it as a silhouette, and our whole scene budget on mobile is
around 500k triangles total. Right now this one prop alone would
use the entire budget for the whole screen. Could we get a lower-
detail version for the background instances, and maybe keep this
detail level just for any hero placement up close? Happy to check
with the tech artist on what triangle count actually reads fine
at the distances this prop will usually be seen from."Notice the shape repeats: state the real number in context the other person can act on (30 instances, the total scene budget, not just this one asset in isolation), and offer a path forward instead of just a rejection. An artist who hears "too high poly" learns nothing they can use next time; an artist who hears "here's the budget this needs to fit inside, and here's why" can make that same judgment call themselves on the next ten props, without a programmer needing to review every single one.
Title: camera bugs out near water pls check
sometimes when near water the camera does something weird and
gets stuck. kinda annoying. thanksAnswers will vary in the specific details invented, but a good rewrite has this shape:
Title: Camera collision gets stuck against invisible geometry when
the player stands at the edge of a water plane
WHAT: When the player-controlled camera is within roughly 2 meters
of a water plane and the player rotates the camera to look back
across the water toward the shore, the camera's collision volume
stops moving and freezes in place, ignoring further player input,
even though there is no visible obstruction.
WHY: This makes it impossible to look around normally near any
body of water, which affects most outdoor levels -- currently
reproduces reliably at the lake in Level 2 and the river crossing
in Level 5.
REPRO STEPS:
1. Load Level 2, walk to the edge of the lake.
2. Stand within about 2 meters of the water's edge, facing the
water.
3. Rotate the camera so it points back across the water toward
the shore behind the player.
4. Continue rotating slowly -- BUG: past a certain angle, camera
rotation stops responding to input entirely.
EXPECTED: The camera should rotate freely around the player
regardless of distance to a water plane, same as over any other
surface.
ACTUAL: Camera rotation freezes once the camera crosses a certain
angle near water, and does not recover until the player moves more
than 2 meters away from the water's edge.
ENVIRONMENT: build 0.21.0, PC, reproduced 4/4 times at the Level 2
lake, 3/4 times at the Level 5 river.
SEVERITY: Medium -- does not block progress or crash, but breaks
camera control in a common outdoor scenario players will hit often.
ACCEPTANCE CRITERIA:
- Camera rotates freely near any water plane, at any angle, in
both repro locations.
- No new regression in normal camera collision against level
geometry elsewhere.The key improvements over the original are the same ones from section 7: exact repro steps someone can follow in under a minute, a concrete why that lets this be prioritized correctly, and acceptance criteria specific enough that QA knows exactly what to re-check before closing it.
Backlog overstuffed by optimism, not evidence. Planning for 42 points against a real recent average of 28 is exactly the failure section 5 names -- the plan is built on hope, not on what the last few sprints actually proved the team can finish. Section 5's fix: plan the next sprint around the real recent average (something close to 28), not around the best-case number.
QA left out of planning. Assuming QA will "test as things land" with no dedicated capacity means the sprint plan only accounts for programmers finishing work, not for the work actually being verified. Section 5's fix: give QA explicit, budgeted time inside the sprint plan itself, the same way a feature's programming time is budgeted.
Stand-up turned into a status report to a boss. A twenty-five minute stand-up where the producer asks engineers to justify tickets that are behind is precisely the failure mode from section 5 -- it stops being three quick questions for the team and starts being a performance review in public, which tends to make people stop admitting real blockers rather than surface them earlier. Section 5's fix: keep it to the three questions, and have any "why is this behind" conversation happen one-on-one, after stand-up, not in front of the whole team.
Given all three problems together, day 8 of 10 with only 15 of 42 points done is not really a surprise -- it is the predictable result of an oversized commitment with no QA time budgeted and a stand-up that was discouraging honesty about blockers all along. Following section 10's crunch discipline, the right move now is to cut scope for the remaining two days (openly decide which of the unfinished tickets slip to next sprint), not to push unplanned overtime trying to hit 42 anyway.
Answers will vary, but a good response has this shape:
"That would look incredible, but fully synced per-object destruction across the whole 4km map, updated every frame, for 100 players, is not realistic -- every player's client would need to stay in sync on the exact state of thousands of destructible pieces continuously, and the network traffic alone would swamp the connection long before we even got to the rendering or physics cost. Here's what IS realistic: a limited set of pre-authored destructible structures (maybe 40-60 across the map, placed at points of interest) plus a few large scripted destruction events tied to the match itself, like a storm-triggered building collapse in the shrinking zone. Would that get you the 'the map feels dangerous and changing' feeling you're after, or is the goal specifically that a player can destroy any arbitrary wall wherever they are standing?"
This follows section 11's pattern exactly: it states the real cost in a unit the designer can act on (network sync across 100 players, not raw complexity notation), proposes a concrete, shippable alternative instead of a flat no, and closes by asking what the underlying goal actually is -- since "the map should feel dangerous and changing" and "every wall must be individually destructible" are not the same request, and the cheaper version may satisfy the real goal completely.
None of this replaces knowing how to write code. It sits around it. A designer who cannot describe what they want, a ticket that does not say why it matters, a review comment that starts a fight instead of fixing a bug, a schedule that quietly turns "we hope to finish this" into "we promised this" -- every one of those costs a team real time and real quality, the same as a bug would, and none of them show up in a stack trace. The programmers who get the most done are rarely the ones who write the cleverest code in isolation; they are the ones who make it easy for a designer, an artist, a tester, and a reviewer to work with them, sprint after sprint, without the process itself becoming the thing that is broken.