A Few Things Every Game Programmer Should Know

A satirical list of hard-won observations from the world of game development, written in the form of ironic remarks about the realities of production. It covers the technical, organizational, and deeply human aspects of making games.

C++ and Technical Paradoxes

• In std::move, nobody actually moves anything anywhere.
• In undefined behavior, the behavior is quite well defined — it just crashes your game.
• In a debug build, there are fewer bugs than in the release build, and the FPS is higher.
• GameObject contains neither game nor object — just bugs and a bunch of antipatterns.
• The memory leak detector itself leaks.
• PhysicsEngine has about as much physics as a fairy tale.
• In EntityComponentSystem, there is neither a system, nor entities, nor components — just data chaos and hundreds of disconnected calls.

The Build Process

• Out of 8 hours of work, 6 go to attempting to build after merging with stable.
• A cross-platform build compiles only on one machine, in a certain office corner, on one compiler, during a full moon.
• In ProfileMode, everything lags except the profiler.
• In LevelStreaming, the whole world loads at once.

Development Process

• In a retrospective meeting, they discuss why everything is bad, but leave it as is.
• In C++, the only "game" aspect is its ability to get on developers' nerves.
• Refactored legacy code starts taking revenge a week later.
• In the tech debt backlog, there are more debts than features. But features get done; debts don't.
• QA reports a bug where everything is described except how to reproduce it.
• Code review feedback arrives when you've already pushed to the release branch.
• A "beautiful optimization" from the tech lead usually tanks FPS.
• In MVP, there is neither minimum, nor viable, nor product.
• In the fire of deadline, everything dies — including team atmosphere.
• In burnout prevention week, there is neither rest nor prevention — just another sprint.
• In the release build, nothing works except the bugs.
• If "don't worry, it's priority 3" shows up — it's usually already on fire in production.

Console Certification Hell

• The cert submission build usually contains 200+ bugs patched with workarounds.
• In TRC/XR/LOT, there are more rules than articles in the Criminal Code (Sony has 450).
• In Xbox GDK, "GDK" stands for "Where's Documentation, Karl?"
• A cert blocker bug appears only when Sony testers test during a full moon, but needs fixing yesterday.

Server and AI

• In server tick, the server should tick, but the tick starts with you.
• The prediction system predicts nothing but breaks everything.
• In navmesh, everything's fine until the AI decides to walk into a wall.
• In a smart object system, the objects are smarter than the characters.
• In the decision-making system, there are no decisions — just if-else chains.
• A Finite State Machine can hang, get stuck, stumble, swim, and fall.

The "Small Change" Fallacy

• In a "small level change," there are usually 200 drags and 500 new bugs.
• In "just add a button" usually lies 3 days of UI hell and a renderer conflict.

Players and Reviews

• "Why so expensive?" reviews come from people who didn't buy the game.
• "It's all Unity's fault!" reviews come even if the game is written on a custom engine.

Audio

• In the audio system, there's always a sound nobody hears (the silence sound).
• In FMOD, an event triggers either never or always, described through a float field.
• The sound designer usually sends tasks like "need the sound a bit more lively" and a screenshot — that's the whole task.

UI and Localization

• The widget UI system renders nothing but takes 40% of CPU.
• One-click deploy works only for the person who wrote it, on their machine, during a full moon.
• In the Unique String ID system, IDs duplicate while strings disappear.
• A non-Latin font usually breaks the entire UI.
• In RTL text, everything displays right... and bottom.
• In voiceover, the actor speaks for 5 seconds, but the character stays silent for 10.
• When you get a letter from the producer saying "it's not a bug, that's how the translation is" — better not argue.

C++ Deep Cuts

• In template metaprogramming, there's no meta, no programming — just a wall of compile errors across 3 screens.
• In the task "add std::any to X" — you lose the type, debugging ability, and performance.
• In engine code, most comments start with // TODO.
• Virtual destructors kill not objects but performance, and sometimes the build.
• In third-party libs, everything is incompatible — especially the licenses.
• assert(false && "should not happen") happens a couple of times a day.
• The most common bug resolution: CNRD (Can't Reproduce in Debug).
• In the save state pattern, you can lose only a few hours of your life.
• In constexpr, you compile during compilation.

Architecture Astronauts

• "Let's rewrite it under ECS" usually ends with a broken engine but a 60-slide presentation.
• "We use our own memory arena." Now nobody knows why it crashes — not even Valgrind.
• "Enabled C++20 support." The production build doesn't compile on any compiler.
• RAII solves everything but creates cycles nobody can fix.
• Encapsulation is great, but a public field saves the release 10 minutes before the deadline.
• Signals and slots are convenient, but bugs now reproduce randomly.
• We don't use goto, but an 800-line switch-case — that's fine.

Eternal Truths

• If a bug is impossible — it still happens. In the release build, with a different stack trace.
• Lines marked //TMP live longer than you work at the studio.
• The closer to milestone, the more often neutrinos fly through memory banks and corrupt bits.
• If a bug is impossible to reproduce — players will reproduce it every single time.
• A feature finished the night before milestone goes into the trailer.
• If you change something "in just one place" — it breaks in three others.
• Every refactor deletes a piece of history.
• You know it could be better. But nobody asks for better.

CI/CD and Process

• Moved the build to CI — now it breaks itself without programmer involvement.
• Someday you'll finish the documentation.
• Everything you spend over a week on gets replaced with asset store assets.
• A ninja hotfix breaks two stable branches.
• Any load speed improvement leads to three new tasks from artists.
• Nobody knows how that legacy code works. But touch it — the whole build breaks.
• Everything that could be inherited wrong — already is.
• If someone said "I cleaned the code" in a meeting — prepare for a week of heisenbugs.

Management and Human Nature

• A feature budgeted for half a year gets disabled before release for "low priority."
• The stupider the idea — the higher the chance it goes to release.
• Tech debt is just a polite name for someone's unfixed bugs.
• If the build is suddenly stable — means you built debug.
• Can't fire the person who wrote this hell. Because they left on their own — two years ago.
• Every "simple fix" from an artist takes a day from a programmer.
• Rewrote the event system to make it clear. Now nobody understands it, including you.
• When told "nothing critical" — it's always a "priority 3" task (see item about priority 3).
• If the manager asks for a "quick way" — they've already sold the feature to leadership.
• The manager-to-programmer ratio correlates with the probability of getting a product rather than a game at release.
• The artist doesn't know how shaders work. The game designer doesn't know how balance works. The producer doesn't know how the game works.
• No bug is scarier than a feature described in the kitchen as "you'll figure out what I mean."
• If the build compiles and runs — doesn't mean it works.
• Did everything written in the task. But the guy who did everything "by eye" was right. Because fewer distractions.
• If a patch releases on Friday — means the weekend is gone and the phone is off.
• Light breaks through concrete, bullets — no. That's game physics.
• The whole project is held together by 3 people management doesn't listen to.
• "Retro-style" — when the artist can't do lightmaps and the render programmer does their work.
• The more you say it's a bad idea, the higher the chance you get it as a task.
• Layoff probability is directly proportional to the reliability of the system you built.