游戏开发，究竟该先定义接口还是该先开始写程序？

tarkey

也许大家都在开发过程中碰到过一些很矛盾的事，比如要写一个模块，一开始就坐在哪想接口，想该实现哪些功能，想了半天想不明白，这个时候就很矛盾了，是继续定义接口？还是开始写代码呢？

学校学过，书上也讲过，在写一个模块之前，一定要想清楚自己需要什么，甚至还需要很详细的文档，写/想清楚了以后再开工。而实际上呢，大家也都发现了，无论你一开始计划得如何的好，到最后的结束这个模块工作的时候，接口或者说是模块结构都被改过N多次了。

这样的话会产生一个什么样的问题呢，久而久之，自己或者别的部门往往会在模块真正开始编码之前就开始慢慢依赖于模块的接口定义，和模块的结构。在真正碰上一些比较大型的模块的时候，模块接口的修改会造成巨大的其他模块的修改量。

实际上，这种开发方式并不适合国内的游戏开发。首先，这种方式对待软件开发的态度有点像生产线一样，有充足的经验，对每一步会带来什么样的后果都十分清楚，技术风险几乎为零。而实际上呢，国内的游戏开发并没有到那个程度，90%的开发制作小组都是头一两次开发游戏，都在做很多实验性质的工作。

那么针对这样的开发情况，我们究竟应该用什么样的态度来对待相互间的合作呢？其实这种情况完全应该用Agile模型来处理。在这种类型的开发中，什么都不重要，最重要的就是人。也许大家也都感觉到，团队中任何一个人的离开都会使整个开发变得很痛苦，不得不改变一些制定好的计划之类的。人就是这类开发过程中最重要的因素，比文档，代码，甚至管理人员更加重要。

所以，对于先定义接口还是先开始写程序这种问题，应该是先和大家讨论，有个大体的方向之后，然后开始写程序，然后每一天下班前开一次会，当然“会”这种形式或许太正规了些，其实主要的意思就是要大家交流一下一天中编码中发现的问题和情况，然后及时的做出结构和程序的修整。当然，在各个时期都还是需要一定程度上的文档的，不一定是需要最终的文档的，但是可以反映整个开发的历史和开发中的矛盾。

对于管理层的人来说，则需要不顾一切的保持在产品出来前团队的稳定，这比一切都重要。我曾经也陷入了这个问题的圈套中，认为所有的文档和代码才是最重要的，总是关注于每个人的文档和代码的质量，而忽视了人这个最重要的元素。一年后的今天，才想明白这个问题。

希望和大家一起讨论，振兴中国游戏业。

tarkey

另外，好象国内的游戏程序员都比较惨，不是说工资待遇，而是说平常除了工作之外，好象没有什么别的娱乐活动了。也许我说得比较片面了，也没做过调查，就身边的程序员和认识的程序员来看，呵呵。

不过在国内做游戏，好的程序员，好的交流环境绝对是一个游戏成功的关键。一个资深的游戏程序员比策划更懂游戏，比策划更懂得该如何制作。这里不是看低策划的作用，而是国内的游戏策划确实很少有能够对系统结构做出建设性的建议的能力。

呼吁改善游戏程序员的待遇。。。。

sea_bug

可能不同阶段不同的考虑，初学者很多都偏向立即代码的阶段，等有经验后，就会往先设计后编写的转变，主要还是靠经验的积累，一开始总是无法设计得完美，通过经验的积累，相信设计会不断提升。

tarkey

呵呵，个人觉得，学游戏和做游戏是两回事，不能放在一起谈的。。。

jianghongbo

先做需求分析, 需求哪里来? 中国人没有专业的书籍可读, 只有认真的观察现在正在运行的系统

fall_tree

晕了，我本人不是计算机专业，学校除了教了一本 C++程序设计 外其它就没讲过了。
再加上不喜欢看书。
本人更没读过什么市场，营销，不懂得需求分析，

可是我又想学写游戏，么办啊？
是不是和玩游戏一样，不看攻略，糊涂地玩上一通，然后连哪个地方几分钟后出现怪物都能猜到了！ 最后要想练什么样的人物，就加么样的点，都了如指掌了～这是不是分析啊？

tarkey

呵呵，别说没书读这种话。
我在楼上说过：做游戏和学游戏制作是两码事，截然不同的方法。

bigfoot

我想，应该是先设计最终的大的框架，在想接口，在设计模块，最后在写代码。否则将永无休止的修改源代码下去。你的投资老板将会给你白眼看的

疯子阿虹

先写程序！

writer15

sea_bug: Re:游戏开发，究竟该先定义接口还是该先开始写程序？

可能不同阶段不同的考虑，初学者很多都偏向立即代码的阶段，等有经验后，就会往先设计后编写的转变，主要还是靠经验的积累，一开始总是无法设计得完美，通过经验的积累，相信设计会不断提升。

我也很同意SEE_BUG的看法，你写不出接口就是因为你的经验不够。而提升经验的方法就是写代码，或者读别人的代码。