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/XINCGer/Unity3DTraining 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 — Solo project — review before adopting

• Last commit 3d ago
• MIT licensed
• ⚠ Solo or near-solo (1 contributor active in 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 XINCGer/Unity3DTraining repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/XINCGer/Unity3DTraining.

What it runs against: a local clone of XINCGer/Unity3DTraining — 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 XINCGer/Unity3DTraining | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of XINCGer/Unity3DTraining. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/XINCGer/Unity3DTraining.git
#   cd Unity3DTraining
#
# 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 XINCGer/Unity3DTraining and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "XINCGer/Unity3DTraining(\\.git)?\\b" \\
  && ok "origin remote is XINCGer/Unity3DTraining" \\
  || miss "origin remote is not XINCGer/Unity3DTraining (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
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/XINCGer/Unity3DTraining"
  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 comprehensive Unity3D training and experimentation repository containing 35+ self-contained game projects and technical demonstrations (2D Platformer, 3D Moon Runner, Space Shooter, Minecraft clone, etc.) plus deep-dives into engine systems (ECS, physics, pathfinding, hot-updates, rendering). It's a living textbook for game development patterns, not a single product—each subdirectory is a standalone learning module with runnable scenes. Monorepo of ~35 independent Unity project folders (2DPlatformer/, SpaceShooter/, Minecraft/, ECS/, HotUpdate/, etc.), each with its own Assets/ hierarchy containing Scripts/, Scenes/, Animation/, Prefabs/. Shared patterns: each project typically has a main gameplay loop in a manager script, often using design patterns (Singleton, Observer, State Machine) documented in DesignPatterns/ subdirectory. Supporting toolkits in ToolKits/, 3rdPlugins/ (third-party DLLs/packages), and SDK/ for mobile integration.

Chinese-speaking Unity developers (内容多为中文) ranging from intermediate to advanced, seeking practical implementations of game mechanics, architectural patterns (design patterns, ECS), and engine features (AssetBundle/hot-update, UGUI, physics, pathfinding, OpenGL rendering). Contributors use it as a reference when building their own commercial titles.

Actively maintained but eclectic: the repo shows steady commits across 30+ subdirectories, suggesting ongoing exploration rather than a single polished product. No obvious CI/CD setup or comprehensive test suite visible in the file list. Verdict: actively developed as a learning sandbox—production-ready components exist (e.g., collision systems, UI frameworks) but the repo is organized for education, not turnkey deployment.

Single-maintainer (@XINCGer) curating diverse experimental code across C#, C++, Lua, GLSL, and Objective-C—high surface area means inconsistent quality. Many subdirectories appear abandoned (e.g., last commit may vary by months per module). No lockfile or dependency management visible; individual projects likely have stale plugin versions (DoTween, pathfinding libraries). Risk: cloning and building a random subdirectory may fail due to missing or incompatible Unity versions.

The 2DPlatformer module shows active animation-clip development (50+ .anim files with recent .meta updates), suggesting current work on 2D platformer polish. The broader repo shows exploration of hot-update mechanisms (HotUpdate/ directory implies work on asset streaming), and references to external repos (ColaFrameWork for custom client architecture, FURIOUS_MOTORSPORT for a racing game spin-off) suggest the author is extracting battle-tested patterns back into this training hub.

Clone the repo: git clone https://github.com/XINCGer/Unity3DTraining.git. Open Unity (version not explicitly pinned; infer from project settings in ProjectSettings/ProjectVersion.txt per subdirectory). Navigate to a target subdirectory (e.g., 2DPlatformer/) and open the .sln or import into Unity Editor. No npm/pip install needed—dependencies are Unity packages or bundled DLLs.

Daily commands: Per subdirectory: open the folder in Unity Editor (2021.3 LTS or similar inferred from .meta files), load the main scene (typically in Assets/Scenes/), and press Play. For example: 2DPlatformer likely has a main level scene you can directly preview. For command-line builds, use unity -projectPath ./2DPlatformer -buildWindowsPlayer ./build.exe (adjust platform flag).

• README.md: Master index of all 35 modules with GitHub links; start here to orient yourself to the repo's scope.
• 2DPlatformer/Assets/Animation/Clips/: 50+ animation clips (Run.anim, Jump.anim, Death.anim, etc.) demonstrate animation state machine setup for a complete 2D platformer.
• DesignPatterns/: Dedicated module showing Singleton, Observer, State Machine, Factory patterns implemented in C# for Unity—essential reference for architecture decisions.
• ECS/: Entity-Component-System implementation; shows data-oriented design alternative to traditional MonoBehaviour inheritance.
• HotUpdate/: Hot-reload and AssetBundle management; critical for live games and runtime updates without recompilation.
• ToolKits/: Shared utility classes and helpers (likely EventSystem, ObjectPool, etc.) that other modules depend on.
• UnityEditorExtension/: Custom editor scripts (Editor/ folder scripts) showing how to extend the Unity Editor UI for custom workflows.
• LearningOpenGL/: Raw OpenGL + compute shader code (C++ and GLSL); bridges Unity rendering into low-level graphics programming.

1. New gameplay mechanic: edit Scripts/ in target subdirectory (e.g., 2DPlatformer/Assets/Scripts/Player.cs for character behavior). 2. UI changes: drag prefabs in Assets/Prefabs/ or edit UGUI scenes (UGUITraining/ shows best practices). 3. Animation: open Animation/Clips/ .anim files in the Animator window. 4. Reusable pattern: extract your code to ToolKits/ and reference it via Assembly Definition (.asmdef) files. 5. Design pattern study: copy an example from DesignPatterns/ and apply to your module.

1. No explicit Unity version lock: Each subdirectory's ProjectSettings/ProjectVersion.txt differs; cloning 2DPlatformer may require Unity 2019.x while ECS requires 2021+. Always check ProjectSettings before opening. 2. Missing .gitignore specificity: Library/, Logs/, and obj/ folders are frequently regenerated; first clone will be large (6.7 MB C# code alone). 3. Third-party plugin versions: 3rdPlugins/ references may be outdated (DoTween, pathfinding libs); compatibility with latest Unity not guaranteed. 4. Lua integration undocumented: Lua/ files present but no clear build instructions for tolua# or binding setup. 5. Assembly Definition (.asmdef) gotcha: If mixing modules, ensure cross-module references are declared in .asmdef files or script compilation will fail silently.

• Entity-Component-System (ECS) — The ECS/ module teaches data-oriented design (separating data from logic) as an alternative to MonoBehaviour inheritance; critical for high-performance multiplayer and large-scale simulations.
• Hot-reload & AssetBundle streaming — HotUpdate/ module shows how to load scenes and assets at runtime without recompiling; essential for live games and reducing deployment friction.
• A* Pathfinding & Navigation Mesh — Pathfinding/ subdirectory implements or wraps A* and navmesh algorithms; understanding these is non-negotiable for any AI-driven game (enemy movement, NPC routing).
• Object Pool & Memory Pool patterns — MemoryPool_ObjectPool/ module shows how to pre-allocate and reuse game objects (bullets, particles, enemies) to avoid GC spikes and frame stutters in real-time games.
• Design Patterns in games (Singleton, Observer, State Machine, Factory) — DesignPatterns/ module catalogs Gang-of-Four patterns applied to Unity; these are the vocabulary for discussing and implementing scalable game architecture.
• Bezier curves & spline interpolation — BezierTest/ explores smooth motion paths and procedural animation; essential for camera movement, projectile arcs, and UI tweens without keyframe bloat.
• Shader programming (ShaderLab & GLSL) — Multiple modules (2DPlatformer, LearningOpenGL) include .shader and .glsl files; custom shaders unlock post-processing, visual effects, and optimization that prefab materials cannot achieve.
• I18N (Internationalization) & Localization — I18N_Localization/ module handles multi-language text and regional formatting; required for shipping games to non-English markets.

• XINCGer/ColaFrameWork — The author's custom client-side architecture framework extracted from production; tightly related as a formalized version of patterns shown in this training repo.
• XINCGer/FURIOUS_MOTORSPORT — Separate repo for a complete racing game; demonstrates how patterns from this training repo (physics, input, UI) scale to a full commercial title.
• sschmtulp/ECS — Standalone Entity-Component-System for Unity; the ECS/ module in this repo draws from or parallels similar architectural explorations.
• Unity-Technologies/NetCode — Official Unity multiplayer framework; complements this repo's network sections (NetWorkAndResources/) for production-grade netcode patterns.
• amirrajan/AdventureIsOutThere — A full 3D platformer game in Unity by the same creator; shows how training concepts from this repo materialize in a polished shipped title.

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.

Create comprehensive README.md for 2DPlatformer project with setup and gameplay documentation

The 2DPlatformer directory has extensive animation clips and controllers (40+ .anim files) but lacks any documentation explaining the project structure, how to run it, gameplay mechanics, or how the animation system is organized. New contributors can't understand the purpose of individual animation clips (e.g., why there are both 'Run.anim' and 'RunRight.anim', or how 'BombLanding.anim' and 'RocketExplode.anim' are used in gameplay).

• [ ] Create 2DPlatformer/README.md documenting project overview and game objectives
• [ ] Add section explaining animation controller organization (Character.controller, Enemy1.controller, Enemy2.controller, etc.)
• [ ] Document the animation clip naming conventions and their roles (e.g., player movement, enemy behaviors, item pickups)
• [ ] Include setup instructions and controls/gameplay guide
• [ ] Add a diagram or table mapping animation clips to their game systems (player, enemies, environment, UI feedback)

Add .gitattributes configuration for Unity binary files in 2DPlatformer

The repo has a .gitattributes file at root but the 2DPlatformer subdirectory contains 40+ Unity binary files (.anim, .controller, .meta files) that may not have proper merge handling configured. Without Unity-specific gitattributes, merge conflicts on animation files can corrupt the project. This is critical for team collaboration on this existing project.

• [ ] Review existing .gitattributes at repo root for Unity configuration
• [ ] Create or update 2DPlatformer/.gitattributes with merge strategies for *.controller and *.anim files
• [ ] Add merge driver configuration for Unity's YAML format (e.g., 'merge=union' or custom merge driver)
• [ ] Document in 2DPlatformer/README.md how to handle animation file conflicts
• [ ] Test with a sample merge scenario to verify binary files don't corrupt

Create animation system documentation and usage guide for 2DPlatformer controllers

With 7 animation controllers (Character, Clouds, Enemy1, Enemy2, Flame, RiverMid, RiverTop) and 40+ animation clips, there's no documentation explaining parameter passing between controllers, animation transitions, or the scripting API for triggering animations. New contributors can't understand the animation architecture without inspecting each .controller file manually.

• [ ] Create 2DPlatformer/ANIMATION_GUIDE.md documenting each controller's purpose and parameters
• [ ] Document animation state transitions for Character.controller (Idle → Run → Jump → Falling → Death)
• [ ] List all animation parameters used across controllers (e.g., boolean flags, speed multipliers)
• [ ] Provide code examples showing how to trigger animations from scripts (e.g., SetBool, SetTrigger calls)
• [ ] Create a state machine diagram for Character and Enemy controllers for visual reference

• Add unit tests for ToolKits/ utility classes (ObjectPool, EventSystem, etc.) using Unity Test Framework (UTF); currently no test coverage visible for shared code that multiple projects depend on.
• Document the Lua integration story (3rdPlugins/Lua/ files exist but no README or build guide); create LuaIntegration/ example showing how to call C# from Lua and vice-versa with a runnable scene.
• Create a 'Quick Start' guide for each of the 5 most-popular subdirectories (2DPlatformer, SpaceShooter, Minecraft, ECS, HotUpdate) listing required Unity version, expected runtime, and key scripts to understand first—currently each module requires exploration to understand entry points.

This Unity3DTraining repository appears to be an educational/learning project with a 2D platformer game and various training examples. The security analysis is limited due to only file structure visibility without access to actual C# code. No obvious hardcoded secrets or exposed sensitive files were detected in the directory structure. However, without examining the actual code, input validation mechanisms, network communication patterns, and dependency versions, a comprehensive security assessment cannot be completed. The project shows no evidence of misconfigurations at the infrastructure level. For a training project, the security posture is acceptable, but production versions should undergo thorough code review, dependency auditing, and implementation of Unity-specific security hardening techniques.

• Medium · Limited Visibility into Code Security — 2DPlatformer/Assets and other project directories. The static analysis is restricted to file structure and metadata only. The actual C# script content in the Unity project is not provided for review. This limits the ability to detect code-level vulnerabilities such as unsafe API usage, improper input validation, or insecure serialization patterns common in Unity games. Fix: Perform a comprehensive code review of all C# scripts, particularly those handling user input, network communication, and asset loading. Use static analysis tools like Roslyn analyzers or SonarQube configured for C# and Unity.
• Low · No Dependency Lock File Visible — Packages directory (not visible) / manifest.json. No package.json, packages.config, manifest.json, or other dependency management files are shown in the file structure. Unity projects typically use manifest.json in the Packages directory. Without visibility into dependencies, it's unclear if the project uses vulnerable third-party libraries. Fix: Ensure all dependencies are explicitly declared in manifest.json and maintained up-to-date. Use Unity Package Manager to manage dependencies and regularly scan for known vulnerabilities using tools like OWASP Dependency-Check.
• Low · Generic Project Structure - No Security Configuration Visible — Project root and configuration directories. No visible security-related configuration files (.env, security.xml, code obfuscation settings, etc.). While this could indicate a training/learning project, production games should have explicit security hardening configurations. Fix: Implement security best practices in Unity build settings: enable code stripping, use IL2CPP for code obfuscation on sensitive platforms, implement anti-cheating measures, and use secure serialization instead of standard .NET serialization for sensitive data.

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.