Games exist to produce a specific feeling in a player on purpose — tension,\nmastery, surprise, delight. A game developer's reason for being is to build\ninteractive systems that reliably manufacture that feeling at sixty frames a\nsecond, then tune until the gap between what the designer intended and what the\nplayer experiences collapses. Fun is not designed on paper; it is discovered by\nbuilding, watching real humans play, and iterating fast.
\n","wordCount":71},{"heading":"Core Mission","id":"core-mission","markdown":"Ship an interactive experience that feels good to play — responsive, fair,\nlegible, worth the player's time — and that runs within its frame and memory\nbudget on the worst hardware you promised to support.","html":"Ship an interactive experience that feels good to play — responsive, fair,\nlegible, worth the player's time — and that runs within its frame and memory\nbudget on the worst hardware you promised to support.
\n","wordCount":33},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is writing gameplay code and content; the real work is defending\nthe player's experience against entropy. A game developer spends their days:\nimplementing the game loop and its systems (input, physics, AI, rendering,\naudio); chasing \"feel\"; budgeting the 16.6ms frame and its memory; profiling and\ncutting the spike that drops the framerate; building tools so designers iterate\nwithout an engineer; integrating art and sound; and, above all, playtesting —\nwatching real people play and changing the game instead of the player. Networked\ngames add the hardest problem in the field: making a laggy, adversarial,\ndistributed system feel local and fair.","html":"The visible work is writing gameplay code and content; the real work is defending\nthe player's experience against entropy. A game developer spends their days:\nimplementing the game loop and its systems (input, physics, AI, rendering,\naudio); chasing "feel"; budgeting the 16.6ms frame and its memory; profiling and\ncutting the spike that drops the framerate; building tools so designers iterate\nwithout an engineer; integrating art and sound; and, above all, playtesting —\nwatching real people play and changing the game instead of the player. Networked\ngames add the hardest problem in the field: making a laggy, adversarial,\ndistributed system feel local and fair.
\n","wordCount":103},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Fun first, found not designed.** You cannot prove a mechanic is fun by\n reasoning about it. Build the smallest playable version, put it in hands, and\n let the playtest tell you.\n- **The frame budget is sacred.** 60fps means 16.6ms per frame for everything —\n logic, physics, AI, render submission; 30fps gives you 33ms. Blow it and the\n whole experience degrades; treat it as a hard constraint.\n- **Feel beats fidelity.** A responsive, juicy mechanic on simple art beats a\n gorgeous one that feels dead. Input latency, animation cancels, screen shake,\n and hit-stop matter more than polygon count.\n- **Cut to make, don't make to cut.** Scope is the enemy. A finished small game\n beats an unfinished large one; kill features early and loudly. Data-drive\n tunable values so designers iterate without waiting on a programmer.\n- **Ship the vertical slice first.** One level, one enemy, one loop polished to\n shipping quality proves the game is fun before you build a hundred that aren't.\n- **The player is never wrong.** If players misread your mechanic, the mechanic\n is unclear.","html":"while(running){ input; update(dt); render; }.\nPhysics wants a fixed timestep for determinism; rendering interpolates between.\nDecoupling simulation from framerate keeps a game stable at 144Hz.FlyingFireEnemy extends FireEnemy extends Enemy — that collapse under new combinations. Compose instead.Games are made by the most cross-disciplinary teams in software: designers (the\nexperience), artists and animators (the look and motion), audio engineers,\nwriters, QA, and producers (scope and schedule). The developer sits at the seam\nwhere every discipline's work becomes code that runs in the frame budget. The\nhealthiest teams keep the build playable daily, hold regular internal playtests\nwhere everyone watches together, and treat the designer-engineer relationship as\na tight feedback loop rather than a ticket queue. Friction lives at the asset\npipeline and the "spec said X but it doesn't feel right" conversations — where\nfeel wins.
\n","wordCount":100},{"heading":"Ethics","id":"ethics","markdown":"Games reach into the brain's reward system more directly than almost any other\nmedium, which makes design a form of behavioral power. Core duties: don't build\ncompulsion loops engineered to override a player's judgment; treat loot boxes,\npay-to-win, and gacha mechanics aimed at children as the gambling-adjacent\npractices they are, and disclose odds honestly. Respect the player's time and\nmoney rather than mining both. Inside the studio, crunch is an ethics issue, not\njust a labor one — sustained overtime is a planning failure paid for with\npeople's health, and \"passion\" is not consent. The hardest gray zones —\nengagement metrics that reward addiction, monetization that targets the\nvulnerable — deserve to be argued in the open.","html":"Games reach into the brain's reward system more directly than almost any other\nmedium, which makes design a form of behavioral power. Core duties: don't build\ncompulsion loops engineered to override a player's judgment; treat loot boxes,\npay-to-win, and gacha mechanics aimed at children as the gambling-adjacent\npractices they are, and disclose odds honestly. Respect the player's time and\nmoney rather than mining both. Inside the studio, crunch is an ethics issue, not\njust a labor one — sustained overtime is a planning failure paid for with\npeople's health, and "passion" is not consent. The hardest gray zones —\nengagement metrics that reward addiction, monetization that targets the\nvulnerable — deserve to be argued in the open.
\n","wordCount":117},{"heading":"Scenarios","id":"scenarios","markdown":"**The jump that feels wrong.** Playtesters keep saying \"the controls feel off\"\nbut can't say why. The expert doesn't add features; they instrument the input.\nThe jump only fires if the button is pressed in the exact frame the player is\ngrounded — so presses a frame early or late silently fail. They add input\nbuffering (queue the press ~6 frames) and coyote time (allow the jump ~5 frames\nafter leaving a ledge), split rise/fall gravity so the arc feels snappy, and add\na landing squash and a sound. None of this is \"realistic\"; all of it makes the\njump feel correct — and nobody can say what changed, which is the point.\n\n**The framerate cliff before cert.** Two weeks from console submission, the game\ndrops to 22fps in the boss arena. Panic says \"lower the resolution.\" The expert\ncaptures a frame in the GPU profiler and finds the boss spawns 4,000 particle\nemitters with overdraw stacking the same pixels dozens of times — fillrate-bound,\nnot CPU-bound. They cap emitter count, switch to a cheaper additive shader, and\nadd LOD. Back to a stable 60 — because they profiled before touching a knob.\n\n**The monetization meeting.** Publishing pushes a loot box with hidden odds and a\n\"pity timer\" the developer knows will drive whales and frustrate everyone else.\nThe expert reframes in retention terms, where the data lives: aggressive\nrandomized monetization spikes ARPU for a quarter and craters day-30 retention\nand store rating. They propose direct cosmetic sales and a disclosed,\ndeterministic battle pass, and insist that if randomized boxes ship, odds are\npublished and the mechanic is gated from minors. The winning argument isn't only\nethical; trust is the asset a live game is built on, and dark patterns spend it\ndown.","html":"The jump that feels wrong. Playtesters keep saying "the controls feel off"\nbut can't say why. The expert doesn't add features; they instrument the input.\nThe jump only fires if the button is pressed in the exact frame the player is\ngrounded — so presses a frame early or late silently fail. They add input\nbuffering (queue the press ~6 frames) and coyote time (allow the jump ~5 frames\nafter leaving a ledge), split rise/fall gravity so the arc feels snappy, and add\na landing squash and a sound. None of this is "realistic"; all of it makes the\njump feel correct — and nobody can say what changed, which is the point.
\nThe framerate cliff before cert. Two weeks from console submission, the game\ndrops to 22fps in the boss arena. Panic says "lower the resolution." The expert\ncaptures a frame in the GPU profiler and finds the boss spawns 4,000 particle\nemitters with overdraw stacking the same pixels dozens of times — fillrate-bound,\nnot CPU-bound. They cap emitter count, switch to a cheaper additive shader, and\nadd LOD. Back to a stable 60 — because they profiled before touching a knob.
\nThe monetization meeting. Publishing pushes a loot box with hidden odds and a\n"pity timer" the developer knows will drive whales and frustrate everyone else.\nThe expert reframes in retention terms, where the data lives: aggressive\nrandomized monetization spikes ARPU for a quarter and craters day-30 retention\nand store rating. They propose direct cosmetic sales and a disclosed,\ndeterministic battle pass, and insist that if randomized boxes ship, odds are\npublished and the mechanic is gated from minors. The winning argument isn't only\nethical; trust is the asset a live game is built on, and dark patterns spend it\ndown.
\n","wordCount":294},{"heading":"Related Occupations","id":"related-occupations","markdown":"A game developer shares the software engineer's discipline around code and\ncomplexity but optimizes for a felt experience inside a hard frame budget rather\nthan correctness alone. Animators and sound engineers own the motion and audio\nthat become \"feel.\" UX designers share the obsession with what the user perceives\nversus what the system does. Mobile developers share the weak-hardware\nconstraint; embedded systems engineers share the religion of fitting a real-time\nloop into a fixed budget.","html":"A game developer shares the software engineer's discipline around code and\ncomplexity but optimizes for a felt experience inside a hard frame budget rather\nthan correctness alone. Animators and sound engineers own the motion and audio\nthat become "feel." UX designers share the obsession with what the user perceives\nversus what the system does. Mobile developers share the weak-hardware\nconstraint; embedded systems engineers share the religion of fitting a real-time\nloop into a fixed budget.
\n","wordCount":77},{"heading":"References","id":"references","markdown":"- *Game Programming Patterns* — Robert Nystrom\n- *Game Engine Architecture* — Jason Gregory\n- *The Art of Game Design: A Book of Lenses* — Jesse Schell\n- *A Theory of Fun for Game Design* — Raph Koster\n- *Real-Time Rendering* — Akenine-Möller, Haines, Hoffman","html":"