If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/utilForever/game-developer-roadmap shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 10 active contributors
• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live utilForever/game-developer-roadmap repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/utilForever/game-developer-roadmap.

What it runs against: a local clone of utilForever/game-developer-roadmap — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in utilForever/game-developer-roadmap | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 491 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of utilForever/game-developer-roadmap. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/utilForever/game-developer-roadmap.git
#   cd game-developer-roadmap
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of utilForever/game-developer-roadmap and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "utilForever/game-developer-roadmap(\\.git)?\\b" \\
  && ok "origin remote is utilForever/game-developer-roadmap" \\
  || miss "origin remote is not utilForever/game-developer-roadmap (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "gdr-terms/src/main.rs" \\
  && ok "gdr-terms/src/main.rs" \\
  || miss "missing critical file: gdr-terms/src/main.rs"
test -f "gdr-terms/Cargo.toml" \\
  && ok "gdr-terms/Cargo.toml" \\
  || miss "missing critical file: gdr-terms/Cargo.toml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "LICENSE" \\
  && ok "LICENSE" \\
  || miss "missing critical file: LICENSE"
test -f "img/client.png" \\
  && ok "img/client.png" \\
  || miss "missing critical file: img/client.png"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 491 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~461d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/utilForever/game-developer-roadmap"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A learning resource and roadmap (built with Balsamiq mockups and documented in this repo) that visualizes the skills, technologies, and career paths for aspiring game developers, with a companion Rust CLI tool (gdr-terms) for searching and learning game development terminology. It provides three visual roadmaps (Introduction, Client, Server) showing what technologies to learn at each stage of becoming a game developer. Monorepo structure: /img/ contains PNG roadmap diagrams (client.png, server.png, intro.png, and dark-themed variants); /src/ holds the Balsamiq project file (Game Developer Roadmap.bmpr) for editing; /gdr-terms/ is a standalone Rust CLI application with Cargo.toml and src/main.rs; root-level README files (standard and dark-theme variants) document the roadmaps.

Computer science students, hobbyist game developers, and career-changers who need structured guidance on which game development technologies to learn and in what order. Specifically, professors (as mentioned in the README) use this to teach game development fundamentals to college students.

Early-stage educational resource. The repo has minimal code (only the CLI tool in gdr-terms/ is implemented in Rust), no test suite visible, and relies primarily on static Balsamiq mockup files. The project appears to be a maintained reference guide rather than an active software product—it's suitable for self-study but not a production system.

Very low risk—this is educational content, not a critical system. The gdr-terms Rust crate has zero production dependencies (empty [dependencies] section), making supply-chain risk negligible. The main risk is staleness: the 2022 roadmap may become outdated as game development technologies evolve. No CI/CD setup is evident in the file structure.

The repo is in maintenance mode. Based on the file structure, the primary content is static (the Balsamiq mockups and PNG images in /img/). The gdr-terms CLI appears to be an incomplete or minimal implementation—only the project skeleton is visible. No recent activity, open PRs, or milestones are evident from the provided data.

git clone https://github.com/utilForever/game-developer-roadmap.git
cd game-developer-roadmap
cd gdr-terms
cargo build --release

Then view the roadmaps by opening README.md in the root directory and examining the linked PNG images.

Daily commands: To view the roadmaps: Open README.md in a markdown viewer or on GitHub; images link to /img/*.png. To run the CLI: cd gdr-terms && cargo run --release. The CLI has no documented entry point behavior in the snippet provided—inspect gdr-terms/src/main.rs for actual functionality.

• gdr-terms/src/main.rs — Entry point for the CLI application that searches game development terms; all contributors must understand the command structure and term lookup logic.
• gdr-terms/Cargo.toml — Rust package manifest defining dependencies, metadata, and build configuration for the gdr-terms CLI tool.
• README.md — Primary documentation explaining the roadmap purpose, scope, and intended audience; essential for understanding project goals and contribution guidelines.
• LICENSE — MIT license file defining legal terms and permissions for code usage and distribution.
• img/client.png — Visual roadmap diagram for frontend game developer path; key reference material for understanding content structure.
• img/server.png — Visual roadmap diagram for backend game developer path; essential visual reference for the secondary development track.

• CLI Application (gdr-terms/src/main.rs) (Rust std library, stdio) — Entry point that parses commands, routes to search logic, and orchestrates output formatting.
  • Failure mode: Panics on invalid arguments; displays error message for unrecognized terms.
• Term Index (Rust collections (Vec, HashMap)) — In-memory data structure containing game development terminology, categories, and descriptions for fast lookup.
  • Failure mode: Returns empty result on term not found; no error state.
• Output Formatter (Rust string formatting, ANSI escape codes) — Transforms term data into human-readable terminal output with optional theme styling.
  • Failure mode: Defaults to standard formatting if theme detection fails.
• Roadmap Documentation (PNG images, Markdown) — Visual and textual guides showing learning paths for frontend, backend, and related game development roles.
  • Failure mode: Missing or corrupted images prevent proper roadmap visualization.

• User terminal input → CLI argument parser — User types command with search term or filter parameter.
• CLI argument parser → Term index search — Parsed arguments route query to appropriate lookup function.
• Term index → Output formatter — Matched term data (name, category, description) passed to formatter.
• Output formatter → Terminal stdout — Formatted, themed output written to standard output stream.
• README.md documentation → User browser or Markdown viewer — Static documentation with embedded image references renders in viewer.
• Roadmap PNG images → User browser or image viewer — Visual roadmaps loaded and displayed alongside documentation.

Add a new game development term

1. Define the new term in the data structure within gdr-terms/src/main.rs (gdr-terms/src/main.rs)
2. Add the term to the searchable index with category and description (gdr-terms/src/main.rs)
3. Update README.md to document the new term in the appropriate roadmap section (README.md)
4. Test the term lookup with cargo run -- <term-name> (gdr-terms/Cargo.toml)

Add a new roadmap visualization

1. Create the roadmap diagram as a PNG image in img/ directory following naming convention (e.g., img/devops.png) (img/)
2. Create a dark theme variant in img/ (e.g., img/devops-dark.png) (img/)
3. Add references to both variants in README.md with explanatory text (README.md)
4. Update README - Dark Theme.md with dark theme image references (README - Dark Theme.md)

Enhance the CLI search functionality

1. Extend the term data structure with additional metadata fields in gdr-terms/src/main.rs (gdr-terms/src/main.rs)
2. Implement new search filters or display options in the main.rs command handler (gdr-terms/src/main.rs)
3. Add any new dependencies to gdr-terms/Cargo.toml if required (gdr-terms/Cargo.toml)
4. Document new CLI features in README.md with usage examples (README.md)

• Rust — Provides memory safety, fast compilation, and efficient CLI performance without runtime dependencies; ideal for a lightweight term search utility.
• Cargo (Rust package manager) — Standard Rust build system enabling reproducible builds, dependency management, and cross-platform compilation.
• PNG image format for roadmaps — Universal, scalable visualization format suitable for displaying learning paths; lossless quality preservation.
• Markdown documentation — Human-readable, version-control friendly format for roadmap descriptions and learning guidance.

• Static term index compiled into binary vs. external data file

  • Why: Simplifies distribution and avoids runtime file I/O dependencies.
  • Consequence: Requires recompilation to add new terms; reduces flexibility but improves portability.

• Light and dark theme image variants vs. single adaptive image

  • Why: Provides optimal contrast and readability for both viewing contexts.
  • Consequence: Doubles image file count but improves user experience across different environments.

• CLI tool instead of web interface

  • Why: Lightweight, developer-friendly, and aligns with terminal-based workflows.
  • Consequence: Limited to terminal users; not accessible via browser without additional backend.

• Does not provide interactive game development tutorials
• Does not host a web server or REST API for remote access
• Does not track user progress or learning history
• Does not handle authentication or user accounts
• Does not provide real-time collaboration features
• Does not integrate with external learning platforms
• Does not perform code linting or project scaffolding

• Avg cyclomatic complexity: ~2 — Codebase is intentionally simple: a CLI tool with basic string matching and I/O; minimal algorithmic or architectural complexity.
• Largest file: gdr-terms/src/main.rs (150 lines)
• Estimated quality issues: ~2

• Hardcoded term data in source (Low) — gdr-terms/src/main.rs: Terms appear to be hardcoded in the binary rather than loaded from a configuration file or database, making term updates require recompilation.
• No error handling framework (Medium) — gdr-terms/src/main.rs: Minimal error handling; panics or silent failures likely occur on invalid input rather than graceful error messages.
• Dual image files for theme support (Low) — img/: Maintains separate light and dark PNG files instead of using CSS or dynamic rendering, leading to image duplication and maintenance overhead.

• gdr-terms/src/main.rs (Search performance) — Linear search through term index on every query; no indexing or caching optimization for repeated lookups.
• img/ directory (Storage and transfer) — Large PNG files for roadmaps may add significant repository size; no compression or lazy-loading mechanism.
• README.md (Documentation maintainability) — Single monolithic documentation file for all roadmaps; scales poorly as content grows.

Balsamiq dependency: Editing roadmaps requires a Balsamiq license or the free community version; the .bmpr file cannot be edited without it. Empty CLI: The gdr-terms/src/main.rs file is minimal with no visible search logic or term database—contributors must add the core functionality. Dark theme duplication: Maintaining two separate README files (README.md and README - Dark Theme.md) risks inconsistency; both must be updated in sync. No CI/CD: Changes are validated only by manual review and PR discussion, not automated tests or builds.

• Game engine architecture (client-side rendering pipeline) — Understanding vertex shaders, fragment shaders, LOD systems, and scene graphs is essential for the Client Roadmap; this repo maps which technologies implement these concepts.
• Networked game state synchronization — The Server Roadmap emphasizes multiplayer architecture; lag compensation, tick rates, and authoritative server patterns are non-obvious concepts that beginners must grasp.
• Real-time event loop and frame timing — Game developers must understand the difference between fixed timesteps and variable delta-time to implement stable physics and input handling, a foundational concept bridging client and server.
• Asset pipeline and serialization (rigging, skeletal animation, texture compression) — The Client Roadmap references 3D modeling and animation; understanding how assets are authored in Blender/Maya and serialized for runtime is critical for performance.
• Database design for game persistence (leaderboards, inventory, save states) — The Server Roadmap requires knowledge of relational and NoSQL databases; game-specific patterns like denormalization for fast leaderboard queries differ from typical web apps.
• Profiling and optimization (CPU/GPU bottlenecks, memory budgets) — Game development is performance-critical; this roadmap implicitly assumes profiling knowledge because rendering and physics simulate at 60+ FPS with tight constraints.

• kamranahmedse/developer-roadmap — The direct inspiration for this project, providing interactive career roadmaps for web/backend developers; game-developer-roadmap adapts its visual format for game dev specialization.
• utilForever/cpp-game-dev-resources — Companion resource by the same author (utilForever) collecting C++ game development learning materials and best practices.
• abitmore/game-dev-roadmap-zh — Community fork/translation of this roadmap into Chinese, demonstrating how the resource is adapted for other language communities.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for gdr-terms Rust binary

The gdr-terms Rust CLI tool (Cargo.toml at gdr-terms/src) has no CI pipeline. A workflow should build and test the binary on push/PR to catch regressions, validate the crate compiles on stable Rust 2021 edition, and optionally publish to crates.io. This prevents broken builds from being merged.

• [ ] Create .github/workflows/rust.yml with cargo build, cargo test, and cargo clippy steps
• [ ] Test on ubuntu-latest with rust-toolchain action
• [ ] Add badge to README.md showing workflow status
• [ ] Verify workflow runs successfully on a test PR

Implement search functionality tests in gdr-terms/src/main.rs

The gdr-terms binary is described as 'A Simple Command Line Application for Searching Game Development Terms' but there are no tests visible in the file structure. Adding unit tests for the core search logic will ensure term lookups work correctly and prevent regressions as features are added.

• [ ] Add #[cfg(test)] module to gdr-terms/src/main.rs
• [ ] Create test cases for exact term matching, case-insensitive search, and partial matches
• [ ] Add sample game development terms as test data (e.g., 'Shader', 'Physics Engine')
• [ ] Run 'cargo test' to verify all tests pass

Complete truncated README.md introduction and add roadmap navigation links

The README.md has incomplete text ('You should grow some understanding of why one tool would be be' is cut off). Additionally, there's no table of contents or direct links to the roadmap images (client.png, server.png, intro.png visible in img/). Completing this improves discoverability of the core content and fixes the reading experience.

• [ ] Complete the truncated paragraph in README.md about tool selection philosophy
• [ ] Add a 'Table of Contents' section with anchor links to each roadmap (Intro, Client/Frontend, Server/Backend, DevOps if applicable)
• [ ] Add embedded or linked images from img/ directory with clear alt-text explaining each roadmap
• [ ] Include a 'Getting Started with gdr-terms' section explaining how to use the CLI tool

• Implement the gdr-terms CLI search functionality: add a terms database (e.g., CSV or embedded const list of game dev terms like 'shader', 'rigging', 'LOD') and a search command in gdr-terms/src/main.rs that filters and displays matching terms with brief definitions.
• Add a dark-theme variant for the Balsamiq mockup and export dark PNG images to /img/*-dark.png for all three roadmaps (intro, client, server); currently only the README exists in dark mode but the diagrams lack corresponding dark-theme images.
• Create a comprehensive CONTRIBUTING.md guide documenting how to edit the .bmpr file in Balsamiq, export PNGs with specific dimensions/naming conventions, and test the CLI before submitting a PR—currently these steps are scattered or missing.

This is a minimal educational project with low security risk. The codebase contains no external dependencies, no hardcoded credentials, and appears to be documentation-focused with a simple command-line tool. No critical or high-severity vulnerabilities were identified. The main recommendations involve implementing security best practices for future development (dependency auditing, CI/CD security checks) and keeping documentation current. The small attack surface is a positive security attribute.

• Low · Missing dependency specification — gdr-terms/Cargo.toml. The Cargo.toml file has an empty [dependencies] section. While this is not a vulnerability per se, it indicates a minimal project with no external dependencies, which reduces attack surface but should be monitored if dependencies are added in the future. Fix: When adding dependencies, ensure they are from trusted sources, regularly updated, and audited using 'cargo audit' for known vulnerabilities.
• Low · No security audit configuration — Repository root. The project lacks a security audit setup or CI/CD configuration visible in the provided file structure. There are no evidence of automated vulnerability scanning (e.g., cargo-audit, dependabot). Fix: Set up automated dependency scanning using cargo-audit in CI/CD pipelines and enable GitHub Dependabot for continuous monitoring.
• Low · Incomplete or outdated roadmap reference — README.md. The README references a 2022 roadmap which is now outdated. While not a security issue, outdated learning resources may point users to deprecated or insecure technologies. Fix: Update the roadmap to reflect current best practices and versions of technologies recommended to users.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.