Choose one small result for your first mod: load a plugin, change one player action, draw one image, or load one room. Follow the matching route below. Use the question index when you already know what you want to do.
A useful first milestone
A plugin that loads and prints one message gives you a working build-and-test loop. A single room with a correct render gives a region author the equivalent starting point. Keep that working version before adding another feature.
Choose your route
| Intended result | First reading | Small first check |
|---|---|---|
| Change gameplay in C# | Development workspace and First plugin | Build and load one plugin |
| Make a room or region | Room authoring and Region folder layout | Load one exported room |
| Define a custom character | SlugBase characters | Select one character with valid JSON |
| Create an item or creature | Object lifetimes and Fisobs items | Understand how an existing item is realized |
| Add graphics or sound | Drawable lifetime or Sound playback | Draw a marker or play one existing cue |
These routes can meet later. A region package may use a library for placed objects, and a character can add a plugin for custom abilities. Add a dependency when a feature needs it, then declare it in the package manifest.
The code route
Start with a complete project file for your own mod. Operating systems covers the build tools and game-testing setup for your platform.
- Build the first plugin and find its startup message with the logging guide. Keep a copy of the successful DLL.
- Learn the handler shape in C# for hooks and the timing in hook lifecycle. Attach one additive hook and preserve
orig. - Follow object interaction, then add a player ability. Read input and state ownership when the recipe uses them.
- Add a Remix toggle. Use the storage guide before retaining values across sessions.
- Run controlled tests, then prepare a release package.
Reading game code helps when the next change has no recipe. IL hooks are a later topic for changes that need instruction-level access.
The region route
- Create and render one room through room authoring. Keep the editable project separate from its exported files.
- Place the outputs using the region folder layout. Match the room identifier and camera image names.
- Add another room and test connections in both directions. Map positions and travel connections are separate data.
- Add settings, then one placed object or creature spawn. Test each addition before expanding it.
- Follow the troubleshooting order and package through the release checklist.
The character route
- Create a character definition with a stable ID.
- Choose a valid starting world and room. Confirm that the room exists for the selected timeline.
- Add selection art using one image before trying a layered scene.
- Implement a custom feature only when JSON-defined behavior needs your own code. Keep cooldowns separate from character parameters.
- Test save behavior before adding story progress or dialogue.
Read examples at their stated scope
The wiki distinguishes a complete example, a code fragment, and a format illustration. A fragment may need an existing plugin, an initialized field, or a particular callback. A world-file example still needs matching room files.
Check each page’s verification details. Source inspection verifies what the recorded implementation does. Compilation verifies references and syntax. An in-game test is needed to establish loading, behavior, appearance, sound, or persistence in your setup. The runtime reference identifies the versions used here.