Make
Use the relevant creation role: 3D form or 2D sprites.
The intended asset workflow
A family of tools should make the creative process easier to understand. Maple’s workflow starts with a clear division of responsibilities, then develops the connections between them.
The Maple family is organized around the job being done. An asset may need creation, animation, conversion, or runtime use, but those are not automatically the same step.
Foundry defines general-purpose 3D modeling. Soar defines animation. Design defines 2D sprite creation. Morph defines supported external-asset conversion. Engine supplies the running-world foundation.
This is a conceptual map of the suite, not a claim that every handoff or shared format is already released.
Use the relevant creation role: 3D form or 2D sprites.
Use the animation role when the asset needs authored movement.
Use a supported conversion route when the input requires it.
Use assets within the world and systems of the runtime.
A 3D modeling task belongs to Foundry’s intended role. A movement-focused task belongs to Soar’s role. A two-dimensional sprite belongs to Design’s role. The division is about purpose rather than forcing every creative project into one workflow.
Foundry’s current early scope is narrower than the complete modeling ambition, focusing on static-asset inspection, organization, transformation, validation, and preparation. The product direction extends to general-purpose 3D modeling.
Soar and Design are introduced by their planned purposes. Specific feature support, file formats, and complete integration with the other applications remain to be verified and announced.
Morph is intended to convert supported external assets into Maple-native assets. Support needs to be specific to the input and the information being carried through.
A conversion route should eventually make its limits clear: which assets it accepts, what information is preserved, what cannot be represented, and what the destination requires. No such public compatibility matrix is announced here.
That makes Morph a bounded preparation role, not a promise that every external file or workflow will work automatically.
Read about Morph’s scopeMaple Engine is the runtime foundation. Grevara is the current game project giving that foundation a concrete purpose: ships, crew, utilities, memory, damage, repair, and continuity.
An asset alone does not define all of its game behavior. Runtime systems need to place it within the experience, with coherent state and relationships to the other systems around it.
The existing engine editor, scene tools, detached windows, and debugger are Engine foundations. They do not erase the separate responsibility of Foundry as a creative application.
Not every asset needs to visit every application. The intended route depends on what it is, where it was made, what it needs to do, and what support is actually available.
This page does not promise a completed common project format, a lossless round trip, universal conversion, released integrations, or a public SDK. It explains the family’s responsibilities so the product direction is clear.
No public suite download, price, license program, or release date is announced here. For project and workflow inquiries, email contact@casilian.com.
Start a conversation
Questions about the Maple workflow, collaboration, or the work behind it? Contact the studio directly.