GAME DEVELOPMENT TO STEAM PUBLISHING

From Zero to Steam: Complete Game Development & Publishing Learning Path

This guide takes you from “I don’t know how to build a game” to “I published my game on Steam and understand what makes games successful.” Each project builds essential skills you’ll need for the next phase.

Understanding the Steam Ecosystem First

Before diving into projects, understand what you’re building toward:

Steam Publishing Requirements

$100 fee per game (recoupable after $1,000 revenue)
Tax documentation (SSN/EIN for US, TIN for international)
Banking information for revenue payments
30-day waiting period after paying before you can release
Store page must be live 2 weeks before launch
1-5 day review process by Valve

Why These Requirements Exist

$100 fee: Replaced the old “Greenlight” voting system. Prevents shovelware spam—under the old system, developers could upload unlimited free games, flooding the store with low-effort content
Tax/Banking: Valve pays you revenue (70% of sales), so they need legal entity verification
30-day wait: Gives Valve time to verify identity and catch fraudulent accounts
2-week store page requirement: Builds wishlist momentum and lets Steam’s algorithm show your game to interested players
Review process: Ensures game matches description and contains no malware

The Reality of Steam Success (2025 Data)

~20,000 games released on Steam in 2025
Only ~300 titles earned over $1 million
Indie games generated $4.5 billion (25% of Steam’s $17.7B revenue)
Top 5 indie games of 2025 earned $500M+ combined
Average Steam user plays only 4-5 games per year

Phase 1: Understanding How Games Work (Fundamentals)

Project 1: The Bare Game Loop

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, Rust, Zig
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 2: Intermediate
Knowledge Area: Game Architecture / Real-Time Systems
Software or Tool: SDL2
Main Book: “Game Programming Patterns” by Robert Nystrom

What you’ll build: A minimal game loop that opens a window, processes input, updates game state at a fixed timestep, and renders at variable FPS—displaying the actual FPS counter and demonstrating the difference between fixed and variable timesteps.

Why it teaches game development: Every game ever made runs on a loop. This is THE fundamental pattern. Without understanding this, you’re just copying tutorial code without knowing why it works.

Core challenges you’ll face:

Window creation and event handling → maps to platform abstraction (why engines exist)
Fixed vs variable timestep → maps to deterministic physics (why multiplayer games work)
Frame timing and deltaTime → maps to frame-rate independence (why games run on different hardware)
Input polling vs event-driven → maps to responsive controls (why some games feel “laggy”)
Double buffering → maps to tear-free rendering (why games don’t flicker)

Key Concepts:

The Game Loop Pattern: “Game Programming Patterns” Chapter 9 - Robert Nystrom
Fixed Timestep: “Fix Your Timestep!” by Glenn Fiedler - https://gafferongames.com/post/fix_your_timestep/
SDL2 Basics: “SDL Game Development” Chapter 2 - Shaun Mitchell
Frame Timing: “Computer Systems: A Programmer’s Perspective” Chapter 9 (Measuring Time) - Bryant & O’Hallaron

Difficulty: Beginner-Intermediate Time estimate: Weekend Prerequisites: Basic C programming, understanding of pointers

Real world outcome:

$ ./game_loop
Window opens (800x600)
FPS Counter displays: 60.0 FPS
Press arrow keys → see "Input: LEFT/RIGHT/UP/DOWN" printed
Hold SPACE → see game state update counter increment at exactly 60 updates/second
Notice: even if FPS drops, game logic stays at 60 updates/second
Press ESC → clean exit

Implementation Hints: The game loop has three phases that repeat forever: Process Input → Update → Render. The critical insight is separating simulation time from render time. Your physics should update at a fixed rate (e.g., 60Hz) regardless of how fast your GPU can render. This is achieved by accumulating deltaTime and consuming it in fixed chunks. SDL2 provides SDL_GetTicks() for timing and SDL_PollEvent() for input. The “double buffering” concept means you draw to a hidden buffer, then swap it with the visible one—this is why you call SDL_RenderPresent().

Learning milestones:

Window appears and closes cleanly → You understand platform event handling
FPS counter is accurate → You understand frame timing
Game updates at fixed rate despite variable FPS → You understand timestep decoupling

Project 2: Pixel Painter (Direct Framebuffer Access)

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, Rust, Zig
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 2: Intermediate
Knowledge Area: Graphics / Memory Layout
Software or Tool: SDL2 (Software Rendering)
Main Book: “Computer Graphics from Scratch” by Gabriel Gambetta

What you’ll build: A program that directly manipulates a pixel buffer to draw shapes—lines, circles, filled rectangles—without using any drawing library functions. You implement Bresenham’s line algorithm and midpoint circle algorithm yourself.

Why it teaches game development: Before you use DrawSprite(), you should understand that sprites are just arrays of colored pixels copied to a framebuffer. This demystifies graphics and helps you understand GPU concepts later.

Core challenges you’ll face:

Understanding pixel formats (RGBA, ARGB, etc.) → maps to texture formats
Implementing line drawing without floating point → maps to Bresenham’s algorithm
Implementing circle drawing → maps to midpoint algorithm
Alpha blending pixels manually → maps to transparency compositing
Understanding pitch/stride → maps to memory layout of images

Key Concepts:

Framebuffer Fundamentals: “Computer Graphics from Scratch” Chapter 1-2 - Gabriel Gambetta
Bresenham’s Algorithm: “Computer Graphics: Principles and Practice” Chapter 3 - Foley et al.
Pixel Formats: “SDL Game Development” Chapter 4 - Shaun Mitchell
Memory Layout: “Computer Systems: A Programmer’s Perspective” Chapter 6 - Bryant & O’Hallaron

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Project 1 (Game Loop), basic math

Real world outcome:

$ ./pixel_painter
Window shows:
- Red line drawn from (0,0) to (400,300) using YOUR Bresenham implementation
- Blue circle at center with radius 100 using YOUR midpoint algorithm
- Green filled rectangle
- Semi-transparent purple overlay demonstrating alpha blending
Move mouse → draws pixels at cursor position
See actual memory addresses being written to in debug output

Implementation Hints: SDL2’s SDL_LockTexture() gives you a raw pointer to pixel memory. Pixels are stored linearly, so position (x, y) is at pixels[y * pitch + x * bytes_per_pixel]. Bresenham’s algorithm avoids floating point by using an “error” term that accumulates and decides when to step in the minor axis. For alpha blending, the formula is: result = (src * alpha + dst * (255 - alpha)) / 255. Understanding “pitch” is crucial—it’s the number of bytes per row, which may be larger than width * bytes_per_pixel due to memory alignment.

Learning milestones:

Can set individual pixels by coordinates → You understand framebuffer addressing
Lines draw correctly at all angles → You understand Bresenham’s algorithm
Transparency works → You understand alpha compositing

Phase 2: Making Things Move and Respond

Project 3: Input System Architecture

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, Rust, GDScript
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 2: Intermediate
Knowledge Area: Input Systems / Event Handling
Software or Tool: SDL2
Main Book: “Game Programming Patterns” by Robert Nystrom

What you’ll build: A complete input system that tracks key states (just pressed, held, just released), handles keyboard remapping, supports gamepad input, and implements an input buffer (like fighting games use for combo detection).

Why it teaches game development: “Why does my character keep jumping?” is usually an input bug. Understanding the difference between key events and key states is essential. Input buffering is why fighting games feel responsive.

Core challenges you’ll face:

Distinguishing “pressed” vs “held” vs “released” → maps to edge detection
Building input abstraction (actions, not keys) → maps to rebindable controls
Input buffering for combos → maps to fighting game input systems
Handling multiple input devices → maps to controller support
Polling vs event-driven input → maps to input latency

Key Concepts:

Input Abstraction: “Game Engine Architecture” Chapter 8 - Jason Gregory
State Tracking: “Game Programming Patterns” Chapter 10 (Command) - Robert Nystrom
Input Buffering: “Why are fighting game inputs SO hard?” by Core-A Gaming (YouTube)
Gamepad Handling: SDL2 Game Controller API documentation

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Project 1 (Game Loop)

Real world outcome:

$ ./input_system
On-screen display shows:
  SPACE: [  RELEASED  ] → Press → [ JUST_PRESSED ] → Hold → [   HELD   ] → Release → [ JUST_RELEASED ]

Rebinding test:
  Press R to rebind "Jump" → Press any key → "Jump" now bound to [your key]

Input buffer visualization:
  [→][→][↓][↘][PUNCH] = HADOKEN detected!
  Buffer shows last 10 inputs with timestamps

Plug in gamepad → automatically detected and working

Implementation Hints: Track TWO arrays: current_keys[] and previous_keys[]. At the start of each frame, copy current to previous, then update current. “Just pressed” = current && !previous. “Just released” = !current && previous. For input buffering, store a ring buffer of {action, timestamp} pairs and check for sequences within a time window. Abstract “Jump” from “Spacebar” by having an action-to-key mapping that players can change.

Learning milestones:

Edge detection works (just pressed/released) → You understand state differencing
Controls are rebindable → You understand input abstraction
Combo detection works → You understand input buffering

Project 4: 2D Physics Engine (AABB Collision)

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, Rust, Zig
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 3: Advanced
Knowledge Area: Physics / Collision Detection
Software or Tool: Custom Engine
Main Book: “Game Physics Engine Development” by Ian Millington

What you’ll build: A 2D physics engine that handles axis-aligned bounding box (AABB) collision detection, collision resolution, gravity, friction, and basic rigidbody dynamics. Visualize collision boxes, velocity vectors, and contact points.

Why it teaches game development: Every platformer, every action game, every physics puzzle uses this. Understanding collision detection and response is non-negotiable. You’ll finally understand why characters sometimes clip through walls.

Core challenges you’ll face:

AABB intersection testing → maps to broad phase collision
Swept collision (tunneling prevention) → maps to fast-moving objects
Collision response (push-out) → maps to physics resolution
Continuous vs discrete collision → maps to frame-rate independence
Spatial partitioning → maps to performance optimization

Key Concepts:

AABB Collision: “Real-Time Collision Detection” Chapter 4 - Christer Ericson
Swept AABB: “Swept AABB Collision Detection and Response” - GameDev.net tutorial
Physics Integration: “Game Physics Engine Development” Chapter 3 - Ian Millington
Spatial Hashing: “Real-Time Collision Detection” Chapter 7 - Christer Ericson

Difficulty: Intermediate-Advanced Time estimate: 2 weeks Prerequisites: Projects 1-3, basic linear algebra (vectors)

Real world outcome:

$ ./physics_engine
Sandbox mode:
- Spawn boxes with mouse click
- Boxes fall with gravity
- Boxes stack on the ground and each other
- Boxes push each other when overlapping
- Toggle debug view: see AABBs, velocity vectors, contact normals

Stress test:
- Spawn 100 boxes
- Watch them settle into stable piles
- FPS stays above 60 with spatial hashing enabled
- Toggle spatial hashing off → watch FPS drop to show the optimization

Tunneling demo:
- Shoot a box at high velocity
- Without swept collision: passes through walls
- With swept collision: stops at wall correctly

Implementation Hints: AABB overlap test: two boxes overlap if and only if they overlap on BOTH axes. For axis X: !(a.max.x < b.min.x || a.min.x > b.max.x). Collision response: find the smallest penetration axis and push the object out along that axis (this is the “minimum translation vector”). For swept collision, you’re finding the time t where the moving box first touches the static box. Spatial hashing: divide space into a grid, only check collisions between objects in the same or adjacent cells.

Learning milestones:

Boxes detect overlap correctly → You understand AABB math
Boxes push each other out without jittering → You understand collision response
Fast objects don’t tunnel through walls → You understand swept collision
100+ objects perform well → You understand spatial partitioning

Project 5: Player Controller State Machine

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, GDScript, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 2: Intermediate
Knowledge Area: Game Logic / State Machines
Software or Tool: Custom Engine or Godot
Main Book: “Game Programming Patterns” by Robert Nystrom

What you’ll build: A platformer character controller using a finite state machine (FSM). States include: Idle, Walking, Running, Jumping, Falling, WallSliding, Dashing, Attacking. Each state has entry/exit actions, update logic, and valid transitions.

Why it teaches game development: “Why can my character attack while jumping?” Because you didn’t use a state machine. FSMs prevent impossible state combinations and make complex character behavior manageable.

Core challenges you’ll face:

State encapsulation → maps to clean separation of behaviors
Transition conditions → maps to game feel tuning
State entry/exit actions → maps to animation triggers
Coyote time / input buffering → maps to forgiving platformer controls
Hierarchical states → maps to complex character behavior

Key Concepts:

State Pattern: “Game Programming Patterns” Chapter 6 - Robert Nystrom
Pushdown Automata: “Game Programming Patterns” Chapter 6 (FSM extensions) - Robert Nystrom
Platformer Feel: “Platformer Toolkit” by Mark Brown (Game Maker’s Toolkit)
Coyote Time: “Celeste & Forgiveness” by Mark Brown (Game Maker’s Toolkit)

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Projects 3-4 (Input, Physics)

Real world outcome:

$ ./player_controller
State debugger shows current state: [IDLE]

Controls:
- Arrow keys to move → [WALKING]
- Hold shift → [RUNNING]
- Press SPACE → [JUMPING] → apex → [FALLING]
- Walk off ledge → [FALLING] (not jumping!)
- Jump within 0.1s of leaving ledge → "Coyote time" jump works
- Near wall while falling → [WALL_SLIDING]
- Jump from wall → [WALL_JUMPING]
- Press DASH → [DASHING] (can't change direction mid-dash)

State visualization:
- Current state highlighted in a state diagram
- Arrows show valid transitions
- Invalid inputs are visually rejected

Implementation Hints: Each state is a struct/class with enter(), update(), exit(), and handle_input() methods. The controller holds a current_state pointer and delegates all calls to it. Transitions happen by setting a next_state, which triggers exit() on current and enter() on next. For “coyote time,” track a time_since_grounded timer; allow jumping if it’s < 0.1s even when in FALLING state. For input buffering, remember jump presses for 0.1s; if you land within that window, jump immediately.

Learning milestones:

Character can’t jump while already jumping → You understand state exclusivity
Coyote time feels natural → You understand forgiving input windows
Adding a new state (e.g., “Crouch”) is easy → You understand state machine architecture

Phase 3: Building Complete (Simple) Games

Project 6: Pong Clone

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: Lua (LÖVE2D), GDScript, Python (Pygame)
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 1: Beginner
Knowledge Area: Game Development / Complete Game Loop
Software or Tool: SDL2 or LÖVE2D
Main Book: “Game Programming Patterns” by Robert Nystrom

What you’ll build: A complete Pong game with title screen, gameplay, scoring, win condition, game over screen, and restart functionality. Add AI opponent with adjustable difficulty.

Why it teaches game development: Pong is the “Hello World” of games. It’s simple enough to complete but requires all the fundamentals: game loop, input, physics, collision, game states, scoring, and UI.

Core challenges you’ll face:

Complete game flow (menus → gameplay → game over) → maps to game state management
Ball physics (angle reflection) → maps to physics response
AI opponent → maps to basic game AI
Scoring and win conditions → maps to game rules implementation
Sound effects → maps to audio integration

Key Concepts:

Game State Stack: “Game Programming Patterns” Chapter 6 - Robert Nystrom
Ball Physics: Basic vector reflection: new_velocity = velocity - 2 * dot(velocity, normal) * normal
Simple AI: Track ball Y position, move paddle toward it with adjustable speed/reaction time

Difficulty: Beginner Time estimate: Weekend Prerequisites: Projects 1-4

Real world outcome:

$ ./pong
Title screen: "PONG" with "Press ENTER to start" and "Press ESC to quit"
Select difficulty: Easy / Medium / Hard

Gameplay:
- Two paddles, one ball
- Ball bounces off walls and paddles
- Score displayed: "Player: 3  |  AI: 2"
- First to 5 wins
- Sound effects on hit, score, win

Game Over:
- "YOU WIN!" or "YOU LOSE!"
- "Press ENTER to play again"

Implementation Hints: Use a state stack or enum for game states: TITLE, PLAYING, GAME_OVER. The ball’s angle should change based on where it hits the paddle—hitting the edge gives a sharper angle than hitting the center. For AI, have it move toward the ball’s Y position but with a maximum speed and optional reaction delay (don’t start moving until ball crosses midfield).

Learning milestones:

Game flows from menu to gameplay to game over → You understand game states
Ball physics feel right → You understand collision response
AI provides challenge without cheating → You understand basic AI

Project 7: Breakout Clone

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: Lua (LÖVE2D), GDScript, JavaScript
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 1: Beginner
Knowledge Area: Game Development / Level Design
Software or Tool: SDL2 or LÖVE2D
Main Book: “Game Programming Patterns” by Robert Nystrom

What you’ll build: A Breakout/Arkanoid clone with multiple levels, power-ups (multi-ball, paddle size, speed), brick types (different hit points), and a level editor.

Why it teaches game development: Breakout adds brick grid management, power-up systems, and level data—three things every larger game needs. The level editor teaches you about data-driven design.

Core challenges you’ll face:

Brick grid data structure → maps to tilemap systems
Power-up spawning and effects → maps to item systems
Multiple ball instances → maps to entity management
Level loading/saving → maps to data serialization
Level editor → maps to tool development

Key Concepts:

Component Pattern: “Game Programming Patterns” Chapter 14 - Robert Nystrom
Data-Driven Design: “Game Engine Architecture” Chapter 15 - Jason Gregory
Level Serialization: JSON or simple text formats for level data

Difficulty: Beginner-Intermediate Time estimate: 1 week Prerequisites: Project 6 (Pong)

Real world outcome:

$ ./breakout
Main menu with "Play", "Editor", "Quit"

Gameplay:
- 10+ levels with increasing difficulty
- Different brick colors = different HP (grey=1, blue=2, gold=3)
- Power-ups drop from bricks:
  - Green "M" = multi-ball (split into 3)
  - Red "L" = larger paddle
  - Blue "S" = slow ball
- Lives counter, score, level number displayed
- Boss brick that takes 10 hits on level 10

Level Editor:
- Click to place/remove bricks
- Select brick type from palette
- Save/Load levels as files
- Test level immediately

Implementation Hints: Store levels as 2D arrays or simple text files where each character represents a brick type. Power-ups are entities that fall and are collected on paddle collision. For multi-ball, maintain a list of balls and update/render all of them—remove balls that go off-screen. The level editor is just the game running in “edit mode” where clicks modify the level data instead of playing.

Learning milestones:

Multiple levels load and play → You understand level data
Power-ups work correctly → You understand entity/item systems
Level editor creates playable levels → You understand data-driven design

Project 8: Platformer with Complete Mechanics

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: GDScript (Godot), C# (Unity), Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool” (Solo-Preneur Potential)
Difficulty: Level 3: Advanced
Knowledge Area: Game Development / Complete Game Systems
Software or Tool: Godot 4 or SDL2
Main Book: “Game Feel” by Steve Swink

What you’ll build: A 2D platformer with: player movement (variable jump height, coyote time, wall jump), enemies with AI, hazards, collectibles, checkpoints, multiple levels, tilemap-based level design, and basic particle effects.

Why it teaches game development: Platformers require mastery of all core systems: physics, player control, AI, level design, game feel. This is the last “practice” game before you start building something publishable.

Core challenges you’ll face:

Tight, responsive controls → maps to game feel tuning
Tilemap collision → maps to level collision systems
Enemy AI (patrol, chase, attack) → maps to behavior trees/FSM for AI
Checkpoint/respawn system → maps to game state persistence
Particle effects → maps to visual feedback systems

Key Concepts:

Game Feel: “Game Feel: A Game Designer’s Guide to Virtual Sensation” - Steve Swink
Tilemap Collision: “Real-Time Collision Detection” Chapter 4 - Christer Ericson
Enemy AI: “AI for Games” Chapter 5 - Ian Millington
Juice/Polish: “Juice it or lose it” by Martin Jonasson (GDC talk)

Difficulty: Intermediate-Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-7

Real world outcome:

$ ./platformer
Title screen with "New Game", "Continue", "Quit"

Gameplay:
- 5 handcrafted levels
- Responsive controls: variable jump height, coyote time, wall jump
- 3 enemy types: Walker (patrols), Flyer (follows), Shooter (ranged)
- Hazards: spikes, moving platforms, falling blocks
- Collectibles: coins for score, keys for locked doors
- Checkpoints that save progress
- Death respawns at last checkpoint with particle effect
- Basic sound effects for all actions

Polish:
- Screen shake on landing/damage
- Particle effects: dust on jump/land, sparks on wall slide
- Camera follows player smoothly with look-ahead

Implementation Hints: For tilemap collision, convert player position to tile coordinates, check adjacent tiles for solidity, and resolve collisions one axis at a time. Variable jump height: apply gravity, but let players “cut” their jump by releasing the button early (reduce Y velocity when released). For enemy patrol AI, move toward waypoints and reverse at walls/edges. Camera look-ahead: offset camera in the direction of player velocity.

Learning milestones:

Controls feel as good as commercial platformers → You understand game feel
Enemies behave predictably and fairly → You understand game AI
Levels are fun to navigate → You understand level design basics

Phase 4: Production-Ready Features

Project 9: Save System Architecture

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, GDScript, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Data Persistence / Serialization
Software or Tool: Custom Engine or Godot
Main Book: “Game Engine Architecture” by Jason Gregory

What you’ll build: A robust save system with versioned save files, migration for old saves, autosave, multiple save slots, save file validation (detecting corruption), and Steam Cloud integration readiness.

Why it teaches game development: Nothing frustrates players more than lost progress. A proper save system handles edge cases: what if the game crashes mid-save? What if you add new game content and old saves are incompatible?

Core challenges you’ll face:

Serialization format choice (JSON, binary, custom) → maps to data format tradeoffs
Version migration → maps to backward compatibility
Atomic saves (crash safety) → maps to file system operations
Save file validation → maps to data integrity
Steam Cloud compatibility → maps to platform requirements

Key Concepts:

Serialization: “Game Engine Architecture” Chapter 15 - Jason Gregory
Atomic File Operations: Write to temp file, then rename (rename is atomic on most filesystems)
Steam Cloud: Steamworks documentation on Cloud saves - automatic sync of specified paths
Save Versioning: Include version number in save, write migration functions for each version

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Any complete game project

Real world outcome:

$ ./save_system_demo
Save Menu:
  Slot 1: [Level 5, 1234 coins, 02:15:30 playtime, Saved: 2025-01-15]
  Slot 2: [Level 3, 567 coins, 00:45:12 playtime, Saved: 2025-01-14]
  Slot 3: [Empty]

Actions:
- Save to any slot → instant, no freeze
- Load any slot → restores all game state
- Autosave every 5 minutes (configurable)
- Corrupt a save file manually → game detects and offers recovery
- Old save from version 1.0 → automatically migrated to current format

Test atomic save:
- Kill process during save → file is not corrupted (temp file approach)
- Power cycle simulation → either old save or new save exists, never partial

Steam Cloud ready:
- Save files in correct location: %APPDATA%/YourGame/saves/ (Windows)
- File format is platform-independent (no endianness issues)

Implementation Hints: Use JSON for human-readable saves during development, consider binary for release (smaller, faster, harder to cheat). Always save to a temporary file first, then rename to the actual filename—this way, a crash mid-write only corrupts the temp file. Store a version number at the start of each save; when loading, check the version and run migration functions if needed. For Steam Cloud, just save to the right directory—Steam handles sync automatically if you configure the paths in Steamworks.

Learning milestones:

Saves and loads work perfectly → You understand serialization
Old saves migrate automatically → You understand versioning
Crash during save doesn’t corrupt data → You understand atomic operations

Project 10: Audio Engine Integration

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, GDScript, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
Difficulty: Level 2: Intermediate
Knowledge Area: Audio / Real-Time Systems
Software or Tool: SDL_mixer, FMOD, or miniaudio
Main Book: “Game Audio Programming” by Guy Somberg

What you’ll build: An audio system with sound effects (with variations), music playback, volume controls, audio ducking (lowering music during important sounds), spatial audio (left/right panning based on position), and audio pooling for performance.

Why it teaches game development: Audio is 50% of game feel. A gunshot that sounds weak ruins a game. Understanding audio mixing, prioritization, and spatialization elevates your games.

Core challenges you’ll face:

Audio format loading (WAV, OGG, MP3) → maps to codec support
Multiple simultaneous sounds → maps to channel management
Sound variation (pitch/volume randomization) → maps to audio design
Spatial panning → maps to positional audio
Audio ducking and priority → maps to mix management

Key Concepts:

Audio Fundamentals: “Game Audio Programming” Chapters 1-3 - Guy Somberg
Spatial Audio: Pan based on entity position relative to camera
Audio Pools: Pre-allocate channels, reuse rather than creating/destroying
Ducking: Lower music volume when important sounds play

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Any game project, basic understanding of audio concepts

Real world outcome:

$ ./audio_demo
Audio Settings Panel:
  Master Volume: [====|====] 80%
  Music Volume:  [==|======] 40%
  SFX Volume:    [======|==] 90%

Spatial Audio Demo:
- Enemy on left → gunshot pans left
- Enemy on right → gunshot pans right
- Far enemy → sound is quieter

Sound Variation Demo:
- Click to shoot → each shot sounds slightly different (pitch/volume variation)
- No "machine gun effect" from identical sounds

Ducking Demo:
- Music playing at normal volume
- Important dialogue plays → music ducks to 20%
- Dialogue ends → music fades back up

Performance:
- Stress test: 50 simultaneous sounds
- Audio pool shows: 32 channels active, 18 queued

Implementation Hints: Use SDL_mixer or miniaudio for cross-platform audio. Pre-load all sound effects at game start; don’t load during gameplay. For sound variation, store base sounds and apply random pitch (±5%) and volume (±10%) on each play. Spatial panning: pan = clamp((entity.x - camera.x) / screen_width, -1, 1). For ducking, maintain a music volume target and interpolate toward it over ~0.5 seconds.

Learning milestones:

Sound effects play without latency → You understand audio loading
Sounds vary naturally → You understand audio design
Multiple sounds don’t clip/distort → You understand audio mixing

Project 11: UI System from Scratch

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C
Alternative Programming Languages: C++, GDScript, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: User Interface / Layout Systems
Software or Tool: Custom Engine
Main Book: “Game Engine Architecture” by Jason Gregory

What you’ll build: An immediate-mode UI system (like Dear ImGui) with buttons, sliders, text input, scrollable containers, layout (horizontal/vertical stacking), and keyboard/gamepad navigation.

Why it teaches game development: Every game needs menus, options, inventory screens. Understanding UI systems helps you build them, debug them, and know when to use existing solutions.

Core challenges you’ll face:

Immediate-mode vs retained-mode UI → maps to UI architecture choices
Hit testing (which element is clicked) → maps to input routing
Layout algorithms → maps to constraint solving
Focus and navigation → maps to accessibility
Styling and theming → maps to data-driven UI

Key Concepts:

Immediate-Mode GUI: “Immediate-Mode Graphical User Interfaces” by Casey Muratori (video)
Layout: Flexbox-style algorithms—available space distributed among children
Navigation: Track “focused” element, arrow keys move focus in layout order
Styling: Separate style (colors, fonts, sizes) from structure

Difficulty: Intermediate-Advanced Time estimate: 2 weeks Prerequisites: Projects 1-3 (rendering, input)

Real world outcome:

$ ./ui_demo
Demo screen shows:
- Buttons (hover highlight, click feedback)
- Sliders (drag to adjust, keyboard arrows work)
- Text input (cursor, selection, copy/paste)
- Checkboxes and radio buttons
- Scrollable list with 100 items (smooth scroll, scrollbar)
- Nested containers (horizontal inside vertical)

Navigation test:
- Tab cycles through elements
- Arrow keys move logically
- Enter/Space activates buttons
- Controller D-pad navigates, A selects

Theme switcher:
- Light theme / Dark theme / Custom
- All elements update immediately

Implementation Hints: Immediate-mode UI means you “call” UI elements every frame: if (button("Click me")) { do_something(); }. The button function both renders the button AND returns true if clicked. Track a “hot” element (mouse is over) and “active” element (mouse is down on). For layout, use a stack-based approach: push a container, add children, pop container—the container figures out child positions. For keyboard nav, assign each element an ID and track which ID is focused.

Learning milestones:

Buttons, sliders work with mouse → You understand immediate-mode UI
Keyboard navigation works → You understand focus systems
Layouts work with variable content → You understand layout algorithms

Phase 5: Steam Integration (Steamworks SDK)

Project 12: Steamworks SDK Basics

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C++
Alternative Programming Languages: C# (via Steamworks.NET), GDScript (via GodotSteam), Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 2: Intermediate
Knowledge Area: Platform Integration / SDK Usage
Software or Tool: Steamworks SDK
Main Book: Steamworks Official Documentation

What you’ll build: Integrate the Steamworks SDK into a game to display the Steam overlay, get the current player’s Steam name, and verify the game is running through Steam.

Why it teaches Steam publishing: This is the bare minimum for a Steam release. Without Steam API initialization, your game won’t be recognized as a Steam game—no overlay, no achievements, no cloud saves.

Core challenges you’ll face:

SDK initialization and shutdown → maps to lifecycle management
Steam App ID handling → maps to build configuration
Overlay activation → maps to platform feature integration
Error handling for Steam not running → maps to graceful degradation

Key Concepts:

Steam Initialization: Call SteamAPI_Init() on startup, check return value
App ID: Create steam_appid.txt for development, real App ID from Steamworks partner portal
Overlay: Shift+Tab opens overlay if game is focused and fullscreen
Callbacks: Steam uses a callback system for async events

Difficulty: Intermediate Time estimate: 2-3 days Prerequisites: A working game in C++ or C# (Unity) or GDScript (Godot)

Real world outcome:

$ ./steam_basics
[STEAM] Initializing Steamworks SDK...
[STEAM] Steam running: YES
[STEAM] App ID: 480 (test app) or your actual App ID
[STEAM] Logged in as: YourSteamName
[STEAM] Steam Overlay available: YES

In-game:
- Press Shift+Tab → Steam overlay appears
- Game displays "Welcome, [SteamName]!"
- If Steam not running: "Please launch through Steam" and graceful exit

Build without Steam (development mode):
- Game runs without Steam for local testing
- Steam features disabled with warning

Implementation Hints: Download the Steamworks SDK from partner.steamgames.com. For development, create a file steam_appid.txt with just 480 (Spacewar test app). Call SteamAPI_Init() early in main(). Call SteamAPI_RunCallbacks() in your game loop to process Steam events. For Godot, use the GodotSteam plugin. For Unity, use Steamworks.NET. If SteamAPI_Init() returns false, Steam isn’t running—show an error or run in offline mode.

Learning milestones:

Game launches and shows Steam overlay → You understand SDK basics
Player’s Steam name displays correctly → You understand Steam identity
Game handles “Steam not running” gracefully → You understand error handling

Project 13: Steam Achievements and Stats

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C++
Alternative Programming Languages: C# (via Steamworks.NET), GDScript (via GodotSteam), Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Platform Integration / Progression Systems
Software or Tool: Steamworks SDK
Main Book: Steamworks Official Documentation (Step by Step: Achievements)

What you’ll build: A complete achievements and stats system: define achievements in Steamworks, unlock them from game code, track stats (kills, playtime, etc.), and handle the Steam notification popup.

Why it teaches Steam publishing: Achievements drive player engagement and completion rates. They’re also one of the first things reviewers check—”no achievements” is seen as lack of polish.

Core challenges you’ll face:

Defining achievements in Steamworks portal → maps to backend configuration
Unlocking achievements from code → maps to event triggering
Tracking stats (incremental progress) → maps to stat accumulation
Achievement icons and names → maps to content pipeline
Testing achievements without publishing → maps to development workflow

Key Concepts:

Achievement API: SteamUserStats()->SetAchievement("ACH_NAME") then StoreStats()
Stats API: SteamUserStats()->SetStat("stat_name", value) for tracking progress
Request Stats First: Must call RequestCurrentStats() and wait for callback before setting
Testing: Use Steamworks steam_appid.txt and the “Reset All Stats” button in Steam client

Difficulty: Intermediate Time estimate: 3-4 days Prerequisites: Project 12 (SDK Basics)

Real world outcome:

$ ./achievements_demo
[STEAM] Requesting stats...
[STEAM] Stats received. Current data:
  - Enemies killed: 42
  - Games completed: 3
  - Achievement "First Blood": UNLOCKED
  - Achievement "Completionist": LOCKED (3/10 games)

Gameplay:
- Kill enemy → "Enemies killed" increments
- Kill 10 enemies → Achievement notification pops up!
- Complete game → progress toward "Complete 10 games" achievement
- Achievement notification slides in from corner with icon

Debug overlay:
- Show all achievements (locked/unlocked)
- Button to reset all achievements for testing
- Live stat display

Implementation Hints: First, create achievements in the Steamworks partner portal with API names (e.g., ACH_FIRST_BLOOD), display names, and icons (unlocked + locked versions). In code, call RequestCurrentStats() on startup and wait for UserStatsReceived_t callback. To unlock: SetAchievement("ACH_NAME") then StoreStats(). For stat-based achievements (kill 100 enemies), increment the stat with SetStat(), then check if threshold is met and unlock. Steam handles the popup notification automatically.

Learning milestones:

Achievement unlocks and shows notification → You understand Steam events
Stats persist across game sessions → You understand Steam stat storage
Progress achievements work (10/100 kills) → You understand incremental achievements

Project 14: Steam Cloud Saves

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C++
Alternative Programming Languages: C# (via Steamworks.NET), GDScript (via GodotSteam), Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Platform Integration / Data Sync
Software or Tool: Steamworks SDK
Main Book: Steamworks Official Documentation (Steam Cloud)

What you’ll build: Configure Steam Cloud to automatically sync save files, handle sync conflicts, and provide manual save/load with Steam Cloud API.

Why it teaches Steam publishing: Players expect their progress to follow them across devices. Steam Cloud is free and relatively easy—not using it is leaving value on the table.

Core challenges you’ll face:

Configuring Cloud paths in Steamworks → maps to backend setup
Auto Cloud vs manual API → maps to sync strategy
Conflict resolution → maps to data merging
Quota management → maps to storage limits
Testing cloud sync → maps to multi-device testing

Key Concepts:

Auto-Cloud: Specify folder paths in Steamworks, Steam syncs automatically
Manual API: SteamRemoteStorage()->FileWrite() and FileRead() for explicit control
Conflict Detection: Check ISteamRemoteStorage::GetSyncPlatforms() and timestamps
Quota: Each game gets limited cloud storage (check your quota in Steamworks)

Difficulty: Intermediate Time estimate: 2-3 days Prerequisites: Project 9 (Save System), Project 12 (SDK Basics)

Real world outcome:

Computer A:
$ ./cloud_save_demo
- Play game, reach level 5
- Save game → file written to %APPDATA%/YourGame/save.dat
- Steam Cloud icon shows: "Syncing..."
- Exit game

Computer B (same Steam account):
$ ./cloud_save_demo
- Game shows: "Cloud save found (Level 5). Load?"
- Load → at level 5!

Conflict scenario:
- Play on Computer A offline, reach level 7
- Play on Computer B offline, reach level 6
- Go online on Computer A first → syncs level 7
- Go online on Computer B → "Conflict detected"
  - Local: Level 6 (newer timestamp)
  - Cloud: Level 7 (more progress)
  - "Which would you like to keep?"

Implementation Hints: The easiest approach: configure Auto-Cloud in Steamworks with your save folder path (e.g., saves/*). Steam automatically uploads when game exits and downloads when game starts. For conflict resolution, track both timestamp and meaningful progress (level reached, playtime). Let the player choose, but default to whichever represents more progress. For manual control, use FileWrite() immediately after saving to force upload.

Learning milestones:

Saves sync automatically between devices → You understand Auto-Cloud
Conflicts are detected and resolvable → You understand sync issues
Players don’t lose progress → You understand the user experience

Project 15: Steam Leaderboards

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C++
Alternative Programming Languages: C# (via Steamworks.NET), GDScript (via GodotSteam), Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool” (Solo-Preneur Potential)
Difficulty: Level 2: Intermediate
Knowledge Area: Platform Integration / Competitive Systems
Software or Tool: Steamworks SDK
Main Book: Steamworks Official Documentation (Step by Step: Leaderboards)

What you’ll build: Integrate Steam leaderboards to upload scores, display global and friend rankings, and show rank around the current player.

Why it teaches Steam publishing: Leaderboards add replay value and social competition. They’re especially valuable for arcade-style games and speedrunners.

Core challenges you’ll face:

Creating leaderboards in Steamworks portal → maps to backend config
Uploading scores → maps to async API calls
Downloading entries (global, friends, around user) → maps to data fetching
Displaying leaderboards in-game → maps to UI integration
Score validation (preventing cheating) → maps to security considerations

Key Concepts:

Leaderboard Types: Global, Friends Only, Around User
Score Types: Ascending (lower is better, e.g., time) or Descending (higher is better)
Upload Method: Keep Best (only update if better) or Force Update (always replace)
Attached Data: Can attach extra data to scores (e.g., replay ghost data)

Difficulty: Intermediate Time estimate: 2-3 days Prerequisites: Project 12 (SDK Basics)

Real world outcome:

$ ./leaderboards_demo
Game Over screen:
- Your Score: 12,450
- "New Personal Best!" (if applicable)
- "Uploading to Steam..."
- "You are ranked #847 globally!"

Leaderboard View:
[Global Rankings - Speedrun Time]
#1  FastPlayer     00:45.123
#2  SpeedDemon     00:47.891
#3  QuickFingers   00:52.456
...
#845 SomePlayer    05:12.789
#846 AnotherOne    05:13.001
#847 YOU           05:15.234  ← highlighted
#848 NextPlayer    05:16.567
...

Tabs: [Global] [Friends] [Around Me]

Friends view shows only Steam friends
Around Me shows ±10 ranks from your position

Implementation Hints: First, create the leaderboard in Steamworks portal with a unique name (e.g., highscores_level1), sort method (ascending/descending), and display type (numeric, time, money). In code, find the leaderboard with FindLeaderboard() (async), then upload with UploadLeaderboardScore(). To download, use DownloadLeaderboardEntries() with different request types (Global, GlobalAroundUser, Friends). Parse the results in the callback and display in your UI.

Learning milestones:

Scores upload and appear on leaderboard → You understand score upload
Can view global, friends, and nearby rankings → You understand entry fetching
UI looks polished and updates live → You understand async UI updates

Phase 6: The Publishing Process

Project 16: Steam Store Page Builder

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: N/A (Marketing/Design)
Alternative Programming Languages: N/A
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 5. The “Industry Disruptor” (affects all your future games)
Difficulty: Level 2: Intermediate
Knowledge Area: Marketing / Store Optimization
Software or Tool: Steamworks Partner Portal, Photoshop/GIMP, Video Editor
Main Book: “How to Market a Game” by Chris Zukowski (blog)

What you’ll build: A complete Steam store page: capsule images (all required sizes), screenshots (5 minimum), trailer video, game description, system requirements, and tags.

Why it teaches Steam publishing: Your store page is your #1 marketing tool. Steam’s algorithm shows your capsule image to potential players—if it doesn’t grab attention in 1 second, you’ve lost them.

Core challenges you’ll face:

Capsule image design (multiple sizes) → maps to visual marketing
Screenshot selection and ordering → maps to feature communication
Trailer editing (hook within 3 seconds) → maps to video marketing
Description copywriting → maps to conversion optimization
Tag selection → maps to discoverability

Key Concepts:

Steam Capsule Sizes:
- Header Capsule: 460x215
- Small Capsule: 231x87
- Large Capsule: 467x181
- Library Capsule: 600x900
- Hero Capsule: 1920x620
Screenshot Rules: No logos/text, actual gameplay, 1920x1080 minimum
“Above the Fold”: First 300 characters of description are shown without scrolling

Difficulty: Intermediate (different skillset—design, not code) Time estimate: 1-2 weeks Prerequisites: A game to market

Real world outcome:

Your Steam Store Page:
- Capsule shows instantly readable game title with compelling art
- 5+ screenshots showing diverse gameplay moments
- 60-second trailer that hooks in first 3 seconds
- Description: "Feature bullets" at top, story/lore lower
- Tags accurately reflect genre (appears in relevant searches)
- System requirements are accurate (players can actually run it)

A/B test thinking:
- Which capsule version performs better?
- Which screenshot order converts more wishlists?

Verification:
- All images pass Steam's upload validation
- Preview mode shows page correctly
- Coming Soon page is live and collecting wishlists

Implementation Hints: Study successful games in your genre. Your capsule image must be readable at small sizes—avoid tiny text or cluttered designs. For trailers, show gameplay immediately (not logos). Front-load your best screenshots. In the description, lead with what makes your game unique, not generic “In a world where…” storytelling. Choose 5 most accurate tags; the first tag should be your primary genre.

Learning milestones:

All required images uploaded and approved → You understand Steam’s requirements
Store page looks professional → You understand visual marketing
Wishlists are coming in → You understand conversion

Project 17: Steam Build Pipeline

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: Bash/PowerShell (scripting)
Alternative Programming Languages: Python, N/A
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: DevOps / Release Engineering
Software or Tool: Steamworks SDK ContentBuilder
Main Book: Steamworks Documentation (Uploading to Steam)

What you’ll build: An automated build pipeline that compiles your game, packages it, uploads to Steam via SteamCMD/ContentBuilder, and sets the build live on a test branch.

Why it teaches Steam publishing: Manual uploads are error-prone and slow. A proper pipeline lets you ship updates confidently and frequently.

Core challenges you’ll face:

ContentBuilder configuration (app_build VDF) → maps to Steam’s build system
Depot organization → maps to platform-specific content
Branch management (default, beta, testing) → maps to staged releases
Automating uploads → maps to CI/CD concepts
Build verification → maps to QA automation

Key Concepts:

App: Your game as a whole
Depot: A collection of files (often one per platform: Windows, Mac, Linux)
Branch: A version of the game (default, beta, etc.)
VDF Files: Valve Data Format—configuration files for builds

Difficulty: Intermediate Time estimate: 3-4 days Prerequisites: Project 12 (SDK Basics), basic scripting

Real world outcome:

$ ./build_and_upload.sh
[BUILD] Compiling game...
[BUILD] Compilation successful
[BUILD] Copying to staging/
[BUILD] Creating app_build_123456.vdf

[STEAM] Logging into SteamCMD...
[STEAM] Uploading depot 123457 (Windows)...
[STEAM] Uploading depot 123458 (Linux)...
[STEAM] Upload complete. Build ID: 9876543

[STEAM] Setting build live on 'testing' branch...
[STEAM] Done!

Steamworks Portal shows:
- New build visible in build history
- 'testing' branch updated
- Ready for internal QA

Implementation Hints: Create an app_build.vdf file that specifies your App ID, depots, and file mappings. Use SteamCMD for uploads: steamcmd +login user pass +run_app_build app_build.vdf +quit. For multi-platform, create separate depots and conditionally include based on platform. Use the “testing” branch for internal builds, “beta” for public testing, and “default” for the main release. Automate this with a script that builds, copies, and uploads in sequence.

Learning milestones:

Build uploads successfully via script → You understand ContentBuilder
Test branch shows new build → You understand branch management
Process is repeatable and documented → You understand CI/CD

Project 18: Steam Launch Checklist Simulator

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: N/A (Process)
Alternative Programming Languages: N/A
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 5. The “Industry Disruptor” (prevents launch disasters)
Difficulty: Level 1: Beginner
Knowledge Area: Release Management / QA
Software or Tool: Steamworks Partner Portal
Main Book: Steamworks Documentation (Release Process)

What you’ll build: A comprehensive pre-launch checklist that covers everything from final builds to marketing timing, executed as a dry-run with a test game.

Why it teaches Steam publishing: Launch day disasters happen from forgetting simple things. This project forces you to verify every requirement before you have a real game on the line.

Core challenges you’ll face:

30-day requirement → maps to timeline planning
Store page review → maps to content compliance
Build verification → maps to QA
Launch timing → maps to marketing strategy
Post-launch monitoring → maps to live operations

Key Concepts:

Release Checklist: Steam’s official checklist in the partner portal
Review Times: 1-5 business days for store page, 1-3 for builds
Launch Visibility Round: Steam may feature you on launch day if you qualify
Post-Launch: Monitor reviews, respond to bugs, manage community

Difficulty: Beginner Time estimate: 3 days (going through the process) Prerequisites: Projects 16-17

Real world outcome:

PRE-LAUNCH CHECKLIST (T-30 days):
☑ Steam Direct fee paid
☑ Tax interview completed
☑ Banking info verified
☑ Store page created and submitted for review
☑ Store page approved
☑ Coming Soon page is live

T-14 days:
☑ Store page updated with final screenshots/trailer
☑ Build uploaded and tested on Steam
☑ Achievements configured and tested
☑ Cloud saves configured and tested
☑ Trading cards submitted (optional)

T-7 days:
☑ Final build uploaded
☑ Build set as default for release
☑ Launch discount set (if any)
☑ Press keys generated for reviewers
☑ Social media posts scheduled

T-1 day:
☑ Verify release date/time in Steamworks
☑ Verify build is ready to go live
☑ Prepare launch announcement
☑ Alert: Store page will go live automatically!

Launch Day:
☑ Game is purchasable!
☑ Monitor for critical bugs
☑ Respond to first reviews
☑ Share on social media

Implementation Hints: Go through Steam’s actual release checklist in the partner portal. Create a project in a spreadsheet or project management tool with every item. Set calendar reminders for each deadline. If possible, do a “fake launch” with a free demo or very cheap test game to experience the full process. Document everything you learn.

Learning milestones:

Understand every step of the timeline → You understand release planning
Know what Valve reviews and why → You understand compliance
Have a reusable checklist for future games → You understand process optimization

Phase 7: What Makes Games Successful

Project 19: Viral Mechanics Case Study Analyzer

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: N/A (Research/Analysis)
Alternative Programming Languages: N/A
Coolness Level: Level 3: Genuinely Clever
Business Potential: 5. The “Industry Disruptor” (informs design decisions)
Difficulty: Level 1: Beginner
Knowledge Area: Game Design / Market Analysis
Software or Tool: Steam, YouTube, Twitch
Main Book: “A Theory of Fun for Game Design” by Raph Koster

What you’ll build: A research document analyzing 10 viral indie games from the past 2 years, identifying what made them spread (gameplay mechanics, streamer appeal, trend timing).

Why it teaches game success: Understanding WHY games succeed is as important as building them. Pattern recognition across hits helps you design for shareability.

Core challenges you’ll face:

Identifying viral mechanics → maps to “streamable” moments
Understanding trend timing → maps to “Great Conjunction” theory
Analyzing retention loops → maps to player psychology
Separating signal from noise → maps to survivorship bias awareness

Key Concepts:

Streamability: Does the game create shareable moments? (Among Us imposter reveals, Fall Guys ragdoll physics)
“Friend Slop”: Co-op horror games where failure is funny (Lethal Company, Phasmophobia)
Trend Surfing: Games that ride emerging waves (cozy games, roguelites, horror co-op)
Hook in First 30 Minutes: Players (and streamers) must “get it” immediately

Difficulty: Beginner Time estimate: 1 week Prerequisites: None

Real world outcome:

VIRAL GAME ANALYSIS DOCUMENT

Game: Lethal Company (2023)
- Revenue: $50M+ in first month
- Viral mechanics:
  - Co-op chaos (friends dying = content)
  - Monsters create jumpscare moments
  - Walkie-talkie voice chat (comedic potential)
  - Failure is funny, not frustrating
- Trend timing: Launched during "friend slop" wave
- Streamer appeal: Every session creates clips

Game: Content Warning (2024)
- Revenue: $10M+ first week
- Viral mechanics:
  - Players literally record videos in-game
  - Views = in-game currency
  - Encourages outrageous behavior
  - Built-in content creation loop
- Self-perpetuating: Game creates its own marketing

[Repeat for 8 more games...]

PATTERNS IDENTIFIED:
1. Co-op with emergent chaos > single-player
2. Failure states that are funny > frustrating death
3. Easy to understand, hard to master
4. Visual/audio moments that clip well
5. Social features that spread naturally

Implementation Hints: Pick games from SteamDB’s top sellers that came from small/indie studios. Watch GDC talks from successful indie devs. Read postmortems on Gamasutra/Game Developer. Watch popular Twitch streams of these games—what moments do streamers react to? What do viewers clip and share?

Learning milestones:

Can articulate why 3 games went viral → You understand viral mechanics
Can identify trend waves → You understand market timing
Can spot streamable moments in new games → You understand content appeal

Project 20: Build Your First “Friend Slop” Prototype

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: C# (Unity) or GDScript (Godot)
Alternative Programming Languages: C++ (Unreal), Lua (LÖVE2D)
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Game Design / Multiplayer
Software or Tool: Godot 4 with multiplayer, Unity with Netcode/Mirror
Main Book: “Multiplayer Game Programming” by Josh Glazer & Sanjay Madhav

What you’ll build: A small multiplayer horror game for 2-4 players with: proximity voice chat, flashlights, a simple monster AI, and one “scary moment” mechanic. The goal is to create 5 minutes of playable content that generates funny/scary moments.

Why it teaches game success: “Friend slop” (co-op chaos games) is the most successful indie genre in 2023-2025. This forces you to understand networked gameplay and emergent content creation.

Core challenges you’ll face:

Networking basics (host/client, RPCs) → maps to multiplayer architecture
Proximity voice chat → maps to spatial audio + networking
Synchronizing monster across clients → maps to network authority
Balancing horror tension → maps to pacing and game design
Creating “clipable” moments → maps to viral design

Key Concepts:

Authoritative Server: Host controls truth, clients are dumb
RPC (Remote Procedure Call): Call function on other machines
Network Interpolation: Smooth out choppy updates
Proximity Voice: Volume based on distance (Vivox, Steam Voice, WebRTC)

Difficulty: Advanced Time estimate: 3-4 weeks Prerequisites: Projects 1-15, understanding of one game engine

Real world outcome:

4 friends on Discord: "Let's try your game"

Game session:
- Host starts server, others join via Steam invite
- Players spawn in dark facility with flashlights
- "Did you hear that?" - proximity voice means only nearby players hear
- Monster spawns, chases one player
- Screaming, flashlight spinning, running
- Player gets caught, ragdolls - friends can't help, only watch
- Surviving players: "GO GO GO" through proximity voice
- One player escapes, others don't
- Everyone is laughing/screaming

Post-session:
- "That was hilarious, let's play again"
- Someone clipped the best moment
- "You should put this on Steam"

Networking works:
- 4 players connected with <100ms perceived latency
- Monster position synced across all clients
- Voice chat works within ~10m game distance
- Host migration: if host leaves, game continues

Implementation Hints: Start with Godot’s high-level multiplayer or Unity’s Netcode for GameObjects. Make the monster server-authoritative (host controls AI). Use Steamworks P2P or a simple lobby system for connection. For voice chat, integrate WebRTC or use Steam Voice. Keep scope tiny: one map, one monster type, 5-minute sessions. Focus on creating ONE scary/funny mechanic perfectly before adding more.

Learning milestones:

4 players can connect and see each other → You understand basic networking
Monster chases work across network → You understand authority
Friends genuinely scream/laugh while playing → You understand viral design

Capstone Project: Full Steam Release

Project 21: Ship a Complete Game to Steam

File: GAME_DEVELOPMENT_TO_STEAM_PUBLISHING.md
Main Programming Language: Your choice (Godot, Unity, Custom)
Alternative Programming Languages: Whatever you’ve become comfortable with
Coolness Level: Level 5: Pure Magic
Business Potential: Anywhere from 1-5 depending on your game
Difficulty: Level 4: Expert
Knowledge Area: Everything Combined
Software or Tool: Everything
Main Book: All of the above

What you’ll build: A complete, polished game released on Steam with achievements, cloud saves, store page, trailer, and real sales.

Why it teaches everything: Theory becomes real when money is on the line. Every lesson crystallizes when you face real players, real reviews, and real sales numbers.

Core challenges you’ll face:

Scope management → actually finishing
Polish and quality bar → competing with real games
Marketing with no budget → creative growth strategies
Handling negative reviews → emotional resilience
Post-launch support → live operations

Game Scope Suggestions:

Tiny (2-3 months): Single-screen arcade game, puzzle game with 20 levels
Small (6 months): Platformer with 5 worlds, simple roguelite
Medium (1 year): Full narrative game, complex roguelite with meta-progression

Difficulty: Expert Time estimate: 3-12 months depending on scope Prerequisites: All previous projects

Real world outcome:

LAUNCH DAY:
- Game is live on Steam!
- First sale comes in... someone bought your game
- First review: "Fun little game, recommended"
- Steam shows concurrent players: 5... 10...
- A small streamer plays your game
- End of week 1: 100 copies sold, 85% positive reviews

You have:
- Built a game from nothing
- Navigated Steam's systems
- Created marketing materials
- Handled a real launch
- Made real money from games
- Learned more than any tutorial could teach

What's next?
- Apply lessons to your next, bigger game
- You understand the entire pipeline
- You know what you're good at and what to improve
- You are now a game developer who ships

Implementation Hints: Start smaller than you think. Cut features ruthlessly. Launch the minimum viable game, then add content post-launch. Collect emails during “Coming Soon” for launch notification. Ask friends to leave honest reviews (not fake positive ones). Engage with Steam community—post devlogs, respond to feedback. Consider a small launch discount (10-15%) to encourage first-week sales.

Learning milestones:

Game is on Steam and purchasable → You understand the full pipeline
Real people are playing → You understand you can do this
You want to make another game → You’ve found your calling

Project Comparison Table

#	Project	Difficulty	Time	Depth of Understanding	Fun Factor
1	Bare Game Loop	Intermediate	Weekend	⭐⭐⭐⭐⭐	⭐⭐
2	Pixel Painter	Intermediate	1 week	⭐⭐⭐⭐⭐	⭐⭐⭐
3	Input System	Intermediate	1 week	⭐⭐⭐⭐	⭐⭐
4	Physics Engine	Advanced	2 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
5	Player Controller FSM	Intermediate	1 week	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
6	Pong Clone	Beginner	Weekend	⭐⭐⭐	⭐⭐⭐
7	Breakout Clone	Beginner-Int	1 week	⭐⭐⭐⭐	⭐⭐⭐⭐
8	Full Platformer	Advanced	2-3 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
9	Save System	Intermediate	1 week	⭐⭐⭐⭐	⭐⭐
10	Audio Engine	Intermediate	1 week	⭐⭐⭐⭐	⭐⭐⭐⭐
11	UI System	Advanced	2 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐
12	Steamworks Basics	Intermediate	2-3 days	⭐⭐⭐⭐	⭐⭐⭐
13	Steam Achievements	Intermediate	3-4 days	⭐⭐⭐⭐	⭐⭐⭐⭐
14	Steam Cloud Saves	Intermediate	2-3 days	⭐⭐⭐⭐	⭐⭐⭐
15	Steam Leaderboards	Intermediate	2-3 days	⭐⭐⭐	⭐⭐⭐⭐
16	Store Page Builder	Intermediate	1-2 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐
17	Build Pipeline	Intermediate	3-4 days	⭐⭐⭐⭐	⭐⭐
18	Launch Checklist	Beginner	3 days	⭐⭐⭐⭐⭐	⭐⭐⭐
19	Viral Game Analysis	Beginner	1 week	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
20	Friend Slop Prototype	Advanced	3-4 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
21	Full Steam Release	Expert	3-12 months	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

Recommended Learning Path

For Complete Beginners

Projects 1-2 (Game Loop, Pixel Painter) - Understand fundamentals
Project 6 (Pong) - Complete your first game
Projects 3-5 (Input, Physics, FSM) - Build core systems
Project 7 (Breakout) - Apply what you learned
Project 8 (Platformer) - Build something substantial

For Intermediate Developers

Projects 9-11 (Save, Audio, UI) - Production features
Projects 12-15 (Steamworks) - Steam integration
Projects 16-18 (Publishing) - Learn the business side
Project 8 (Platformer) - Polish and release

For Those Ready to Ship

Project 19 (Viral Analysis) - Understand the market
Project 20 (Friend Slop) - Build with virality in mind
Project 21 (Full Release) - Ship it!

Why This Specific Order?

Game Loop First: Everything else depends on understanding the core loop
Rendering Before Input: You need to see what’s happening to debug input
Physics Before Controllers: Controllers are built on physics
Simple Games Before Complex: Build confidence with completeable projects
Production Features After Gameplay: Don’t polish what isn’t fun yet
Steam Integration After Game Works: Integration is easier when game is stable
Marketing After Product Exists: You can’t market what you don’t have
Viral Analysis Before Final Game: Design with success patterns in mind

Summary

Project #	Project Name	Main Language
1	The Bare Game Loop	C
2	Pixel Painter (Direct Framebuffer)	C
3	Input System Architecture	C
4	2D Physics Engine (AABB)	C
5	Player Controller State Machine	C
6	Pong Clone	C
7	Breakout Clone	C
8	Platformer with Complete Mechanics	C
9	Save System Architecture	C
10	Audio Engine Integration	C
11	UI System from Scratch	C
12	Steamworks SDK Basics	C++
13	Steam Achievements and Stats	C++
14	Steam Cloud Saves	C++
15	Steam Leaderboards	C++
16	Steam Store Page Builder	N/A (Marketing)
17	Steam Build Pipeline	Bash/PowerShell
18	Steam Launch Checklist Simulator	N/A (Process)
19	Viral Mechanics Case Study Analyzer	N/A (Research)
20	Build Your First “Friend Slop” Prototype	C# or GDScript
21	Ship a Complete Game to Steam	Your Choice

From Zero to Steam: Complete Game Development & Publishing Learning Path

Understanding the Steam Ecosystem First

Steam Publishing Requirements

Why These Requirements Exist

The Reality of Steam Success (2025 Data)

Phase 1: Understanding How Games Work (Fundamentals)

Project 1: The Bare Game Loop

Project 2: Pixel Painter (Direct Framebuffer Access)

Phase 2: Making Things Move and Respond

Project 3: Input System Architecture

Project 4: 2D Physics Engine (AABB Collision)

Project 5: Player Controller State Machine

Phase 3: Building Complete (Simple) Games

Project 6: Pong Clone

Project 7: Breakout Clone

Project 8: Platformer with Complete Mechanics

Phase 4: Production-Ready Features

Project 9: Save System Architecture

Project 10: Audio Engine Integration

Project 11: UI System from Scratch

Phase 5: Steam Integration (Steamworks SDK)

Project 12: Steamworks SDK Basics

Project 13: Steam Achievements and Stats

Project 14: Steam Cloud Saves

Project 15: Steam Leaderboards

Phase 6: The Publishing Process

Project 16: Steam Store Page Builder

Project 17: Steam Build Pipeline

Project 18: Steam Launch Checklist Simulator

Phase 7: What Makes Games Successful

Project 19: Viral Mechanics Case Study Analyzer

Project 20: Build Your First “Friend Slop” Prototype

Capstone Project: Full Steam Release

Project 21: Ship a Complete Game to Steam

Project Comparison Table

Recommended Learning Path

For Complete Beginners

For Intermediate Developers

For Those Ready to Ship

Why This Specific Order?

Summary

Sources