本文共 1396 字，大约阅读时间需要 4 分钟。

第一轮：Dr.Mech

参加了为期7天的第一轮DEMO竞赛，最佳团队，总结一下开发过程中的一些要点。

问题：

1. 关于项目时间安排，由于项目核心代码量并不算太多，所以前几天还是比较从容的，不过这也导致许多细节只能在最后一上午进行完善，仓促中不免发生一些遗漏。

2. 本次开发过程中，由于经验不足，没有系统的规划程序方面的安排，直接上手写代码，开发效率受到一定程度的影响，代码质量也不过关。

   目录结构混乱，之后的项目可参考下方：
   
   由于unity项目资源众多（场景、脚本、模型、贴图、动画、着色器、音视频片段等），命名上缺乏统一的规范，这里最好用大驼峰命名法，同一资源类型用下划线+两位序号区分。

3. 程序对美术进行相关的规格要求，产出的图片大多都是原图直接使用，这在一定程度上影响的项目的内存消耗。美术相关要求可参考

4. 程序对策划配置表没有开发相关工具，策划数值调试耽误部分时间。由于时间问题，目前可采用github开源工具进行处理，参考

总结：

1. 可适当增加需求分析阶段的时间安排，将需求功能认真划分，确定模块接口，有利于提高开发效率。
2. 既然是团队工程开发，必然需要制定相关的开发规范，提前与策划制定好配置表的相关表项，与美术要求资源规范，要让美术和策划参与到游戏引擎的使用中。
3. 程序开发应遵循迭代开发的模式，在白模阶段将核心玩法搞定，可与美术对接好相关资源文件规格。
4. 给玩家适当的“勾引”，游戏的巧妙之处。

第二轮：吃货探险家

第二轮历时14天，第二名也算满足了，我们组抽到的题目比较宽泛，由于之前接触的不多，所以对工作量预想并没有一个大致的概念。

问题：

1. 时间方面，由于在项目评估方面经验不足，无法预估工作时间，我们花费了较长时间确定玩法，后来证明这段时间确实多有浪费。
2. 在我的强烈要求下，我们制定了相关的程序规范和美术对接规范，这次的代码质量整体要高于上次，但是随着开发的演进，很多时候忽略了这些规范，导致后期项目结构仍有混乱的现象，美术资源方面也没有进行专门的检查。
3. 项目分工严重偏差，由于并不是主程，说话的分量自然也…所以很多需求都由主程直接完成，导致其他程序略有闲置，虽然很感谢主程，但是在需求划分方面确实做的不够。
4. 潜在威胁最终导致bug，这次我们采取从csv读取配置的方式处理相关数值，中文部分有乱码我一直没在意，直到最后发现策划新填写的一版配置表出了问题，却为时已晚。可参考

总结：

1. 程序应当利用经验对策划的需求进行时间评估，保证规定时间能够完成
2. 增加对需求的明确分析，分工明确
3. 在替换模型时缺乏经验，一张一张对效率低下，应采用动态方式进行加载，可参考
4. 重新梳理unity开发流程，整理项目框架
5. 应注重UI交互，引导玩家而不是干扰玩家
6. 最后，跟优秀的人一起工作的好处就是，节省交流成本。

33天总结

1. 多看，大神优秀代码，并学习超越，更新自我
2. 多问，向他人请教好的技巧、方法
3. 多总结，就是现在写的东西，这个做的还可以
4. 美术与策划需要是用unity进行一些调整性工作
5. 美术设计不应脱离所对应的游戏产品
6. 在视觉引导要有新意，符合游戏整体的设计理念，ui与界面的融入，对用户的反馈（ux），主次关系要明确。
7. 美术和程序应当具备评估策划需求时间花费的能力
8. 游戏制作需要目标明确，过程应当是快乐的，要坚持一些自己的想法，要检查设计理念，成员统一目标
9. 作品应注重完成度，注重打磨，音效、特效需要与画面相结合

转载地址：http://cznaf.baihongyu.com/