Game dev — overview

Status: 🟩 COMPLETE (🟦 LIVING — engines and tools evolve regularly) Last updated: 2026-06-19 Plain-English tagline: Building games is structurally different from building webapps — different time loop (60 frames per second instead of “react to user clicks”), different math (3D, physics, animation), different tools (engines like Unity, Unreal, Godot). A whole adjacent universe worth knowing the shape of.

In plain English

A typical webapp’s life looks like: page loads → user clicks → server responds → page updates → user clicks again. Discrete events; mostly idle in between.

A typical GAME looks completely different: the program runs a LOOP, 60 times per second (or 120, or 144), drawing the screen, processing physics, updating positions, checking for input, playing audio, networking — all on every frame. The CPU and GPU are constantly busy, frame after frame, until the player quits.

That structural difference shapes EVERYTHING about how games are built:

Different tools — game engines (Unity, Unreal, Godot) instead of web frameworks
Different languages — C# (Unity), C++ (Unreal), GDScript (Godot), occasionally JavaScript / TypeScript (browser games)
Different math — 3D vectors, matrices, quaternions, physics, animation curves
Different deployment — Steam, App Store, Play Store, consoles, the web (less commonly)
Different optimization — frame budgets, memory pooling, GPU-aware code
Different design — game design vs. UX design (related but distinct disciplines)

For Bible Quest-style work: game dev is mostly OUT OF SCOPE. Bible Quest IS a webapp; the closest “game-like” pieces are gamification elements (progress tracking, quests, streaks) — which can be built with regular webapp tools.

But knowing the shape of game dev is useful because:

The patterns are referenced in webapp contexts (“the game loop,” “ECS,” “frame budget”)
AI tools generate game code sometimes; recognizing it matters
“Could I build a game?” comes up; knowing the rough answer saves exploration time
Web games are increasingly viable (modern browser is a real game platform)

This entry maps the territory at a competent-tourist level.

Why it matters

Three concrete reasons even a non-coder benefits:

Games are a real part of modern software. Mobile games are the largest entertainment industry by revenue. Indie games on Steam, web games, browser-based education games — all real shapes of software.
The vocabulary matters. “Frame rate,” “physics engine,” “shaders,” “game loop,” “ECS” appear in tech contexts. Knowing what they mean prevents bafflement.
The line between game and app is blurring. Bible Quest has “quest” in its name. The gamification of webapps (streaks, points, achievements, progression) borrows real game design. Knowing the source helps.

The trade-off: full game dev knowledge takes years. This entry is the conceptual map; if you actually build games, you’ll need much deeper resources.

The game engines

A game engine is to game dev what Next.js is to web dev — a framework that handles the boring parts (graphics, audio, physics, input, scene management) so you can focus on what’s specific to your game.

The dominant engines in 2026:

Unity (C#)

The most-used engine globally. Cross-platform (PC, Mac, mobile, console, web via WebGL/WebGPU). Strong for 2D and 3D. C# scripting. Huge asset store. Free for small studios; royalties / per-install fees at scale.

Best for: mobile games, indie 2D + 3D, mid-budget projects.

Used by: Among Us, Hollow Knight, Cuphead, Pokémon Go, Hearthstone, countless mobile titles.

Unreal Engine (C++ + Blueprints)

The “AAA” engine. Best-in-class graphics. Strong for 3D, high-fidelity rendering. C++ scripting plus Blueprints (visual programming). Free; royalties at high revenue.

Best for: big-budget 3D games, photorealistic visuals, VR.

Used by: Fortnite, Gears of War, Borderlands 3, Hellblade, The Matrix Awakens demo.

Godot (GDScript or C#)

Open-source, lightweight, growing fast. Excellent for 2D, capable for 3D. Has its own scripting language (GDScript — Python-like) plus C# option.

Best for: indie 2D, learning game dev, anyone who values open source.

Used by: Brotato, Halls of Torment, Cassette Beasts.

Other engines

GameMaker — 2D-focused; used by Undertale, Hyper Light Drifter
Bevy — Rust-based; very modern, growing
Construct — visual / no-code; for non-programmers
PICO-8 — fantasy console; tiny, charming, popular for game jams
Phaser — JavaScript 2D game library for browser games
Babylon.js / Three.js — JavaScript 3D libraries (more “render 3D in browser” than full engines)

For someone NEW to game dev in 2026: Godot is a great first engine (free, gentle learning curve, growing community). Unity is the most career-relevant. Unreal is the deepest if 3D AAA is the goal.

For browser-based games specifically: Phaser (2D), Three.js (3D), or Unity WebGL export.

The game loop — the heartbeat

Every game has a main loop that runs every frame:

while game is running:
  1. Process input (keyboard, mouse, gamepad, touch)
  2. Update game state (positions, AI, animations, physics)
  3. Render the screen (draw what the player sees)
  4. Play any pending audio
  5. Sync to the display refresh rate (~16.6ms for 60 fps)

This runs 60 times per second (typical), 120 fps on high-refresh displays, sometimes 30 on mobile. Each cycle has a TIME BUDGET — at 60fps, you have 16.6ms per frame for everything.

If a frame takes longer than the budget, the game “drops a frame” — the screen doesn’t update on time, the player notices a stutter. Consistent performance matters as much as average performance.

This is why games are MICRO-OPTIMIZED in ways webapps aren’t. A 5ms slowdown is invisible in a webapp; in a game, it’s a missed frame.

What’s in a typical game engine

Game engines bundle dozens of subsystems:

Subsystem	What it does
Rendering	Drawing 2D sprites or 3D meshes to the screen. Uses the GPU.
Physics	Simulating gravity, collisions, friction. Box2D (2D), Bullet/PhysX (3D).
Audio	Playing sounds, music, 3D-positioned audio.
Input	Keyboard, mouse, gamepad, touch, VR controllers.
Animation	Skeletal animation, blend trees, IK (inverse kinematics).
Networking	Multiplayer synchronization, lobbies, matchmaking.
Asset management	Loading + caching textures, sounds, models, scenes.
Scripting	Letting designers/programmers write game logic.
Scene management	Levels, transitions, save/load.
UI	Game menus, HUD elements (different from web UI).
Particles	Smoke, fire, explosions, sparks.
Lighting + shaders	Dynamic lighting, materials, shadows.
Build pipeline	Exporting for Windows, Mac, Linux, mobile, web, console.

The engine handles 90%+ of this. You focus on YOUR GAME’s specific logic.

A concrete example: Pong in three approaches

The simplest game — paddles bouncing a ball.

Browser-based (vanilla JS + Canvas)

const canvas = document.getElementById("game");
const ctx = canvas.getContext("2d");
 
let ball = { x: 200, y: 150, dx: 3, dy: 2 };
let paddle1 = { y: 130 };
let paddle2 = { y: 130 };
 
function update() {
  ball.x += ball.dx;
  ball.y += ball.dy;
  if (ball.y < 0 || ball.y > 290) ball.dy = -ball.dy;
  // collision detection with paddles...
}
 
function render() {
  ctx.clearRect(0, 0, 400, 300);
  ctx.fillRect(ball.x, ball.y, 10, 10);
  ctx.fillRect(10, paddle1.y, 10, 40);
  ctx.fillRect(380, paddle2.y, 10, 40);
}
 
function loop() {
  update();
  render();
  requestAnimationFrame(loop);
}
loop();

~50 lines for a working Pong. Browser handles the rendering via Canvas; requestAnimationFrame provides the frame loop synced to the display.

In Unity (C#)

Drag a Ball GameObject. Drag two Paddle GameObjects. Attach a Rigidbody2D + Box Collider for physics. Attach a script like:

public class Ball : MonoBehaviour {
  public float speed = 5f;
  Rigidbody2D rb;
 
  void Start() {
    rb = GetComponent<Rigidbody2D>();
    rb.velocity = new Vector2(speed, speed);
  }
 
  void OnCollisionEnter2D(Collision2D collision) {
    if (collision.gameObject.CompareTag("Paddle")) {
      rb.velocity = new Vector2(-rb.velocity.x, rb.velocity.y);
    }
  }
}

Physics, collision, audio (a “ping” on bounce) — built into the engine. ~10 lines of game-specific code; the rest is engine glue.

In Godot (GDScript)

Similar to Unity in structure — drag scene objects, attach a script:

extends RigidBody2D
 
func _ready():
  linear_velocity = Vector2(300, 200)
 
func _on_body_entered(body):
  if body.is_in_group("paddle"):
    linear_velocity.x = -linear_velocity.x

Same idea, different syntax. Godot’s “scenes” are reusable hierarchies (like React components).

Why games are HARDER than webapps

A few specific challenges that don’t appear (or appear less) in webapp work:

1. Continuous performance

Every frame matters. A 16ms budget. Spike → visible stutter. Webapps tolerate the occasional 200ms delay; games can’t.

2. Coordinate math + physics

3D positions, rotations (quaternions!), camera matrices, collision detection — all math-heavy. The engine helps, but you still need to think in vectors.

3. Game design ≠ UX design

Games have to be FUN. Webapps have to be USABLE. Different bar; different skills. Onboarding, difficulty curves, reward loops, narrative — none of this maps to webapp design.

4. Asset pipelines

A typical game has hundreds-thousands of art assets (textures, models, animations, audio). Producing them, importing them efficiently, keeping them in version control, optimizing them for runtime — a whole subdiscipline.

5. Platform fragmentation

A game on Windows, Mac, Linux, iOS, Android, PS5, Xbox, Switch is FIVE+ different builds. Each has its own quirks, certifications, store requirements.

6. Performance tooling

Frame profilers, GPU profilers, memory profilers. Knowing why a frame took 22ms instead of 16ms requires specialized tools.

7. Multiplayer is hard

Adding multiplayer is “rebuild everything with network sync in mind.” Latency compensation, anti-cheat, lobbies, matchmaking, server costs.

The webapp world is mature and ergonomic; the game dev world is more fragmented and requires more specialized knowledge. Both are valid careers; they’re different careers.

Web games — the underrated path

If you’re a web developer curious about games, the BROWSER is increasingly capable:

WebGL + WebGPU — GPU-accelerated rendering in the browser
Phaser — established 2D game library
Three.js, Babylon.js — 3D libraries
PixiJS — 2D rendering library (used by many web games)
Construct — no-code-ish 2D game builder
Unity WebGL export — Unity games compiled to web (sometimes laggy but functional)
Godot web export — similar
PlayCanvas — full web-based engine

Pros of web games:

No installation
Cross-platform automatically
Easy sharing (just a URL)
Solid for 2D casual games

Cons:

Performance ceiling lower than native
Limited file system access
Battery drain on mobile
Most “serious” games aren’t on web

For Bible Quest-style projects with light gamification (a “verses found” achievement, a streak counter, a points system) — you don’t need a game engine. Standard React + good design covers it. You’d only reach for a game engine if making something genuinely game-shaped (a puzzle, a quiz with rich animations, an actual platformer).

Game design vs UX design

Adjacent disciplines; meaningful differences:

Aspect	UX design (webapp)	Game design
Goal	Get the user to their goal efficiently	Engage the player; create enjoyable experience
Friction	Bad — minimize	Sometimes good (challenge, difficulty curve)
Feedback loops	Subtle (confirmations, micro-interactions)	Heavy (juice, screen shake, particle effects, audio)
Onboarding	Fast; get out of the way	Often a paced tutorial; teaches as you play
Predictability	Always good	Often broken intentionally (surprise!)
Reward structure	Tied to user’s external goal	Intrinsic to the experience

Gamification of webapps borrows from game design. The discipline behind “well, why does this Duolingo streak feel rewarding?” is real and learnable.

Books worth reading if interested:

The Art of Game Design (Jesse Schell) — comprehensive, accessible
Rules of Play (Salen + Zimmerman) — academic but thorough
A Theory of Fun for Game Design (Raph Koster) — short and provocative

Common gotchas

“Frame rate” matters more than you think. A 30fps game looks janky after you’ve played 60fps. 120fps+ on competitive games feels meaningfully smoother. Match your platform’s typical frame rate.
Don’t allocate memory in the game loop. Allocations cause GC pauses. Pool objects (pre-allocate; reuse).
The “game loop” pattern is OLDER than webapps. From Pong onwards. Webapps adopted event-driven; games kept the loop because frames are continuous.
Physics is hard to get RIGHT. Engines provide it; using it well requires understanding (or accepting weird defaults).
3D math is the gatekeeper. Vectors, dot product, cross product, matrices, quaternions. Spend time here OR use the engine to avoid it.
Asset optimization is a real job. Texture atlases, mipmaps, LODs (level of detail), audio compression, model simplification — engines help but choices matter.
Don’t ship in debug mode. Game engines have “build” vs “play in editor” — they’re WILDLY different in performance. Ship a release build.
Game development has its own culture. Game jams, conferences (GDC), forums (TIGSource), communities. Different vibe from webapp world.
Indie games rarely make their developers rich. A small fraction succeed. Plan finances accordingly.
“Crunch” is a real and ugly industry issue. Long hours, burnout, exploitation. Indie / solo dev avoids most of it; AAA studios are notorious.
Cross-platform games need cross-platform testing. A Mac-developed game tested only on Mac will have Windows bugs. Same for mobile/desktop.
Save files + cloud saves matter. Players expect their progress to persist + sync across devices. Add early; don’t bolt on.
Game updates require careful versioning. A new build might break old save files. Plan migrations.
Multiplayer adds servers (or P2P). Server hosting, matchmaking, anti-cheat — months of work for “just multiplayer.”
Console certification is strict. Sony, Microsoft, Nintendo each have detailed rules. Failing means delays.
The App Store / Play Store impose game-specific rules too. Especially around microtransactions, ratings, content.
Procedural generation is hard to balance. Random generation produces unbalanced gameplay; tuning takes iteration.
“Juice” makes games feel alive. Screen shake, particle effects, snappy animations, audio cues. Cheap to add, hugely affects perceived quality.
Audio is half the game. Bad audio kills immersion; great audio elevates everything. Sound design is its own discipline.
Localization is a real cost. Translating UI, dialogue, marketing for multiple languages. Plan ahead in the architecture.
Game engines have steep learning curves. Unity: weeks-months. Unreal: months. Godot: weeks. Native game dev: longer.
Modding extends games’ lifetimes hugely. Games with mod support (Minecraft, Skyrim, Factorio) outlive their official supported lifetimes by decades.
Game dev career paths are different. Game programmer, engine programmer, gameplay programmer, technical artist, level designer, narrative designer — specialized roles.
The “indie game scene” is a community. Game jams (Ludum Dare, GMTK Jam), itch.io, IndieCade. Real and supportive.
AI is reshaping game dev too. Procedural content, AI-generated assets, NPC behavior driven by LLMs. Watching the next 2-3 years will be interesting.
Web games are CLEARLY rising. Browsers are fast; distribution is friction-free; instant play. Watch this segment grow.
Don’t conflate “gamification” with “making a game.” Most webapp gamification is borrowed game-design tricks (achievements, streaks, points). You don’t need a game engine to do it.
Bible Quest’s “quest” is gamification, not a game. Real game dev is dramatically different. Don’t accidentally over-scope a webapp into game-dev territory.
AI-generated game code needs scrutiny. Game-specific code (especially math, physics) is easier to mess up than CRUD logic. Verify before shipping.
requestAnimationFrame is the browser’s game loop. If you want to build a tiny browser game, start there.
2D is easier than 3D. By a lot. Start with 2D if learning.
Pixel art is forgiving. You can produce decent-looking pixel art faster than decent-looking high-fidelity art. Many successful indie games lean on pixel aesthetics.
Mobile gaming dwarfs PC + console combined. Mobile is where the money is at scale (with massive caveats around monetization patterns).

When game dev intersects with webapp work

Some real overlap:

Animation libraries (Framer Motion, GSAP) for webapps borrow game-loop patterns
Three.js / Babylon.js for 3D scenes inside webapps (product viewers, visualizations)
Canvas API + requestAnimationFrame for any custom rendering (charts, data viz, mini-games)
Phaser embedded in a webapp for a “play this mini-game” feature
Gamification design patterns (streaks, badges, levels) applied to non-game UIs

For Bible Quest, the relevant intersection is gamification design. A “verse-of-the-day” streak, a “books completed” achievement, a progress bar with satisfying animation — these are game design ideas in a non-game context. You don’t need Unity. You need React + thoughtful UX.

When you’d actually go into game dev

You’d reach for a game engine when:

You’re building a GAME, not a webapp with game-like elements
The interaction is continuous (real-time movement, physics, animation)
You want native cross-platform from one codebase (Unity, Godot)
You need GPU rendering capability (3D, complex 2D)
You’re targeting consoles / Steam / dedicated game platforms

You’d stay in the webapp stack when:

You want web distribution
The interaction is event-driven, not continuous
You’re adding gamification, not building a game
Your team already knows React / Next.js

For Bible Quest: stay in the webapp stack. The “quest” framing is wonderful as gamification; doesn’t need a game engine to deliver it.

Sources

Unity Learn — official Unity tutorials
Unreal Engine Documentation
Godot docs — open-source engine
Phaser docs — JavaScript 2D
Three.js — JavaScript 3D library
GameDev.net — community
The Art of Game Design (Jesse Schell) — the canonical game design book
Game Programming Patterns (free online) — Bob Nystrom’s free book
itch.io — indie game marketplace + community
IGDA — International Game Developers Association

Tech & AI, Explained

Explorer

game-dev-overview