蜡忆余彩【游戏日志03】设计到实现：程序开始搭建游戏的基础框架

2 小时前1 浏览

这期主要记录一下目前程序侧的开发进度。

前面的工作更多集中在关卡设计、核心涂鸦和剧情结构上，而到了真正实现的阶段，我们也开始把策划案里比较抽象的内容，一点点拆成具体的交互、道具、状态和程序逻辑。

从目前两位程序的反馈来看，整体开发过程比较顺利，策划侧的需求也比较明确，暂时还没有遇到明显“完全做不出来”的核心功能。

现阶段真正需要花时间处理的，更多是不同系统之间应该怎么连接，以及后续如何让新的关卡和物品能够比较顺利地接入现有框架。

本期进展

本期主要推进了程序侧的基础功能搭建与系统拆分。

目前正在逐步整理和实现的内容主要包括：

交互系统、道具系统、植物复苏逻辑、涂鸦相关逻辑、背包 / 持有状态以及关卡推进。

【例：植物复苏效果】

其中不少功能目前仍然使用测试物品和基础类进行验证。

也就是说，现阶段程序首先解决的是：“这个功能能不能稳定运行？”

而不是一开始就把所有正式资源和具体物品全部接进去。

等基础逻辑逐渐稳定之后，再把测试内容替换成真正会出现在游戏里的纸飞机、水壶、彩笔等交互物，并根据不同道具继续扩展具体功能。

目前程序侧也在尝试把一些会被反复使用的功能提取成比较通用的基础结构。

比如不同道具虽然用途不一样，但可能都会涉及：

是否可以交互、是否可以拾取、当前是什么状态、交互完成后需要触发什么结果。

先把这些共通部分整理好，后续第二关、第三关再加入新的交互物时，就不需要每个物品都重新从头实现。

整体来说，目前程序侧的开发节奏还是比较顺畅的。

其中一位程序的反馈比较概括：

目前策划需求比较明确，功能继续拆分之后基本都能够实现，还没有碰到明显做不出来的内容。

另一位程序的感受则更加直接：

开发顺序目前比较清晰，基本就是一直明确下一件要做的事情，然后继续往下做。

对现在这个阶段来说，这其实也是比较理想的状态。

问题与风险

目前程序侧最大的难点，并不是某一个单独功能有多难实现，而是：

随着功能逐渐增加，不同系统之间的关联也开始越来越多。

例如一个看起来很简单的交互，后续可能会变成：

玩家操作道具
→ 道具状态变化
→ 谜题条件满足
→ 关卡进度更新
→ 核心涂鸦发生变化
→ 对应色系恢复
→ 下一阶段内容开启

单独看其中任何一个功能都不算特别复杂。

但当这些功能开始互相影响以后，如果系统之间的接口没有提前整理清楚，就很容易出现：改一个功能，另外几个模块也跟着出现问题。

目前程序侧也特别提到，像交互、背包、涂鸦以及后续关卡推进之间的联系会比较多，所以需要尽量提前确定不同模块之间的职责和接口。

另外一个比较实际的问题是：

策划侧后续还需要进一步整理具体的交互物清单。

相比于只写：“玩家找到道具并完成解谜。”

程序更需要知道：

这个物品叫什么？

玩家可以对它进行什么操作？

触发条件是什么？

交互完成以后会改变什么状态？

这些内容越明确，程序在判断“现有功能能不能复用”以及“是否需要增加新的交互类型”时也会更加顺利。

所以目前我们的一个重要目标，就是在玩法设计和程序实现之间把这层信息继续补完整。

下期计划

下一阶段程序侧会继续完善基础交互框架，并开始把目前使用的测试内容逐步替换成真正的关卡功能。

当前最重要的目标是：先把第一关从头到尾完整跑通。

也就是先完成一套完整的核心流程：

观察线索
→ 与场景和道具交互
→ 完成谜题
→ 更新关卡状态
→ 恢复对应色系
→ 开启下一阶段

第一关本身既是玩家的教学关，也是后面两个关卡的重要基础。

所以相比现在就同时铺开所有内容，我们更希望先通过第一关验证：

这套交互逻辑是否合理；

系统之间的连接是否稳定；

现有框架能不能支持后续关卡继续扩展。

与此同时，程序侧还会继续整理：

交互系统、道具系统、涂鸦系统以及关卡推进之间的接口。

策划侧也会进一步补充具体的交互物和道具清单，方便后续逐步实现不同物品的具体功能。

只要第一关的完整闭环能够稳定运行，后面的植物关和家庭关就可以在现有框架上继续搭建，而不需要每个关卡重新从零开始。

#TapTap聚光灯 #TapTap聚光灯游戏创作挑战 #聚光灯gamejam开发者日志

聚光灯游戏创作挑战

9.0

前往论坛

游戏开发者讨论区

1.2 万关注·3730 帖子