创作方向 · 7 / 7
先把一段小体验从头到尾做完，再去扩展——每一次变更都要记录下它对工期的影响。
3D 原型诞生于 2026年9月23日，有一个写明的目标：在两个周末（9月26日至27日、10月3日至4日）内交付一个可玩的 Windows 演示版，使用 Godot、在 Tripo 中制作的模型和人形动画，内部完成目标定在 10月4日，并于 10月5日提交至 Tripothon S1。产品确定的优先顺序是：开发速度第一，画面质量第二，技术扩展能力第三；视觉参考是《My Time at Evershine》——参考的是美术方向，并不承诺复现它的规模或精细度。
此后，有两个决定改变了方向。9月29日，作者决定让 3D 版成为完整的游戏，2D 版转为规则参考，迁移成为首要任务：计划变成了两个里程碑下的 32 个 issue——Jam 04/10（#1 至 #6）和 Pós-jam（#7 至 #32）。10月1日，他又决定把 2D 和 3D 两款游戏放在相互独立的仓库中，Godot 项目置于根目录，系统都在本地。看板是验收标准的来源；issue 是工作单位，文档则记录它的缘由。
项目决策
先把一段小体验从头到尾做完，再去扩展——每一次变更都要记录下它对工期的影响。
3D 原型诞生于 2026年9月23日，有一个写明的目标：在两个周末（9月26日至27日、10月3日至4日）内交付一个可玩的 Windows 演示版，使用 Godot、在 Tripo 中制作的模型和人形动画，内部完成目标定在 10月4日，并于 10月5日提交至 Tripothon S1。产品确定的优先顺序是：开发速度第一，画面质量第二，技术扩展能力第三；视觉参考是《My Time at Evershine》——参考的是美术方向，并不承诺复现它的规模或精细度。
此后，有两个决定改变了方向。9月29日，作者决定让 3D 版成为完整的游戏，2D 版转为规则参考，迁移成为首要任务：计划变成了两个里程碑下的 32 个 issue——Jam 04/10（#1 至 #6）和 Pós-jam（#7 至 #32）。10月1日，他又决定把 2D 和 3D 两款游戏放在相互独立的仓库中，Godot 项目置于根目录，系统都在本地。看板是验收标准的来源；issue 是工作单位，文档则记录它的缘由。
9 条原则
不容商量的事
先小而完整，再求大
先把一段体验从头到尾做完，再去增加系统、角色或场景的数量。完整的玩法构想（种植、养殖、采集、采矿、钓鱼、制作、经济、战斗、任务、友谊、剧情）不能和四天制作期内承诺交付的内容混为一谈。新功能必须替换掉同等的工作量，否则就留在 Jam 的承诺范围之外。
坚持 Godot；Windows；单人；第三人称
使用 Godot Standard 和 GDScript，不迁移到 Unity 或 Unreal；Forward+ 为首选，前提是在目标电脑上测试通过。平台为 Windows，Steam 是之后的目标，但不强制集成；浏览器、移动端和主机都不在范围内；没有多人模式，也没有网络架构；第三人称相机使用 SpringArm3D。
几乎所有模型都用 Tripo，不用 Blender
角色、房屋、物件、装备和植被都来自 Tripo；交付不依赖 Blender，也不靠手工重拓扑或手工建模。第一项必做测试，是让一个完整的角色在编辑器之外的 Build 中跑起来：65 根骨骼的原型（9月23日）和 Carro Quebrado 的房子（9月24日）在批量生产之前验证了这条管线。骨骼绑定最终也出自 Tripo 自己（人形 Auto Rig 自动绑骨，Mixamo 骨架），而不是 Mixamo。
9月29日：3D 版成为完整的游戏
2D 版转为规则参考，迁移成为首要任务，参加 Jam 时有什么就交什么。3D 版已有的东西保留。原始文档中有三项没有进入 Jam 里程碑，转入了 Pós-jam：带记忆的 LLM 对话（#32，优先级待定）和种植（#8）；与存档位绑定的保存功能（#7）最终还是在 9月29日当天完成了。如果其中哪一项需要回来，由作者决定，issue 所属的里程碑也随之调整。
10月1日：相互独立的仓库
3D 版位于 acentauric/myths-valley-3d 仓库的根目录，在 main 分支上；2D 版在 acentauric/myths-valley 中独立发展。任何开发或测试命令都不需要检出另一个仓库；也没有规则、数据或音频的同步器。已经分叉的四个共享文件（把斧头作为可装备的物品）等待作者决定：要么把这条规则推广到 2D，要么正式宣布分叉。
两种视觉风格，后来只剩一种
直到 Build 10，“设置 → 场景与时间”都可以选择整个山谷如何构建：Tripo（主线）或程序化（早期验证），两者从不混用，为的是在同一个地方对照两者，以便决定主线。程序化风格没有再添加新的美术，也不是在顺带的改动中被移除的：移除它是一项独立任务，并设有门禁，发生在 2026年10月10日的 Build 11 中。如今山谷只有 Tripo 一种风格。
Jam 的取舍：哪些放进来，哪些往后放
放进来的：在已有锚点上的任务、背包、HUD 上的体力、新界面的按键表、第一批 Tripo 手持物品，以及翻译。不放进来的：第 2.5 阶段（扩展区域意味着 KML 绘图和导入）、野兽（需要骨骼绑定和动画片段）和室内（需要房间，而房间是一个系统，不是一个模型）。离提交只剩四天还去做新界面，提交就是这么丢掉的。取舍的规则：没有门禁，什么都不进 Demo。
一切都要翻译，翻译出自作者之手
所有玩家文本都提供巴西葡萄牙语（pt-BR）、英语和西班牙语，不只是菜单——这一决定在第 3 阶段之前就已做出，好让第一个任务步骤从诞生起就带着 _en 和 _es。代价是内容量翻了三倍；收获是山谷的受众不再有天花板。迁移提供结构和门禁；译文出自 Ramon 之手。
2D 是参考，不是主人
山谷有自己的任务机制（CadernoDoVale，一行进度，没有清单），这是作者的决定：这里的新任务可以采用不同的模式、格式和顺序。建造项目先带着身体增益效果上线，美术之后再补（“效果先行，美术随后”）。图鉴就是收藏（L），天赋网在 K，村子在 P，背包在 I，面板在 J——与 2D 版教程教的按键相同。
8 条规则
落到实处，体现在日常
- 每一次方向调整，都要连同它对工期的影响记入决策文档；新功能要么替换同等的工作量，要么留在承诺范围之外。
- 只要 Jam 04/10 里程碑中还有未完成的任务，它就优先；Pós-jam 则按各个 issue 中描述的依赖关系推进。
- 一个切片关闭一个 issue 时，计划中对应的阶段要在同一个 commit 里划掉：看板和计划不一致，就等于有两份计划。
- 每一批 Tripo 任务都要先获批准再运行，界面显示的费用要在点击之前发到对话里；标有 'modelos-3d' 的 issue 会消耗积分，必须先批准费用。
- 不要把决策文档当作 Tripothon 的规则：截止时间、时区、格式、视频时长、类别以及关于既有项目的规定，都要在提交前对照现行表单核实。
- 清楚标明哪些在 2D 底子中已经存在、哪些是为原型制作的；在核实适用的规则之前，不要声称符合参赛资格。
- 交付物是一个打包成 ZIP 的 Windows Build，包含所有必需文件、可识别的 commit 或 tag、运行说明，以及资产和署名清单。
- 每个模型的再分发许可（包括测试原型，以及万一取消套餐后的 Tripo 模型）都要在发布前确认。
体现在哪里
- 第一次本地测试（2026年9月23日）
独立的 Godot 项目，一个 65 根骨骼的人形原型（先是不带动画片段的 FBX，后来换成在 Tripo 中导出、带动画片段的 GLB），一个身高 1.78 米、可奔跑、带碰撞和相机的控制器；Forward+ 在 GTX 1660 Ti with Max-Q Design 上成功启动。 - 第一栋接入的房屋（2026年9月24日）
Tripo Studio → GLB → Godot 的半自动流程，用 Carro Quebrado 的房子完成了验证：65 积分，任务 fef21312-…，1,915,732 → 273,548 个三角面。 - 看板（2026年9月29日）
32 个带 3d 标签的 issue，分为 Jam 04/10（#1–#6）和 Pós-jam（#7–#32），并按领域打上标签：sistemas、interface、conteudo、mapa、modelos-3d 和 qualidade。 - 分仓（2026年10月1日）
项目在根目录打开，系统都在本地，测试无需检出 2D 仓库（#44 和 #61）；模型和 WAV 放在 Git LFS 中（#60）；开场和操作控制会统计失败次数，并经过证伪，确认会通过退出码判定失败（#69）。 - Build 标识
“v0.1.0-dev · Build #6”（2026年9月28日），是这一衍生版本的历史里程碑；当前的发行版是 Windows 版 Build 12（v0.12.0）；2D 版为 0.2.0-dev、Build 14。