游戏项目的技术开发成本

      在游戏行业已经有多个年头了，在手机游戏行业混，所以项目多是中小型项目。从j2me单机游戏，商业模拟游戏，到java的wap网游。基本上这些都是用java开发的。不同的项目有不同的经验教训。我且先从几个方面说起。
1、软件项目是否易于动态开发甚至动态发布？很多j2ee项目，以及一些c/s架构的项目，很难做到这两点。在我做商业模拟游戏项目的时候，第一款联想笔 记本连锁专卖店项目，是采用c/s架构。服务器端要更改一点东西，就得重启。客户端要更改，也得重新连接。回合制游戏，还得经过好几个回合才能到需要的那 个界面。这样开发过程中，很多时间就这样浪费了。当时我觉得这个从技术上来讲，确实很浪费，但c/s可以做出很好的效果，c和s两端都有很大的提升空间， 以及技术发展空间。所以当时我还很看好这样的架构。当然这个时候也认识到b/s架构的威力，至少发布成本几乎为0，动态开发也是可能做到的。更改了新版 本，不需要重新下载既可以开始测试。后来boss决定转向b/s架构开发，这个时候我认为处理商业模拟游戏的早期，还没有足够多的项目经验，不足以制作产 品平台，所以就希望架构上能够做到动态开发。这个时候我的选择是mysql+javabean+jstl+js+css。由于不打算做商业模拟游戏开发引 擎，所以javabean部分设计成可以重用的，只有用户管理模拟模块，绝大部分的计算在数据库中用存储过程计算。这样，基本上开发商业模拟游戏，可以达 到动态开发和动态更新两个目的，开发成本大大降低。第一款游戏开发周期为4个月+，采用B/s架构开发了几款商业模拟游戏后，这个开发周期降为5周。基本 达到了我预期设定的1个月的目标。人月成本从12人月降为5人月。当然，由于早期还是以项目形式开发，没有考虑做成引擎或者开发平台，为今后的项目复用， 这样的代价是维护成本比较高。所以，应该还有第二种降低开发成本，而且降低维护成本的途径。先做开发平台，包括相关的开发工具和引擎，然后将可变的部分尽 量脚本化。通过固化引擎和工具，降低后续项目开发的代码量，大量缩减开发成本，这应该是一条更可取的路，但是前期的成本会更高。
2、软件项目代码量的控制。早先一个j2me游戏，<1万行的代码量，商业模拟游戏，1-3万行的代码量，wap网游，10万行左右的代码量。可 见，最后一个wap网游项目有点问题。这是我的一个大教训。对于wap网游这样的项目，合理的代码行数应该是3-5万行左右。这样才是一个中等游戏项目的 代码规模。为什么没有做到呢？1、我对年轻程序管理上以提建议为主，有些程序员总喜欢自己造轮子，比如该用quatz，硬要自己写一个timer的扩展， 我也不阻拦，只要能完成任务，不能防微杜渐，所以后面不好收拾。2、这个项目我介入的比较晚，早先的架构决定了很多都得自己重新开发来过。最终后果很严 重，项目的代码规模失去了控制。所以虽然这个项目最终性能还不错，但开发和维护成本都很高，毕竟，这么多代码摆在那里，何况里面不少并不高明的重复造轮子 的代码。记得前段时间去某个公司面试，技术主管比较年轻，问了如何看待重复造轮子的问题。我的答复是，我不鼓励重新造轮子。第一，很多人之所以重新造轮 子，是因为不知道有这样的轮子存在。第二，是因为对别人的轮子不熟悉，不愿意学，当然，也可能存在部分轮子质量不太高，学习成本很高。第三，很多轮子并不 是最适合目前项目的需要，通用的轮子对很多特定的项目而言可能功能过多，性能等方面都有影响。这里面，只有第三种才是有必要考虑重新造轮子的，但是，往往 得出第三种结论的时候，你其实已经先用了轮子，可以用数据证明轮子不太合适了。这个时候需要考虑的切换成本和重造轮子的收益。所以，作为项目管理者，在架 构设计的同时，把轮子选的相对合理一点，以此控制项目的代码量，这是控制项目成本的重中之重。选好外界通用的轮子，固化自身产品线自产自销的特定轮子，是 逐步降低项目成本，提升竞争力的重中之重。
3、在软件硬件更新换代频繁的年代，技术路径选择如何寻找平衡。对于大公司，因为切换的成本非常高，所以技术选择上相对保守。对于小公司，存在两种可能， 先锋类型的，非常激进，这样才能让时间成为这样小公司的朋友，一步领先，步步领先，在技术上获取越来越大的影响力。保守类型，采用最主流的开发技术，这样 在公司不稳定的情况下，可以以较低的成本让开发团队基本稳定。对于新老程序员，同样也有类似的选择，新程序员选择主流的开发技术，可以让自己在人才市场有 更多的选择，对于老程序员，选择较为先锋的技术，可以押宝未来的技术潮流，提升影响力。所以，最终的选择，是要平衡各方利益，相对成本较低的选择。比如在 小公司的我，已经体会到不用主流技术，新人容易流失的痛苦，同时也看到了小公司采用最新的技术，新人也流失的痛苦。所以，采用什么样的技术，和团队的人员 构成息息相关。在项目开发过程中，团队成员的稳定是至关重要的。所以，不能单凭技术喜好和眼前的成本做考虑，需要从长远考虑自己的团队需要如何发展，采用 什么样的技术可以确保团队沿着这样的路径前进。尤其对于希望做产品开发平台的团队而言，这点至关重要，当然，对于短期项目，这个问题相对而言就可以放松一 些。另外，对于大多数小公司而言，由于业务规模的原因，硬件上的总成本很小，利用率比较低，所以，架构上越是支持负载均衡等多服务器的设计，就可以越放心 的采用开发成本最低的新技术，这样可以通过利用硬件成本的可伸缩性降低软件开发成本。而不是相反，花太多的力气在软件性能提升上，浪费硬件的能力。所以， 小公司尽量不要谈性能如何如何高，真正需要重视的是架构上的可伸缩性。这点在架构上的要求相对高一点，但一旦走进了这条路，后面的问题会轻松很多。
游戏项目很有意思，目前技术方面我能体会的也就是上面的三点。希望今后在架构设计方面能够更进一步，也能做一点更细的总结。