Caelis
An AI tool for making RPG Maker MZ development faster without taking control away from the creator.
Caelis began with a practical question: if agentic software development was getting faster, why did building an RPG Maker game still feel so slow?
The situation.
I wanted to spend more time working on my games. Agentic development was making ordinary software dramatically faster to build, but game development, especially in RPG Maker MZ, still involved a lot of slow, repetitive setup and content population. The gap became frustrating enough that I wanted to build something for my own workflow.
Then I noticed the opening: RPG Maker MZ uses JavaScript, stores much of a project in readable JSON, and follows a relatively simple folder hierarchy. An AI tool did not need to replace the engine or generate a whole game; it could work with those existing structures to understand a project and help populate it.
What I did.
I created and maintain Caelis as an independent, public repository, combining product engineering and agent-tool design with years of using RPG Maker. I shaped it first as a tool I would genuinely use on my own games: inspect what is already there, understand how the pieces relate, and reduce the repetitive work of populating a project.
My key design decision was to make the write path visible: inspect, create a persisted plan, review it, confirm it, validate it, and retain a backup/rollback route. This keeps the creator's judgement above the agent's output instead of treating generated changes as inherently safe.
How the work unfolded.
Work with RPG Maker’s real structure
Used MZ’s JavaScript, JSON data, and predictable folder hierarchy as the foundation for project inspection and content tooling instead of placing another opaque layer over the engine.
Separate reading from writing
Built read-only project intelligence independently of mutations so a creator can investigate a project without granting an agent permission to alter it.
Put a reviewable plan before every change
Designed guarded operations around persisted plans, stale checks, validation, backups, explicit confirmation, and rollback on failure.
Respect plugin and asset boundaries
Used source-free plugin profiles and public metadata rather than extracting proprietary plugin implementation or copying paid documentation.
Keep project memory local
Developed a portable project-local Codex for entities, assertions, decisions, sources, and session memory without making a remote service the default.
What happened.
Caelis now has a working foundation for inspecting RPG Maker MZ projects, validating their data, understanding plugins, keeping project memory locally, and preparing database or event changes through a reviewable plan.
The most important result was the safety model. Reading a project is separate from changing it, every write begins with a persisted plan, and validation, backups, confirmation, and rollback keep the creator in control of what the agent changes.
What I learned.
The engine already exposed the opportunity
RPG Maker MZ’s JavaScript, JSON, and straightforward project layout made focused AI tooling more useful than trying to replace the engine.
Agent safety is interaction design
A confirmation step, readable diff, validation result, and recovery path are product features, not merely implementation details.
Local-first can be a product choice
Keeping project knowledge close to the project improves portability and gives creators clearer control over their material.
Capability needs a boundary
Tooling can be useful without reproducing proprietary plugins, paid manuals, or game assets; stating what it will not do builds trust.
Related links.
Repositories, demos, event pages, posts, and other places connected to this project.