Ash of Aetharn

我的工作

独立开发 · 玩法 / 系统设计 · 数值平衡 · 工程实现 · AI 工作流设计

截至当前（P3 全量构建阶段），已实现的系统覆盖战斗、探索、构筑、商业化与内容生产的全链路：

• 战斗系统——费用 / 攻击 / 状态 / 魔法 / UI 全套，基础状态机 + 场景切换框架
• 探索地图——领土扩张模型，事件 / 商店 / 任务挂接
• 背包 + 战前配置——v2 动作按钮 + 卡牌选择 modal 视图
• 存档系统——跨场景与跨局数据序列化
• 战斗奖励系统——基于通用 Action 抽象的统一奖励接口
• 升星合成系统——近战 / 远程 × 普通 / 精英的四阶单位星位构筑
• 遗物系统——按权重抽取的 cross-battle 永久增益
• 领袖系统——含选择界面与差异化能力
• 敌方 AI——Commander 架构，从被动应对到策略性决策
• 事件系统——作为奖励 / 惩罚 / 叙事载体
• 商店系统——含行商机制
• 祝福 / 诅咒系统——玩家身上的 cross-battle buff / debuff
• 刻印系统——卡牌级永久 modifier，构筑维度增强
• 音频 + 美术管线——BGM 接入 + 占位单图 + Tween 程序化

AI 协同工作流方法论

项目的第二条产出线，沉淀为一套独立可复用的方法论：

• Chat × Code 双角色，职责严格分离——Claude Chat 主导设计决策与方案审查，Claude Code 主导架构提案与代码实现，二者边界清晰、互不越位。
• 强制工作流——Code 收到需求后必须按"评估现状 → 提出架构方案 → 列出决策选择题 → 等待开发者拍板 → 实施"五步推进，技术细节视为参考而非规定，不机械执行。
• 五层文档体系功能正交——GDD（数值）/ TDD（架构）/ design（决策演进）/ methodology（可复用经验）/ balance（数值调整记录），各装各的、不重叠。
• 计划与记录分离——里程碑 / 模块 / 长期技术债 / inbox 收件箱 / 模块子任务 5 个概念明确归位；9 个命令式 Agent 行为触发场景，让 Agent 按场景对照行动而不靠上下文推断。
• 数据驱动设计——所有游戏数值（单位 / 魔法 / 遗物 / 事件）经 xlsx → JSON 管道生成，代码零硬编码；扩展新资源仅改数据不动结构。

核心玩法特色

• 阵营机制差异化——不同势力以独立的资源 / 单位 / 魔法循环对抗，引出风格迥异的玩法
• 动态 AI 系统——AI 跟随玩家成长，从被动应对到主动反制
• 星级构筑系统——单位按近战 / 远程 × 普通 / 精英分四阶星位，构筑组合空间
• 自然涌现的战术——2D 物理 + 单位碰撞体让阵型布置自带战术深度

开发阶段

项目以 6 阶段路线推进，每阶段有明确退出标准：

• P0 筹备 ✓ ——项目工作流与协作规范建立
• P1 基础建设 ✓ ——数据管道、数据加载器框架
• P2 核心原型 ✓ ——一场战斗可完整运行；核心循环验证
• P3 全量构建 → 进行中 ——所有核心系统可运行，数据驱动，跑通完整一局
• P4 打磨与扩展 ——阵营扩展、真实美术替换、内测迭代
• P5 发行准备 ——Steam 审核、愿望单积累、发行策略
• P6 发行后运营 ——数据监控、热修复、内容更新路线

概念文档

5 页项目概念文档节选（点击查看大图）：

封面 概述 / 世界 玩法介绍 核心特色 涌现战术

策划文档节选

数据驱动的系统设计——单位与祝福 / 诅咒的 schema 化配置（点击查看大图）：

单位数据（faction / cost / atk / hp / spd / move_type） 祝福 / 诅咒数据（type / duration / script_path）

工程实践

采用 feature-branch workflow：5 个 feature 分支并行（player-hud / blessing-curse-system / loot-architecture / event-system 等），主分支保持稳定，单分支平均 280+ commits。配合 main / dev 双分支策略与按功能颗粒度的 commit 规范（feat / fix / data / doc / refactor / test / chore）。