Drago Tower model guide
Read as Markdown · All game guides · Measured native reference
Replacement skin support
This game supports the v2 skin contract. Replace the visible body and the exact named physical meshes listed at the end of this page. Use the surround and trim suggestions below to add matching scenery. Preserve the functional regions and state-dependent clearances described here.
Station identity
Use asset dragontower, IDs dragontower:0 through dragontower:4, floor elevation Y = 0–64 and scale [1,1,1]. The game is labeled Drago Tower in the UI. Its root is dragontower in the native game library.
Treat it as an upright board with a dynamic tile arrangement. Do not model a fixed ladder over the face based on one concept image. The current native reference contains the geometry needed for several column layouts.
All difficulty layouts
The tower has nine rows. The current configurations are:
| Difficulty | Tiles per row | Safe tiles per row |
|---|---|---|
| EASY | 4 | 3 |
| MEDIUM | 3 | 2 |
| HARD | 2 | 1 |
| EXPERT | 3 | 1 |
| MASTER | 4 | 1 |
Names such as d4_r0_t0, d3_r0_t0 and d2_r0_t0 identify native reference tiles for the four-, three- and two-column arrangements. The suffixes identify row and column; they are not executable commands. Only the active difficulty's arrangement is shown. Preserve the union of every layout's space, including the top and bottom rows.
Controls and animation areas
| Region | Function | Preserve |
|---|---|---|
| Active row tiles | Choose a tile at the current step | The full row width and visible feedback |
| Other rows | Progress/history and unreached levels | Keep their visual hierarchy readable |
| Native CASH OUT button | Starts a round when idle; cashes out when allowed | The button and its front approach |
| Settings | Opens difficulty and stake controls | The complete clickable face |
| Status screen | Current game status and return information | All text and numbers |
| Revealed tile area | Shows safe/hazard feedback | Space in front of every row |
The client only permits choices in the correct row/state. An uploaded ornament cannot create another tile or make an unreached row playable. The primary nearby prompt changes according to the active game. Do not bake “always available” Cashout text or a promised multiplier into custom signage.
Modeling recipe
Make external side pylons, low plinth accents or a title beyond the native upper boundary. Use generous empty space around the tower. A dragon ornament that overlaps only the top row still makes the game difficult to use. A decorative staircase in front can push players out of the intended approach or hide the low control bank.
Keep solid decorative pieces separate so their box colliders do not span the front of the board. Position the cabinet near a perimeter with its front facing the room if that suits the layout. Rotate the accompanying rug and props by the same yaw. Check both neighboring cabinets and the straight view from the player's eye height.
Use simple, matte material regions around the tiles. Revealed-state colors belong to the native client, so avoid a patterned frame that resembles permanent selected or hazardous cells. Do not add a fixed four-column overlay; it will misalign on HARD, MEDIUM or EXPERT.
Review matrix
Inspect EASY, MEDIUM, HARD, EXPERT and MASTER, not just four-column mode. Include the first row, a middle step, the highest row, a completed/lost round and a cashout state in an authorized preview. Ensure the next available row and status screen can be understood on mobile. Static meshes cannot show this full state matrix by themselves.
AI brief
Get game_skin_contract for dragontower and download my current world draft.
Build an original [theme] replacement body in Blender using the reference socket
measurements and the preserved gameplay regions described in this guide.
Upload static body/button assets; bind only the listed control/part sockets.
Keep native labels, game values and collision. Use supported v2 placements, clips
and result-motion channels for presentation changes.
Save with game_skin_save and the current revision. Inspect the fitted model
and report budgets and reviewed states. Do not upload code or publish via MCP.
See the common modeling workflow for export and draft handling.
Reference skin sockets (v1 and v2)
Read game_skin_contract({"game":"dragontower"}) before saving. The current fingerprint is 924683f5f720ea2e. The live catalog is authoritative if a copied example differs.
The replacement body is fitted to station-local world bounds [-4.1640751, 0, -1.1684503] through [4.1640751, 10.5709474, 1.9840131]. Width, height and depth are [8.3281503, 10.5709474, 3.1524634]. These values already include source scale. Entity scale remains [1,1,1].
| Accepted binding slot | Fixed native action | Fixed index / seat | Native label | World-space bounds, minimum → maximum |
|---|---|---|---|---|
control.cashout | cashout | None | CASH OUT | [-3.7641353, 1.6746155, 0.9163082] → [-2.885837, 2.0004075, 1.7910646] |
control.settings | settings | None | SETTINGS | [2.885837, 1.6949118, 0.9920556] → [3.7641353, 1.9801109, 1.7153171] |
Only slot and the converted model asset hash go in each binding. Action, index and seat columns explain platform behavior; do not copy them into uploaded JSON. All listed sockets are optional visual overrides. Omitted sockets retain native meshes. Repeated Settings actions are distinct physical sockets and must use the exact listed ID. The catalog provides exact mesh-local localBounds for fitting and the full matrixSource for native orientation.
Save a skin with game: "dragontower", its current fingerprint, a converted body hash and the chosen bindings. Apply it only to existing dragontower:<index> entities. Declare each binding in the skin manifest. Follow the exact manifest and fitting rules and the export workflow.
V2 layout and animation
Fetch game_skin_contract({"game":"dragontower"}). Use presentation.targets to position the body, complete display and each listed physical control. Control labels and clickable proxies follow their target; action/index/seat identity stays the same. Numeric idle and result clips are supported. Use a result clip on display to animate the live presentation; this game has no separate card/coin/ball motion channel. Reference dimensions above describe the neutral layout before v2 placement. See the exact fields, transforms and limits.