无风的港湾

营销人员可能明白强势品牌的重要性，但却对游戏机制一无所知；程序员可能深谙强大游戏机制的意义所在，但对游戏机制的传达方式一窍不通。这样的营销人员和程序员都无法各自打造出成功的游戏。因为一款成功的游戏离不开跨领域的协调性，然而，我们经常见到情况就如上所述，游戏制作团队的成员往往只熟悉游戏设计中面向己方的专业知识，对其他学科的知识所知甚少。

此时游戏设计师的职责显得尤为关键把不同专业的观点融合为全面的设计构想。如果设计师做不到，结果就是，团队里的成员各忙各的，把时间和精力浪费在毫不相干的工作上。

游戏设计包含了几个层次的工作，且各个层次彼此不同，就如游戏的市场营销和用户界面，把这些毫不相干的层次组合起来，这看似一项艰难的任务。完成这项任务需要明白游戏设计交叉性的理论框架、形象化游戏设计方案的下滴（上滴）效应。

手机平台的两个支点

手机游戏带给玩家的融入感可能不如掌机游戏或电脑游戏那么强烈，但如果要深入研究游戏设计结构，简易的手机游戏却是个理想的探索起点。手机游戏开发之所以独特基于两点：能简则简，以量取胜。

能简则简。你可能已经听说过这么句话：一旦所有可删除的对象都被删除了，一个游戏就趋于完美了。手机平台检验了这个论断。即使是在今天这个iPhone的黎明时代，手机游戏开发者仍然不得不应对手机游戏需局限于128K空间的难题，而这128K包括了美工、代码、游戏数据、声音和其他所有游戏要素。

这种容量限制几乎足以令任何一种游戏设置寸步难行，但游戏还是顽强地活下来了，虽然硕果仅存的是些再简单不过的游戏。这些残存下来的游戏拥有高度精炼和清晰可辩的设计构架。

以量取胜。在时间相对紧凑的开发周期中，手机游戏设计师要同时开工好几个游戏，这几乎囊括所有你能想得到的游戏类型。

同时设计三四款不同的游戏，你有两个选择：要么是通过一个共同的工作期掌握所有游戏的设计进程，要么顶着令人抓狂的压力分别跟进所有游戏设计进度。以下是一些手机游戏设计的经验总结。 (更多…)

标签Tags：代码, 对象, 工具, 技巧, 数据, 游戏, 游戏开发, 盈利, 程序, 类, 系统, 营销, 表, 解决, 设计, 鼠标

我始终认为，在 MMORPG 里采用多边形碰撞检测是件很傻的事情。当然傻不是坏事，基于多边形碰撞检测，一帧检查一次的这种做法，实现起来非常简单。很符合 kiss 原则。我们只需要一点点数学知识和一点点编程技能就能做出来了。反正 client 上，也就检查一个主角。加上可以使用简化的碰撞模型，进一步的减少运算量。

但是放在服务器上，这个运算量可不小。所以这几天我寻思着找个更好的方法出来。
(更多…)

标签Tags：ie, 代码, 判断, 数据, 方法, 游戏, 游戏开发, 编程

周末一直在考虑怎样在游戏服务器中保存和管理那些有平面坐标的对象。希望能方便的查到每个对象附近的东西。以往用过的方法是给（平面）场景打上格子，然后再把每个对象放入相应的格子中。

这次又遇到这个问题，却不想用网格的方法来解决问题了。

原因主要是这么几点：一，用网格对于大场景特别消耗内存，而且不太适合做无限延展的场景。二，查询每个对象周围的东西时，不太方便。格子的粒度越小，速度越慢。

虽然这两个问题，都可以通过改进算法来回避。不过这次，我想尝试一下用四叉树解决这个问题。

用四叉树的话，内存占用量应该 O(n) 。如果定死了四叉树的扩展深度，可以推算出节点的最大可能消耗量。我想，如果只是为了解决 AOI 的计算，5 级深度已经足够。这样，大约预分配出 20 * n 个节点，几乎肯定够用了。

我希望场景是从坐标原点向四周无限延展开，没有什么具体的尺寸限制。所以，这次实现的时候对四叉树做了改造。第一级的划分是一个特例，它将平面分成四块，每一块都可以向某个方向无限延伸。
(更多…)

标签Tags：对象, 数据, 方法, 游戏, 游戏开发, 程序, 类, 节点, 表, 解决

今天开始正式开始做数据服务器。在这点上，我希望一组服务器上所有的逻辑服务遇到的数据存取需求都通过一个单一的数据服务器完成。而且，写入数据是单向通讯的。即，逻辑服务器只提读写盘请求，而无须确认。写数据好说，读数据稍微难处理一点，我现在的方案是，数据服务器加载数据的部分只对位置服务器负责，把数据提交到位置服务器即可。位置服务器可以通过分析数据知道玩家的数据流应该流向哪台逻辑服务器。

以上逻辑是基于每个玩家有独立的数据的，而且一个玩家同时只存在于唯一一个场景。也就是说，当一组数据存活的时候，只唯一属于一台逻辑服务器。这样做的好处是，切换场景非常的简单，只是让玩家从一个场景退出，给数据服务器发出写盘指令，并发送所有数据。数据服务器写盘的同时也 cache 了这些数据，并向位置服务器提交新的位置，并把这些数据转发向位置服务器。位置服务器可以再转交给新的场景。

对于玩家登陆和登出的处理并没有特别之处，我们可以设立两个虚拟场景，一个负责登入，一个负责登出。每个新连接自动导入登入场景，这个场景负责发出加载指令（下面可以看到，甚至无须设置加载数据的协议）。然后再做一个自动的场景切换操作即可。而玩家登出，则是转入登出场景，这是一个黑洞，玩家的连接可以在这里安全的断掉。

当玩家不停的穿梭于各个场景之间时，为了避免频繁的数据转发，我们可以给玩家数据做一个赃标记。如果没有弄赃，实际的数据可以不被转发。这个标记的另一个意义在于，若数据没有弄赃，而数据服务器的 cache 中又没有数据时，就需要从外存加载了。其实这就是一个读请求。 (更多…)

标签Tags：cache, ie, 人, 对象, 数据, 方法, 游戏开发, 类, 表, 解决, 设计, 连接

目前，我们的游戏服务器组是按多进程的方式设计的。强调多进程，是想提另外一点，我们每个进程上是单线程的。所以，我们在设计中，系统的复杂点在于进程间如何交换数据；而不需要考虑线程间的数据锁问题。

如果肆意的做进程间通讯，在进程数量不断增加后，会使系统混乱不可控。经过分析后，我决定做如下的限制：

如果一个进程需要和多个服务器做双向通讯，那么这个进程不能处理复杂的逻辑，而只是过滤和转发数据用。即，这样的一个进程 S ，只会把进程 A 发过来的数据转发到 B ；或把进程 B 发过来的数据转发到 A 。或者从一端发过来的数据，经过简单的协议分析后，可以分发到不同的地方。例如，把客户端发过来的数据包中的聊天信息分离处理，交到聊天进程处理。

有逻辑处理的进程上的数据流一定是单向的，它可以从多个数据源读取数据，但是处理后一定反馈到另外的地方，而不需要和数据源做逻辑上的交互。

每个进程尽可能的保持单个输入点，或是单个输出点。

所有费时的操作均发到独立的进程，以队列方式处理。

按功能和场景划分进程，单一服务和单一场景中不再分离出多个进程做负载均衡。 (更多…)

标签Tags：cache, 人, 分离, 数据, 数据库, 游戏, 游戏开发, 程序, 类, 系统, 设计, 连接

MMO 的 engine 中，需要解决的最重要的问题之一，就是如何把游戏世界中的状态改变消息正确的通知给需要知道这条信息的玩家。

通常，我们会设定每个玩家的 AOI ( Area Of Interest )。当一个对象发生改变时，它会把消息广播出去；那些 AOI 覆盖到它的玩家会收到这些广播消息。

但是，在我们现在的游戏系统中，简单的 AOI 系统是不够用的。比如，类似 wow 中的盗贼隐身，明明已经离你很近，但是你的 client 却看不见他。诚然，我们可以在 client 判断这个逻辑，对盗贼不于显示，而 engine 依然广播盗贼移动的消息。对于不作弊的 client ，这是个简单的解决方案。但在理论上却提供了看见隐身人的可能性，所以，我期望有更好的方法让 engine 可以只将消息广播到那些必须接收这些消息的 client 。但是，在实现这个同时，又不能让底层 engine 牵扯太多逻辑信息。 (更多…)

标签Tags：ie, 人, 判断, 对象, 属性, 数据, 方法, 游戏, 游戏开发, 类, 系统, 解决

现在 MMO 中经济系统往往是设计的关键。可能是网络游戏发展的时间较短，并没有形成系统的理论的缘故，我所了解的网络游戏中都没有特别好的处理好经济系统中货币的控制和流通问题。

我们知道，货币只是一种经济活动中一种媒介，货币本身是没有价值的。但是，网络游戏中却很难体现这一点。系统对游戏直接的货币投放是不可控制的，虽然很多设计人员企图控制，但只是收效不同而已。大体上，大家都是用玩家的在线时间换取系统货币总量的增加，而用玩家自身的修炼回收掉货币。还有一小部分是用上税和赌博的形式回收掉。

云风正在设计的游戏很不一样，是基于国家间的贸易和战争而不是个人修炼的。强调一种政府的管理，而非玩家自发组成的团体。我更希望做出一个战略感的游戏，而不是强调团体战术或者个人战斗。 (更多…)

标签Tags：人, 工具, 方法, 游戏, 游戏开发, 系统, 自身, 设计

大多数实时网络游戏，将 server 的时间和 client 的时间校对一致是可以带来许多其他系统设计上的便利的。这里说的对时，并非去调整 client 的 os 中的时钟，而是把 game client 内部的逻辑时间调整跟 server 一致即可。

一个粗略的对时方案可以是这样的，client 发一个数据包给 server，里面记录下发送时刻。server 收到后，立刻给这个数据包添加一个server 当前时刻信息，并发还给 client 。因为大部分情况下，game server 不会立刻处理这个包，所以，可以在处理时再加一个时刻。两者相减，client 可以算得包在 server 内部耽搁时间。

client 收到 server 发还的对时包时，因为他可以取出当初发送时自己附加的时刻信息，并知道当前时刻，也就可以算出这个数据包来回的行程时间。这里，我们假定数据包来回时间想同，那么把 server 通知的时间，加上行程时间的一半，则可以将 client 时间和 server 时间校对一致。

这个过程用 udp 协议做比用 tcp 协议来的好。因为 tcp 协议可能因为丢包重发引起教大误差，而 udp 则是自己控制，这个误差要小的多。只是，现在网络游戏用 tcp 协议实现要比 udp 有优势的多，我们也不必为对时另起一套协议走 udp 。 (更多…)

标签Tags：ie, player, server, 数据, 方法, 游戏, 游戏开发, 系统, 表, 解决, 解决方法, 设计

3d 游戏会用到大量的帖图，许多显卡要求贴图的尺寸必须是2的整数次方。这样，许多贴图的边角都会被浪费掉。尤其是大量无关的小贴图，我们通常想把他们合并在一张贴图上，尽量充满整个区域。

合并这些零碎贴图的算法，在学术上被称为排料问题。我尚未找到特别好的解决方法，所以这里就不展开写了。这里想讨论的是这些小贴图的管理。

我们现在的思路是，在engine 的比较上的层次，不用关心需要用的贴图在哪里，在哪张图片上的哪个区域。这样做，就不用局限于相关的图放在一张物理的图片上，可以由工具任意分割打包组合。固然，不相干的贴图过于零碎的逻辑贴图分散在不同的物理图片上，会降低效率。但这个问题就和内存分配器的实现中，内存碎片的问题一样，是不可避免但却可以有诸多方法来改善的。

其实 DirectX 本就充当了一个显存管理器的工作。我们做的只是在这种基于动态的管理模式上再加一层事前的开发期优化而已。

实现的方法很简单，用一个文本文件描述另一个图片文件的区域即可。engine 只需要把这个文件当作一个逻辑贴图打开解析。至于物理图片文件的管理，交给资源管理模块即可。

而这个文件的生成和管理，就得另写一个工具了。能写出优秀的图片自动组合工具固然好，如果没有也可以退而求其次，做一个可以给人像搭积木一样的拼图工具也可以。可以方便的让人来把零散的图片见缝插针的拼到一起，未尝不是一件趣事

标签Tags：人, 图片, 工具, 方法, 游戏, 游戏开发, 解决, 解决方法

游戏的 client 最文件数量最多，数据量最大的，往往是美术资源。（几乎所有的商业游戏都会在游戏发布时对资源文件打包，我们这里讨论的是开发期未打包的文件）当一个游戏的规模大到一定时，我们需要调动巨量的美术人力来制作这些资源。伴随着游戏规模和制作团队的扩大，设计资源文件的存放目录结构和文件命名规则往往成了项目一开始的头等大事。

2d 游戏这个问题稍微轻一点，3d 游戏更是有模型，贴图，骨骼等等的文件关联性在里面。这次我们的 3d 项目，让我又一次面对和思考这个问题。

如果公司有多个成熟的类似项目，整个美术的制作流程被流水线化了。那么久而久之，自然有一套目录结构和命名规则的规范可以遵守。但是由于项目的多变性，而技术的改良，这个规范也不是一成不变的。

这里说的技术，不能狭义的看成是 3d 渲染技术。关于资源的管理，复用等也是 3d engine 技术的一部分。
(更多…)

标签Tags：google, ie, 人, 搜索, 数据, 方法, 游戏, 游戏开发, 程序, 类, 解决, 设计, 链接