点光源的管理
我们 3d engine 的点光源相关的代码，以前设计的是比较糟糕的。最近几天，我决定自己动手重新设计和实现这块东西。性能倒是次要的东西，重要的是要把模块分离，减低耦合度。
这个光源模块设计要解决的问题在于：
GPU 的处理能力，目前看来比较有限，不可能实时处理无限数量的光源。所以，当你的场景里设置了许多的光源时，必须可以拣选出最可能影响被渲染物体的光源信息，把这个信息交给驱动去处理。
December 29, 2009
November 26, 2009
骨骼动画的插值与融合
花了三天时间搞定了困扰了我半年的事情，心情非常之好。
是这样的。我们的 3d engine 中的骨骼动画的插值融合总有点问题。如果是两个变化比较大的动画想从一个过度到另外一个，效果总是不太对。对于图形程序，很难用测试驱动的方式开发的缘故之一，就是因为对与不对有很大程度是人的视觉感受，而不是可以简单校验的数值。想写一个判定正确与否的程序，估计不比把代码写正确简单。
所谓不对呢，问题其实老早也想明白了。现象就是有些动作之间过度像纸片一样，而不是直觉中，人物用合理的方式运动。这时，只显示骨骼动画信息中的关键帧反而效果更好。（这些关键帧，是美术人员在 max 这样的软件中制作出来并导出的：或是用动作捕捉而来的）
其问题在于，没能对骨骼的变换信息做正确的插值。
原来这部分代码写的很脏乱，且原作者已经离开。后继人员要么知其然而不知其所以然的在上面修补，要么就没心思把这个东西真的弄对。（毕竟暂时看起来，这并不是迫切需要解决的问题。它不会引起程序崩溃，也不影响开发进度。）
我倒是一直很想自己来重新设计制作这一块，可一直忙于更多别的事情。加上，大学线形代数也没学好，把其中的数学基础知识补上，还是颇要些精力的。
拖了这么久，终于，这周一咬牙，求人不如求己。还是自己弄吧。
September 18, 2009
AOI 的优化
去年写过几篇过于 AOI 模块的设计。将 AOI 服务独立出来的设计早就确定，并且一定程度上得到了其他项目组的认可。（在公司内部交流中，已经有几个项目打算做此改进）
最近一段时间，我在这方面做进一步的工作。（主要是实现上的）
首先，基于 KISS 的考虑，删除了原有协议中的一些不必要的细节。比如，不再通知 AOI 模块，对象的移动速度。移动速度虽然对优化很有意义，但毕竟是一冗余数据。考虑这些，容易掉入提前优化的陷阱。
其次，增加了一条设置默认关心区域的协议。这是出于实用性考虑。
September 09, 2009
游戏动作感设计初探
最近两年似乎大家一致的想把网络游戏向所谓动作感、打击感的这个方面推进。我想是因为，已经有太多人厌倦了打木桩吧。
我们在三年前就一直在考虑这个问题，但似乎走向了歧路。一个劲的考虑如何解决网络同步问题，怎样在一定网络延迟下保持公平，怎样避免作弊……
结果，尝试了多次后的结论就是，我们依然没有找到正确的方法解决以上问题，暂时把这一块搁置起来。最近，公司又有许多同事热切希望给游戏加入更多的操作感。我们又重拾这个课题。这次，换了个角度看这个问题：假设我们完全不考虑网络这个因素，就算做单机游戏，我们其实也没有太多动作游戏的设计实现经验。那么首先要解决的是如何把游戏的操作手感做出来，之后才应该考虑怎样在网络环境下实现它们。
为此，我纠结了很久。花了很长时间思考，以及编写了大量的代码印证，总算感觉自己的思路稍微清晰了一点。做一下记录，不一定正确，只是写出来或许可以给其他同僚提供一些思路。在内部讨论的过程中，这些也被广泛的质疑，许多人都不太认同。所以，一家之言，辜枉看之。
July 29, 2009
3d engine 中的贴图资源管理
今天有同事问了我一个涉及贴图管理的问题，看起来他们是想改进他们项目现在用的 3d engine （前些年由网易方舟工作室开发的）。我们随便聊了一下，最后的结果是他们取消了一开始的一个需求。
是的，知道自己最终需要什么是特别重要的，不要把过程当成目的。
下面要写的和今天的讨论无关，只是想记录一下：我们的 3d engine 中的贴图资源管理方案。
资源管理是一个很复杂的模块，当然我们应该尽量简化它。在此之前，我曾经记录过我们的资源管理模块的设计变迁。上篇文章到现在也有几个月了，我又做了些设计上的简化，不过变化不大，暂时不提。
而贴图资源作为一种特殊资源，又有所不同。仔细斟酌之后，我把它放在高一层次专门管理。
如前辈所言：确保特殊的情况是真的特殊。在《The Elements of Programming Style》和 《Unix 编程艺术》中都有提及。
那么，第一个问题是：为什么其是特殊的？
May 10, 2009
树结构的管理
要写过多少代码才能得到哪怕一点真谛？
多少年过来，我在潜意识的去追求复杂的东西。比如我自幼好玩游戏，从小到大，一直觉得玩过的游戏过于简单（无论是电子游戏还是桌面游戏），始终追寻更复杂规则的游戏，供我沉浸进去。或许是因为，有了更高的理解和控制复杂度的能力，就可以更为轻松的驾御复杂性。
这很好的解释了 2000 年到 2004 年我对 C++ 的痴迷。还有对设计模式的迷恋。
Eric S. Raymond 说：尽量不要去想一种语言或操作系统最多能做多少事情，而是尽量去想这种语言或操作系统最少能做的事情——不是带着假想行动，而是从零开始。禅称为“初心”（beginner's mind）或者叫“虚心”(empty mind) 。
代码写多了，问题见过了，甚至是同一问题解决多了。模式这种东西自在心底，不必拿出来。时时的从零去想，总能重新明白一些道理。
为什么说语言重要也不重要，算法和数据结构重要也不重要。对要解决的问题的领域的理解很重要（即明白真正要做什么）。理解了，我们才可以用面向对象，用模式去套问题；可理解了，我们又不真的需要这些繁杂的抽象。
闲话放一边，今天想谈谈树结构的管理。
April 06, 2009
为 lua 插件提供一个安全的环境
wow 开放了一套用户自定义的插件系统，很多人都认为，这套系统是 wow 成功的因素之一。反观国内乃至韩国的网游，至今没有一款游戏能提供相当自由度的用户自定义插件系统。
最开始，暴雪是想让用户可以由用户甚至第三方自定义操作界面。后来，这套基于 XML 和 lua 的插件系统不仅仅用来做界面了。
从我在网游行业从业这么多年的经验，游戏界面相关的开发也是颇费人力的。甚至于，Client 开发到了维护期，几乎都是在 UI 上堆砌人工。一套自由的插件系统，对于开发商和用户是双赢的。
但是，插件系统也是双面剑。最典型的负面问题就是安全。越是自由，越是给机器人制作开放了自由之门。这里暂且不提这个方面的问题。首先关注一下另一个：尽可能的保护系统中不想被插件系统访问的数据，避免利用插件编写木马。
March 25, 2009
关于地表贴图
首先，我不是混 3d 圈的人，所以我对圈子里各种地表的渲染方法并不熟悉。今天写这一篇，纯粹是因为前段时间帮负责 3d 模块开发的同事解决了一个算法问题。
从我有限的 3d engine 相关知识来看，我最早了解的是类似 2d tile 拼接的地面渲染方式。玩过星际的地图编辑器的就知道我指的什么。等到魔兽三，虽然 engine 改成 3d 的了，但是方法没有大的变化。就是用贴图做成图素去拼接起来。依稀记得无冬之夜也是这种方法，时间太久，不敢确认。
后来，我看了 big world 的方案，就是在地面高度网格的顶点上记录一个贴图混合系数。最多在一个 chunk （记得似乎是 25 格）里最多可以用四张不同的贴图，然后根据地面网格的顶点混合系数，混出最终的效果。
这个方法比较节省资源，听说很多 3d engine 对地面的渲染都这么干。
不过 big world 默认的地面网格，每个格子单位长为 4 米。结果地面的过度就显得非常粗糙了。这点，天下2 的场景美术私下跟我抱怨过。说是不能做出 wow 里的效果。到了创世西游，应美术的强烈要求，单位格被改成了 2 米，很大程度是为了让地表渲染的更漂亮。当然数据量也增加了 4 倍。
March 10, 2009
关于游戏中资源管理的一些补充
最近在实践中印证了我的一些想法，是关于资源管理的。确认自己的猜想是正确的总是件开心的事情。
先简单回顾一下以前写的几篇东西：
这不是最早的思路，但是是我能找到的最早在 blog 上公开并实际实现的思路。里面提到的部分东西，尤其是多线程设计部分，后来都一一被换掉，理由是过于复杂并实际上没能达到要求。或是细节上很难有 stable 的实现。
经过一些思考，以及经历了许多实践后。对上面的东西，一部分做了肯定，一部分做了否定。肯定的是，资源管理的大策略是对的：那就是和其它部分正交化，尤其是要独立于游戏逻辑之外。生存期不应和游戏逻辑耦合。
到目前最后一次在 blog 上记录思考和资源管理相关的问题。认清的最重要一点就是：
至于多线程预读的问题，资源模块已经可以了解资源数据文件间的关联信息。简单的开一条线程 touch 那些未来可能读到的文件即可。把预读和缓冲的工作交给 OS ，这应该是一个简洁有效的设计。并不需要太多顾虑线程安全的问题。
那么今天想说什么？
February 28, 2009
关于地图编辑器的一些想法
大凡 RPG 游戏（包含 MMORPG），在制作期都需要开发一个地图编辑器。
早年 2d 游戏就有这个需求，基于 Tile 的 Engine 如是，基于整图的 Engine 亦如是。到了 3d 游戏，这个东西更少不了。
对于 3d engine 中附带的地图编辑器，通常有几个用途：拉地形（也有基于模型的地形）、摆放物品（以及特效）、设置玻璃墙（或是设置障碍格）；有时也包括设置摄象机、事件触发点、摆放 NPC 等等。
在很长时间里，我都倾向于制作一个大而全的编辑器 IDE 。但最最近两年，随着编程风格及开发习惯的改变，我对这种做法产生了怀疑。
November 29, 2008
XMPP 简单研究
最近想做一个游戏服务器和 IM 互通的服务。最初的想法是可以增进游戏帐号的安全，比如游戏用户可以通过绑定一个 IM 帐号，从而不用登陆游戏就向游戏服务器发一些指令。这些指定通常是用来冻结一些帐号的功能。而游戏服务器也可以通过 IM 帐号向离线用户发送一些关键消息。这样，只需要解除绑定 IM 帐号需要一定的时间，或使用更安全的途径，即可以让游戏帐号更加安全。（至少，游戏用户可以从 IM 上获知他的游戏帐号每次登陆登出的时间、IP 等等）
后来细想，这里面可以做的东西还有许多。玩家会因为多一个信息通道，而更轻松的去玩那些需要长期驻留的游戏。游戏厂商也可以多一个挽留玩家的渠道，甚至用来宣传新游戏或游戏的增值服务，等等。好处不再列举。
其实、绑定 IM 帐号和绑定手机号本质上区别不大。只不过，IM 帐号几乎是零费用，又不像 SMS ，控制权掌控在移动手里。IM 更适合做双向交流（SMS 的双向交流不那么方便，而且对用户和游戏运营商都有经济负担）。独立提供一个 Game2IM 的服务供众多游戏运营商使用也是个有趣的主意。和 SMS 一样，只要给出一个简单接口让游戏运营商调用，把游戏网络和 IM 网络互联就可以了。
实现这个想法有两个方案。其一是制作各种 IM 的机器人，通过机器人和用户 IM 沟通。这个方案技术门槛稍低，有许多现成的机器人可以使用。缺点是，受 IM 提供商的限制（比如好友数量限制）。无法使用机器人的签名针对性的向用户传递特有的消息。除非你为每个游戏用户定制一个机器人，但那样，每个机器人都需要单独一个连接，对资源消耗过大。
第二个方案就是使用已有的 IM 互通方案，自己提供一个特有的 Game-IM 网络，跟已有的 IM 网络互通。比较流行的 IM 互通协议用基于 SIP 的 SIMPLE 和起源于 Jabber 的 XMPP 。
我最常用的 IM 是 google talk ，本身就实现了标准的 XMPP Client 和 XMPP Server 协议；而我们的 网易 popo 也实现了 XMPP 的 s2s 网关。我想研究一下 XMPP 是个不错的选择。
November 25, 2008
AOI 服务器的实现
以前谈过多次 AOI (Area of Interest) 的实现，因为我们的游戏尚在开发，模块需要一个个的做。前期游戏世界物件不多的时候用个 O(N^2) 的算法就可以了：即定时两两检查物件的相对距离。这个只是权益之计，这几天，我着手开始实现前段时间在 blog 上谈过的 独立的 AOI 服务器。
既然是独立进程，设计协议是最重要的。经过一番考虑，大约需要五条协议，四条是场景服务器到 AOI 服务器的（列在下面），一条由 AOI 服务器发送消息回场景服务器。
创建一个 AOI 对象，同时设置其默认 AOI 半径。注：每个对象都有一个默认的 AOI 半径，凡第一次进入半径范围的其它物体，都会触发 AOI 消息。
删除一个 AOI 对象，同时有可能触发它相对其它 AOI 对象的离开消息。
移动一个 AOI 对象，设置新的 (2D / 3D) 坐标，并给出线速度的建议值。
设置一个 AOI 对象相对另一个的 AOI 半径，覆盖其默认设置。注：AOI 半径可分两种，一为进入半径，二而离开半径。通常一开始，每个 AOI 对象为其它对象均设置一个进入半径；当消息触发后，由场景逻辑重新设置一个离开半径。例如，一个 AOI 对象的默认半径是 10 米，当它被创建并指定坐标后，任何物体进入它的 10 米范围内，都会立刻由 AOI 服务器发送出一个 AOI 消息；而后两者之间不会再自动触发消息。场景服务器收到消息后，可主动向 AOI 服务器设置新的 AOI 离开半径 12 米，当此物体远离到 12 米远后，离开消息触发；下一步再由场景服务器重置进入半径。
这套协议相对简单，可以满足游戏的一般需要，并隐藏 AOI 服务的实现细节。对象全部由 handle 方式传递，由场景服务器自己保证 handle 的唯一性。在我这次的实现中，每个 AOI 对象同时只能拥有一个 AOI 半径触发器，但是协议本身无此限制。
下面，我们再来看一下实现细节。
July 27, 2008
把 AOI 的部分独立出来
应该是在 blog 上第 2 次讨论 AOI 的问题了，另外还要算上一篇写完没有公开的。
昨天刚出差回来，晚上跟前大唐的服务器主程聊了一下。扯到了 AOI 的问题，我提了个分离这个模块的方案，在此记录一下。
AOI 主要有两个作用，一个是在服务器上的角色（玩家或 NPC ）做出动作时，把消息广播到游戏地理上附近的玩家。当进程中负责的玩家不是很多的时候，可以直接对整个进程内的连接广播。这样的处理最简单，随着硬件的提高，可能是未来的主流方法。但是目前，为了减少处理的数据量，尤其是带宽，我们通常需要 AOI 模块裁减一些数据。
第二，当玩家接近 NPC 时，一旦进入 NPC 的警戒区域，AOI 模块将给 NPC 发送消息通知，以适合做一些 AI 的反应。
July 20, 2008
一个简单的寻路算法
周末跟同事聊天，问了一下最近公司新项目的一些需求。发现现在无论是玩家还是策划，纷纷要求引擎可以实现自动寻路。虽然我对此不以为然，但其实这也不是什么难题，打算随便做一个好了。
我们现在的 engine 是用矢量线段描述场景中的障碍的。这些线段无所谓人工标记还是从场景模型中自动生成出来，又或者是用传统的打格子的方法变换出来。在这些障碍线构成的矢量场景中寻路其实不是什么难事。
我们只需要在场景中标记出若干 waypoint ，这些 waypoint 一般在大片无障碍区域的中央，以及分叉路口。游戏中故意设计迷宫为难玩家绕来绕去又没有什么玩点内容在里面是没有什么意义的。（除非是“不可思议的迷宫”这种以迷宫为重要玩法的游戏）所以，大多数游戏场景，路径的拓扑关系复杂度非常有限。 waypoint 靠人工设置就足够了。
btw, 自动生成 waypoint 也不是难事，反正这个东西不会是性能要点，机器生成 waypoint 不会比人工设置的糟糕太多。算法就不展开谈了。waypoint 的设置要点是：场景中所有可达区域都能看到至少一个 waypoint ，这个要求可以用程序检测。
我们把所有 waypoint 间可以直线连接的线路连起来，得到一张图。可以预存下这张图，以后的工作则非常简单。
June 24, 2008
摄象机接口的设计
最近在调整 3d engine 的接口。前段时间把 GC 模块加到底层后，很多部分都需要修改实现了（可以简化许多实现代码）。既然重构代码，不如就再次审查一遍接口的设计，结合最近的一些想法，重新弄一下。
嗯，那么 3d 引擎是什么？跟 3d api （Direct3D 或 openGL）有什么区别？固然，engine 如果只是做 3d api 的一层薄薄的封装，抹平各套 3d api 的差异。那么，就过于底层，显得小了。
如果为特定形式的游戏写死代码，让开发者写一些 MOD 插件就可以形成不同的游戏，那么又显得太高。在这种高层次上，游戏类型会限制于 engine 的实现。比如魔兽争霸 3 就直接用户写 MOD ，并的确有人以此发展出许多玩法。但你永远不可能在 魔兽争霸 3 的基础上写一个 MOD 实现第一人称射击游戏。
所以我指的 3d engine ，是处于 3d 游戏软件结构中间地位的东西。
那么，我们的 3d engine 到底要解决的是什么问题？做 engine 绝对不是以我能在 3d api 的基础上扩展出什么东西为设计向导。因为，对于完成一个软件，是一个从机器实现域映射到问题域的过程。这两个领域的模型是不同的。3d api 完成的是实现域的扩展，engine 则应该完全从实现域到问题域的一个变换，让开发者可以用最接近问题域的语言来表达问题。
May 31, 2008
3d 引擎中对场景数据的接口设计
目前是我第一次设计 3d engine ，虽然主要贡献 3d 方面代码的同事不是第一次做了。我们做了两年多，大方向上是我在把握设计。但是毕竟是没有什么经验，也就老在修改。
这个周末再审以前做的东西，觉得接口上还需要调整一下。比如精灵的控制接口、摄象机的控制接口、场景描述的接口等等。以一个游戏开发人员的角度来看，我需要接口是什么样子的？
我希望是最方便的描述虚拟世界中各样东西的相互关系，引擎当隐藏住不必要的细节，比如 3d 方面的数学知识，专业化的术语，复杂的坐标转换等等。今天写下这些，不是定论，而是做些思考的记录。
我想知道，对于 3d 引擎的使用人员，如何描述虚拟场景，暴露出怎样的接口是比较合适的。
May 23, 2008
关于 openGL 的 4444 贴图
我们在实现游戏界面时，用了一张 RGBA 4444 的贴图做 buffer 。最近同事测试效率时总不满意，发现上载 4444 贴图时，openGL 表现出来的性能实在是太差。（显卡为 ATI X300 ，最新版驱动）
几个人一开始怀疑是显卡或驱动程序的缺陷，进而想换总做法，不用软件渲染界面的方案。改把界面元素全部放到显存里。前几年，我为天下二设计界面的模块时，也有同事有此疑惑，编写代码做过比较。记得当时的结论是：仅仅从性能角度上考虑，把界面所用资源全部放到显存里，并不能提高太多速度（反而可能性能更低）。当时用的 Direct3D 做底层，似乎没有今天遇到的问题。
May 07, 2008
数值调整、模拟器、编辑器
最近做游戏数值有点头大。也研究了一些游戏的设定，有点心得。举个很小的例子来谈谈：
wow 里的护甲对物理伤害吸收是乘一个百分比的，其公式为：
min (护甲/(护甲 + 400 + 85 * 敌人等级) , 0.75)
怎样理解这样一个公式的内在含义？为什么会设置成这样？
May 01, 2008
那些日子（二）
我在北京生活了半年。接触北京这个城市要更早一些。大约 85 年的时候去过，一周时间几乎玩遍了北京所有的景点。小时候的记忆特别美好，我在那个时候爱上了北京。记忆中，天安门广场是那么的大，紫禁城的宫殿如此雄伟…… 以至于回到学校时，不知道用怎样的形容词才能形容。
10 多年后，我在学校的机房上网，泡 bbs ，做个人主页，写一些关于游戏的自己的想法。交了许多的网友。大家都是业余的，年轻气盛，想自己做出好玩的游戏。王欣是第一个给我发 email 的职业游戏人。更早的 97 年，国内有两家大的游戏公司，前导和腾图，有如台湾的大宇和智冠。可惜生不逢时，前导做不了大陆的大宇，腾图也远不及智冠。
腾图命中注定的散掉，王欣的八爪鱼工作室从腾图分的出来。98 年，王欣邀请我在假期去北京玩，他把我带进游戏这个圈子。我又有机会站在天安门广场，原来并没有那么大。我想，如果毛泽东纪念馆挪一下地方的话，广场会更宽广一些，和我儿时记忆中的一样。小时候怎么就没这种感觉呢 :) 。
那个年代，我成月成月的逃课，去北京帮王欣做些兼职工作，并听他说些早年北京游戏圈子有趣的八卦，有如今天我给新人说起往事。回忆起来，自己其实什么也没做，似乎又做过点什么，反正最后一次，我拿了一小笔兼职工资。不过没有花掉，因为回到学校的时候，一个同班同学缺钱交学费，我全部借给了他，毕业那天他才凑起来还我。
当然，身在北京，我就有机会四处拜访网友同好。随即发现，其实许多网友都已经专职在做游戏了。有些人后来再没怎么联系，比如曾经在金洪恩做《自由与荣耀》的 3d engine 的 rick huang ，我还记得他在那个晚上，他抱怨他的后继者让代码从几万行膨胀到十几万；又比如做《独闯天涯》的郭巍，他念叨过来北京前没有钱吃饭，小组里每个人一个冷馒头就可以啃一天，脑子里只想着把游戏做出来 ……
两个很重要的朋友，也是在那段时间见的面 —— 余雪松和吴东黎。我们通过在网易个人空间（当时叫 N-SPACE）交换链接认识的。他们搭档了很多年（直到今天），经历很传奇。
April 30, 2008
那些日子（一）
明天就是五一假期了，同事都已放假。我不打算在假期加班，因为加班也无事可做，手头上的工作都需要与人合作。
前几天和新同事吃夜宵，大家聊的异常兴奋，我也忍不住开始想当年。当年那些美好的日子，记忆已经很模糊了。我想再过个两年，估计我都不能准确回忆起那些曾经对我影响深刻的日子准确的时间。是时候记下点什么，对自己是一种纪念。
我这人有个优点，选择性记忆，那些不快的回忆很容易随风而去。活在我记忆中的人们，对他们只留下感激。我也曾经爱写日记，很早我就写电子日记，记在自己的机器上，PDA 上，当我有一些不愿意再回忆的事情时，我会个将整个文件加上密码，长长的一次性密码，保证自己只能记住一小段日子。当这段日子过去，密码就消失在记忆中。然后再也打不开这些文字，等到下次更换硬盘，无论我多么的想再看一眼当年的自己，也无能为力，只好把加密过的文件删去。
我想我就是这么成长过来，没有什么挫折的感觉被反复咀嚼，都已经抛在脑后。生命中没有什么不可以失去的，这个道理很早就明白了。我曾经懊恼过丢失了大量的源代码、自以为写的不错的文章、早年的聊天记录、珍贵的日记、数年的电子邮件…… 最后我明白了，一切的一切不过是身外之物，我能拥有回忆中最美好的部分，那么已经是特别幸福了。
不过也正是如此，以下的记录也只能是我努力的回忆。或许因为时间久远，跟真实有所偏差，或许从我的角度只看到的事物的一面，但是、我可以保证，并没有故意在叙述中掺差虚假的东西。
是的，我想讲一个真实的故事，一个拥有数千万玩家的游戏诞生的故事。我并不喜欢这个游戏系列本身，但是我为这个产品自豪。我的代码曾运行在几千万用户的机器上，作为一个程序员，还有什么比这更让人满足的呢？也许有，比如让这个用户数量再扩大 10 倍。
April 27, 2008
游戏数值公式的表象与本质
周末、睡的比较晚，起的也比较晚。总的来说比平常睡眠时间长一些，所以到了这周一的第一个小时，我还是全无睡意。随便写点什么，关于游戏的，关于游戏设计方面的东西。
鉴于我在游戏设计领域还没有什么建树，远不如游戏程序设计方面有发言权。甚至对游戏设计说三道四的话，还不如在软件开发上乱侃几句有分量。在下充其量也就是个没吃过猪肉天天能见着猪跑的家伙，如果有猪肉已经吃腻味的方家读到这里，请一笑了之，别跟我一般见识。
本来在本文成文前打的腹稿中想举出些实际的例子来，可是发现怎么都会或多或少的得罪圈子内的策划朋友。罢了，只说些空话好了，算我做了半个月游戏数值，闲暇时发的点牢骚。
从为我们的游戏设定角色基础属性，以及设计战斗伤害的计算公式开始。
April 21, 2008
不那么随机的随机数列
曾经看过这样一种赌徒的策略：假设在一场赌大小的赌博游戏中，赔率是 1:1 ，而庄家不会出千，开大和开小的概率均等（皆为 50%）。赌徒一开始压一块钱，如果他压错了，那么下一次就压两块，再错继续加倍。一旦压对，赌徒永远可以保证有一块钱的进帐。并且从 1 块钱重新开始。
看起来，这种策略能保证永远包赚不赔。但实际上为什么没有人用这个方案发财呢？
放到现实中，试图采用这个策略去赌博的人，几乎都会赔的倾家荡产（当然只要是赌博，差不多都是这个结局）。不要怪运气，不要怪庄家出千，因为这个策略从一开始就注定了失败。
April 10, 2008
游戏的帧率控制
我曾在不同场合，多次向人表达我对游戏程序设计的一个重要观点：时间控制，对于游戏程序设计至关重要。
这是因为，大多数电子游戏，都是一个实时人机互动系统。在非人机互动的软件中，软件及硬件一起是一个封闭系统，时间参数对这个系统是否正确工作是无意义的量。这样的系统，我们尽量应该设计成自动化工作模式，只要有正确的输入，得到正确的输出即可。通常，这样的系统的开发，还应该有自动化测试的流程去驱动它。
但实时人机互动软件则不一样，我们得把人看成系统的一部分。人和机器的交互是通过人眼、人耳、键盘、鼠标等完成信息交换的。如果把人脑看成一个线程、计算机看成另一个线程，我们几乎没有能力实现一个资源锁，利用锁的方式保证系统工作永远正常。人脑在全速运转时，适时得不到正确的信息输入，整个系统就可认为出现了故障。
可见，在这样的系统中，时间控制显得多么的重要。
April 06, 2008
负反馈系统在模型动画控制中的应用
最近在解决 3d engine 接口的一处设计问题。我们知道，在 3d 游戏中，engine 的接口设计往往比性能更加重要，这决定了 engine 是否好用，甚至是否能用。简单的功能堆砌不是 engine 。
目前我想弄清楚的一个技术点就是，当模型置入场景后，如果播放的动画本身有位移，引擎应提供怎样的接口，让使用者最为方便的表达他意图。
具体到一个问题点来说，当我们的美术人员制作了一组四足动画奔跑的动画后，怎么在游戏中最自然的表现出来。
就我有限的眼界所知，有许多人在制作 3d engine 时是这么规定的：美术需要把动画调整成原地奔跑的样子。（或者换个方式，在从制作软件中导出时，让原本具有位移的动画变为原地移动）如此，就可以在最终表现时，自由控制播放的速度。
但是稍加思考，就知道这样做导致的图象表现和我们期待的样子是有偏差的。下面让我们来分析一下。
March 15, 2008
基于 lua 的热更新系统设计要点
很久没写 blog 了，主要是忙。项目排的很紧，一个小项目上线，发现不少问题，所以把多余精力都投进去了。最后人手不够，亲自上场写代码。在不动大体的情况下，最大能力的修改了一些设计，并把能重写的代码重新写过了。
这一周，写了三天半程序（其中通宵了一次）。平均每天写了千多行程序。基本上把原来项目里用的几万行东西替换下来了。重构总是能比老的设计更好，不是么？ :) 不过这事不能老干，个人精力再充沛。故而还是找到称心的合作人比较好，也不能啥都自己做啊。程序员的效率差别可不只十倍二十倍的差别这么少。btw, 前段时间通过这里找到的新同事不错，呵呵。如果有缘，还想再找一个能干的。我相信，聪明人在一起做事可以获得更多快乐。
闲话扯到这里，总结下这两天做项目的一点经验。那就是：当我们需要一个 7*24 小时工作的系统时，实现热更新需要注意的要点。当然，这次我用的 lua 做实现，相信别的动态语言也差不多。只是我对 lua 最为熟悉，可以快速开发。
March 02, 2008
MMO 的排队系统
这两周那是忙的天昏地暗。都是些琐碎的事情，两个项目的。理理代码，发发邮件，打打电话，改改 bug ，开开会，签签字，写写报告。周末也加了一天班，工作居然是安装一个论坛系统，外加修改 css ，以及修改模板，调整版面。没办法，时间紧，人手少。
btw, 在服务器上装 php 时，因为开始 ports 没有更新，出了好多问题。mysql 一开始忘记装 gbk 的支持，困扰我老半天。鄙视一下公司购买的某著名 php 写的论坛系统，居然默认不是用 utf-8 编码的。
闲话扯到这里，今天想谈一下上月底，四年逢一次的好日子里，我们公司憋了好久的《天下2》终于又一次体验测试的事情。
February 19, 2008
角色动作控制接口的设计
最近一段时间工作的侧重点转移，我从服务器的设计转到客户端这边来。
自从最底层引擎的架构完成后，我们的客户端留了两个人在全职写代码，一个人负责 C 层面的 3d engine ，另一个人负责设计高层面的应用接口，并在此基础上完成游戏 demo 。
从程序员角度上看，人都是相当不错的。要设计有设计能力，有编码有编码能力。代码审美观上大家也很一致，所以我们几个人一起工作的很愉快。
唯一美中不足的是，做 demo 的程序员游戏接触的太少，所以在操作手感调整方面有点相形见绌。需要经常性的跟负责战斗动作系统的策划沟通调整。而策划毕竟不太明白程序背后再用怎样的方法实现，最终还是有点不尽人意。如果有足够的时间，倒总是能调整好。不过现在项目进度比原来计划有所提前，我就直接参于进来参合了。加快这方面的开发进度。
上周花了几天时间通读了所有相关的代码，整体设计还是不错的。不过这两天用下来，还是觉得有点别扭。
我希望游戏能有比较流畅的操作感，可以灵活的操作游戏角色做出各种动作，包括战斗时的腾挪，组合技能等。写了不少脏代码尝试我希望的手感时，终于发现一些设计问题了。
February 17, 2008
键盘毕竟不是手柄
周末在写 demo ，为了给同事示范我希望得到的操作手感。作为一个能写点程序的游戏设计者，自己随时实现出来看看恐怕是不可多得的优势了。
我们的游戏有一定的动作成分在里面，所以我不想采用鼠标控制角色的行动，以对拍砖头的形式表现格斗场面。本质上我更偏好 console game 和游戏手柄的操作感。不过在 PC 平台上，手柄并不普及，只能在最普及的输入设备——键盘和鼠标上下点工夫了。
手柄控制方向主要有两种：
其一是模拟杆，在 PSP ，PS ，Wii 等手柄上均有安装。好处是至少可以感知两级力度，并可提供非常细的方向信息输入。控制游戏角色行动时，操作感很不错。
鼠标通过移动可以提供方向信息，甚至通过移动速度可以模拟出力度的差别。但毕竟鼠标缺乏力的反馈，且必须通过移动才能提供信息，本身不能保留状态（鼠标的 button 可以提供状态，所以很多 fps 把前进操作设置在鼠标的按键上），和手柄的感觉还是差了很远。
btw, IBM 的 TrackPoint 如果特别针对去开发，其实是个不错的游戏输入设备，可惜还是太专有化了。
其二，就是类似任天堂的十字键。由于有专利，到别的厂家那里换成了其它形式，不过大体还是差不多的。这类设备可以精确的输入八个方向，在格斗游戏中用的最多。比如我的最爱 VF4 EVO 的 PS2 版，干脆就禁止了模拟杆的输入，只允许用八方向键。
对应到 PC 上，大多数游戏用 WASD 四个按键模拟这个设备。不过要小心的是，由于键盘硬件设计的缘故，大多数键盘处理三个以上按键同时按下时，会发生所谓锁键问题。比如我的 DELL 键盘，同时按下 W 和 D 键后，再按 E 键，系统就接收不到 E 键的消息。这类情况试硬件决定，不同键盘处理能力不同。据说有比较强悍的键盘可以处理任意 7 个按键同时按下的消息，我就没有试过了。
好在现在的键盘处理两个按键的能力还是绰绰有余的，用 WASD 模拟八个方向的输入足够了。
November 30, 2007
讲稿
如果不出意外的话，我现在正在准备在 2007软件开发2.0大会 上的一个演讲：大世界网络游戏服务器的构架 。马上就要上讲台了。
其实主要是介绍下我们这两年正在开发的网络游戏引擎服务器部分的设计。这里有 PPT 可以下载 。
November 25, 2007
随机数有多随机？
作为一个常识，每个程序员在做入门学习时，都会被老师谆谆教导：我们用的编程语言中的随机函数，只能产生出伪随机数。它有它的内在规律，只能作为对显示世界的随机事件的近似模拟。接下来，我们通常会被传授随机种子的概念。以及用物理上更随机的量做种子。比如系统时间、两次敲击键盘的时间间隔、多次移动鼠标的偏移、甚至系统出错的出错信息码等等。
作为游戏数值策划，除了加减乘除，用的最多的数学概念恐怕就是随机数了。有经验的数值策划或许从他的前辈那得知计算机中程序产生的随机数并不太可靠；或者他本身就受过程序方面的训练。如果游戏项目更幸运一点，担当数值策划的他是一个数学爱好者，并读过诸如《计算机程序设计艺术》这样的技术书籍，那么事情会好的多。可惜大多数境遇下，策划们从不深究计算机随机数背后的细节，也不太关心所谓“伪”随机数究竟“伪”到什么程度。
最近几天，有测试人员向我抱怨，我们游戏中某些概率设定总感觉有点怪怪的。似乎跟文档上的不同。
这种抱怨并不少见，许多网络游戏玩家都在抱怨系统生成的随机数不太对劲。善良点的玩家会归咎到自己的 RP 上，阴谋论者则指责系统作弊。运营着的游戏背后，数值策划和程序员们有苦说不出。
有必要科普一些数学常识，也作为我周末读书的一些笔记。
November 15, 2007
思维的惯性
晚上在办公室晃荡，对面的同事在加班写代码。我凑上去看看在写什么。我向他了解了后明白了，大约是服务器上角色 buff 的实现吧。
BUFF 这个术语是现在网络游戏中非常常见的。给角色加一个 BUFF 通常意味着对虚拟角色的一些数值上的临时修正：例如，攻击力 +5 ，防御 -10% ，速度加倍，等等。
玩过魔兽世界的朋友应该很容易理解这些。通常游戏里的 BUFF 设定比我上述的例子更加的复杂。
这里不谈游戏设定，谈谈实现。
October 07, 2007
网络游戏的技术基础
July 19, 2007
模型顶点数据的压缩
缘起：听天下组的同事谈起，游戏的资源数据量太大，导致了加载时间过长，影响到了操作感。最终不得不对数据进行压缩。
当玩家配置的物理内存足够大时，往往资源数据压缩会适得其反。因为多出来的数据解压缩的过程会占用掉太多的 CPU 时间。物理内存够大的话，操作系统会尽量的拿出物理内存做磁盘 IO 的 cache ，即使你的程序不占用太多的逻辑内存，而反复从硬盘加载大块数据，也不会感觉到磁盘速度的影响。当数据量大一个一个临界时，被迫做不断的外存内存的数据交换，这个时候，数据压缩就会体现出优势。因为解压缩的 CPU 时间消耗是远远小于硬盘 IO 所消耗的时间的。
btw, 玩现在的 MMORPG 往往配置更大的物理内存得到的性能提升，比升级 CPU 或显卡要划算的多，就是源于这个道理。通常 MMORPG 都需要配置海量的资源数据，来应付玩家的个性化需求。
天下组的同事暂时只做了骨骼动作信息的压缩。这个这里暂且不谈，我想写写关于模型顶点数据的压缩。记录下这两天在思考的一个有损压缩算法。
July 13, 2007
游戏中的货币
曾经写过一篇关于网络游戏中的货币经济系统的文章，由于我本人对经济学只是浅尝，读书不多，所知甚为有限，怕是贻笑大方了。但这不影响我对此继续抱有极大的兴趣。最近，又再思索那个困扰游戏设计者的问题：究竟如何用游戏规则来稳定虚拟货币。
首先，我认为现在的网络游戏中，货币并不完全等同于现实社会中的货币。现实社会中，货币只是一种能直接起交换手段或支付媒介作用的东西，它本身没有价值；货币的投放由央行控制。但在大多数网游中，货币本身有了实用价值，它可以从系统那买到各种补给品，或是可以直接增加虚拟角色的能力。而且货币本身也多由玩家自己的主动行为生产。
同时，在健康的虚拟经济环境中，虚拟货币也起到了现实货币同样的作用——作为支付媒介。
虚拟货币的多重职能，使得在架构虚拟社会的规则时，需要万般小心。而虚拟货币也往往因其多重职能，使得游戏中的市场调节能力减弱。现存的几乎所有网游中都没有设计出一个央行的角色，还真怪不得通货膨胀得不到有效的控制了。
那么，能否构建出一个更接近现实社会的经济模型呢？对于设计一个较之现存游戏更有趣好玩的经济系统，即使这不是唯一之道，但至少是一条值得尝试的路。今天在这里记录一些尚未深思熟虑的想法，权作自己的笔记。方家读过，请一笑了之。
July 06, 2007
唯一的游戏世界
今天写下上一篇 blog 之后，跟另一个组的同事讨论了我的这篇文章。他们的项目先是多服务器的架构，后来重构后改成了单服务器的设计。我们的讨论第一个出现的分歧就是在于对多服务器设计的复杂度会造成的影响。
讨论了一段时间后发现大家的对一些问题的定义从一开始就有区别。回头来大家换个角度讨论了一下，发现其实那些分歧都是不存在的。
讨论告一段落后，我浏览了一遍聊天记录，觉得有必要总结一下 :)
三年前，我跟公司一些策划同事有接连几天的争执：到底玩家是否需要一个宏大的虚拟世界？或是我们若实现这样一个虚拟世界，到底有没有价值？该怎样维护这样的一个大世界，让它不会受到一些暂时性设计 bug 的毁坏性影响？
可以说，三年前的争论是导致我成立独立团队做现在这样一个项目的重要起因之一。因为当时，我几乎得不到任何的支持，策划，程序，美术方面等等几乎都是不赞成的意见。
那个时候，我也的确找不到确凿的证据来说服大家。但今天，思路清晰了许多。
July 05, 2007
游戏服务器组间的通讯
网络游戏世界的构建有越来越大的趋势，游戏设计者希望更多的人可以发生互动。技术人员的工作就是满足这些越来越 BT 的需求。
我们目前这个项目由于是自己主导设计，而我本人又是技术方案的设计者。所以，技术解决不了的问题就不能乱发牢骚了。作为游戏设计者，我希望整个游戏世界的参于者可以在一个唯一的大世界中生存，他们永远有发生互动的可能。注意这里只是保留这种可能性，实际上，即使是现实社会，每个人的社交圈子都不大。即使是千军万马的战场上，无论是将军还是士兵，都不需要直接跟太多人互动。
我们的游戏的技术解决方案仍旧是将游戏大世界分成若干独立服务器组，人为的将人群切分成更小的独立单位。这里，技术上需要解决的是：服务器组间可以灵活的交换数据。
June 21, 2007
平台无关的游戏引擎
一直以来，我们的新引擎一直以跨平台为设计目标。这倒不是说，我们有多重视非 Windows 平台的用户。只是我觉得，一个好的设计一定是很容易做到平台无关的。对于做跨平台开发这件事情，公司里支持的人寥寥。光老丁都几次三番劝我不要把精力花在无谓的地方。
唉，怎么说呢。写了这么多年程序，我一直把编写代码和设计软件作为一件很有趣的事情在做。所以我并不认为我做的一切是一种工作，它是我的玩具。早就不需要担心后半辈子的生活问题，所以没有人可以阻止我做想做的事情，更何况我认为良好的设计造就优秀的产品。今天看似多花的精力，日后慢慢的会给出回报。
回想当年做西游的客户端，我固执的把内存的占用量控制在 64M 左右，让低配置的机器也可以流畅的运行。为了达到这一点，当年多花了好多的精力。做内存中的精灵压缩，做地图的动态加载，做图象数据的 cache 和主动交换，改动许多我认为会更多占用内存的数据结构，阻止美术的一切可能过于消耗内存的设计。
这些在我离开西游的开发后的这么多年里，配合硬件的发展，往日做的那些，得以让后来的不断扩展玩法和美术资源可以稳定的进行。后期的开发维护人员可以用足够的东西来“浪费”。前期的种种约束和正是为了后期的无拘束扩展，直到这些项目顺利的走完生命期。
我希望几年之后，依旧有人感谢我当下做过的努力。
June 08, 2007
2007 年玩家主流显卡配置
本文版权归所有、谢绝任何形式的（部分或全部内容）转载
花了两天和同事一起做了一次数据挖掘工作。
前几天拿到了大量的显卡标识串统计数据（百万条级别），开始做数据分析。因为数据不太规则，所以颇花了些工夫。我想数据的来源和分析结果未得到公司允许前，都不能公开。不过我想在这里透露一些大略信息，对从事游戏开发的朋友（尤其是商业 3d 游戏）会有不小的帮助。
目前，NVidia 、ATI 、Intel 三家几乎垄断了玩家的显卡市场，市场份额超过了 95% 。如果你硬要考虑一些小厂商的话，不妨关注一下 VIA（包括其收购的 S3）和 SiS 。算上这两家已经涵盖了 99% 以上的玩家机器了。
一些若干年前风光过的显卡，如 Voodoo Trident 等现在依然有人用，但如今已经非常稀少。当然，还有人用一些更为稀少的专业显卡，或是我没听过的品牌的垃圾卡（疑是电子垃圾）在玩游戏 :D
May 24, 2007
DXT 图片压缩
这两天在写 DDS 格式的解码程序。DDS 是微软为 DirectX 开发的一种图片格式，MSDN 上可以查到其文件格式说明：DDS File Reference 。
其中的 DXT 图片压缩格式，现在已经为绝大多数 3D 显卡硬件所支持。（它使用了由 S3 公司所发明的一种有损图象压缩算法。btw, 在我的那本书中，P232 有所提及）。DXT 格式 也叫作 S3TC ，现在可以被流行看图软件直接显示的图象格式中，只有 .dds 文件支持这种压缩。为了开发方便，我们的引擎也就支持了 .dds 文件的加载。
一起做引擎的同事希望即使在硬件不支持的时候，我们也能正常加载并使用贴图，所以便有了对 DXT 软解码的需求。
好在以前研究过一些，写起来也不麻烦。
May 11, 2007
资源的内存管理及多线程预读
网络游戏的 client 开发中，很重要的一块就是资源管理。游戏引擎的好坏在此高下立现。这方面我做过许多研究和一些尝试。近年写的 blog 中，已有两篇关于这个话题的：基于垃圾回收的资源管理、动态加载资源 。
最近在重构引擎，再次考虑这一个模块的设计时，又有了一些不算新的想法。今天写了一天程序，一半时间在考虑接口的设计，头文件改了又改。最终决定把想到的东西在这里写出来，算是对自己思考过程的一个梳理。
March 30, 2007
游戏服务器内的组播
游戏服务器在设计时，会有许多组播的需求。比如一个 NPC 需要向周围的观察者播出它的状态信息。无出不在的各种聊天频道中需要向频道中的参于者广播聊天消息等。
通常，我们会为每个组播的请求维护一张列表，然后再把需要的信息包发送给指定列表上的多个连接。这个过程在很多地方都会遇到，一个设计的不太好的引擎，再这里有可能滋生诸多 bug 。尤其在多服务器的设计时尤其如此。
这两天，我试图寻找一种简洁统一的解决方案。
March 29, 2007
游戏服务器处理多个连接入口的方案
最近在考虑为一组游戏服务器配置多个连接入口。这个需求来至于我们的国情。作为大的游戏运营商，势必要考虑国内的网络状况——南北不通的现状。以往别的公司的代理游戏，由于不是自己开发，都选择了一个实际的方案：在北网通和南电信各放若干组服务器。北边来的在北边玩，南方住的安居在南方。
我们的游戏却不行，因为我需要一个完整的大世界，必须解决南北互通的问题。据我所知国内运营的游戏 EVE 是比较好解决了这个问题的。
我们自己的游戏大多也解决了，只是宣传上还是鼓励玩家登陆相应的服务器。我们的解决方案本质上很简单。建立有多个出口的机房，同时拥有电信和网通的线路。或是用自己的线路互联电信和网通的机器。这后者普通用户自己在家也可以做，只要你肯花钱，同时购买电信的 ADSL 于网通的宽带即可。目前许多城市两者都向大众提供服务。
当然，最终我们还是需要编写服务器的程序员做一些配合。
March 20, 2007
为何麻将如此流行？
曾经有种流行的说法是，中国人喜欢打麻将，日本人喜爱围棋，而美国人多打桥牌。这类文章 google 一搜一大把。
当然中国人或是韩国人也喜欢下围棋，而日本人也没以前那么爱围棋了。八十年代的时候，似乎在国内校园里也非常流行打桥牌。而桥牌在美国现在还是不是那么那么流行，就不得而知了。所谓国民的特性从所喜爱的游戏中可看出总总之观点，我一直是不置可否的。今天写的跟这些无关。
由于家庭渊源，我个人不喜欢打麻将。但对麻将也没有感情上的厌恶。小时候即没见父母打过，也不曾见过传送中的因为麻将而导致的家破人亡、妻离子散。只觉得麻将无非一种有竞技性质的桌上游戏而已。
我对麻将所知非常有限，规则陆陆续续的了解了许多。大约知道各地的细则不太一样，大体却是相差不大。似乎体育总局定过一个国标麻将 ，我们的 popo 游戏 就是按这个做的，据我所知，喜欢玩这个规则的不多。大家还是按地域各打各的一套。这也是边锋游戏成功的秘诀之一。
那么，在我看来的一个普通游戏，甚至没有统一明确的规则，为何风靡整个华人世界呢？
February 12, 2007
我们需要 photoshop 之外的选择
游戏的美术工作有时是挺枯燥乏味的。我在公司这几年看到太多美术，连续几天的辛勤工作，只为了将一批图按同样的模式修改成另一个样子。甚至这个工作只是修修通道、转转图片格式等等。
由于有些工作流程比较繁琐，甚至可能会有些变化，并不是每次操作的人都愿意使用 photoshop 中带的批量处理模式来提高效率。最终造成了一种奇怪的现象：明明人手充足，每个人每天都在重负荷的工作，但是整体的完成度却提不上去。在许多时间里，大家干的并不是创造性的工作，而是一些并不需要多少脑力的活儿。
今天碰到件事，我们需要给一些人物角色图片勾一下边。也就是把动画图素展开成带 alpha 通道的图片序列。然后把通道部分提取出来，轮廓扩大、羽化、上色，再叠加回原来的图。这样做的目的是可以把游戏里的角色从背景中突显出来。
February 01, 2007
多服务器的用户身份认证方案
当游戏服务器群达到一定规模后，让用户只从一个入口连入会给这个入口带来很大的压力。这样，我们就需要让服务器群中的多台机器都允许用户直接连接。
当服务器开放给用户直接登陆后，必须面临的一个问题就是用户身份认证的问题。
大多数提供网络服务的公司都做了一套统一的用户认证系统，比如微软的 passport ，网易的通行证，等等。为了避免重复验证用户身份而给用户认证系统带来过大的负担，云风在这里给出一个参考解决方案。
January 15, 2007
3D engine ，中间层的缺失
我们的游戏引擎已经开发了一年半了，其中 3d 引擎部分也做了近一年。
一个好的引擎，渲染部分总是容易做的。因为面对的问题比较单一，资料也很丰富。需要克服的问题很有针对性，即使短期解决不了的问题，放在那里也关系不大。我们团队有两个同事拥有完整 3d engine 开发经验，所以在渲染引擎接口设计部分也不会走太大弯路。（不过事实上，因为基础构件的重写，渲染引擎也是几经修改的）
最近 3d engine 部分又面临一次大的重构。起因是这样的：
December 29, 2006
碰撞检测
我始终认为，在 MMORPG 里采用多边形碰撞检测是件很傻的事情。当然傻不是坏事，基于多边形碰撞检测，一帧检查一次的这种做法，实现起来非常简单。很符合 kiss 原则。我们只需要一点点数学知识和一点点编程技能就能做出来了。反正 client 上，也就检查一个主角。加上可以使用简化的碰撞模型，进一步的减少运算量。
但是放在服务器上，这个运算量可不小。所以这几天我寻思着找个更好的方法出来。
December 06, 2006
在 Windows 下使用 Timer 驱动游戏
在 Windows 平台下写游戏，相比 console 等其它平台，最麻烦之事莫过于让游戏窗口于其它窗口良好的相处。
即使是全屏模式，其实也还是一个窗口。如果你不去跑窗口的消息循环，一个劲的刷新屏幕，我估计要被所有 Windows 用户骂死。
那么怎样让你的游戏程序做一个 Windows 下的良好公民呢？
October 29, 2006
用四叉树管理散布在平面上的对象
周末一直在考虑怎样在游戏服务器中保存和管理那些有平面坐标的对象。希望能方便的查到每个对象附近的东西。以往用过的方法是给（平面）场景打上格子，然后再把每个对象放入相应的格子中。
这次又遇到这个问题，却不想用网格的方法来解决问题了。
原因主要是这么几点：一，用网格对于大场景特别消耗内存，而且不太适合做无限延展的场景。二，查询每个对象周围的东西时，不太方便。格子的粒度越小，速度越慢。
虽然这两个问题，都可以通过改进算法来回避。不过这次，我想尝试一下用四叉树解决这个问题。
October 19, 2006
数据服务器的设计
今天开始正式开始做数据服务器。在这点上，我希望一组服务器上所有的逻辑服务遇到的数据存取需求都通过一个单一的数据服务器完成。而且，写入数据是单向通讯的。即，逻辑服务器只提读写盘请求，而无须确认。写数据好说，读数据稍微难处理一点，我现在的方案是，数据服务器加载数据的部分只对位置服务器负责，把数据提交到位置服务器即可。位置服务器可以通过分析数据知道玩家的数据流应该流向哪台逻辑服务器。
以上逻辑是基于每个玩家有独立的数据的，而且一个玩家同时只存在于唯一一个场景。也就是说，当一组数据存活的时候，只唯一属于一台逻辑服务器。这样做的好处是，切换场景非常的简单，只是让玩家从一个场景退出，给数据服务器发出写盘指令，并发送所有数据。数据服务器写盘的同时也 cache 了这些数据，并向位置服务器提交新的位置，并把这些数据转发向位置服务器。位置服务器可以再转交给新的场景。
对于玩家登陆和登出的处理并没有特别之处，我们可以设立两个虚拟场景，一个负责登入，一个负责登出。每个新连接自动导入登入场景，这个场景负责发出加载指令（下面可以看到，甚至无须设置加载数据的协议）。然后再做一个自动的场景切换操作即可。而玩家登出，则是转入登出场景，这是一个黑洞，玩家的连接可以在这里安全的断掉。
当玩家不停的穿梭于各个场景之间时，为了避免频繁的数据转发，我们可以给玩家数据做一个赃标记。如果没有弄赃，实际的数据可以不被转发。这个标记的另一个意义在于，若数据没有弄赃，而数据服务器的 cache 中又没有数据时，就需要从外存加载了。其实这就是一个读请求。
月初我在公司内部讲解这个设计时，遭到了一些同事的疑问。最典型的一个是，帮派信息如何处理。的确，类似帮派的信息，不属于任何一个玩家。如果你单独设一个非玩家对象保存这些数据时，可能会分布到不同的逻辑服务器上。的确对数据服务器的设计是一个挑战。
今天仔细考虑过以后，我发现可以从设计上避免这个问题。方法如下：
October 18, 2006
多进程的游戏服务器设计
目前，我们的游戏服务器组是按多进程的方式设计的。强调多进程，是想提另外一点，我们每个进程上是单线程的。所以，我们在设计中，系统的复杂点在于进程间如何交换数据；而不需要考虑线程间的数据锁问题。
如果肆意的做进程间通讯，在进程数量不断增加后，会使系统混乱不可控。经过分析后，我决定做如下的限制：
如果一个进程需要和多个服务器做双向通讯，那么这个进程不能处理复杂的逻辑，而只是过滤和转发数据用。即，这样的一个进程 S ，只会把进程 A 发过来的数据转发到 B ；或把进程 B 发过来的数据转发到 A 。或者从一端发过来的数据，经过简单的协议分析后，可以分发到不同的地方。例如，把客户端发过来的数据包中的聊天信息分离处理，交到聊天进程处理。
有逻辑处理的进程上的数据流一定是单向的，它可以从多个数据源读取数据，但是处理后一定反馈到另外的地方，而不需要和数据源做逻辑上的交互。
每个进程尽可能的保持单个输入点，或是单个输出点。
所有费时的操作均发到独立的进程，以队列方式处理。
按功能和场景划分进程，单一服务和单一场景中不再分离出多个进程做负载均衡。
性能问题上，我是这样考虑的：
我们应该充分利用多核的优势，这会是日后的发展方向。让每个进程要么处理大流量小计算量的工作；要么处理小流量大计算量的工作。这样多个进程放在一台物理机器上可以更加充分的利用机器的资源。
单线程多进程的设计，个人认为更能发挥多核的优势。这是因为没有了锁，每个线程都可以以最大吞吐量工作。增加的负担只是进程间的数据复制，在网游这种复杂逻辑的系统中，一般不会比逻辑计算更早成为瓶颈。如果担心，单线程没有利用多核计算的优势，不妨考虑以下的例子：
计算 a/b+c/d+e/f ，如果我们在一个进程中开三条线程利用三个核同时计算 a/b c/d e/f 固然不错，但它增加了程序设计的复杂度。而换个思路，做成三个进程，第一个只算 a/b 把结果交给第二个进程去算 c/d 于之的和，再交个第三个进程算 e/f 。对于单次运算来算，虽然成本增加了。它需要做额外的进程间通讯复制中间结果。但，如果我们有大量连续的这样的计算要做，整体的吞吐量却增加了。因为在算某次的 a/b 的时候，前一次的 c/d 可能在另一个核中并行计算着。
具体的设计中，我们只需要把处理数据包的任务切细，适当增加处理流水线的长度，就可以提高整个系统的吞吐量了。由于逻辑操作是单线程的，所以另需要注意的一点是，所有费时的操作都应该转发到独立的进程中异步完成。比如下面会提到的数据存取服务。
对于具体的场景管理是这样做的：
October 02, 2006
服务器消息的广播
MMO 的 engine 中，需要解决的最重要的问题之一，就是如何把游戏世界中的状态改变消息正确的通知给需要知道这条信息的玩家。
通常，我们会设定每个玩家的 AOI ( Area Of Interest )。当一个对象发生改变时，它会把消息广播出去；那些 AOI 覆盖到它的玩家会收到这些广播消息。
但是，在我们现在的游戏系统中，简单的 AOI 系统是不够用的。比如，类似 wow 中的盗贼隐身，明明已经离你很近，但是你的 client 却看不见他。诚然，我们可以在 client 判断这个逻辑，对盗贼不于显示，而 engine 依然广播盗贼移动的消息。对于不作弊的 client ，这是个简单的解决方案。但在理论上却提供了看见隐身人的可能性，所以，我期望有更好的方法让 engine 可以只将消息广播到那些必须接收这些消息的 client 。但是，在实现这个同时，又不能让底层 engine 牵扯太多逻辑信息。
这里提出一个简单的方案：
September 16, 2006
心跳服务器
我们目前游戏服务器的初步架构是一个连接服务器处理来自多个客户端的连接数据，这个服务器将所有数据汇总后通过一个 socket 发送到后方的逻辑服务器。这个设计曾经写过一篇 blog 提到过。
今天，我在两个服务器之间加入了一个控制心跳的服务器。其原始作用很简单，就是按心跳（目前的设定是 10Hz）从连接服务器上拿到数据，再转发给逻辑服务器。并把逻辑服务器发出的数据转出。
September 13, 2006
目前我们的游戏服务器逻辑层设计草案
我们一开始的游戏逻辑层是基于网络包驱动的，也就是将 client 消息定义好结构打包发送出去，然后再 server 解析这些数据包，做相应的处理。
写了一段时间后，觉得这种方案杂乱不利于复杂的项目。跟同事商量以后，改成了非阻塞的 RPC 模式。
首先由处理逻辑的 server 调用 client 的远程方法在 client 创建出只用于显示表现的影子对象；然后 server 对逻辑对象的需要client 做出相应表现的操作，变成调用 client 端影子对象的远程方法来实现。
这使得游戏逻辑编写变的清晰了很多，基本可以无视网络层的存在，和单机游戏的编写一样简单。
June 14, 2006
魔兽世界之过?
看到这样一篇文章，魔兽世界之过 。老实说，作为一个从美服 beta 开始接触 wow ，然后在美服付费玩了大半年，既而转战国服一年的老 wow 玩家来说。我在喜爱 wow 的同时， 也赞同文中的观点。
group > solo 就我自己来说，是反对的。不过之前一直没说出口。我自己打 wow ，一直到 60 级都是 solo 并且觉得非常有趣。而且每个任务都不放过，每个副本都要完成（当然不包括后期必须太多人的）。前期的 5 人副本，都是在不太高的级别，邀请几个非常熟悉的同事以 3~4 人完成的。那种克服困难后的喜悦无以言表。尤其是在 24 级的时候单身一人完成圣骑士的圣锤任务，跑断了腿不说，还在死生之间转了很多次。
整个游戏过程，没有接受任何经济上的资助，最多跟同级的玩家借点点钱。
现在我已经不玩 wow 了，但是我有同事还整天泡在里面。听取了他的观点后，更坚定了我的想法。raid 的确是 wow 的硬伤之一。当然，还有文中提到的荣誉系统等。
June 07, 2006
网络游戏中的货币系统
现在 MMO 中经济系统往往是设计的关键。可能是网络游戏发展的时间较短，并没有形成系统的理论的缘故，我所了解的网络游戏中都没有特别好的处理好经济系统中货币的控制和流通问题。
我们知道，货币只是一种经济活动中一种媒介，货币本身是没有价值的。但是，网络游戏中却很难体现这一点。系统对游戏直接的货币投放是不可控制的，虽然很多设计人员企图控制，但只是收效不同而已。大体上，大家都是用玩家的在线时间换取系统货币总量的增加，而用玩家自身的修炼回收掉货币。还有一小部分是用上税和赌博的形式回收掉。
May 21, 2006
脏矩形演示 demo
上个世纪，我在个人主页上发布了风魂。2000 年的时候，我给它加上了脏矩形的支持。之后，就再也没有发布新的版本。
实际上，我经历了好几个游戏项目后，那么久远的代码已经被抛弃不用，但是由于工作原因，新的代码没能公开。现在回首那些老代码，居然发现如此的丑陋不堪。
不过，一些思路还是可以保留下来使用的，其中之一就是脏矩形技术。
May 19, 2006
不太精准的时钟
目前，我们的游戏的同步是依赖机器时钟做预测的。这种做法的前提是，client 的机器和 server 的机器的时钟走速必须相同。这样，当我们把时刻校对了以后，可以不通过网络就可以知道时间信息。即，每个通过网络包传送过来的事件已经发生了多久。这只需要发送方为事件打上时间戳，然后接收方以自己的时候为准求出时间差即可。
April 26, 2006
广播和监督服务器
前几天写到我们把服务器组分成连接服务器和逻辑服务器的想法，这代码部分已经完成，并且比最初的构想增加了不少东西。比如允许逻辑服务器广播数据包，由连接服务器分发等。
随着工作的深入，这两天想了更多东西。
April 19, 2006
IOCP , kqueue , epoll ... 有多重要？
设计 mmo 服务器，我听过许多老生常谈，说起处理大量连接时， select 是多么低效。我们应该换用 iocp (windows), kqueue(freebsd), 或是 epoll(linux) 。的确，处理大量的连接的读写，select 是够低效的。因为 kernel 每次都要对 select 传入的一组 socket 号做轮询，那次在上海，以陈榕的说法讲，这叫鬼子进村策略。一遍遍的询问“鬼子进村了吗？”，“鬼子进村了吗？”... 大量的 cpu 时间都耗了进去。（更过分的是在 windows 上，还有个万恶的 64 限制。）
使用 kqueue 这些，变成了派一些个人去站岗，鬼子来了就可以拿到通知，效率自然高了许多。不过最近我在反思，真的需要以这些为基础搭建服务器吗？
April 15, 2006
网络游戏的对时以及同步问题
大多数实时网络游戏，将 server 的时间和 client 的时间校对一致是可以带来许多其他系统设计上的便利的。这里说的对时，并非去调整 client 的 os 中的时钟，而是把 game client 内部的逻辑时间调整跟 server 一致即可。
一个粗略的对时方案可以是这样的，client 发一个数据包给 server，里面记录下发送时刻。server 收到后，立刻给这个数据包添加一个server 当前时刻信息，并发还给 client 。因为大部分情况下，game server 不会立刻处理这个包，所以，可以在处理时再加一个时刻。两者相减，client 可以算得包在 server 内部耽搁时间。
client 收到 server 发还的对时包时，因为他可以取出当初发送时自己附加的时刻信息，并知道当前时刻，也就可以算出这个数据包来回的行程时间。这里，我们假定数据包来回时间想同，那么把 server 通知的时间，加上行程时间的一半，则可以将 client 时间和 server 时间校对一致。
April 05, 2006
贴图的合并
3d 游戏会用到大量的帖图，许多显卡要求贴图的尺寸必须是2的整数次方。这样，许多贴图的边角都会被浪费掉。尤其是大量无关的小贴图，我们通常想把他们合并在一张贴图上，尽量充满整个区域。
合并这些零碎贴图的算法，在学术上被称为排料问题。我尚未找到特别好的解决方法，所以这里就不展开写了。这里想讨论的是这些小贴图的管理。
March 08, 2006
基于垃圾回收的资源管理
游戏中有大量的资源数据，这部分数据通常数以百兆，甚至上G。如何在运行时管理好这些数据，也是游戏软件相对其他许多软件的一大难题。
管理这些资源分为加载和Cache两个方面。对于资源数量比较少的游戏，我们可以采用只加载不释放的方式，即使资源总量大于物理内存数，OS 在虚拟内存的管理方面也自然有它的优势。至于加载的时机，为了追求用户玩的时候的流畅体验，我们可以在一开始就进行 loading。当然也可以为了减少 loading 时间，去做动态加载。动态加载的问题比较复杂，可能涉及多线程，以及预读操作。这篇 blog 不展开谈。前段时间写过一篇动态加载资源 可以参考。
如果总的资源数很大的时候，我们就需要 cache 管理。因为在 32 位 OS 下，虚拟地址空间是有限的。这里主要谈 cache 的管理。
March 06, 2006
以人为本，美术资源的归档
游戏的 client 最文件数量最多，数据量最大的，往往是美术资源。（几乎所有的商业游戏都会在游戏发布时对资源文件打包，我们这里讨论的是开发期未打包的文件）当一个游戏的规模大到一定时，我们需要调动巨量的美术人力来制作这些资源。伴随着游戏规模和制作团队的扩大，设计资源文件的存放目录结构和文件命名规则往往成了项目一开始的头等大事。
2d 游戏这个问题稍微轻一点，3d 游戏更是有模型，贴图，骨骼等等的文件关联性在里面。这次我们的 3d 项目，让我又一次面对和思考这个问题。
January 05, 2006
动态加载资源
如今很多游戏engine宣称自己支持动态加载地图，也就是说可以作到跨地图时的零读取时间。听起来很高深的技术，实际不难实现，当然我们在大话西游和梦幻西游中早已经实现了。最近我正在考虑更加通用的解决方案。
先说说基本的思路。也就是我们需要把地图数据切割成小块，让每一块的数据读取解析量并不太大。然后，就可以根据玩家所在坐标读取最小数据量的数据。当玩家移动的时候，利用一些机器闲置时间去读周围的场景，或者进一步可以根据玩家移动方向把前方数据预读的优先级别调高。
December 30, 2005
当编辑器也成为游戏
最近我们立了个新项目，一个 2d游戏。和另一个主要的 3d 项目同时进行。这样比较方便更充分的利用资源。2d 游戏的技术已经很成熟了，所以我希望在两三个月内可以完工。
虽然以前的 engine 是现成的，但是最近脚本研究的比较多，所以我还是给出了个关于嵌入脚本的计划，把原来的 engine 重新包装一下，改成完全脚本驱动的。
October 11, 2005
游戏，一种奇怪的软件
现在做半职业游戏策划了，但是还是改不了程序员的老毛病。尤其是在写策划案的时候，方更加觉得程序的优美。程序是可以调试的，可以用工程的方法做质量控制，可以有测试的机制。大多数时候是可以被验证的。而且掌握了正确的方法，我们可以一步步的把程序搭出来，逐步看到成果。
但是游戏，作为一种软件则不然。