Game Development

Game development is software engineering with an unusual constraint: everything must finish in about 16 milliseconds, sixty times a second, forever. That single requirement reshapes every decision downstream — why games favor data-oriented layouts over deep object hierarchies, why garbage collection is treated as a hazard, why simulation and rendering are separated, and why "correct but late" is a bug.

The other defining trait is breadth. A shipping game touches real-time rendering, physics, audio, input, networking, asset pipelines, tooling, and platform certification. Engines like Unity, Unreal, and Godot exist to absorb most of that so a team can spend its time on the part players actually experience.

TL;DR

• Games are soft real-time systems: a frame budget (16.6 ms at 60 FPS) governs every design choice.
• Pick an engine unless you have a specific reason not to — Unity, Unreal, or Godot cover almost every project.
• The game loop — input → update → render — is the architectural spine; fixed-timestep simulation keeps physics deterministic.
• ECS trades inheritance for cache-friendly data layout when entity counts get large.
• Multiplayer is not a feature you bolt on; client prediction and server authority shape the whole codebase.
• Performance work is profiling-driven — CPU, GPU, and memory each have distinct failure modes.

The Frame Budget

Featured Topics

Engines

• Unity — The most widely used engine; C#, huge asset ecosystem, strong on mobile
• Unreal Engine — C++ and Blueprints, best-in-class rendering, the AAA default
• Godot — Open source, lightweight, GDScript and C#, excellent for 2D

Gameplay Architecture

• Game Loops & ECS — Fixed timesteps, interpolation, and entity-component-system design
• Game Physics — Rigid bodies, collision detection, and determinism
• Game AI — State machines, behavior trees, pathfinding, and utility AI

Graphics

• Shader Programming — Vertex and fragment shaders, the GPU pipeline, and render passes
• Procedural Generation — Noise, grammars, and seeded worlds

Multiplayer

• Multiplayer Netcode — Server authority, client prediction, rollback, and lag compensation

Common Questions

Which engine should I start with?

For a first project, Godot or Unity. Godot is small, free, open source, and has the shortest path from "empty project" to "something moves on screen" — especially in 2D. Unity has the largest tutorial and asset ecosystem, uses C#, and is the industry default for mobile and mid-size 3D games. Unreal has the strongest out-of-the-box rendering but a heavier toolchain and a C++ codebase; it pays off on visually ambitious 3D projects and less so on a solo 2D game. Choosing "wrong" costs far less than not shipping — every engine teaches the same fundamentals.

Do I need to write my own engine?

Almost certainly not, unless engine work is the goal. Writing an engine is a valuable education in systems programming, rendering, and memory management, but it is a different project from making a game, and it defers everything players see by months. The common exception is a small, tightly scoped 2D game built on a framework rather than an engine — libraries like SDL, raylib, or Bevy give you a loop and a renderer without the editor.

How much math do I need?

For 2D: vectors, basic trigonometry, and linear interpolation get you a long way. For 3D: add matrices, dot and cross products, and quaternions for rotation — you rarely derive them, but you need to know which operation you want and why gimbal lock happens. Shader work leans harder on vector math and interpolation. Most of it is learned on demand, driven by a specific problem, rather than up front.

What actually makes a game run slowly?

Different things on each processor, which is why profiling before optimizing matters more here than almost anywhere else. On the CPU: too many per-object updates, cache misses from pointer-chasing object graphs, and garbage collection pauses. On the GPU: too many draw calls, overdraw, expensive fragment shaders, and oversized textures. On memory: asset bloat and allocation churn during gameplay. A game that stutters and a game with a low average frame rate usually have completely different causes — frame-time graphs tell you which you have.

Is multiplayer hard to add later?

Yes, and this is the most common expensive mistake. Networked games need a clear authority model, deterministic or reconcilable simulation, and a separation between "state the server owns" and "state the client predicts." Retrofitting that onto a codebase that assumed one local player usually means rewriting the gameplay layer. If multiplayer is in scope, design for it from the first prototype. See Multiplayer Netcode.

Learning Path

Beginner

Build a complete, tiny game — Pong, Breakout, a one-screen platformer — in Godot or Unity. Finishing is the skill being practiced.

Intermediate

Learn the game loop and fixed timesteps, collision and physics, state machines for AI, and basic shaders. Ship something with a menu, save data, and an ending.

Advanced

ECS and data-oriented design, custom render passes, netcode with prediction and rollback, procedural generation, and platform-specific performance work.

Related Hubs

• Programming Languages — C++, C#, and Rust dominate game code
• Performance & Optimization — Profiling and frame-budget work
• Frontend Development — Three.js and WebGPU for browser games
• Algorithms & Data Structures — Pathfinding, spatial partitioning, and graph search