 日志正文
|
||
|
建议准备做项目和正在做项目的都来看看，吸取一下教训。处女项目就失败了，对团队每一个人打击都是很大的。 1.过多的工作压到了同一个人身上 在很多小公司[或小项目组]里，总有那么一个核心程序员，负担了几乎所有的编程任务。这个人即使是个天才，也被繁重的工作压的没有学习和自我提高的时间。 比如设计模式这样的思考方式也是近几年才进入中国普及开来，却并非那么容易学习。整天迫于项目压力，就无法领悟新的东西，保用更好的方法解决问题。 独自一个人总揽大局，在项目后期很容易因为想早点结束，而把整个代码补丁打得满目沧夷，只求能解决眼前碰到的BUG而不为长远的结构稳定去考虑了。 结果整个工程无法分出明显的模块，各部分耦合度太高，必一处牵动全身，一直到新的BUG出来后无可救药。 2.过分的弹性工作制 游戏程序员好似天生追求自由的一群人，白天办公室里经常看不到几个人，晚上通宵达旦地在电脑前奋战。不否认好的程序员在精神兴奋的时候可以连续工作写出质量不错的代码，但是停下来时几天没有进展也是时有发生。尤其到了项目后期，一旦BUG重重，程序员备受挫折，仿佛眼前的活永远都干不完，而且调试程序也失去了编写程序时的新鲜感，最终假借弹性工作抽的名义，消极台式拖垮项目的先例已经有很多了。 弹性工作制不等于没有计划，不等于可以随意为之。在项目没有进展，面程序员却整天不干正经事，只知道聊天，浏览网页的时候，程序员并非没有心理压力，他可能只是不知道下一步该怎么做，或是问题太多已无从入手，这说明项目已经失控了。 3.没完没了的变化，没完没了的返工 大家都想把自己的作品做的更好，往往正在做的还是自己的处女作。自己的游戏做了一半，看见新上市的游戏有了什么新玩法，新东西，都想抄到自己的东西里来。 新发现什么技术可以让画面效果更绚，就迫不及待地实现出来看看。又或者，新做出来的东西老是不满意，三天两头地放弃重做，力求完美。最终，游戏老是做不完，看不到尽头。如果从投资方来了时间压力，最后一咬牙反个四处有缺漏的版本交出去，等待着的是玩家没完没了的投诉电话。 4.没有及时的测试 谁都知道软件做完了是需要做测试的，测试出问题就应该修正，这似乎是天经地义的事情，但是落到实处，早期的国产游戏却很少有严格的测试。因为很多人忽略了一点，无论是哪种软件开发方法，测试都不是在软件全部开发完毕后才进行的。等到大家看到项目好像已经完工，这时候对游戏做整体的测试已经完了。必定发现一大堆的BUG，已经到了无处着手的地方，如果只是头痛医头脚痛医脚那还真的不如借这次的经验教训，把程序推倒生来做的更好的设计呢。 5.项目的主导严重地偏向了某一个职位上 早期的游戏大多是程序员主导整个游戏的设计的，程序员说应该怎么做就怎么做，说今天要怎么改就怎么改，甚至没有单独的游戏策划一职，全部由程序员包办。 这对小型游戏倒没什么，对于规模较大的游戏，最终即使游戏程序本身没有大的问题，但是在游戏性方面却让玩家难以接受。作为技术人员，很容易把目光注视到技术的枝节上，而忽略了玩家的感受，大多数情况玩家并不把技术人员扬扬得意的地方放在眼里，游戏毕竟是给人玩的。 后来又出现了策划为主导的游戏，策划拍脑袋一想，我们应该加点什么，那么程序员就日日夜夜地加班完成。如果实在是技术解决不了的还就算了，最怕的是，本来技术解决有问题，可能新加的设计会影响到整体的框架结构、对硬件的过分要求行，暂时像铁皮膏药一样把功能补上去看起来工作得很好，可是早早地就给日后的持续开发留下了隐患。程序员在实现的时候盲目听从策划的安排，没有仔细地全面思考，造成了项目无法完成。 我也听说过美术甚至市场人员为主导的项目，但并没有接触过这样的团队，就不太清楚会出现什么问题了。 总而言之，游戏开发是一个需要大家共同努力的事情。我们应该把自己的思考都带入到开发中，盲目地跟从别人的想法或固执地坚持自己都有可能影响整个项目。
我的相关日志：
阅读(?)评论(0)
|
||
评论
想第一时间抢沙发么？