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/CleverRaven/Cataclysm-DDA 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.

GO — Healthy across the board

• Last commit today
• 11 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{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 CleverRaven/Cataclysm-DDA repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/CleverRaven/Cataclysm-DDA.

What it runs against: a local clone of CleverRaven/Cataclysm-DDA — 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 CleverRaven/Cataclysm-DDA | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "CleverRaven/Cataclysm-DDA(\\.git)?\\b" \\
  && ok "origin remote is CleverRaven/Cataclysm-DDA" \\
  || miss "origin remote is not CleverRaven/Cataclysm-DDA (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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "android/app/build.gradle" \\
  && ok "android/app/build.gradle" \\
  || miss "missing critical file: android/app/build.gradle"
test -f ".github/workflows/matrix.yml" \\
  && ok ".github/workflows/matrix.yml" \\
  || miss "missing critical file: .github/workflows/matrix.yml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

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

Cataclysm: Dark Days Ahead is a turn-based roguelike survival game written in C++ with a procedurally generated post-apocalyptic world. Players scavenge for resources, build/repair vehicles, craft items, and fight diverse monsters from zombies to killer robots in a persistent, complex game world with deep simulation mechanics. Monolithic C++ application with modular data layer: src/ contains engine code (gameplay, rendering, UI), data/ holds JSON-defined content (items, monsters, recipes, mapgen), and tests/ provides unit coverage. Cross-platform builds via CMake (CMakeLists.txt) with separate ncurses and SDL2 rendering backends; Gradle wraps Android builds; Python and shell scripts handle build automation and code generation.

Game developers and modders interested in open-source roguelike design, C++ game programming, and procedural generation; also hardcore survival game players who want deep mechanics, modding support, and community-driven content via JSON data files.

Highly mature and actively developed: the project has 28.8M lines of C++ code, robust CI/CD with GitHub Actions (matrix.yml, clang-tidy, CodeQL, astyle validation), test coverage tracking, and frequent commits. Production-ready with extensive platform support (Linux, Windows, macOS, BSD, Android, Emscripten) and established packaging in Arch, Fedora, Debian/Ubuntu, and Flatpak.

Low risk for a community project: established contributor base, comprehensive tooling (clang-tidy, CodeQL, astyle enforcement), and .github/workflows automation. Main risks are legacy C++ codebase requiring careful refactoring, large scope makes onboarding harder, and reliance on volunteer contributions for less-popular features. No apparent single-maintainer bottleneck.

Active development across multiple domains: GitHub Actions workflows indicate ongoing work on translation builds (build-translations.yml), Android bundle releases, Emscripten web port, code quality checks (clang-tidy, CodeQL, IWYU), and tileset composition (compose-tilesets.yml). The codebase has robust CI preventing regressions.

git clone https://github.com/CleverRaven/Cataclysm-DDA.git && cd Cataclysm-DDA && mkdir build && cd build && cmake .. && make -j$(nproc) (Linux/macOS); see doc/c++/COMPILING.md for detailed OS-specific instructions including Windows (MSVC), Android (Gradle), and BSD.

Daily commands: make (Makefile variant) or cd build && make after cmake .. (CMake variant). For ncurses: make RELEASE=1 TILES=0; for SDL tiles: make RELEASE=1 TILES=1. Android: ./gradlew assembleRelease. Web: emcripten build via GitHub Actions (see .github/workflows/emscripten.yml).

• CMakeLists.txt — Root build configuration for cross-platform compilation; defines all targets, dependencies, and platform-specific settings that every contributor must understand.
• android/app/build.gradle — Android build configuration and dependency management; essential for Android platform contributors and understanding the build matrix.
• .github/workflows/matrix.yml — Defines the multi-platform CI/CD pipeline (Windows, Linux, macOS, Android, Emscripten); critical for understanding how code is tested and built.
• README.md — Project overview, philosophy, and download links; every contributor should understand the game's scope and survival-game design goals.
• CONTRIBUTING.md — Contribution guidelines, coding standards, and submission process; mandatory reading for all pull request authors.
• .clang-tidy — Code quality and linting rules enforced across the C++ codebase; defines static analysis expectations for all contributors.
• .astylerc — Automated code formatting rules for C++ sources; ensures consistent style across the 600-file codebase.

Add a new platform or build target

1. Define target-specific compiler flags and sources in CMakeLists.txt root configuration (CMakeLists.txt)
2. Add platform-specific build configuration preset in CMakePresets.json (CMakePresets.json)
3. Create a new GitHub Actions workflow YAML in .github/workflows/ for the platform matrix (.github/workflows/matrix.yml)
4. For Android, add ABI and NDK flags in android/app/jni/Application.mk (android/app/jni/Application.mk)
5. Update CMake Find modules in CMakeModules/Find/ if platform requires custom dependency discovery (CMakeModules/Find/FindSDL2.cmake)

Enforce a new code quality rule

1. Add the rule to .clang-tidy for C++ static analysis enforcement (.clang-tidy)
2. Update .astylerc if the rule relates to code formatting or style (.astylerc)
3. Update .editorconfig if the rule affects indentation or line endings (.editorconfig)
4. Enable the check in the clang-tidy GitHub Actions workflow (.github/workflows/clang-tidy.yml)
5. Document the rule in CONTRIBUTING.md under coding standards section (CONTRIBUTING.md)

Add automated labeling or PR validation

1. Define label rules based on file paths in .github/labeler.yml (.github/labeler.yml)
2. Add validation logic to .github/comment-commands.yml for custom bot commands (.github/comment-commands.yml)
3. Create or update a workflow YAML in .github/workflows/ (e.g., pr-validator.yml, check-branch-name.yml) (.github/workflows/pr-validator.yml)
4. Update .github/ISSUE_TEMPLATE configuration if new issue types need templates (.github/ISSUE_TEMPLATE/config.yml)

Set up development environment for a new platform

1. Create a new devcontainer.json in .devcontainer/ for the target platform (.devcontainer/devcontainer.json)
2. Define a Dockerfile in .devcontainer/ with all required build tools and dependencies (.devcontainer/Dockerfile)
3. For cross-compilation, add platform-specific preset to CMakePresets.json (CMakePresets.json)
4. Document build instructions in CONTRIBUTING.md setup section (CONTRIBUTING.md)

• CMake (primary build system) — Cross-platform compilation abstraction; supports Windows (MSVC), Linux (GCC), macOS (Clang), Android (NDK), and Emscripten with a single configuration
• C++ (primary language) — Performance-critical for turn-based game loop, procedural generation, and real-time rendering with SDL2
• SDL2 + SDL2_image/mixer/ttf (graphics & audio) — Cross-platform abstraction for rendering, input handling, and audio; enables desktop (Windows/Linux/macOS) and mobile (Android) builds from shared code
• Android NDK (Android platform) —

Procedural world generation uses seeds for reproducibility, so tests may depend on seed state—verify in worldfactory.cpp before modifying generation. JSON content files must strictly follow schema or cause silent load failures; use JSON linter (see .github/workflows/json.yml). Android builds require keystore.properties for signing (see build.gradle snippet), else release builds fail. Translations rebuild on master changes (build-translations.yml), affecting merge timing. The codebase uses optional features (TILES, SOUND, TESTS) controlled at compile time; ensure your changes don't break ncurses-only or headless builds. Emscripten builds are experimental (see .github/workflows/emscripten.yml); not all features work on web.

• Procedural Map Generation with Seeds — Cataclysm generates infinite persistent worlds deterministically via seeds in worldfactory.cpp—understanding seed-based RNG is essential to adding new terrain types or special locations without breaking reproducibility
• Turn-Based Simulation Loop — The core game loop in game.cpp processes player actions, NPC turns, and monster AI each turn; modifying or optimizing this affects all game feel and balance
• JSON Schema Data-Driven Content — All game content (items, monsters, recipes) is defined in JSON with implicit schemas in data/ rather than code; enables mods and content updates without recompilation, but requires strict adherence to schema
• Abstract Rendering Backend Pattern — ui.cpp abstracts rendering to support both ncurses (terminal) and SDL2 (graphical) backends; adding new visual features requires implementing both backends consistently
• Chunked World Representation — Map data in map.cpp is stored in chunks to enable large open worlds without loading all terrain into memory; understanding chunk loading/unloading is critical for memory-efficient survival game design
• Cross-Compilation via CMake — The project builds for 6+ platforms (Linux, Windows, macOS, BSD, Android, Emscripten) via CMake with platform-specific flags; adding new platform support or conditional features requires CMake expertise
• NPC/Monster AI via Behavior Trees and Pathfinding — Cataclysm's monster and NPC behavior is driven by AI systems handling pathfinding, goal selection, and combat tactics; modifying difficulty or adding new enemy types requires understanding these decision systems

• rogue-likes/mangband — Classic roguelike ancestor sharing turn-based mechanics and procedural generation philosophy, though less complex survival sim
• UnidayStudio/RoguelikeDungeon — Modern open-source roguelike with similar JSON data-driven design for content, though focused on fantasy dungeon crawling vs. post-apocalyptic survival
• CleverRaven/Cataclysm-DDA-Android — Official Android port companion repo providing mobile distribution and platform-specific optimizations
• CleverRaven/Cataclysm-DDA-Tiles — Tileset repository containing graphics and sprite definitions used by SDL2 tiles build target
• naev/naev — Similar open-source game using C with procedural generation and complex simulation, demonstrating alternative architecture for large game projects

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 workflow for Android build validation on pull requests

The repo has complex Android build configuration in build.gradle (with ABI selection, localization flags, keystore handling) but no CI workflow validating Android builds before merge. The .github/workflows directory has many workflows (matrix.yml, msvc-full-features.yml, emscripten.yml) but no Android-specific validation. This would catch Android-specific regressions early and ensure the gradle configuration remains functional.

• [ ] Create .github/workflows/android-build.yml that compiles Android variants using the gradle build configuration
• [ ] Reference the ABI flags (abi_arm_32, abi_arm_64, abi_x86_32, abi_x86_64) from build.gradle to test multiple architectures
• [ ] Validate with and without localization (localize flag) to catch translation integration issues
• [ ] Run on pull requests to src/, data/, and build.gradle changes to avoid unnecessary CI runs

Add input validation and unit tests for JSON game data loaders

The repo contains extensive JSON configuration in the data/ directory (visible from CDDA being a data-driven game with procedural generation, JSON linting in .github/workflows/json.yml, and flake8/linting setup). However, there's no evidence of unit tests validating that JSON parsers correctly handle malformed input, missing required fields, or edge cases. A dedicated test suite would prevent silent data loading failures and improve game stability.

• [ ] Examine src/ for JSON loading code (likely in a json_reader.cpp or similar based on typical C++ game architecture)
• [ ] Create tests/json_loader_test.cpp with test cases for: missing required fields, invalid types, null values, empty arrays, and circular references
• [ ] Add tests validating critical data structures (items, monsters, recipes from data/*.json) can be parsed and validated
• [ ] Integrate into existing test CI or create tests/CMakeLists.txt if not present

Create comprehensive devcontainer setup for Windows native development

The repo has devcontainers for cross-compilation (.devcontainer/cross-compile/Dockerfile) and graphical development (.devcontainer/graphical/Dockerfile), but the build.gradle Android configuration and .vscode/msbuild.ps1 PowerShell script suggest Windows native MSVC builds are important. There's no Windows devcontainer despite .github/workflows/msvc-full-features.yml indicating MSVC is a primary build target. This would lower barriers for Windows-based contributors.

• [ ] Create .devcontainer/windows/Dockerfile installing MSVC buildtools, CMake, vcpkg, and dependencies from .github/vcpkg_triplets/
• [ ] Create .devcontainer/windows/devcontainer.json with mounts for vcpkg cache and MSVC toolset configuration
• [ ] Document in .devcontainer/windows/README.md how to use the container with VS Code's Dev Containers extension
• [ ] Validate the setup can successfully build using CMakeLists.txt with MSVC triplets (x64-windows.cmake, x86-windows-static.cmake)

• Add unit tests for JSON schema validation in data/ to catch malformed monster/item definitions early—tests/ currently lacks dedicated JSON schema coverage, causing runtime errors instead of compile-time feedback
• Improve cross-platform CMake documentation: add comments to CMakeLists.txt explaining Android/Emscripten/MSVC-specific flags since new contributors often fail on non-Linux builds
• Create a 'common modding pitfalls' guide in doc/ explaining the JSON content system, seed-based mapgen gotchas, and how to test mods locally without full recompilation (currently undocumented)

The codebase shows reasonable security practices for an open-source game project, with proper UTF-8 encoding and conditional build logic. However, there are moderate concerns around keystore and local properties file management, which could expose cryptographic credentials if not properly protected. An incomplete gradle property assignment requires immediate attention. The project would benefit from enhanced dependency management with lock files, explicit signing verification, and clear documentation of credential handling practices for contributors. No evidence of injection vulnerabilities, hardcoded secrets in visible code, or critical misconfigurations was found in the analyzed files.

• High · Keystore Properties File Management — build.gradle (keystore.properties handling). The build.gradle file loads keystore properties from a configurable file path. The default filename 'keystore.properties' and its actual location are not properly validated. If this file contains sensitive cryptographic keys or passwords for signing Android releases, it could be accidentally committed to version control or exposed. Fix: Ensure keystore.properties is in .gitignore, use environment variables or secure build secret management for sensitive credentials, and document secure key storage practices for contributors.
• Medium · Local Properties File Security — build.gradle (local.properties handling). The build.gradle loads local.properties which may contain sensitive build configuration. While this is a common Android practice, it can inadvertently expose API keys, credentials, or build secrets if not properly managed. Fix: Ensure local.properties is in .gitignore, document which properties should never be committed, and consider using environment variables for sensitive configuration.
• Medium · Incomplete Gradle Property Assignment — build.gradle (abi_x86_64 variable definition). The build.gradle file contains an incomplete property assignment: 'def abi_x86_64 = getProperty' which appears to be cut off. This syntax error could cause build failures or unexpected behavior if the file is actually in this state. Fix: Complete the property assignment and ensure all gradle property definitions follow the pattern used for other ABI variables.
• Medium · Cleartext Encoding Specification — build.gradle (JavaCompile configuration). While specifying UTF-8 encoding is good practice, the build configuration doesn't explicitly validate or enforce secure handling of compiled artifacts. No security checks are visible for unsigned APK/AAB outputs or unvalidated release builds. Fix: Implement signing verification for release builds, add security scanning for APK/AAB outputs, and enforce secure build configurations through gradle plugins.
• Low · Missing Gradle Wrapper Validation — Project root (gradle/wrapper configuration not visible). The file structure shows build.gradle but no evidence of gradle-wrapper configuration details. Gradle wrapper integrity is important to prevent man-in-the-middle attacks during dependency downloads. Fix: Use gradle-wrapper with SHA-256 verification, document the wrapper version in version control, and verify wrapper checksums during CI/CD builds.
• Low · No Visible Dependency Lock File — build.gradle and project root. The provided build.gradle snippet doesn't show lock files (like gradle.lockfile) which are important for reproducible builds and preventing dependency injection attacks. Fix: Implement dependency locking using gradle.lockfile, commit lock files to version control, and regularly update and audit dependencies.

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.