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/Unity-Technologies/EntityComponentSystemSamples 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 — Mixed signals — read the receipts

• Last commit 1d ago
• 20 active contributors
• Distributed ownership (top contributor 41% of recent commits)
• Other licensed
• CI configured
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 Unity-Technologies/EntityComponentSystemSamples repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Unity-Technologies/EntityComponentSystemSamples.

What it runs against: a local clone of Unity-Technologies/EntityComponentSystemSamples — 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 Unity-Technologies/EntityComponentSystemSamples | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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"

# 4. Critical files exist
test -f "Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs" \\
  && ok "Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs" \\
  || miss "missing critical file: Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs"
test -f "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneLoadingSystem.cs" \\
  && ok "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneLoadingSystem.cs" \\
  || miss "missing critical file: Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneLoadingSystem.cs"
test -f "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/ContentBuilder.cs" \\
  && ok "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/ContentBuilder.cs" \\
  || miss "missing critical file: Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/ContentBuilder.cs"
test -f "Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs" \\
  && ok "Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs" \\
  || miss "missing critical file: Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs"
test -f "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneAuthoring.cs" \\
  && ok "Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneAuthoring.cs" \\
  || miss "missing critical file: Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneAuthoring.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/Unity-Technologies/EntityComponentSystemSamples"
  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).

EntityComponentSystemSamples is Unity's official collection of example projects demonstrating the Data-Oriented Technology Stack (DOTS) framework — a high-performance ECS (Entity Component System) architecture for game development. It provides runnable samples for Entities, Physics, Netcode, and Entities.Graphics packages, plus foundational 101 tutorials covering Job System, ECS fundamentals, physics simulation, and networked multiplayer patterns. Monorepo structure with parallel sample projects: Dots101/ contains beginner tutorials (Jobs101, Entities101, Physics101, Netcode101, ContentManagement101); EntitiesSamples/, PhysicsSamples/, NetcodeSamples/ contain advanced feature demos; GraphicsSamples/ (HDRPSamples/, URPSamples/) isolate rendering pipelines. Each top-level project is a standalone Unity project with Assets/, including C# systems, baking authoring scripts, and .unity scenes.

Unity game developers learning DOTS—ranging from beginners working through Jobs101 and Entities101 tutorials to intermediate engineers building networked multiplayer games with Netcode101 or physics-heavy simulations with Physics101. Also useful for graphics programmers exploring the HDRP and URP rendering pipelines via GraphicsSamples.

Actively maintained and production-ready. The repo targets Unity 6.2 LTS with packages at v1.4 stability releases (Entities, Netcode, Physics, Entities.Graphics). CI/CD is configured via .github/workflows/github-repo-stats.yml. The project structure shows comprehensive coverage across five major sample categories with linked documentation and video walkthroughs, indicating sustained official support.

Low risk for learning, medium risk if shipping production code without further vetting. The samples depend on rapidly-evolving DOTS packages (Entities 1.4, Netcode 1.4); future major versions may break sample code. No visible test automation in the file list suggests samples are validated manually. The Dots101/ContentManagement101 weak object loading patterns hint at evolving APIs that may need updates.

No recent commit data visible in the file list, but the presence of github-repo-stats.yml workflow suggests ongoing repo stats collection. The ContentManagement101 project with both weak object and weak scene loading patterns suggests active exploration of content streaming and LOD systems. Likely maintaining compatibility with Unity 6.2 LTS releases and DOTS package updates.

1. Clone the repo: git clone https://github.com/Unity-Technologies/EntityComponentSystemSamples.git. 2. Open one of the sample projects (e.g., Dots101/Entities101/) in Unity 6.2+. 3. Load the Entities package (v1.4+) and dependencies via Window > TextureGenerator > Package Manager (DOTS packages auto-resolve). 4. Open a sample scene from Assets (e.g., HelloCube/1. HelloCube/HelloCube.unity) and play.

Daily commands: Each sample is a standalone Unity project. Open the target folder (e.g., Dots101/Entities101/) in Unity 6.2+. Resolve dependencies via Package Manager (Entities, Physics, Netcode, Entities.Graphics packages auto-reference via manifest.json). Open a scene from Assets and press Play in the Editor, or Build > Build Settings > Build to standalone executable.

• Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs — Core system demonstrating weak object reference patterns in DOTS for content management—foundational pattern used throughout samples.
• Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneLoadingSystem.cs — Primary example of scene-based content loading with subscenes; shows how to structure systems for dynamic content in ECS.
• Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/ContentBuilder.cs — Build-time tooling for content packaging; critical for understanding how samples are prepared for runtime loading.
• Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs — Authoring component demonstrating entity conversion patterns; essential reference for converting traditional GameObjects to ECS entities.
• Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneAuthoring.cs — Shows how to author scene-level data for ECS consumption; needed to understand entity baking and data binding.
• Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/WeakSceneListScriptableObject.cs — Configuration object managing which scenes to load; demonstrates data-driven design for content management systems.

Add a new weak object type to load

1. Create an authoring component inheriting from MonoBehaviour in Assets/1. WeakObjectLoading/ directory (Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs)
2. Add a baker method to convert the authoring data to ECS components (Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakRenderedObjectAuthoring.cs)
3. Extend WeakObjectLoadingSystem to handle the new component type in its OnUpdate (Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs)
4. Test by adding the authoring component to a GameObject in WeakObjectLoading.unity scene (Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoading.unity)

Add a new subscene to dynamic load/unload

1. Create a new scene in Assets/2. WeakSceneLoading/Subscenes/ and mark it as a subscene (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Subscenes/)
2. Add the subscene path to WeakSceneListScriptableObject configuration asset (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/WeakSceneList.asset)
3. Update ContentBuilder.cs to include the new scene in the catalog generation (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/ContentBuilder.cs)
4. Extend WeakSceneLoadingSystem to trigger loads/unloads for the new scene based on runtime conditions (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/WeakSceneLoadingSystem.cs)

Implement custom content catalog from remote source

1. Create a new system similar to LoadingRemoteCatalogSystem in Assets/2. WeakSceneLoading/ (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/LoadingRemoteCatalogSystem.cs)
2. Define JSON schema matching the output of ContentBuilder.cs post-processing (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/BuildPostProcessing.cs)
3. Implement IJobEntity or foreach loop to parse remote catalog and queue scene loads (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/LoadingRemoteCatalogSystem.cs)
4. Test by hooking up to container scene and verifying scenes load from your remote source (Dots101/ContentManagement101/Assets/2. WeakSceneLoading/ContainerScene.unity)

• Entity Component System (DOTS) — Enables high-performance, data-oriented content management with cache-friendly memory layouts; required for streaming large amounts of dynamic content efficiently
• Subscenes and Baking — Converts authoring-time GameObject data to optimized ECS entities at build time; enables fast runtime instantiation and dynamic load/unload of scene content
• Weak Object References — Allows runtime loading of assets without strong compile-time dependencies; enables flexible content streaming and reduces memory footprint
• Job System — Parallelizes content loading, parsing, and initialization across multiple cores without GC allocation overhead
• Shader Graph — Demonstrates visual content pipeline in DOTS context; decouples content creation from performance-critical rendering code

• Use weak references instead of direct asset references

  • Why: Allows flexible runtime content loading and remote catalog support
  • Consequence: Requires async loading systems and adds complexity to content initialization; fails gracefully if assets are missing rather than at compile time

• Separate authoring (GameObject) from runtime (ECS entity) representation

  • Why: Enables optimization of entity layout and reduces memory overhead at runtime
  • Consequence: Authoring workflow is more complex; requires baking pipeline and two separate data representations during development

• Load content from remote catalogs at runtime

  • Why: Enables dynamic content delivery, A/B testing, and post-launch content updates
  • Consequence: Requires network reliability; adds latency (100-500ms) and requires fallback mechanisms for offline scenarios

• Use subscenes for granular loading/unloading

  • Why: Provides fine-grained control over which entities are active; reduces memory and CPU footprint of inactive content
  • Consequence: Increases scene file count and complexity; requires careful scene organization and catalog management

• Real-time editing of content during gameplay (samples are playmode-focused)
• Supporting legacy GameObject-based rendering (DOTS Graphics required)
• Cross-platform asset serialization beyond Unity's native formats
• Handling deprecated DOTS packages (samples target 1.4+ releases only)

1. DOTS packages (Entities, Netcode, Physics) are fast-moving; sample code may not compile against newer package versions without updates. 2. Burst JIT compilation requires specific C# subset compliance (no virtual methods, no LINQ in critical paths)—samples show compliant patterns but easy to break. 3. WebGL builds are unsupported for DOTS; samples target Standalone/Console/Mobile. 4. Baking happens at edit-time during scene load; authoring scripts must complete synchronously or face timeout. 5. No explicit dependency on external services, but ContentManagement101 samples assume ability to load from URLs/local paths.

• Entity Component System (ECS) — Core architectural pattern in this repo; fundamental to understanding how DOTS organizes data (components) separately from behavior (systems) for cache efficiency.
• Burst Compilation (JIT to native) — Samples show C# code that compiles to machine code via Burst; requires understanding of C# job safety and managed/unmanaged boundaries to write performant code.
• Baking (Edit-time Code Generation) — ContentManagement101 and Entities101 samples heavily use baking to convert authoring scripts to ECS entities; critical pattern for bridging designer workflows with runtime data.
• Archetype (Entity Query Optimization) — Samples demonstrate entity queries filtering by component sets; understanding archetypes explains why query structure affects cache coherence and performance.
• RPC (Remote Procedure Call) for Networking — Netcode101 samples use RPC commands to invoke behavior across networked clients; essential pattern for multiplayer DOTS games beyond basic state replication.
• Content Streaming & Catalogs (Asset Runtime Loading) — ContentManagement101 demonstrates weak object/scene loading via catalogs; addresses production concerns of large games needing runtime content management without loading entire worlds.
• Data-Oriented Design (DOD) — Foundational philosophy behind DOTS; samples optimize for CPU cache by storing homogeneous component data contiguously, contrasting with traditional OOP object layouts.

• Unity-Technologies/Entities — The core ECS package that all samples depend on; source for Entities API design and monthly releases.
• Unity-Technologies/NetCode_Samples — Specialized netcode samples extending this repo's Netcode101 with advanced multiplayer patterns (lobbies, state sync).
• Unity-Technologies/Physics_Samples — Dedicated physics simulation examples complementing Physics101 with collision callbacks, constraints, and performance profiling.
• Unity-Technologies/Graphics — Entities.Graphics package repository; defines shader authoring and HDRP/URP integration patterns referenced by GraphicsSamples.
• rust-lang/rustlings — Inspirational structure: like rustlings' bite-sized examples for learning a language, this repo provides scaffolded 101 projects for learning DOTS incrementally.

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 missing README files for Dots101 sample projects with setup and learning path instructions

The repo README references Dots101 projects (Jobs101, ContentManagement101) but there are no README.md files in these directories. Contributors should create comprehensive README files for each Dots101 project that explain prerequisites, how to run samples, and learning objectives. This is critical since the main README explicitly recommends these as entry points for new DOTS learners.

• [ ] Create Dots101/Jobs101/README.md with setup instructions and learning outcomes
• [ ] Create Dots101/ContentManagement101/README.md documenting the weak object/scene loading samples and how to navigate the structured folders (1. WeakObjectLoading, 2. WeakSceneLoading)
• [ ] Include specific instructions for opening scenes and running systems for each sample
• [ ] Add cross-references to the main README sections and video tutorials mentioned

Add validation tests for sample project Unity version and package compatibility

The README specifies that projects use Unity 6.2 and exact package versions (Entities, Netcode, Physics, Entities.Graphics 1.4). There's currently no automated verification that sample projects remain compatible. Add a GitHub Action that validates ProjectSettings.asset files across all sample projects to ensure they match documented requirements.

• [ ] Create .github/workflows/validate-project-versions.yml to parse ProjectSettings.asset in each sample project root
• [ ] Verify minimum Unity version matches 6.2 across all projects (Dots101, EntitiesSamples, PhysicsSamples, NetcodeSamples, GraphicsSamples)
• [ ] Check that package.json files reference correct package versions (Entities, Netcode, Physics, Entities.Graphics at 1.4.x)
• [ ] Add workflow to run on PR and fail if incompatibilities are detected

Create learning path documentation linking code samples to concepts with file-level comments

The ContentManagement101 project has well-organized systems (LoadingLocalCatalogSystem.cs, LoadingRemoteCatalogSystem.cs, WeakObjectLoadingSystem.cs) but lacks inline documentation explaining which DOTS concepts each demonstrates. New contributors should add comprehensive XML documentation comments to these core files explaining the architectural patterns and linking to official DOTS documentation.

• [ ] Add detailed XML doc comments to Dots101/ContentManagement101/Assets/1. WeakObjectLoading/LoadingLocalCatalogSystem.cs explaining catalog patterns
• [ ] Document Dots101/ContentManagement101/Assets/1. WeakObjectLoading/WeakObjectLoadingSystem.cs with references to entity serialization and weak reference concepts
• [ ] Add comments to Dots101/ContentManagement101/Assets/2. WeakSceneLoading/LoadingRemoteCatalogSystem.cs explaining streaming and remote loading patterns
• [ ] Document the build post-processing flow in Assets/2. WeakSceneLoading/Content Settings/Editor/BuildPostProcessing.cs

• Add missing unit tests for baking authoring scripts in Dots101/Entities101/Assets/HelloCube/ to verify entity component generation under different configuration states.
• Extend the ContentManagement101 weak object loading sample to include explicit error handling and retry logic for failed catalog loads, with documentation of failure modes.
• Create a beginner's troubleshooting guide documenting common Burst compilation errors (e.g., managed types in jobs, virtual methods) with links to failing sample code and fixes.

The Unity EntityComponentSystemSamples repository is primarily a sample/educational codebase with low inherent security risk. The project structure contains game assets, shaders, authoring components, and systems typical of Unity DOTS development. No critical vulnerabilities were identified in the provided file structure. The main security considerations are: (1) inability to assess dependency vulnerabilities without package manifests, (2) ensuring no sensitive data is hardcoded in ScriptableObject assets, and (3) reviewing editor build scripts for best practices. The codebase follows standard Unity project organization and appears well-structured. For production use, implement dependency scanning, secure configuration management, and regular security audits of any modified samples.

• Low · No dependency lock file provided for analysis — Dependencies (not provided). The dependency/package file content was not provided in the analysis. Without examining package manifests (package.json, packages.config, manifest.json, etc.), transitive dependency vulnerabilities cannot be fully assessed. Fix: Provide package manifests and lock files for dependency scanning. Consider using tools like OWASP Dependency-Check or Snyk to scan for known vulnerabilities in Unity packages and their dependencies.
• Low · Potential hardcoded asset configurations — Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/WeakSceneList.asset. The codebase contains multiple ScriptableObject asset files (*.asset) that may contain hardcoded configuration values. While this is common in Unity, sensitive data should never be stored in these files. Fix: Review all .asset files and ScriptableObject implementations to ensure no sensitive data (API keys, passwords, endpoints) are hardcoded. Use environment variables or secure configuration systems for sensitive data.
• Low · Editor-only build processing code — Dots101/ContentManagement101/Assets/2. WeakSceneLoading/Content Settings/Editor/. Editor scripts (BuildPostProcessing.cs, ContentBuilder.cs) have access to sensitive build processes. While these are development-only, they could potentially be exploited during development. Fix: Ensure editor scripts use appropriate access modifiers and are properly protected. Review build post-processing scripts for any security-sensitive operations. Consider code review processes for build automation code.

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.