开拓芯“Neon”开发有感

本文系用户投稿，不代表机核网观点
今天是2025.5.5凌晨1：36，我在此写下这篇开发感想。 
今年我19岁，这个项目开始的时候我还未满19。为什么说这是我的第一次长跑呢，其实是第一次参与或者说带时间跨度这么大的项目。很不幸的是，并没有像我预想的那样，出道巅峰、一战成名，而是与不少人一样，半死不活的拖到了现在。
这篇文章是我个人对Neon这部作品开发过程中碰到的一些问题进行一些分析以及对未来发展方向的一个规划。

首先，团队管理
在这一方面，我做的相当失败。在一开始我们的人员结构是1技策2程序1美术1音乐，中期发现美术人手不足，我们又临时补充了一个UI美术，但是面临动画岗位的空缺时，实在是太难招到这方面专精的人才了。同时由于部分成员出现了消极怠工的状况，还有后招UI工作上无法协调，组成再次出现了变动。到了中后期，我们的组织架构变为1技策1程序1美术1音乐，但是所有人的工作积极性严重下降，四月一整月的进度不如3.24一天的进度。反思自身原因，因为谈恋爱了，确实对工作还是有一定影响的；再看团队，大多数成员个人工作都比较繁重，有的人在准备面试，有的人可能比较需要接一些单子，还有的人可能课业比较繁重，最终结果就是团队开发氛围有一个断层式的下降。究其原因，我感觉最主要的还是清明节当时刚谈恋爱，精力分散了一部分，团队气氛没托起来，就沉下去了（
我们的团队在组建之初属于是典型的“野队”，大家在各个社群上认识，集齐了四个岗位就上了。并不是说这种方式不可取，但是在组建这种队伍的时候我想又一些要素不得不考虑到：
沟通能力  在过去，我可能不会把这个能力放在首位，但是经历了这次项目经历后，个人感觉沟通能力甚至一定程度上超过了业务能力，业务能力的不足可以通过人数（不同方向专精）或者学习来弥补；但是沟通能力不足，或者说对自身能力的不自信导致的“社恐”，会导致整个项目无法向前推进，这不仅仅关乎项目的呈现效果，更是直接关乎项目是否能够成功落地。这个能力的衡量标准我觉得可以是：
是否敢于说“我做不到”
是否能够提出自己的要求
是否敢于将自己的进度（草稿、素材、文档、Code）展示给其他成员，并进行讨论。
业务能力 业务能力决定了你我能给这个项目带来的“收益”，在项目中学习的成本是比较高的，一定程度上牺牲开发时间进行学习，很容易拖慢整体进度。但是在我看来，业务能力并不是说越强越好，而是一个团队的业务能力相近是最理想的，不会因为能力不匹配造成能力较弱成员的内耗，也不会使能力较强的成员因为与预期的落差而感到沮丧，这两个问题其实也是Neon这个项目后期进度堪忧的关键。实话讲，我并不太清楚这个怎么能够精确衡量，这大抵需要有长时间的开发经验才能了解，但是其实也有的一眼能够看出水平是否匹配，不要为了面子妥协，组队应当是个双向选择的过程。
热情 个人感觉热情是大学生团队进行开发的核心动力，应当没有几个团队在组建之初就是奔着赚钱去的。每个团队成员的热情越高涨，那么其与这个项目建立的关系也就更加深刻，这在很大程度上可以避免半道跑路的情况发生
其次，项目管理

图示为我们最开始的一个时程安排，最主要的问题我觉得有三个：
极度理想化
安排过满
错估团队成员生产力
这三个问题的根本在我看来是非长期合作伙伴之间能力的不了解导致的。最近看了@Hyrls的文章以后，去读了《项目管理基础》这本书（我读的是[英]约瑟芬·希格尼所著的版本，不知道是不是这本，但是还是颇有内涵的），书中提到的一个观点我认为能够对上述问题有一定的改善：“真正做事的人务必参与规划”。每个成员，或者我们按照书中的概念来讲，每个“干系人”，都在计划时程时都参与进来，就能很大程度的避免一些上述问题的发生。
可惜了，没有在上学期了解PM这方面的知识，这是导致这个项目最终未能在due day前完成的一个重要原因，接下来还有十几天，希望能赶上CUSGA最终的提交（）

关于资产List这块，我其实仍然不太确定这种方式是否合理；我们组的List的罗列主要依靠的是策划一个人的想象与思考，其实很多要素在中后期才发现并没有考虑在内，同时高估了组员自身的能力，很多比如说特效这些需要的是一些相对复合型的工作者，传统的美术和程序之间信息损耗过大，有时候并不能达成很好的效果。现在看来，从资产遇到的困难这方面出发，我认为在大学生独立游戏这个开发群体中，除非队内有一个时间能力都相当充裕的全栈大佬把关，否则美术、音乐音效、策划这类工作也一定要掌握引擎和团队的版本控制工具，可以不精通，但是至少能够把基本效果实现出来给程序进行重构，尽可能的减少信息的损耗。
总的来说，把List上的任务完成并不困难，困难的是将这些要素最终组装，在组装的过程中生产一些细节化的资产填补“空隙”。
开发模式上，我们采用的是一个典型的瀑布开发模式，也就是核心玩法验证👉基本策划案👉开发👉测试👉发布，目前是停滞在了开发阶段。这种开发模式相当常见，大部分团队也选择了这种方式，其最大的不可控个人认为在于相当依赖于前期规划，对于经验并不那么丰富的制作人来说，很难照顾到所有关键点位，这样的结果一种是像我们一样，所有人都疲于解决，士气越来越低落，另一种则是每个成员都在努力拓展自己的部分，最终造成范围失控，越做越大，但是项目永远不完整。或许日后会了解并尝试其他的开发模式？但是并不紧急。

线上协作中交流主要用QQ，在线文档使用飞书，版本控制工具使用的Plastic。但是其实协作并不是很紧密，基本上都是各个岗位联系我，我又去接洽目标成员。这就导致了我们的协作效率相当低下，一部分原因是因为我个人沟通表达能力可能并没有那么强，另一部分原因是这样的沟通模式注定了效率不会非常高。这也是我为什么现在觉得团队成员之间能够互相沟通，自行决策一些东西相当重要，尤其是当制作人一个人的能力不足以扛起一整个项目的时候。
其实在项目开始之初，我并没有做风险管理的意识，想的是“兵来将挡，水来土掩”，但其实很多问题的预案是十分必要的。就比如说我们遇到的主角Koi的动画资产未能达到预期的问题（项目停滞的导火索），如果我们提前想到了相关问题，那么就可以直接转向或者是寻求其他一些解决方案，而不是在放手和不放手之间不断摇摆，再而衰，三而竭。
再者，开发经历
在项目开始之初，跟每个开发者一样，大家都抱有相当的热情，可以说这段时间是项目进展最快的部分，基本gameplay在此时初具雏形，当大家面对一个切实能玩的游戏时，其带来的反馈会形成正向激励，促使项目快速进步。
在项目中期，要将一开始的玩法demo细化，扩展相关资产，并且打磨一些交互方面的问题。这一阶段一方面面临长期测试对游戏本身玩法新颖度形成质疑，另一方面会由于成果形成的正向激励不如前期从0到1的激励，使得开发速度逐渐下降，这个阶段最关键的可能是总结已有成果，优先以一个个功能集为节点进行开发，至少让队伍看到成果才有动力继续开发，一味的催促并不能从根本上解决效率低下的问题，这也是我在这次项目中没有做好的部分。
说实话，个人现在也不知道该怎么把这个项目继续下去，但是在可预见的将来应当是不会放弃这个项目的，即使队伍中的成员不愿意再继续进行开发，我也会选择个人用一些取巧的方法实现一部分功能，简单“封口”，至少把它做完，然后或许在未来的某个阶段重拾？（
最后，个人发展
我个人在团队中扮演的角色算是技术策划，甚至可能有些偏向于全栈。主要做的部分是核心玩法的实现、关卡设计、一部分音效还有动画部分。其实在项目之初有些高估了自身的水平，承接了太多工作，尤其是动画这个工作，专业性太强我之前也没有过深入研究，侧面的动作还有许多同类型的游戏可以参考，但是正面背面的动作本身就是2D骨骼的一个难点，缺乏参考，最终的实现效果其实相当不好。在未来我应当会回归我一开始选择的技术策划方向，适当放弃动画啊音乐这些，研究gameplay的设计和一些基本的引擎、c#、shader的编写
最后的最后，是我的联系方式，
Email：18698699786@163.com 
QQ:386032666
欢迎指正。