加入游戏业5年来接触到不少开发模式，其中两种比较典型：
A：程序负责实现，策划负责设计。
B：程序负责底层代码支持，策划负责功能和逻辑的设计和实现。
简单的区分就是：第一种情况，策划是不接触代码的，所有代码都由程序完成；第二种情况，程序则不关心游戏具体的内容，只负责引擎和工具支持，游戏的逻辑和规则部分代码是由策划在程序提供的支持基础上完成的。
由于各自的工作分工不太一样，因此工作方式也有很大不同，其中也有一些不同的陷阱。
A类，主要问题是经常会出现策划设计完成后程序说不能实现，或者程序理解策划案错误，做出来的效果令策划不满意。
这种团队非常依赖程序与策划间的沟通，如果沟通不好就会出现种种问题。对策划案的质量要求也比较高。要求程序员要懂一点游戏，策划要懂一点程序。
B类，由于游戏逻辑和规则是策划自行实现的，因此很少会出现程序声称策划设计无法实现的情况。
这种模式对策划和程序间的沟通需求较少，对文档要求较低。这种模式中程序员可以专心技术，甚至一点游戏都不懂似乎都问题不大。而对策划的程序能力要求较高，要能自己编程实现（虽然是在程序提供的工具基础上进行）。
实际上，还存在很多AB之间的模式，也就是策划要负责一部分实现，但是可能仅仅是一部分逻辑或者一部分数据。
A类的优缺点：
优点：
1：首先，专业分工明确，各部门职责明确，管理上相对更顺畅。
2：相对于B，通常过程文档更丰富，便于后期维护。
缺点：
1：由于职责分明，各部门对于其他部门的知识相对了解较少，可能出现以知识优势忽悠的情况，早年这种情况较多，目前应该说已经很少见了。
2：分工明确，也导致部门间沟通需求更多，增大了沟通成本，而当团队过于依赖口头沟通时反而可能导致过程文档质量下降。
3：由于程序策划分工明确，互相对对方专业了解不足，因此对测试员的知识面要求比较高。
下面再分析B模式的优缺点。
优点：
1：首先，这种模式对沟通要求低，因此往往能够节约开发时间。但是需要警惕，不要把必要的沟通也省略掉。
2：程序员可以专心与程序底层，而不需要关注游戏逻辑和表现，因此相对来说游戏底层的稳定性可能会更高（只是有这个可能性）。
3：开发模式决定了这类游戏系统的扩展性往往较高，因为底层和游戏逻辑之间的分隔比较清晰。因此，做换皮类项目更快，更稳定。往往可以在更短的时间内，作出一个换皮项目，实现流水线式的游戏开发。
缺点：
1：由于是策划自行设计自行实现，因此可能导致文档质量较差，后期可维护性较差，人员流动对项目的影响较大。（只是这种可能性较大而已）
2：策划依赖程序工作，团队的工作效率严重依赖程序能力，当程序能力不足或者出现比较严重的问题时，会导致整个团队效率的下降。表面上看程序不参与游戏具体内容的制作，但是实际上在这种团队，程序一定是核心部门。
3：虽然此类团队的第二个项目（或者换皮项目）会做得很快，但是这是建立在第一个项目的基础上的，由于前面的问题，此类模式开发第一个游戏时效率并没有优势，甚至可能存在劣势。
4：游戏规则和逻辑是策划实现的，而策划毕竟不是专业的程序员，因此这部分的代码质量往往相对较差，bug会比较多。于是在这种团队中，测试组的重要性相对更突出一些。
博文
