85 lines
8.6 KiB
Markdown
85 lines
8.6 KiB
Markdown
# Project Notes
|
|
|
|
## Target Hardware: AYN Thor
|
|
|
|
- AYN Thor main display: 6-inch AMOLED, 1920 x 1080, 120Hz.
|
|
- AYN Thor secondary display: 3.92-inch AMOLED, 1240 x 1080, 60Hz.
|
|
- AYN Thor UI sizing must be designed against Android CSS/layout viewport, not physical framebuffer pixels.
|
|
- Approximate Thor CSS viewports: main display 960 x 540, secondary display 620 x 540.
|
|
- Test top-screen UI only against the main display viewport, and bottom-screen UI only against the secondary display viewport.
|
|
|
|
## Input Requirements
|
|
|
|
- Every game screen, menu, dialog, overlay, and gameplay interaction must be fully navigable by controller at all times.
|
|
- Any time a screen, menu, dialog, overlay, or gameplay interaction is added or changed, verify controller navigation still works for that surface before considering the work complete.
|
|
- Controller navigation must not depend on touch, mouse, keyboard, or hidden developer-only shortcuts.
|
|
- Focus state must always be visible and predictable when controller navigation is active.
|
|
- Avoid interaction patterns that trap focus, lose focus, or require precise pointer input.
|
|
|
|
## Architecture Requirements
|
|
|
|
- Keep systems modular and scoped by responsibility.
|
|
- Prefer small reusable modules/components over large files with mixed concerns.
|
|
- Keep shared game logic independent from platform-specific web or mobile wrappers whenever practical.
|
|
- Apply game changes to both web version and mobile app version.
|
|
|
|
## I Want To Heal 1 vs I Want To Heal 2
|
|
|
|
- I Want To Heal 1 is the existing healer-first menu/combat game. Preserve its current progression, saves, inventories, collection logs, combat screens, and content unless the user explicitly asks to change IWT1.
|
|
- I Want To Heal 2 is the new 2D boss-arena version. Keep IWT2 code, content, save data, inventories, character levels, and collection logs separate from IWT1 so the two modes are not confused.
|
|
- The app should offer a game-select screen before the main menu: `I Want To Heal 1` launches the old version, and `I Want To Heal 2` launches the new 2D version.
|
|
- Both games must remain usable from the same Android APK and from `iwanttoheal.phenomrom.com`.
|
|
- Prefer an explicit folder split for IWT2, such as `src/modes/iwt2/`, with subfolders for screens, simulation, rendering, content, and save/repository code.
|
|
- Keep IWT2 simulation state independent from rendering. Arena movement, AI, boss attacks, collisions, damage, stun/knockdown, progression, inventory, and collection logs should live in pure TypeScript modules where practical.
|
|
- IWT2 rendering can use a 2D canvas/game runtime, but renderer objects must not become the source of truth for saveable gameplay state.
|
|
- IWT2 needs continuous movement input: left analog stick on AYN Thor and WASD on keyboard. Do not rely only on existing menu-style navigation actions for arena movement.
|
|
- IWT2 menus, dialogs, inventory, collection log, pause overlays, and game-select screen must still follow controller navigation requirements.
|
|
- IWT2 boss mechanics and indicators must be modular. Add reusable hit-shape, damage/status, telegraph/indicator, hazard, and marker primitives under `src/modes/iwt2/sim/` or `src/modes/iwt2/render/` instead of hardcoding boss-specific rules in Phaser scenes. Boss AI may compose these primitives, but renderer code should draw sim-owned indicators generically.
|
|
- Every IWT2 boss must have a boss pet collection-log reward. Add the pet to IWT2 boss reward metadata when adding the boss, and keep boss kill pet drops at a rare 1 in 500 chance.
|
|
- IWT2 boss and party movement must be built with crowding and hazard escape in mind from the first implementation. New bosses must not rely on straight-line chase or single-vector hazard avoidance if the boss can create ground effects, wall pressure, summons, or multi-boss overlap.
|
|
- IWT2 AI-controlled party members must be able to route around nearby ground effects and telegraphs using deterministic local steering/path scoring. Avoidance should consider hazard damage radius, telegraph danger, boss collision radius, nearby party members, wall clearance, and a center-safe bias when escaping danger.
|
|
- IWT2 bosses must not be allowed to pin the tank, DPS, or themselves in arena corners. Any boss that chases, charges, pounces, relocates, or creates persistent hazards needs wall-disengage/relocation behavior and must avoid sustained wall contact.
|
|
- IWT2 collision resolution must run after both party movement and boss movement so party-vs-boss and party-vs-party overlaps do not persist into damage, projectile, or hazard ticks. When resolving boss overlap near walls, prefer pushing party members toward arena center instead of clamping them deeper into the wall/corner.
|
|
- Any new IWT2 boss or boss-pair change must be verified with forced simulation for that boss alone and in at least one two-boss pairing. Sim checks should look for sustained boss wall contact, live party overlap, party members stuck near hazards with near-zero movement, and deaths caused by corner pileups rather than intended mechanics.
|
|
- First IWT2 boss conversion target: Bulldrome. Bulldrome should have normal melee tank damage, a charge across the arena that damages and knocks down/stuns hit players for 0.75 seconds, and every 3rd charge should be followed by an AoE ground slam around the boss that also damages and knocks down/stuns hit players for 0.75 seconds.
|
|
- IWT2 starter party fantasy: player-controlled healer plus visible party members moving in the arena. Paladin tank holds aggro; ranger fires arrows; mage fires fireballs; rogue flanks; warrior fights in melee. Each class should have a distinct icon and color scheme.
|
|
|
|
## IWT2 Boss Asset Requirements
|
|
|
|
- IWT2 gameplay boss sprites should use side-view cel-shaded PNG art by default, not top-down token art.
|
|
- Boss sprites should face right in source art. Renderer may flip sprites horizontally for left-facing movement; avoid 360-degree rotation for side-view sprites.
|
|
- Use original creature designs only. Do not copy franchise art, silhouettes, armor layouts, or exact monster designs.
|
|
- Generate full-body sprites with generous padding, crisp inked outlines, simple shaded color blocks, and strong silhouettes readable on the Thor main viewport.
|
|
- Keep gameplay sprites transparent after processing, cropped to content plus padding, and sized appropriately for Thor. Prefer final PNGs around 512 px wide unless a smaller asset remains crisp.
|
|
- Store IWT2 boss gameplay sprites under `public/iwt2/bosses/` using `<boss-id>-side-cel.png`.
|
|
- In boss metadata, set `spriteUrl`, `spriteView: 'side'`, `spriteWidthScale`, `spriteHeightScale`, and `spriteYOffsetScale` so the rendered sprite preserves its source aspect ratio and reads well near party members.
|
|
- Use a flat chroma-key source background for generated sprites, then remove it locally. Use `#00ff00` unless the boss has green/teal body colors; use `#ff00ff` for green/teal bosses. The key color must not appear in the boss.
|
|
- Validate every final sprite has transparent corners and renders nonblank in the 960 x 540 Thor main viewport.
|
|
|
|
Base prompt for future IWT2 boss sprites:
|
|
|
|
```text
|
|
Use case: stylized-concept
|
|
Asset type: production game boss sprite for I Want To Heal 2 arena gameplay
|
|
Primary request: side-view cel-shaded sprite of an original <boss fantasy> boss, facing right, full body visible
|
|
Subject: <distinct silhouette, body plan, role/mechanic cues, readable combat posture>; original design, not copied from any franchise
|
|
Style/medium: clean 2D cel-shaded action-game sprite, crisp inked outline, simple shaded color blocks, readable at small size
|
|
Composition/framing: centered single character, side-view with slight 3/4 depth, full body, generous padding, no cropping
|
|
Lighting/mood: clear high-contrast game lighting, readable over dark arena grid
|
|
Color palette: <boss palette and accent colors>
|
|
Scene/backdrop: perfectly flat solid <#00ff00 or #ff00ff> chroma-key background for background removal
|
|
Constraints: background must be one uniform <key color> with no shadows, gradients, texture, floor plane, reflection, or lighting variation; do not use <key color> anywhere in the boss; no cast shadow; no text; no watermark; no UI; no logos
|
|
```
|
|
|
|
## Performance Requirements
|
|
|
|
- Treat CPU, GPU, memory, battery, and startup cost as first-class constraints.
|
|
- Avoid unnecessary per-frame allocations, polling, timers, layout work, and re-renders.
|
|
- Keep assets sized appropriately for Thor displays; do not ship oversized textures, images, audio, or data blobs without need.
|
|
- Prefer event-driven updates and cached calculations for UI and game systems.
|
|
- Profile or measure when changing hot paths, rendering, animation, input handling, asset loading, or persistent state.
|
|
|
|
## Build Requirements
|
|
|
|
- User rebuilds app; do not rebuild APK unless explicitly requested.
|