开发未动，设计先行。我一直强调设计优先的思想。
沟通，沟通很重要，也很有技巧。大家记得通天塔的故事吗，让整个项目组用一种语言说话，就能发挥巨大作用。
------------------------ * * * -------------------------------
模块划分与细化：
觉得头脑里有很多东西，但比较乱。
Module Base Game Play Logic —— 以游戏逻业务逻辑划分的模块
Module Base Game Code Logic —— 以游戏代码逻辑划分的模块
觉得有很多名词，很多模块在头脑中闪现，但直觉上感觉到这些虽然都是可以独立划分的模块，但是它们是有区别的，有交叉的。发现一个说法“引擎设计 & 功能设计”比“游戏业务逻辑 & 游戏代码逻辑”这个说法更准确。在这个基础上加入“底层引擎”的说法，在客户端游戏里，这更多地指为硬件平台建立的。
我借用过来，来表示一些和具体游戏业务解耦性更强的模块。但我们最终需要的是代码逻辑架构，在这个基础上展现游戏业务。作为游戏架构设计人员，我们更关心的是下面虚线索表示的代码架构，即如何去组织代码，如何划分各个模块，这一切的努力都是为了良好的展现游戏业务逻辑。游戏世界是异常复杂的，游戏制作也一样。但我们需要非常清晰的明白一点，那就是开发人员需要的是一个简单的世界，越简单越好。简单的系统才会健壮，简单的系统才会高效。而我们却面对一个复杂的游戏世界，这样的矛盾应该怎么办呢？一个好的主意，就是抽象，从繁杂的游戏世界中，抽丝剥茧，归纳总结，把一个复杂的东西，整理成一个简单有效的架构。这里我想适当区分一下，架构和引擎的区别。架构这个词更多地表示整个系统的代码组织，逻辑结构。引擎则更多地表示功能性，或者说基础功能（公共功能）这样的东西。
游戏系统开发中的分工合作——服务器端和客户端：
展现一个网络游戏世界是复杂的事情，需要服务器端和客户端的共同配合。Server/Client （或者更准确的说Brower），这两者分别负责不同的方面，简单地说，Client端负责在玩家那里展现一个具体的游戏世界，一个可视的游戏世界，一个局部的游戏世界，一个短暂的游戏世界，一个充满了细节的游戏世界；而Server端则管理着整个游戏世界，持续而不间断，监控着每一个游戏玩家在这里进进出出，并且让这些玩家连成一个整体。两者的思路和做法都有着很大的区别，有各自需要解决的难题，但同时也有公用，通用的地方。而且很重要的一点，从游戏开始，每一个细节，每一个动作，都需要S端和C端密切地配合协作，才能使得游戏良好愉快地运行着。所以我们既需要区别对待，有需要协调管理，使他们能够如图上所示，像一个整体良好而健壮地工作。在开发过程中，Server端开发人员和Client端开发人员需要良好持续地沟通，这样才能保证整个代码架构像一块完整的基石一样支撑复杂的游戏世界。
游戏是一个系统工程，需要各个方面的通力合作，策划，客户端，服务器端，美术，制作人......甚至到每一个方面又能划分更多的层次，大家在游戏层面下是一个整体，但又个性鲜明，如何配合协调，是个值得研究的课题。比如我是一名客户端开发人员，在客户端这里需要解决游戏战斗逻辑和游戏UI（比如这样粗略地分一下），如果我一段时间内做某一个部分，比如做游戏UI，那头脑里的思路都是模板，按钮，登录...如果忽然换到战斗逻辑上，开始什么碰撞，魔法，效果什么的，其实是需要一段时间适应适应的。而如果使用了统一的框架结构，或者有良好的通用引擎，那么做起来就会愉快的多，这个转换的代价就比较小，时间也短。这体现了一种很高的项目管理水平，悠然而神往。我想项目管理是个高智力的活，PM需要有很高的执行力，而执行力不是一句抽象的语言，需要建立在对项目组成员了解的基础上，对项目组成员工作了解的基础上，甚至如上面所说，要了解的很细致，工作的转换，遇到的困难，以及如何帮助他们处理这些困难，更重要的是预先避免让他们陷入某种困境，这可能比帮助他们从困境中解脱出来更重要。
上面谈了很多，但终归是一个意思，项目组的成员要彼此了解，在钻研自己负责的方面的基础上，要了解他人的工作；项目组人之间对彼此的性情，说法方式也要了解，这样就能准确地把握住对方的意思，不至于产生误解。这样在工作中就能彼此照顾，互相站在对方的角度上考虑问题。这样最终就会产生一个整体的合力，整体最重要。我们赞美个性，但不需要破坏整体的个人英雄。这是我学习绘画的时候的学到的一个原则 ：）
游戏资料规范
这里所要讲的资料库，并不是指网游SERVER上的那个玩家数据资料库，那是另一个范畴的东西，而且如果要探讨，几乎都是技术层面的。
游戏其实是由众多的数据资料与逻辑计算所构成，那些表面上看得到的文字、讯息、图像，实际上是在规则基础上附加上去的东西。
有了前面那些底层环境的准备，接下来架设了上层的环境，这时才开始置入了游戏的核心，也就是各式各样的判定规则、显示规则等等的东西。（通常会先从图像显示开始，然後逐步测试、慢慢加入功能）。这样一份文档里应该是包括游戏玩法规则的。（How Play Game Rules：HPGR），例如，胜负判定，游戏公式算法，随机事件，剧情，任务，法术，物品，属性，Boss等一系列的东西。我仍然要强调一点，不是要程序干扰策划的工作，也不是策划要参与枯燥的编程，但两者之间仍然是有相当的交叉点的。例如我举个例子，我在列游戏脚本系统（GameScript System）这一项的时候，考虑到WebGame使用脚本并不容易，而且我也没有什么特别好的主意来实现一个脚本系统，这个代价相当大。但当我和策划交流后，他告诉我比如完成一个任务，打死某某怪，取得某某东西，符合某某条件，那么就认为完成了任务。在我听来，这就是要做一个真值表，或者FSM样的东西，一个跳转逻辑。而我把这样一个FSM提供给用户（这里是策划）一个简单的规划页面，这就形成了一个关于脚本“Script”的共识。
而这些功能大致完善了，接下来就是把扩张的各种资料放入游戏中了，这是所谓的合成阶段。游戏是一个一个的循环所构成，置入这些资料依然要经过反覆的测试。
应该可以想到，既然是这时候才要加入大量资料，那表示游戏开发团队的人力投入甘特图并不是方形的，而是倾向於菱形。
针对上面所说的，我把它归结为一个《游戏资料规范》（《Game Play Data Standard》），英文不好，这得找强叔重新规范一下，而且这个应该有熟悉游戏世界的高手来做。这个虽然不是开发层面上的，但应该说是技术层面上的，和开发息息相关，大家记得通天塔的故事吗，当大家用同一种语言说话的时候，连上帝都害怕，让整个项目组用一种语言说话，是能发挥通天的作用的，何况小小游戏。
逻辑处理
“逻辑处理在游戏引擎里，一般就是放置AI、角色关系处理、事件关系处理以及网络处理相关的运算。这一个层的东西，会因为游戏本身的适性需求而有重大改变，所以也被称为〝游戏有关层〞（意思就是说其他的是游戏无关层了），在概念上是放置在游戏引擎的最顶端，因为它会直接和游戏的上层沟通，然后根据相关处理，调用更底层的功能来达到目的。”但考虑来，考虑去，虽然觉得上面的说法很有道理，但我认为用逻辑处理这个概念过于大了，很难具体地提取出来一个模块来做，它是无处不在的。所以在各个模块中分散地处理，或许更合适一些。
客户端游戏架构：
思考的过程是复杂的，渐进的，但思考的结果应该是升华的，是简单的。
对于复杂的游戏世界，最后都归结为处理游戏实体，一切都是实体，玩家是实体，NPC是实体，场景是实体，地图是实体，这些可见的是实体，不可见的脚本是实体，游戏的根也是实体….通过这样的处理，我们在一个统一的模板下去研究各种各样的实体，比如说，游戏的整体循环驱动就是由一个叫Game的实体驱动起来的，通过这样的方式以求得复杂的游戏与简单的结构的统一。
备注：这是我在客户端上面的思考结果，如上面所说，客户端和服务器端各有特点，我相信这个架构对于其他系统开发应该是可以有所借鉴，但如何借鉴，还需要深入探讨，特别是要落实到实际代码上，经过这样的实践才是有价值的。