msw-general

MSW General — Foundation Skill

The foundation skill for MSW (MapleStory Worlds) creation, integrating shared tools, domain knowledge, platform rules, and file authoring. Every other MSW skill depends on it.

---

Core Principle: Visual Polish

MSW is a game creation platform. The goal is not a prototype where logic merely runs — it is a polished game players can enjoy.

So whatever entity you create — monster, NPC, tower, item, background object — search for and apply appropriate resources (sprites, animations, sounds) that match its role and personality. Do not leave the default sprite in place or leave SpriteRUID empty.

Resource application principle when creating an entity:

1. After creating the entity, use the msw-search skill to find sprites/animations that fit it
2. Apply the RUID of the found resource to SpriteRendererComponent so the entity is visually represented
3. If there is combat, also set hit/explosion effects; if there is interaction, set sound effects

Functionality implemented != finished. A polished game requires appropriate resources plus visual presentation.

---

When making a .model — catalog first

Do not start a new .model from an empty file. The skill-local models/ folder contains validated templates organized by category — monsters (ChaseMonster/MoveMonster/StaticMonster), NPC (StaticNPC), players (Player/DefaultPlayer), terrain (Foothold/Ladder/Rope/Portal), map objects (MapObject/SkeletonMapObject/ItemAsset), particles (BasicParticle/SpriteParticle/AreaParticle/AnimationPlayer), sound (Sound/SoundEffect), tile map containers (TileMap/RectTileMap), UI (UIButton/UIText/UISprite/UIGroup, etc.), external media (WebSprite/YoutubePlayerWorld).

Workflow: Read references/model.md IN FULL FIRST (mandatory — see "Model Work Preflight — MUST" below) → pick the closest template from the catalog → load it via ModelBuilder (call protocol: references/builder-protocol.md) → replace the 3 identifiers (EntryKey, Id, Name) through the builder → customize Components/Values/Properties/Children through the builder → save under a typed subfolder of RootDesk/MyDesk/Models/ (e.g. Models/Monsters/{Name}.model, never directly under MyDesk/) → refresh. Detailed catalog and builder procedure: references/model.md §2.

The builder emits the required value metadata, so agents do not need to read or hand-write .model format internals.

For a monster, first pick a pattern in references/animation-state.md §0, then follow references/monster.md §5 for the recommended path.

• Pattern A (verified working canonical — Soldier reference setup, full source inlined in references/monster.md §7): no template needed; assemble 11 components from scratch with a custom script.MyMonsterAI (SoldierAI-style) instead of AIChase/AIWander. StateComponent.IsLegacy left at the default.
• Pattern B (MonsterCanonical.model): AIChaseComponent + ActionSheet pipeline. StateComponent.IsLegacy=false mandatory. The other monster templates (ChaseMonster / MoveMonster / StaticMonster) leave ActionSheet empty and use defaults that silently fail under Pattern B (uppercase keys, SortingLayer="Default", IsLegacy=true).

For any entity that has StateAnimationComponent (monster/NPC) or AvatarStateAnimationComponent (player) — or any .mlua that calls ChangeState / AddState / SetActionSheet — also read references/animation-state.md. The state-machine ↔ animation pipeline, the two-pattern split, default-state registration rules, [LEA-3005] cause, and SetActionSheet vs ChangeState semantics live there (not duplicated into per-entity docs).

---

Placing multiple entities — model first

If the same entity is going to appear twice or more in a map (5 monsters, 10 trees, 3 portals, …), author a .model first and place each instance via modelId rather than copy-pasting inline @components.

Instance count of same composition	Choice
1 (truly one-off decoration in a single map)	inline @components is acceptable
≥2	.model + modelId instances (default)
Spawned at runtime (SpawnByModelId)	.model is required regardless of count

Why this is the default:

• Edit once, propagate everywhere — change SpriteRUID/HP/ActionSheet in the model and every instance updates. Inline copies require touching N entities each time.
• Smaller, reviewable .map diffs — modelId instances carry only Transform overrides; inline copies bloat the map by hundreds of lines per entity.
• Avoids drift — five inline copies silently diverge (one gets IsLegacy: true, another forgets SortingLayer: "MapLayer0"). The model anchors the canonical values.
• Required for SpawnByModelId — without a registered model id, dynamic spawning fails.

Workflow:

1. Author .model under RootDesk/MyDesk/Models/{Category}/{Name}.model (see folder rule above).
2. Place each instance via MapBuilder (call protocol: references/builder-protocol.md) so ids, paths, componentNames, origin metadata, and per-instance component overrides stay synchronized.
3. refresh.

Details and the inline-vs-modelId comparison: references/entity.md "Two-Step Map Editing Workflow", references/model.md §1.

---

Entity Work Preflight — MUST

If the task involves an entity in any way, you must read references/entity.md first. No exceptions.

---

Builder Protocol Preflight — MUST

If the task creates or modifies any .map / .model / .ui file — directly, or as a side effect of writing .mlua that spawns / places / binds — you must Read references/builder-protocol.md IN FULL FIRST (no offset / limit). No exceptions.

builder-protocol.md is the single entry point that consolidates the call protocol of all three builders (MapBuilder / ModelBuilder / UIBuilder) into one document. Knowing only one builder's protocol and then invoking another builder's .cjs bypasses that builder's write-side contract (componentNames sync, Values typeKey metadata, write-time auto-lint, placeModel component mirroring, child entity invariants) — and the three are interlocked through cross-flow (model authoring → map placement → ui binding), which is why they share one document.

Triggers (intentionally broad — Read builder-protocol.md whenever any match):

• .map changes (entity placement, component patching, tile / foothold inspection)
• .model changes (new authoring, value / component / property / child edits)
• .ui changes (new build, component CRUD, binding injection)
• Any call to MapBuilder / ModelBuilder / UIBuilder
• Requests shaped like "entity-shaped" work — monster / NPC / projectile / map object / popup / HUD, etc.
• Any code using _SpawnService (a spawnable model must be authored and placed first)

The domain refs (entity.md / model.md / msw-ui-system design references) are read alongside builder-protocol.md — they are not substitutes (domain context + call protocol are a pair). Do not skip on the grounds that you read it in a prior turn — re-read every turn.

---

Model Work Preflight — MUST

If the task involves authoring or editing a .model file in any way — including any call to ModelBuilder (any API), creating a new model from a template, mutating components/values/properties/children/event links on an existing model, or even a one-line tweak — you must Read references/model.md IN FULL FIRST (no offset/limit, no cat/Get-Content). No exceptions.

The builder's template catalog, the 3-identifier replacement rule (EntryKey / Id / Name), required value metadata, property/child/event-link API surface, and the typed save-folder layout under RootDesk/MyDesk/Models/ live only in references/model.md. Calling the builder without reading references/model.md first silently produces broken models (missing value metadata, mismatched identifiers, wrong save folder, default-value silent failures). Reading scattered template files or guessing the API from memory is not a substitute — re-confirm at the start of every new turn that touches a .model, even if a previous turn already loaded it.

---

Map Work Preflight (do this BEFORE any map work)

Before starting any map-related task — entity placement, spawn, movement scripts, model authoring, tile edits, etc. — you must complete these two steps in order:

1. Identify the target map — its path (./map/{mapname}.map), its root entity, and its location in the Hierarchy.
2. Use MapBuilder to read MapComponent.TileMapMode as a number (call protocol: references/builder-protocol.md). Keep the value in mind for the rest of the session.

Value	Mode	Required Body	Runtime log on mismatch / missing Body
0	TileMap (MapleTile, side-view + Foothold)	RigidbodyComponent	[LEA-3004] MissingComponent : Entity is missing 'RigidbodyComponent'.
1	RectTileMap (RectTile, top-down)	KinematicbodyComponent	[LEA-3004] MissingComponent : Entity is missing 'KinematicbodyComponent'.
2	SideViewRectTileMap (SideViewRectTile, side-view tile)	SideviewbodyComponent	[LEA-3004] MissingComponent : Entity is missing 'SideviewbodyComponent'.

Never start map work without knowing the current TileMapMode. The three modes differ completely in Body component, gravity, collision, and event stacks. A mismatch is almost never a compile-time error — it shows up either as a silent failure (entity doesn't move / passes through walls / invisible) or as one of the three [LEA-3004] MissingComponent runtime logs above. Whenever you see one of those three messages, suspect a TileMapMode ↔ entity Body mismatch first.

Recommending the right mode — MUST when starting a new map or when the current mode is clearly wrong for the user's goal

Whenever the user describes what game / map they want to build (new map authoring, "make a side-scroller", "I want a top-down dungeon", or you read the current .map and find its TileMapMode does not fit the user's intended gameplay), you must explicitly recommend the appropriate TileMapMode to the user and explain why before proceeding with any further entity / model / script work.

Use this decision matrix as the source of truth:

User's intended game / gameplay	Recommend	Why
MapleStory-style side-scrolling action · jump · ladder · freely placed footholds (platformer)	0 MapleTile	Side-view + gravity, FootholdComponent line-segment platforms — non-grid, freely placed platforms
Top-down RPG · maze · board game · dungeon crawler · Bomberman-style · RTS-style · farming sim	1 RectTile	Top-down 4-directional free move, no gravity, square-tile grid
Tile-based side-scrolling platformer · Mario-style pixel action · side-view puzzle (square-tile side-view)	2 SideViewRectTile	Side-view + gravity on a tile grid (not freely placed footholds)

Procedure:

1. If the user has not yet told you what kind of game they want, ask before recommending a mode (one short question is enough — e.g. "Is it top-down, or side-scrolling (jump/ladder)? And is the terrain based on freely placed footholds, or a square tile grid?").
2. Once the intent is clear, state the recommendation (mode number + name + one-sentence rationale) and the matching Body / map component the user will need (platform.md §4 mapping table).
3. Lock the choice in early — switching TileMapMode later wipes terrain, forces every Body / movement script to be re-checked, and may force re-painting all tiles (platform.md §4 "Cautions When Switching Map Type").

Changing TileMapMode — user action in Maker, not an AI file edit

The AI must never flip MapComponent.TileMapMode by editing the .map JSON directly. Mode switching requires swapping tile components, rebuilding footholds, converting tile-data formats, and resetting terrain — all internal Maker operations.

Guide the user to do this in the Maker editor:

1. Open the Maker editor's Hierarchy window.
2. Right-click the target map entity in the Hierarchy.
3. From the context menu, choose the "Switch ..." option that matches the target mode (Switch TileMap / RectTileMap / SideViewRectTileMap). Maker performs the conversion, swaps the tile component, and resets terrain as needed.
4. After the user confirms the switch is complete, call MCP refresh, then re-read MapComponent.TileMapMode to verify and re-check every dynamic entity's Body component against the new mode.

The AI's role in mode changes: recommend → wait for user to right-click-switch in Maker Hierarchy → refresh → fix Body components / scripts that no longer match. Never write a new value to TileMapMode from a file edit.

The table above is a summary. The mode-switch procedure, the post-Body-swap checklist, and the silent-failure symptom dictionary beyond LEA-3004 live only in references/platform.md §4 (mapping + check protocol + switching policy) and references/troubleshooting.md (full symptom dictionary) — you must Read them when changing modes / swapping Body / debugging silent failures. Per-map-type detail patterns: platform-maple.md / platform-rect.md / platform-sideview.md. Tile painting: references/tile.md. Map Work Preflight: references/entity.md.

---

Platform Rules Preflight — MUST when any of these triggers fire

If any of the following triggers matches your task, Read the corresponding reference before editing code or proposing a plan. These triggers are intentionally broad — when in doubt, read. The "8 Core Rules" in this SKILL.md are a summary only; the symptom→cause→fix tables, per-map-type code patterns, the MovementComponent conversion formulas, and SortingLayer/SpriteRUID details live only in references.

Trigger (keyword / situation)	File to read
jump, gravity, movement, MoveVelocity, InputSpeed, JumpForce, WalkSpeed, SpeedFactor, foothold, patrol	**The matching map

...