Production Game Engines

Modern engine architecture:

Modules:

• Core: math, memory, file I/O, threading.
• Renderer: 2D, 3D, postprocessing.
• Physics: 2D, 3D.
• Audio: 2D, 3D.
• Input: keyboard, mouse, gamepad, touch.
• Animation: skeletal, sprite.
• Asset pipeline: import + bake assets.
• Networking.
• Editor.
• Scripting.

Asset pipeline:

• Source assets: PNG, FBX, WAV.
• Baked assets: texture atlases, compressed audio, mesh formats.
• Loaded into runtime.
• Hot reload during development.

Editor:

• Visual scene editing.
• Inspector for components.
• Asset browser.
• Play mode in editor.
• Custom tooling.

Build pipeline:

• Compile code.
• Bake assets.
• Package per platform (Windows, macOS, Linux, console, mobile).
• Code signing.

Cross-platform:

• One codebase, many targets.
• Per-platform code: input, file paths, threading.
• Per-platform builds: x86, ARM, console-specific.

Performance:

• 60 FPS = 16.67 ms.
• AAA target: 30-60 FPS @ 4K, hundreds of thousands of triangles.
• Critical: efficient draw calls, asset streaming, multithreading.

Common engine choices for indies:

• Unity: 2D + 3D, easy curve, big asset store.
• Unreal: AAA visuals, blueprint scripting.
• Godot: free, lightweight, growing.
• GameMaker: 2D-focused, simple.
• Bevy: Rust-based ECS, no editor yet.
• Custom: full control, much more work.

When to roll your own:

• Highly specialized (custom physics, novel rendering).
• Constrained platform (homebrew, retro).
• Engine architecture is the goal (learning).

When NOT to:

• Shipping a game on time.
• Standard 2D/3D needs.
• Multi-platform.

For learning: build your own toy engine (~5000 LOC). Learn the architecture. Then ship games on Unity/Godot.

Build your own X is the better learning approach. Build a real game on a real engine to ship.