Back to Details

build-isometric-arpg

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Build Isometric ARPG

构建等距动作ARPG

Build one coherent playable loop before expanding scope: title/menu, character choice, movement, one encounter, reward, progression, and continuation.
在扩展范围之前先构建一个连贯的可玩循环：标题/菜单、角色选择、移动、一场战斗、奖励、进度提升以及后续流程。

Establish the production contract

确立生产规范

  1. Inspect the current game entry point, scene loop, content model, controls, save model, and tests.
  2. Record the authoritative baseline before integrating dependent work. Preserve unmerged work and do not build from a stale branch.
  3. Define data-driven contracts for player classes, equipment, enemies, zones, encounters, quests, and review fixtures. Keep authored content separate from runtime state.
  1. 检查当前游戏的入口点、场景循环、内容模型、控制方式、存档模型和测试用例。
  2. 在集成依赖工作之前记录权威基准版本。保留未合并的工作内容，不要基于过时分支进行构建。
  3. 为玩家职业、装备、敌人、区域、战斗、任务定义数据驱动的规范，并审核测试用例。将创作内容与运行时状态分离。

Build in vertical slices

采用垂直切片开发

Deliver each slice with a playable route and deterministic test state. Prefer this order:
  1. Movement, camera, collision, target selection, and pause/restart.
  2. One combat verb plus contact, damage, posture, recovery, and death.
  3. One enemy with telegraph, decision loop, and counterplay.
  4. One reward and atomic inventory/progression update.
  5. One zone transition or objective completion.
Avoid adding a second system until the preceding slice has gameplay proof, automated coverage, and a stable save/load path.
每个切片都需提供可玩路径和确定性测试状态。优先遵循以下顺序：
  1. 移动、相机、碰撞、目标选择以及暂停/重启功能。
  2. 一种战斗动作，加上接触判定、伤害、姿态、恢复和死亡机制。
  3. 一个带有动作预警、决策循环和应对机制的敌人。
  4. 一种奖励机制以及原子化的物品栏/进度更新。
  5. 一次区域切换或目标完成流程。
在前一个切片具备游戏玩法验证、自动化测试覆盖以及稳定的存档/加载路径之前，不要添加第二个系统。

Maintain runtime boundaries

维护运行时边界

  • Keep simulation state deterministic and serializable where possible.
  • Consume authoritative contact events; do not infer physics outcomes from visual state.
  • Centralize timing, damage, cooldown, and content values. Do not duplicate combat clocks across components.
  • Make equipment, pickups, save migration, and reset flows atomic and idempotent.
  • Provide review query parameters or fixtures for difficult states such as boss phase changes, empty inventory, interrupted actions, and save migrations.
  • 尽可能保持模拟状态的确定性和可序列化。
  • 使用权威的接触事件；不要从视觉状态推断物理结果。
  • 集中管理计时、伤害、冷却和内容数值。不要在组件间重复设置战斗时钟。
  • 使装备、拾取物、存档迁移和重置流程具备原子性和幂等性。
  • 提供用于查看特殊状态的查询参数或测试用例，例如 boss 阶段变化、空物品栏、中断动作和存档迁移。

Validate before release

发布前验证

Run focused unit tests, type/lint checks, production build, and a real playthrough in the repository-approved browser. Verify a fresh start, saved continuation, loss/retry, one complete objective, keyboard/mouse controls, and the intended mobile baseline. Report known baseline failures separately from new failures.
运行针对性的单元测试、类型检查/代码规范检查、生产构建，并在仓库认可的浏览器中进行实际游玩测试。验证全新启动、存档续玩、失败重试、完整目标完成、键鼠控制以及预期的移动端基准表现。将已知的基准故障与新故障分开报告。