182 lines
8.4 KiB
Markdown
182 lines
8.4 KiB
Markdown
---
|
|
id: DEC-0026
|
|
ticket: studio-scene-workspace
|
|
title: Scene Workspace Ownership and Wave-1 Tilemap Scope
|
|
status: abandoned
|
|
created: 2026-04-14
|
|
accepted: 2026-04-14
|
|
agenda: AGD-0029
|
|
plans:
|
|
- PLN-0049
|
|
- PLN-0050
|
|
- PLN-0051
|
|
- PLN-0052
|
|
tags:
|
|
- studio
|
|
- workspace
|
|
- scene
|
|
- tilemap
|
|
- asset
|
|
- runtime-alignment
|
|
---
|
|
|
|
## Decision
|
|
|
|
The Studio SHALL introduce a dedicated `Scene Workspace` as a first-class shell workspace for scene authoring.
|
|
|
|
The `Scene Workspace` MUST own the authoring lifecycle of scenes as scenes, not as asset-detail forms.
|
|
|
|
The Studio SHALL treat the edited scene as an intermediate authoring artifact owned by the `Scene Workspace`.
|
|
|
|
The `Scene Workspace` MAY create a new scene and, as part of that flow, create the corresponding `SCENE` asset.
|
|
|
|
The `Assets` workspace MAY also create a `SCENE` asset, but it MUST NOT paint tilemaps, edit scene content, choose scene tilesets, or own other editorial scene configuration.
|
|
|
|
When a `SCENE` asset is created from `Assets`, authoring and subsequent editing MUST be delegated to the `Scene Workspace`.
|
|
|
|
The first implementation wave of the `Scene Workspace` SHALL expose only the `Tilemap` aspect.
|
|
|
|
The wave-1 `Tilemap` aspect MUST support:
|
|
|
|
- a left scene navigator;
|
|
- a central map editing surface;
|
|
- a right-side tilemap details area with dimensions and layer-relevant detail;
|
|
- a tile palette area for tile selection and painting;
|
|
- four canonical scene layers;
|
|
- independent layer dimensions;
|
|
- scene-first navigation;
|
|
- explicit tile presence semantics aligned with the runtime model;
|
|
- basic painting, erasing, tile selection, layer visibility, and layer focus.
|
|
|
|
The wave-1 `Scene Workspace` MUST NOT include:
|
|
|
|
- authoring for camera boundaries;
|
|
- authoring for lights;
|
|
- authoring for AABB data;
|
|
- placeholder tabs that imply those capabilities already exist;
|
|
- advanced paint tools such as marquee, bucket fill, flood fill, or equivalent higher-order tooling.
|
|
|
|
The `Scene Workspace` MUST use an explicit and stable binding between the intermediate scene artifact and the corresponding `SCENE` asset.
|
|
|
|
That binding MUST NOT rely on path inference as its primary semantic anchor.
|
|
|
|
The `Scene Workspace` MUST own editorial tileset selection for the scene.
|
|
|
|
Any technically valid glyph bank MAY be referenced as a tileset under the scene-authoring model.
|
|
|
|
Optional Studio-only curation such as tagging glyph banks for better discoverability MAY exist, but it MUST NOT redefine the underlying capability contract.
|
|
|
|
## Rationale
|
|
|
|
This decision separates two different responsibilities that would otherwise collapse into one another:
|
|
|
|
- scene authoring as an editorial workspace concern;
|
|
- asset management as an asset-first Studio concern.
|
|
|
|
Keeping the `Scene Workspace` independent prevents the `Assets` workspace from becoming a generic container for heavy domain editors.
|
|
|
|
That separation also matches the user-facing intent:
|
|
|
|
- the `Assets` workspace can create or surface a `SCENE` asset;
|
|
- the `Scene Workspace` is where the user actually authors the scene.
|
|
|
|
Wave 1 is intentionally narrow.
|
|
|
|
The goal is to prove the canonical scene-authoring loop around tilemaps, layers, tileset selection, and save semantics before introducing additional aspect domains such as camera, lights, or collision-adjacent editing.
|
|
|
|
The decision also keeps the Studio aligned with the runtime model already present in `../runtime`:
|
|
|
|
- four canonical layers;
|
|
- per-layer tilemaps with independent dimensions;
|
|
- explicit tile presence rather than magic empty glyph ids;
|
|
- no leakage of viewport-cache or transient renderer concerns into authoring ownership.
|
|
|
|
## Technical Specification
|
|
|
|
### 1. Workspace Topology
|
|
|
|
- The Studio shell MUST mount `Scene Workspace` as its own workspace entry.
|
|
- The `Scene Workspace` MUST follow the same shell/workspace separation rules as other Studio workspaces.
|
|
- The `Scene Workspace` MUST own its operational detail locally rather than pushing it into shell-global surfaces.
|
|
|
|
### 2. Scene Ownership Model
|
|
|
|
- A scene edited in `Scene Workspace` MUST be treated as a Studio-owned intermediate authoring artifact.
|
|
- The scene authoring artifact MUST have its own stable identity.
|
|
- The scene authoring artifact MUST be the primary navigation unit inside the `Scene Workspace`.
|
|
- The related `SCENE` asset MUST appear only as linked context, status, or action, not as the primary navigation unit of the workspace.
|
|
|
|
### 3. Relationship with `Assets`
|
|
|
|
- `Assets` MAY create a `SCENE` asset.
|
|
- `Scene Workspace` MAY create a `SCENE` asset as part of creating a new scene.
|
|
- `Assets` MUST delegate scene-content authoring to `Scene Workspace`.
|
|
- `Assets` MUST NOT expose map painting or equivalent scene-editor interactions.
|
|
- The Studio SHOULD support contextual handoff from `Assets` to `Scene Workspace` after `SCENE` asset creation.
|
|
|
|
### 4. Binding Contract
|
|
|
|
- The relationship between a scene authoring artifact and a `SCENE` asset MUST be explicit.
|
|
- The primary binding anchor MUST be Studio metadata or equivalent explicit identity linkage.
|
|
- Path MAY be retained as secondary location context.
|
|
- Rename or relocation MUST NOT silently break semantic linkage solely because paths changed.
|
|
|
|
### 5. Wave-1 UI Composition
|
|
|
|
- The left region MUST provide a scene navigator inspired by the custom-navigation discipline used in `Assets`, but it MUST remain scene-first rather than asset-first.
|
|
- The top region of the workspace MUST provide an aspect-tab structure.
|
|
- Wave 1 MUST expose only one visible tab: `Tilemap`.
|
|
- The central region of the `Tilemap` tab MUST host the editable map canvas.
|
|
- The right-side upper region MUST show tilemap dimensions and relevant details for the active scene/layer context.
|
|
- The right-side lower region MUST show the tile palette used for picking and painting.
|
|
|
|
### 6. Scene Model Expectations for Wave 1
|
|
|
|
- The workspace MUST model exactly four scene layers.
|
|
- Each layer MUST support independent dimensions.
|
|
- Each layer MUST be editable in a way compatible with the runtime-aligned canonical scene model.
|
|
- The workspace MUST NOT flatten all layers into one synthetic shared-size map contract.
|
|
|
|
### 7. Tileset Rules
|
|
|
|
- Tileset choice MUST be owned by `Scene Workspace`.
|
|
- The workspace MAY resolve tileset selection per scene or per layer, as long as the chosen model remains explicit and internally consistent.
|
|
- Any glyph bank that is technically valid for use as tileset data MAY be selected.
|
|
- Optional Studio editorial tagging MAY improve filtering and discoverability, but MUST remain non-normative to the base capability.
|
|
- `Assets` MUST NOT override editorial tileset selection from the scene workspace.
|
|
|
|
### 8. Editing and Save Rules
|
|
|
|
- The `Scene Workspace` MUST save the intermediate scene authoring artifact through its own save flow.
|
|
- Saving the scene authoring artifact MUST remain distinct from asset creation or asset-management flows.
|
|
- The workspace MUST support a normal save-oriented document/editing lifecycle for the scene artifact rather than an asset-form `apply/reset` lifecycle.
|
|
|
|
### 9. Tooling Scope for Wave 1
|
|
|
|
- Wave 1 MUST support basic painting.
|
|
- Wave 1 MUST support erasing through explicit tile presence control.
|
|
- Wave 1 MUST support selecting a tile and palette for painting.
|
|
- Wave 1 MUST support layer visibility.
|
|
- Wave 1 MUST support layer focus.
|
|
- Wave 1 MUST NOT depend on bucket fill, marquee, flood fill, or equivalent advanced editing tools.
|
|
|
|
### 10. Tile Semantics
|
|
|
|
- Tile absence MUST be represented by explicit presence state.
|
|
- `glyph_id = 0` MUST remain a valid glyph identifier.
|
|
- Erasing a tile MUST clear presence state instead of writing a magic empty glyph value.
|
|
- Painting behavior MUST operate over explicit tile data such as active state, glyph id, palette id, and flip state.
|
|
|
|
## Constraints
|
|
|
|
- This decision is limited to the `Scene Workspace` and its Studio-local boundary with `Assets`.
|
|
- This decision MUST NOT be used to infer packer publication rules beyond the existence of a linked `SCENE` asset.
|
|
- This decision MUST NOT be treated as approval for camera, lighting, AABB, or other future aspect tabs.
|
|
- Any future change to the ownership boundary between `Scene Workspace` and `Assets` requires an explicit revision or replacement decision.
|
|
- Any future change to the stable binding contract between scene artifact and `SCENE` asset requires an explicit revision or follow-up decision.
|
|
|
|
## Revision Log
|
|
|
|
- 2026-04-14: Initial accepted decision from AGD-0029.
|
|
- 2026-04-15: Abandoned by explicit user request before implementation completion; follow-up work must proceed through a new discussion rather than this decision.
|