【雨田计划】开发者日志4_程序上号

【本期进展】

这次是程序上号啦！给大家汇报一下我们的进展以及想法

零、文档对接

• 接入了 GameFramework 作为项目的基础框架。这是我们第一次使用如此大型的框架，相比过去 “manager of manager” 式的组织方式，它在规范与文件结构上都有显著差异。
• | 二编：希望这步别迈的太大……雨栀表示这次美术已经完全无法插手代码了。这让雨栀很伤心哈哈哈哈……
• 为便于团队成员快速上手，编写了若干对接文档，说明模块职责、命名规则与目录组织。希望通过这些文档，帮助未来的开发能更平滑地扩展，而不是在后期被迫进行痛苦的重构（真的很痛苦）。

文档对接图

一、系统拆解

• 在雨栀确定核心玩法循环后，我们将其转化为程序可理解的实现流程（Procedure），包括数据加载、模块初始化、主菜单、场景切换与进入游戏等环节。
• 在每个流程中，标出依赖模块，以便后续进一步拆解与实现。
• 整个系统被分为若干独立模块：Entity、Map、Camera、Time 等。
• 其中：
• Map 模块由“晒晒”框架的缔造者、伟大而全能的最强程序小雪负责；
• Camera 与特效由小红负责；
• 其他部分由我树树主导。
• 经历多次 GameJam 的积累，我们这次决定采用 Ability 组合系统。
• 通过在 Datatable 中配置不同能力与数值，策划即可组合出多样的实体行为。
• 这种方式不仅扩展性强，也可能带来更多“你确定这不是 BUG 吗？”的惊喜（惊吓）。

系统拆解图

二、Map 模块拆解

• Map 模块过于复杂，“一制作人二程序”约定了一天的线下 PK。从下午讨论（吵吵）到晚上回宿舍，才终于把大致结构拆解完毕（大概
• 我们首先从静态数据入手，分析了多款地图类游戏的数据存储方式，研究它们如何保证 Map Block 的唯一性。结合自身需求，最终设计出一个 五层嵌套的 Map 数据结构，能从 Datatable 中读取出唯一、无歧义的块定义。
• 我们随后从顶到底梳理了玩家在地图上的所有操作逻辑：UI 层、逻辑层该如何实现。同时讨论操作方式是否符合 PC 平台的习惯、玩法对接和实现上有无困难（例如拖拽、放置等）。在此基础上，确定了 MapComponent 所需的主要函数与运行时数据结构，并提前考虑与 EntityComponent 等模块的联动。

Map 模块拆解图

【下期计划】