Repository navigation
Home
Welcome to the Captivity Reloaded modding wiki. This documentation explains how to create, test, package, and publish mods for the data-driven Mod API.
Content notice: The game and some examples contain mature sexual themes. Individual catalog entries may contain additional warnings.
Captivity Reloaded uses Unity 2021.3.45f1. Most mods are ordinary folders of JSON and assets; Unity is used when you need the project’s authoring, preview, validation, or packaging tools.
If this is your first mod, follow these pages in order:
- Set up the modding environment.
- Build your first pack.
- Learn how pack IDs and files work.
- Copy the closest working pack from the example pack index or
ModSDK. - Validate and package the mod.
- Complete the mod-author test matrix.
- Publish it to the community catalog.
- Asset patches for published Core artwork slots.
- Inherited weapons or usable items.
- Inherited clothing, hairstyles, and equipped stat changes.
- Challenges, difficulties, and rule profiles.
- Small changes built from a maintained example pack.
These projects reuse existing Core behavior and normally require fewer files and less runtime testing.
- Original enemies with custom atlases, movement, attacks, and effects.
- Player and enemy animations, including optional DragonBones round trips.
- Tiled stages and maps.
- Stage scripts, interactions, machines, encounters, and room transitions.
- Unity-authored assets packaged into platform-specific AssetBundles.
Advanced content has more cross-file references and should be tested on every platform and movement type it claims to support.
A mod is a versioned pack with a manifest.json, namespaced content IDs, and declared dependencies. The loader discovers enabled packs, resolves their order, validates their content, and registers supported definitions without allowing arbitrary mod C# code.
Mods can inherit reviewed Core templates, provide fully data-defined content, or replace explicitly published asset slots. Stable content IDs reconnect saves and dependencies across updates. Read Core concepts for the model and Implementation status for the current feature boundary.
Warning
Mod API v1 is in freeze review. Fields marked Experimental may change before promotion. The JSON Schemas and runtime validator are authoritative over tutorial snippets.
Mod authors still need to test the same artifact their users receive. Installing and managing mods covers loose folders, .capmod files, the in-game catalog, updates, rollback, disabling, and uninstalling. Read Windows, Android, and WebGL before making cross-platform claims.
| Need | Go to |
|---|---|
| Exact JSON properties and limits | Field-by-field API reference |
| Authoritative JSON contracts | Schema index |
| Patchable Core artwork | Public asset-slot catalog |
| Runtime diagnostic codes | Validation and error-code catalog |
| Defaults and compatibility rules | Defaults and compatibility |
| Common failures | Troubleshooting |
| Mod API changes | Changelog and migration guides |
Project contributors should use:
- Development setup
- Building and testing
- Repository layout
- Contributing documentation
- Release verification runbook
The detailed cross-file contract lives in the Mod API v1 specification. Documents outside Docs/Modding/Public contain implementation history and planning notes rather than user instructions.
Published from Docs/Modding/Public. The repository documentation is the canonical source.
Captivity Reloaded wiki* Captivity Reloaded Wiki
- Getting started
- Core concepts
- Content types
- Authoring tools
-
Reference
- Example pack index
- Schema index
- Field-by-field API reference
- Public asset-slot catalog
- Core enemy asset slots
- Validation and errors
- Validation/error-code catalog
- Mod API changelog
- Migration guides
- Troubleshooting
- Glossary
- Defaults and compatibility
- Resource limits
- Mod-author test matrix
- Implementation status
- Mod API v1 release checklist
- Release verification runbook
- Release evidence template
- Licensing and redistribution
- Development