Editor development: choose an extension point
Plugin, tools, theme or core: where to start and what to verify.
Editor development
First decide whether to extend the editor from a project or change its C++ implementation. Most panels, resource audits and commands can start as an EditorPlugin without rebuilding the engine.
| Task | Start here |
|---|---|
| Custom panel and command | EditorPlugin and EditorDock. |
| Dedicated workspace | Main-screen plugin. |
| Custom property editor | Inspector plugin. |
| Code running while a level is edited | Tool code. |
| Consistent colors, icons and sizes | Tool theming. |
| Built-in behavior unavailable through the API | Editor architecture, then a separate source build. |
Minimal working cycle
- Create a separate project for the tool. Do not begin with bulk changes to a working project or the installed Runtime.
- Define one operation, such as auditing resources in the selected level. Separate reading from actions that modify files or the Entity tree.
- Use public EditorInterface methods and an intended extension point. Searching internal controls by name or button text is not a stable plugin API.
- Register elements when the plugin is enabled and remove them when disabled. Check repeated activation without duplicate panels or handlers.
- Support undo/redo for level changes. A working button that only reads the tree does not prove correct editing or undo behavior.
- Check long text, window size, keyboard focus and the selected theme, then reopen the project.
When C++ is needed
If the public contract is missing, first locate the feature owner in current source and determine a minimal change. Building an editor and installing it over a working engine are separate actions. Use a separate binary for experiments; see engine development.
Do not copy internal filenames and class names from an old guide without checking: the editor structure changes. C# API identifiers must match the installed SDK.
Reckfell Engine documentationBack to top ↑