一、程序开发本身
1. Cairngorm 框架的使用不够清晰,导致代码可读行降低。在cairngorm框架中大量的加入逻辑处理,使整个框架的耦合度以及代码的沉余大大的提升,建议能够把逻辑处理单独的提出来要调用逻辑的地方使用接口进行衔接。
2. 页面之间相互调用频繁,建议采用事件进行通信,降低各模块之间的耦合度。
3. 模块划分不明确,造成单一模块过大,影响游戏的可玩性。
4. 对代码的管理还不够规范,没有统一的编码规范和命名规则等,注释写得太少,增加修改BUG的难度。程序应该多加正确详细注释,注释不能进行复制。有些比较关键的点和巧妙的运用一定要加入注释,否则别人无法维护;
5. 做好本职工作。
6. 前后台通信方式socket的使用范围。建议socket+remote结合;
7. 前台逻辑结构设计加强;
8. 需要后台验证的数据结构简化, 前后台数据传输协议的优化封装,尽量减少带宽占用;
9. 前台画面播放的cpu和内存控制;
10. 数据库的事务;
11. 游戏数据日志;
12. 后台管理与游戏同步开发;
13. 前台刷新机制,及时刷新前台页面数据显示;
14. 数据库关系;
15. 游戏加载进度条显示的体验和进入游戏后的过渡体验不好;由于整个游戏的框架设计和模块划分没有规划好,导致第一次加载了大量的资源;感觉加载很慢,很多资源没有人为控制,导致进入游戏看到是一块块的呈现,玩家感觉加载不够流畅;
16. 新手引导,新手教程的整体规划;
17. 外部资源加载机制(尽量让资源独立,资源需要用到时才加载);
18. 程序设计时尽量考虑程序的扩展性和通用性;
二、团队配合
1. 事务没有追踪;常常就是口头上说了然后就又忘记了;
2. 计划跟不上变化。策划文档的改动太频繁;经常会出现一个功能性的设定,到后来改动多次,界面也有改动多次;
3. 开发过程中总是遇到这样的情况:边开发边问策划具体开发要求,达到的效果。特别是在开发前期,程序方面会发现很多的策划文档没有足够详细的设计和流程图,多数时候都是靠询问临时解释;
4. 团队的整体磨合上还有一些欠缺,整体质量的保证只是通过程序员自身的素质决定,而非有效的管理协作,团队应该相互协作,发挥优势互补的能力,建议主程能够拿出魄力,很好的引导大家形成团队战斗意识。
5. 在对外的协作上还应该加强,这样既减少了与策划的沟通不畅导致的失误,也可以团结整个团队;
6. 文档。有时候的改动或新加功能,应形成文档,避免造成以后责任无法追溯。
7. 需求。只有文档已经基本上完成才能提交与程序进行开发。避免中途频繁修改;
8. 开发。当一个模块结构需要设计时候。设计人员应该将自己的设计方案与组内人员进行探讨,探讨评估结束通过才能确定该模块的结构设计;
9. 改动。当设计有改动时候能够先反复想好,最终形成文档(包含修改原因),以避免重复修改。
10. 责任。当一件事情,明知可能会影响游戏的时候或没按流程(紧急除外),仍然要求进行时,程序有责任并有权利进行拒绝。
11. 建议和讨论。策划之外的人员只能是对自己不明之处进行询问,而不应对该问题进行一些本质上改动性的建议和讨论,以避免误导策划的思维造成决策性的错误。
12. 催促。当一件事情已经在很紧急的处理中的时候,不应再有人进行催促,避免给处理人员造成更大的心理压力,使得处理人员思维紊乱,从而事倍功半;
13. 否定。当一件事情被否定的时候。应该由否定相关人员提出相应解决办法给予解决
14. 流程。除非紧急事情。否则需按正规流程执行,如果是紧急事情。处理过后应补上。
15. 问题。出现问题应该先由组内人员对该问题进行讨论解决。只有当问题不能被组内人员解决时候才寻求外援;
16. UI设计没有做到统一规划,策划在设计的时候基本上没有考虑到整个系统的一些通用性的资源设计,造成很多公用的资源被多次加载,增加了游戏容量但是体验感不够好(比如按钮的统一风格和弹出框的样式使用、应该尽量重用和统一)
17. 没有对一个游戏的框架性的设计,很多东西想到了就加进来,到了后面就越来越混乱;
18. 资源的管理很混乱;分类不够明确;出现很多冗余的资源和代码;(比如:大家都在使用ui.fla的时候,管理不好很容易造成很多图片的冗余和归类不明确);
19. 上级领导经常会在没有经过比较充分论证的情况下就要求下面的人干一些修改或者是新功能开发;这些往往会偏离策划的初衷,让整个产品变成“四不像”;