Overview
METK is a desktop editor for building tile-based game maps. Its current foundation includes layer-based editing, tileset handling, rule-oriented tooling, TMX export workflows, and a multi-panel workspace.
The architecture keeps UI, application orchestration, editor models, rendering, and platform APIs distinct. React handles interface composition while PixiJS owns high-frequency canvas rendering and Tauri supplies desktop capabilities.
Problem
Interactive editors combine dense UI, mutable document state, high-frequency rendering, file processing, and native desktop behavior. Coupling those concerns directly to React would make performance, testing, and long-term extension harder.
Engineering scope
The repository includes React workspace UI, editor models and sessions, application managers and commands, PixiJS canvases, Zustand state, XML/JSON processing, TMX export, Tauri file and dialog integration, internationalization, and unit/integration tests.
Editor architecture
The interface delegates workflows to an application layer, which coordinates editor-domain objects and sessions. Rendering reads the domain through a PixiJS boundary, while file import/export and desktop operations stay behind infrastructure-facing services and Tauri APIs.
Key editor capabilities
Layered workspace
Dockable editor regions for properties, tilemaps, tilesets, layers, rulesets, and entity collections.
Tilemap rendering
PixiJS and pixi-viewport handle canvas rendering and navigation outside React's high-frequency render loop.
Editor operations
Application managers, sessions, and command objects coordinate changes to editor state.
File workflows
Tauri file/dialog APIs and dedicated processing layers support project resources and TMX export.
Engineering decisions
Keep canvas rendering outside React
- Problem
- Tilemap interaction can produce updates at a frequency and scale that do not fit ordinary component rendering.
- Decision
- Use PixiJS and pixi-viewport as a dedicated graphics layer while React composes panels and controls.
- Tradeoff
- Performance boundaries are clearer, but synchronization between UI state and renderer state must be designed deliberately.
Commands and application managers
- Problem
- Editor actions can affect document models, selection, sessions, views, and persistence at once.
- Decision
- Route workflows through application managers and command objects instead of embedding them in UI components.
- Tradeoff
- There are more explicit layers and types, in exchange for testable operations and lower UI coupling.
Tauri desktop shell
- Problem
- The editor needs native file and dialog capabilities while retaining a TypeScript interface and graphics stack.
- Decision
- Package the application with Tauri and expose focused native commands/plugins to the frontend.
- Tradeoff
- The project carries Rust and platform build requirements, but avoids shipping a browser-only file workflow.
Challenges & tradeoffs
- Synchronize React panels, Zustand state, editor sessions, and PixiJS render state without making one layer own everything.
- Normalize tilemap, tileset, layer, entity, and selection data across import, editing, and export paths.
- Keep a complex, docked workspace usable while the editor remains in active development.
- Design extension points for rules and future plugins without prematurely fixing an unstable API.
Technology
- 01Tauri
- 02React
- 03TypeScript
- 04PixiJS
- 05Zustand
- 06Tailwind CSS
- 07Vitest
Current outcome
- An operational desktop editor foundation with a real multi-panel workspace and tilemap canvas.
- A modular source structure covering application workflows, editor models, graphics, platform integration, and tests.
- Active development continues; the repository explicitly does not present the current build as a polished end-user release.
Links
The AGPL-licensed source repository is public. Release packaging and a public live demo are not currently presented as available.
View repository