大家好，这里是蜜糖，本文记录了我这两个月中游戏《想开了》开发过程中的感悟。

5月Booom之后，我们评估了demo的后续开发工作之后，选择在Unity的Corgi引擎上进行开发。经过一个半月的赶工，总算是在cj上拿出一个勉强能玩的，一定程度上表达出我们立项想法的demo。

这里想通过这篇文章记录一下这一个半月的项目发展，文章标题或许有些矫情，但是：

如果你跟我的标签有所重叠的话，或许文章中的内容和方法能够对你有所启发。

只有有DDL才会有工作的动力。同时，只有有时间节点的约束，才能更好的识别制作内容的必要性做出取舍。成熟的项目管理人员“全都要”是危险且不成熟的，必须要认识到项目的核心竞争力在哪里。

而在参加过Booom之后的当时，7月底的CJ简直就是天生为我们设置的下一个DDL。

2个月时间，时间不会太长，方便进行中期规划；也方便针对每一个人制定一个可以接受的工作量。

我们在Booom完成后，因为希望将游戏改为银河城的探索形式的游戏，考虑到工作量的原因，所以切换使用了Corgi引擎来减少工作量，所以在这个基础上，需要从熟悉框架为起点重新规划所有的工作量。

我们在使用git作为代码同步工具的基础上，选择使用腾讯云文档来进行轻度协同办公的方式，开发部分的分工如下图：

同时，添加了开始结束时间之后，当项目延期了之后，可以通过可视化的形式预估出延期内容，从而进一步保证项目的可控性。

其实这样的任务拆分才是互联网所说的OKR模式，我们的工作过程为了关键结果负责，本次我们的关键结果是CJ顺利出展，而所有的项目代办都是为了出展顺利，但是出展并不是一个硬性的标准的，从高到低可以分为：

可以看出，我们最后的兜底内容可谓是十分的低了，所以心理建设其实很健康。而实际上我们的最终成果是2.5左右，在核心的关卡上加入了部分的效果，但是没有进一步的优化。不过，已经能够基本展示出我们的立项主题了，也同样符合OKR内容完成60-80%的话，最后就会有一个不错的结果。

一切都以灯塔为目标，成员开发内容延期是常见的事情，但在DDL时间点不断临近的过程中，不断评估完成事项的重要性，调整工作内容的优先级。

比起大家的能力，我其实更关心信息传达的有效性和通畅性。在此基础上，由于原团队由4人构成，指责为：主程、TA、美术、关卡策划。

考虑到希望进行银河城式的关卡设计，所以希望在1个半月中创建20个房间左右的地图，所以这里我们需要额外的关卡来同步设计。

为了可控性，我暂时是从粉丝群中邀请了两位朋友来帮忙完成设计。因为在本次demo中，比起单个谜题的质量，我更关心的是谜题的类型再大地图维度上的前后关系。所以只要是有希望家，对传统的平台跳跃类型有一定的认识，并能良好沟通的朋友，就可以完成计划中的任务。

而为了大家能够对整体的关卡有一个完整的认识，我进行了以下步骤。

1. 对关卡难度进行了定义：

我对关卡谜题的难易度进行了描述，从而拉起大家对于关卡谜题的认知。这样在先进行信息同步后，后续如果难度超过了预期设计中的形式的话，由于已经预先对规定的关卡难度进行了描述，所以比较便于沟通对已经创建的难度。

ce：简单谜题，核心判定在角色极限高度、极限距离的60%，即容错40%，在连续的操作中由单个的能力、机关组成，连续操作数量不大于3次，例如连续蹬墙跳3次。 作用：1、能力教学；2. 用来缓和谜题节奏，和ch、cm交替出现；3. 用于叙事。 cm：中等谜题，连续3-5次以及以下谜题容错20%，或者1-2次单0%容错的谜题，可以由两种能力、机关组成。 作用：1、单种、或者组合能力的验证，应当主要以当前区域的能力做验证； ch：困难谜题，连续多个0%容错，或者某种快速切换的技能组合； 作用：在boss战前，所有boss战中需要使用的组合，都是要通过至少一个ch组合进行验证的。如果boss战存在需要多种技能的组合，则需要让玩家通过多种ch对应技能组合。 cc：挑战谜题，随便放开了设计，可以做场景外时差，但是cc挑战必须要有对应的奖励，可以是捷径奖励、可以是收集品奖励、可以是额外的辅助能力提升（生命值上限、精力条上限等） 作用：1、如果玩家能通过挑战谜题，则默认以下情况：玩家已经对某一种组合十分熟练，可以跳过后续的能力验证（也就是所谓的可以通过cc谜题设计捷径）；2、可以在无关主线的部分通过cc涉及额外的支线挑战；3. 隐藏房间、或者独立房间中作为奖励挑战。

2. 对地图进行编码命名

这个其实是参考“银河战士”的官方手册中的方式，对谜题、奖励、动画交互等位置进行编码，这样可以在为进行地图设计的时候就进行地图设计。从而在设计之前为全体同步地图设计的调性。

整个游戏的关卡的排列主要是根据模块的拼接串联组成的。而对于一个模块的定义为：

{场景:一位大写字母}{房间:两位数字}{模块:两位数字}{模块类型:1、2位小写字母}

例如: L0101ce

而我们对所有的场景也进行枚举编码，例如：莲花池（Lotus）： L，混乱空间(Space)： S，火焰山(Fire)： F。

这样，而模块类型就是上文中的挑战、以及其他的事件、动画等类型。这样设计后，就可以对地图设计从而得到以下的流程：

这样，就可以非常清晰的一定程度的规划出来难度曲线，并根据规划分片的将内容交付给不同同学的，进一步的也可以以迷题为单位追踪开发进度：

3. 大地图的交互设计

我心目中的地图设计是可以一张地图达到多次复用的目的，而这样的设计很难通过文字描述传达到伙伴心里。所以，大地图设计还是少不了的，我这里选择直接用云文档的“流程图”功能来大概编辑出地图：

但是心疼的是，这个图片组件太多了，甚至还需要开vip，为了CJ忍了。

但是可以看出来，通过这种方式，我们可以通过房间的编号准确的描述出大地图中房间在空间上的关系，并且我们可以在早期的时候就设计出一些预期中的交互。

比如上图中的D02 会重复通过三次，第一次是在进入后，无法前进，需要通过D03、D04取得蹬墙跳能力；回去之后第二次通过D02继续前进；当打完Boss之后返回后最后一次通过D02，这时因为具有Dash能力，所以可以快速的通过一些之前只能绕行的机关。

又比如D005有一个极难的验证玩家能力的挑战，通过后可以绕近路到达D08，但这里的难是第一次通过时，如果已经通过具有了Dash能力了，那么这里的难度就会降低很多。

诸如此类，所以在设计每个房间的时候可以添加额外的文字补充，再配合大地图的位置关系，可以在拆分进行关卡设计的同时，保持房间的功能性以及作用。

而实际上，在本次构建demo的时候，我们将龙宫地图部分拆分为4份，并行进行地图设计，然后在交叉试玩，再重新调整难度以及修复bug。

基于以上三个部分，将地图的设计模块化拆分，先进行逻辑定义，然后再实现定义，最后再用原本的需求进行验收，从而让关卡设计尽量符合最初的设计初衷。

我永远相信，我们的队员是最棒的，但是我们的美术就是最棒的。

在CJ的时候有很多的人都是因为我们的海报而驻足停留的：

我们想走国风的的线路。

但是同样的，还是具有工作量的问题，所以我们这次并没有更换之前的格子的方案。而是继续使用相对熟悉的格子方案，对世界进行拓展。

由于计划中我们的剧情是具有8种场景的，而在demo种计划使用其中6种，抛去之前已经完成的莲花池地图，我们仍然需要创建5个世界的地图。

在总时间有限的情况下，我们判断，格子的方案肯定不好，因为整体与水墨风格有些割裂，因为边缘太过规整了，和水墨的形意有些出入。

但是考虑到时间的原因，以及主美大大比较忙，所以仍然采用的是原方案。

最终效果如下：

可以看出来，整体的风格是统一的。我们采用了相对可控的方案，并最后完成了目标。虽然马赛克格子的方案不能说是对国风的一种很好的展示。实际上，在CJ展会上也确实有老师指出，方格的方案与水墨风格有些割裂，这个也确实是下一阶段我们主要研究的一个方向。

但从结论上说，我认为当时的方案选择，使我可以在有限的时间内完成一个完整的DEMO，而这个已经足够完成我们的玩法验证与风格展示了，从结果上来看，我很满意。

做游戏，一个人的能量终归是有限的。尽管你会觉得团队协作的时候可能束手束脚，总会引入新的问题。但是，我认为这都是为以后当你需要扩大规模时的一种磨练。

而这种规划、协调的能力，是需要锻炼的，同样的，如果你可以积累规划协调的案例，也更方便后续从事相关方面的工作。我本人之前是从事互联网开发的，有一些协调管理经验，但如即便你没有这些基础，我认为别害怕，尝试的担任队伍的对接、协调工作，会对你收获很大。

因为独立游戏，在初期我们往往是没有足够的资金支持的，所以注定队伍中常态化是大家能力并不是齐平的，或者专业程度各自不一样。比如我们的队伍，其中4个人是工作老油条，不过不是游戏专业的，也都是以兼职的方式来进行，而更有两个是学生还未正式工作。

所以我们并没有正经的游戏的流水线经验，不过我认为别怕，葫芦娃救爷爷，爷爷最后也是救出来了。在这个工程中你需要切实关注的是两个事儿：

保持热情，积累，当有一天你打磨好demo后，或许有机会扩大规模协调大家完成它。

程序员就别指望什么文笔了，但是这两个月的过程中从头开始学习框架并规划剧情背景，完成的工作量还是挺大的。非常感谢队伍中小伙伴的不离不弃。这次CJ也非常快乐认识了很多老师，很多人，同时还是要感谢机核和二七带来的BOOOM，点燃了很多人。