Skip to content

Portable content creation tool

Status: future idea. No framework or implementation has been chosen.

Goal

Explore a small app that helps the owner and AI assistants create abilities, characters, enemies, stages, upgrades and items. It should be useful on different computers and reduce repetitive Unity setup. Consider sprite and animation support as well.

Proposed approach

  • Shared creation engine: accept structured instructions, check the requested content and report results. The AI can use this without opening the app.
  • Small desktop app: use the same engine to offer forms, search, previews and clear error messages. Drafting should work offline without Unity where practical.
  • Unity import: when the project and matching Unity Editor are available, use the Unity command line to create or update Unity assets and run focused checks without opening the graphical Editor. A machine without the project and Unity can prepare a draft, but cannot complete this step locally. A remote worker is a separate future choice.

The Unity project remains the source of truth for game content. Draft files are proposals, not a second independent content database. Track whether content is a draft, has passed checks, has been imported, or has actually been tested in the game.

Example: create and try an ability

  1. The owner asks the AI for an ability. The AI asks about behavior or other details only when needed, then prepares the definition, code and related upgrade using the project rules.
  2. Ask whether an icon already exists. Allow the owner to add or replace it later; show a clear missing-icon state instead of blocking a draft.
  3. Reuse the existing sprite slicing or cropping workflow where possible. Check how its settings and frame data are stored before deciding what the app can preview or edit.
  4. Show the ability's information, icon, linked upgrade and check results in the app. Keep internal IDs stable and out of the normal editing view.
  5. The app or AI asks Unity to import and check the changes. Once a suitable test build is available, launch the test stage with the requested character and content selected. The owner tries the behavior and records the result.

For the first test connection, consider passing a test selection when launching the game. Live control from the app while the game is already running is a separate, more complex option. Label a directly granted ability so it is not mistaken for testing the normal reward path. Creating new code generally requires a new build before a built game can use it; group changes to avoid unnecessary builds. The current test stage cannot yet select a specific ability or accept an app's test selection.

Useful features

  • Start from existing patterns or templates, then show only fields relevant to the chosen content.
  • Generate internal IDs safely, hide them in normal editing, and keep existing IDs and Unity asset references stable.
  • Preview names, descriptions, values, sprites and simple animation frames. Later, explore importing spritesheets, setting up animation clips and connecting existing animation controllers.
  • Show missing references, invalid values and duplicate IDs before writing. Show a preview of files that would change.
  • Give the AI a command-line interface with clear results and errors; the app uses the same operations.
  • Later, connect created content to the short test stage for the owner to try. Show whether the content passed automated checks, was manually played, or still needs a check.

Important limits

  • A unique ability or enemy behavior may still need new code and a Unity compilation. Templates can cover common behavior; they cannot automatically guarantee a new idea works.
  • Importing images and animation data is different from drawing sprites or building a full animation editor. Start with existing files and simple previews.
  • Preserve existing IDs, metadata, authored values and player data. Do not silently overwrite files; handle an already-open Unity project safely.
  • Keep the creation rules in one place or verify them against the project so the app and Unity do not gradually disagree.
  • Build and test separately for supported operating systems. A small app can still need operating-system components; mobile support is not assumed.

Small first experiment

  1. Choose one common, data-based upgrade as a complete example. List its real fields and references.
  2. Create and validate a draft using the shared command-line engine. Preview the proposed changes and errors.
  3. Import it through the matching Unity Editor in batch mode, preserving IDs and existing files. Run a focused check and record the outcome.
  4. Add a small app screen using the same operation only if the experiment saves enough work. The owner tests the resulting upgrade in the test stage when practical.
  5. Add other content types one at a time after the first path works.

Compare TinyJS and Tauri when this work starts. TinyJS uses JavaScript for the desktop app and its backend; Tauri uses a Rust core and supports external helper programs. Both use the operating system's web-view component, so platform requirements and distribution need testing. Keep the creation engine independent of either choice where practical.