# Engine, art, and production plan

Updated September 23, 2026. The Old Road browser prototype now implements movement, automatic sprite combat, HP, enemy turns, victory/defeat and replay. The full campaign and Godot production project remain unimplemented.

## First playable foundation

[Play The Old Road](prototype/) and read the [confirmed cinematic combat direction](gameplay-cinematic-combat-and-the-first-playable.html). The initial foundation is modular browser JavaScript and Canvas. It has one generic hero, one generic enemy, an 8 × 7 map, blocked terrain, pathfinding, basic attack forecasts and automatic side-view sprite exchanges. Player input occurs on the tactical map; the cinematic has no gameplay inputs. The map idle reuses the directional walking cycle in place.

The code separates encounter definitions, pure rule functions, a turn/presentation controller, and sprite rendering. Tests cover movement legality, forecast/resolution agreement, turn locks, single application of damage, victory and defeat. Asset provenance and a module guide ship with the prototype. Browser deployment makes this loop immediately reviewable; it does not establish production engine performance.

## Decision: Godot with 2D sprites in a 3D tactical scene

The earlier engine proposal is **Godot**, typed **GDScript**, and a fixed orthographic camera for the larger production slice. Verify and pin the stable engine version when that project is created. The current playable is the browser foundation described above. [Godot release archive](https://godotengine.org/download/archive/).

The game should look like a richly presented sprite tactics game. Implement its height, bridges, occlusion, and lighting with simple 3D terrain, while using authored 2D sprite frames for the units. Godot explicitly supports mixing Sprite3D/AnimatedSprite3D with 3D environments and orthographic cameras. [Godot: 2D in 3D](https://docs.godotengine.org/en/stable/tutorials/3d/introduction_to_3d.html), [Sprite3D reference](https://docs.godotengine.org/en/stable/classes/class_sprite3d.html).

This is an engineering recommendation for this project's priorities, not a benchmark declaring one engine universally better.

| Option | Fit for this project | Decision |
|---|---|---|
| Godot, sprite units and 3D terrain | Direct control over simulation, UI, small tools, and hybrid scenes; manageable project structure | Recommended |
| Unity with URP | Strong alternative for a team already productive in C# and Unity, particularly with established deployment needs | Choose instead if existing team expertise outweighs setup cost |
| Pure 2D Godot isometric rendering | Excellent fallback for a fixed view; smaller rendering scope but manual height/occlusion work | Keep as a prototype fallback |
| Unreal | Technically capable; this game's main challenges are authored tactics, content, UI, and sprites | No clear project-specific advantage at this stage |
| RPG Maker or a tactics framework | Potentially quick for a constrained tactics demo; deep world simulation and custom presentation need careful fit testing | Avoid building the main plan around unknown framework limits |

Unity provides 2D/3D workflows and URP as a scalable renderer. Those are real alternatives, not reasons to switch from a tool the team already knows. [Unity Engine](https://unity.com/products/unity-engine), [Unity URP documentation](https://docs.unity.com/en-us/engine/6000.7/manual/render-pipelines/universal-render-pipeline).

Godot is MIT licensed. That is helpful for controlling the project's engine dependency and distribution, while shipped third-party assets still need their own records. [Godot license](https://godotengine.org/license/).

Assume Windows PC first, with controller support. Console export and certification require a separate confirmed plan; open-source engine availability is not a promise of effortless console shipping. Start with the renderer suited to the actual target hardware, then profile a real battle. The first technical spike compares a restrained modern renderer setup with a lower-cost configuration before selecting final lighting effects.

## Presentation specification

### Sprites

Prototype **64 × 64 frame cells** with a roughly 40–52 pixel-tall human silhouette and a consistent foot anchor. These are targets to test in a real scene, not dimensions certified by the generated illustrations. Characters are around three heads tall: expressive enough for Ragnarok-like appeal, grounded enough for military silhouettes. Compare one 48-pixel cell variant if the first sprite feels too detailed at camera distance.

Begin with four authored diagonal views for the isometric camera. Logical battlefield facing stays north/east/south/west; map it deliberately to screen-facing art. Never indiscriminately mirror a character's sword hand, insignia, scars, or asymmetrical cape. Eight directional views and camera rotation are later art-budget decisions.

Use a shared palette family rather than enforcing one tiny palette across all effects: 24–32 colors per character as a starting target, limited shadow ramps, warm skin highlights, and meaningful silhouette accents. Teal/ivory identifies the hero's company, crimson/brass the crown, while distinct shapes and UI markers communicate allegiance for colorblind players.

Current pilot: one 16-frame walking clip in each of eight map directions per unit, reused for idle-in-place and traversal. Separate side-view ready, attack and hit clips serve the cinematic. The first attack/hit exports were too static and were replaced with stronger clips. Future production frame budgets must count both sprite scales, equipment variants and per-action cleanup; there is no approved full-roster frame count yet.

Use nearest filtering for sprite textures and conservative alpha handling. Separate ground/contact shadows from painted sprite shadows; otherwise lighting gets baked twice. Test outlines against snow, mud, foliage, fire, and dark interiors. The generated concept images do not establish true low-resolution pixel consistency and must not be cut apart and called finished animation atlases.

### Environments

One logical cell equals a fixed world-space footprint, initially one engine unit. Quantize surface heights into steps for gameplay while allowing decorative geometry between them. Use modular terrain, walls, stair segments, doors, roofs, and bridges. Store tactical surfaces explicitly so the art mesh does not determine the rules.

The first environment kit is a river settlement: stone bridge, mill, granary, road, water, timber homes, carts, market shelters, and an interior war table. Reuse it in prosperous, besieged, damaged, and repaired states. Introduce one second biome only after this kit proves legible and fast to author.

The camera is orthographic, fixed at a tested isometric-like angle. Smooth panning can produce pixel shimmer; evaluate snapping and sprite projection at actual target resolutions. Select a stable game render scale after comparing 640 × 360 and 960 × 540 scenes, with high-resolution UI composited separately. Integer upscale is desirable where it fits the display; letterbox or use a documented fractional-scale fallback rather than promise perfect pixel geometry at every window size.

Lighting should guide attention with warm windows, cool shadows, readable silhouettes, and restrained atmospheric depth. Depth of field must not obscure tactical cells. Bloom, fog, and screen effects can be reduced. No rendering trick should make the attack forecast hard to read.

### Portraits and interface

Painted anime portraits use a more detailed scale than sprites. Establish face, hair, key colors, and costume landmarks in a character reference sheet, then check portrait and sprite against it. Expression library begins with neutral, concerned, angry, amused, and vulnerable. Reuse portrait crops deliberately rather than asking a generator to redesign the face for every emotion.

Use navy panels, ivory information areas, and thin brass borders. Heading serifs can supply period flavor, but body text uses a clean readable face. Build all final text, icons, focus states, and diagrams as real engine UI. The generated mockups contain decorative filler and illustrative job connections; their exact wording and tree edges are not the rule specification.

Sound target: small ensemble strings, woodwinds, restrained percussion, regional motifs, and quiet environmental sound. Reserve a shared three-note family motif for the brothers, reharmonized as their relationship changes. Begin with licensed temporary tracks and original interface sound cues; score against real gameplay pacing later. Full voice acting is outside initial scope.

## Astra, image generation, and AutoSprite

**Yes, I can help with pixel sprite work**, including character specifications, visual concepts through the image tool, palette and silhouette review, frame metadata, import scripts, asset organization, and small code-authored pixel assets. That does not mean an attractive generated still is automatically an animation-ready sprite.

The official GPT-6 Astra model page lists image input and text output, plus support for the image-generation tool. Therefore distinguish the reasoning/coding model from the tool producing raster images. This package used the built-in image-generation tool. [Official Astra model reference](https://developers.openai.com/api/docs/models/gpt-6-astra).

Assuming the user's AutoSprite is **autosprite.io**, its documentation describes image-to-animation generation and PNG sheets with JSON atlas data. Its product page advertises isometric directional generation. These are vendor capabilities to validate with a pilot asset, not proof that every generated sheet will meet this game's standard. AutoSprite is connected and generated the map and cinematic sheets used in The Old Road. The character records, sheet IDs and generation settings are recorded in the prototype asset provenance. [AutoSprite introduction](https://www.autosprite.io/docs/introduction), [AutoSprite product overview](https://www.autosprite.io/).

### Recommended art pipeline

1. **Design one unit.** Approve Pyrrhus's silhouette, age, face, costume, palette, scale, handedness, and foot position. His current dark-haired teal-cape appearance is a proposal, not canon extracted from the website.
2. **Create one master idle sprite.** Generate a candidate, then clean its pixel clusters and edges in Aseprite or another pixel editor. Save the editable master and flattened export.
3. **Prove direction changes.** Build four views and verify identity, weapon hand, cape length, and silhouette. Do not generate the full roster before this works.
4. **Animate through AutoSprite.** Use the accepted source for one walk and one attack. Supply timing/keyframe constraints where available. Export the actual sheet and atlas; record the model/settings and source revision.
5. **Normalize and clean.** Validate cell dimensions, anchor, frame count, duration, alpha edges, color drift, idle-to-motion transitions, and weapon contact. Remove duplicate or malformed frames. Human review remains part of production.
6. **Import and review in Godot.** Loop the animation over four backgrounds and play an attack with its real hit timing. Check sprite foot sliding and projected scale. Approve a walk at game size, not only an enlarged editor preview.
7. **Scale by family.** Build a small set of body families, outfit variants, weapon animations, and VFX. Named characters retain distinguishing silhouettes. Never promise every job/weapon/costume combination before its frame cost is counted.

Production art target: a cleaned, consistently anchored directional map walk reused for idle, together with matched side-view combat clips. The current 192-pixel map and 384-pixel cinematic exports are source-resolution pilot art; the older 64-pixel target has not been validated by these assets. Measure time spent cleaning and regenerating. If manual cleanup exceeds the benefit, use AI for concepts and train a hand-authored production pipeline instead.

Suggested asset record: `character_id`, `revision`, `source`, `frame_size`, `foot_anchor`, `directions`, `animation_names`, `durations_ms`, `event_frames`, `palette_id`, and `rights_notes`. Never rely on filenames alone to recover animation semantics.

## Technical architecture

Keep game rules independent from scene nodes. A tactical command requests an action; the rule system validates and resolves it. The rendered sword swing consumes the emitted result and does not calculate damage. This lets the same battle logic drive prediction, AI, replays, and automated checks.

| Module | Owns | Does not own |
|---|---|---|
| BattleState | Units, surfaces, readiness, statuses, objectives, RNG state | Camera or animations |
| RuleResolver | Legal actions, forecast, effects, outcome events | Input device logic |
| BattleView | Terrain, sprites, overlays, effects | Authoritative HP or turn order |
| CampaignState | Days, provinces, roads, resources, armies, event queue | Dialogue prose |
| CampaignResolver | Travel, economy, orders, remote conflicts | Interface rendering |
| NarrativeState | Flags, promises, relationship events, story gates | Duplicate economy calculations |
| Content | Jobs, abilities, items, encounters, dialogue definitions | Mutable save state |

Use authored Godot Resources for definitions, with stable string IDs and validation. Use explicit versioned save data for mutable state; save IDs instead of duplicating every content definition. A save includes the campaign date, queued orders/events, unit status, relationship promises, active mission, and random-generator state. Use atomic save replacement and a recoverable previous save.

For maps, build a graph of walkable surfaces and legal edges; a single `(x,y)` tile address cannot represent a bridge over another route. AStar3D can assist with graph search, but movement costs, clearance, jumps, occupied cells, and unit permissions remain custom game rules. [Godot AStar3D](https://docs.godotengine.org/en/stable/classes/class_astar3d.html).

For AI, start with explainable utility scoring over legal actions: objective progress, expected damage, danger, rescue, and formation. Cache reachability per relevant state. Do not begin with machine learning or an LLM controlling shipped combat. Author major enemy behavior as readable tactical priorities.

Narrative uses a small node format with explicit requirements, effects, choices, and fallback routes. Keep localization keys separate from code. A mature external dialogue tool may replace the format after an integration spike, but the concept does not depend on an unverified plugin.

Suggested future repository structure:

```text
game/
  project.godot
  src/{battle,campaign,narrative,ui}/
  scenes/{battle,world,camp}/
  content/{jobs,units,abilities,provinces,dialogue}/
  art/{characters,terrain,portraits,ui}/
  audio/
  tests/
tools/{asset_import,content_validation}/
docs/concept/
```

Use Git for code and text content; use Git LFS for large binary art sources once asset production starts. Keep source art, exported runtime assets, and generated candidates distinguishable. The browser prototype is versioned with this bible; it needs no package install to run or execute its rule tests.

## Build order and milestone gates

Planning assumption: one experienced developer working full time with part-time art/narrative help. Ranges are effort estimates, not delivery promises. Concurrent art can overlap engineering, but uncertainty in the sprite pipeline makes a fixed full-game schedule premature.

| Milestone | Rough effort | Reviewable output | Gate to proceed |
|---|---|---|---|
| 0. Canon and art pilot | 1–2 weeks | Agreed setting constraints; one animated unit in one terrain scene | Unit is readable and pipeline repeatable |
| 1. Combat foundation | 2–3 weeks | 12 × 12 test map, six units, pathing, turn order, forecast, four jobs | A full battle resolves and can be reloaded |
| 2. Cinderford | 2–3 weeks | Escort and mill objectives, wounds, enemy AI, controller UI | New players understand their losses and wins |
| 3. Campaign linkage | 2–3 weeks | Three provinces, travel clock, a remote raid, steward assignment | Battle outcome changes a later campaign choice |
| 4. Narrative slice | 2–3 weeks | Whitebridge battle, brothers' reunion, Mira scene, save continuity | Characters and consequences are clear without explanation |
| 5. Polish and evaluation | 2–4 weeks | Cohesive 60–90 minute build, audio pass, accessibility, measured performance | Players want another mission; production cost is measurable |

This implies approximately **11–18 full-time development weeks** for a credible slice under the stated staffing assumptions, potentially longer for a first-time developer or inconsistent art generation. It is not a promise that AI compresses a content-heavy RPG into a weekend. Budget the full game only after measuring one polished battle, one environment kit, one animation family, and one narrative scene.

### The first two battles

**Cinderford:** six allies, eight enemies, a mill, three refugee wagons, a raised bridge, two routes, surrender, one destructible barricade. Four shared jobs: Vanguard, Archer, Apothecary, Acolyte. Pyrrhus has a small Wayfarer command set. Win by escorting at least two wagons; the third wagon and mill are independent outcome flags. Hold the route and avoid losing Pyrrhus. Optional sacrifices remain visible afterward.

**Whitebridge:** a smaller ambush with Ciro as an allied command guest and Xeno as a vulnerable support guest. Arriving with fewer supplies or without Yselle changes the approach. Victory opens the reunion scene. The Cinderford raid resolves from the orders left behind, demonstrating the cost of absence.

### Validation when implementation begins

Meaningful automated checks: legal routes respect surfaces and height; forecast equals actual deterministic effects; save/load preserves outcomes and RNG; travel crossing day seven resolves economy exactly once; negative supplies cannot generate free troops; remote clashes respect travel; a captured companion has a valid scene fallback; mutually exclusive romance commitments cannot both be set silently.

Human playtests: can a first-time player identify the objective, forecast, retreat route, and cost of leaving a steward? Do they understand why a remote battle was lost? Do they feel pressure without feeling that reading dialogue wastes time? Can they read the game at 1280 × 720 with a controller? Does the same character remain recognizable across every view?

Performance target to validate later: stable 60 fps on a specifically chosen modest PC at 1080p, responsive menus, and no noticeable pause when selecting a movement range. Hardware, actual scene load, and profile results must accompany any future performance claim.

## Scope cuts in order

If the slice costs too much: remove camera rotation; reduce outfit variants; simplify lighting; reduce province count; replace free-roaming hubs with illustrated menus; reduce optional battles. Preserve the link between battle, governance, and relationships. That link is the game's identity.

First validate and refine The Old Road's two-scale sprite presentation. Then extend the same rule/event contract into a small Cinderford encounter with approved named-character art, more units and terrain. Keep the world map and full job tree behind that acceptance gate.