很不好意思，我只回复了两份，别的都还没有动键盘回复。一是周末在打游戏（平时实在没空），二是需要和同事讨论一下才有结论。我们工作室 11 号放假，10 号晚上办公室就没人了。也就这两天会比较所有的简历吧。

嗯，已收到的简历我都看完了（真是花了不少时间呢），明天会发给工作室其他写程序的同事看。我想若安排面试，就是年后的事情了。我们大约在 21 号正式上班。

请原谅我这个周末的懈怠。接下来我会尽力回复 email 的。

游戏时间大约在 50 小时左右，没看任何攻略，没有炼级，没有改武器，基本一路冲到底的。就是几个 boss 稍微难一点，retry 了几次，大体上对于熟练 RPG 玩家没什么难度。

然后接着就是回头做 64 个冥碑任务（现在完成了 20 多个，其中只做了一个 A 级的比较难），开传送点等等。我估计把盘走完，还需要至少五十小时吧。

这次剧情依旧不错，我比较喜欢，但不是最好。（FF 10 和 FF 7 我更喜欢一点）我的日文水平是入门级里的入门，理所当然的，好多地方没看明白。只能连蒙带猜了。生日那天，居然传出官方消息说是五月要出中文版，这算是今年的生日礼物吧 :D 一定会买来再玩一次的。

角色里三个 mm 都不错，任挑一个我都喜欢。不过感觉这次有点恶趣味。虽然没明白做百合向的，我想有几个镜头也是故意做的满邪恶了 :D

人物基本的可升级数值设定只留下 HP 物理 魔法 三个值（加上 ATB 槽和职业两个等级），我觉得是要莫大的勇气的。不过想想也够了。即可以做得丰富，又不多余。

我想 ATB 进化到这个样子，我们已经不能单纯把 RPG 游戏分成即时和回合制了。也并非如许多策划念叨的：回合的间隔缩小就成了即时。FF13 每次做出操作选择的时间间隔并不短，但流畅度，紧张感，爽快感却并不见少。

其实 FF13 里吸收的元素都不是新鲜东西，只是很融洽的组合在一起罢了。

我们这里工作室，需要招聘两名程序员。在未来至少一年的工作是：专职制作维护 3d engine 中的模型编辑器和场景编辑器。（每个一人维护）

要求：

1. 熟悉 C 语言，或 C++ 。至少有一门动态语言的经验，lua 最好，python 或其它也可以。

2. 能够全心制作编辑器（至少一年），最好有相关经验（非必须）。

3. 有 3d 方面编程经验优先，但不是必须。需要有学习 3d 编程的兴趣和动力。

4. 有任意一款 GUI 框架编程经验者优先。（例如 QT ）

待遇方面，不会太高，但也不算低。所以特别牛的同学就免了，可能满足不了你的要求。就算愿意，我也心里不舒服。

完全抱着从头学习的想法的同学也需要考虑一下。我们还是需要有一点点经验的，不可能花半年时间慢慢培养到可以开始动手干活。（经验指：可以独立编写 GUI 程序）

有兴趣的同学可以给我发 email 附上简单的简历。

我们是小团队，工作室制。我是团队负责人，全权负责团队一切事务。工作室下属于网易游戏部门（网易互动娱乐）。

团队以研发为主，暂不涉及游戏运营等。

今天晚上就碰到这么一个诡异的问题，我觉得是我太久没摸 C++ 了，对那些奇怪的语法细则已经不那么熟悉了。有知道的同学给我解惑一下吧。

事情的起因是，我想安装一个 perl 模块唤作 Syntax::Highlight::Universal 。

本来用 CPAN 安装很方便的，直接 install 即可。

可是在我的机器上，make 死活通不过。我就仔细研究了一下编译出错信息。又读了一下源代码，自己感觉没错。纠结了半天，仔细模仿出错的地方写了一小段程序测试。

各位同学觉得有问题么？我初看觉得没有。但是 gcc 一编译就出错。一开始是觉得 gcc 版本太高（4.x），可能语法检查更严格了。后来换了 gcc3 ，问题依旧。

出错信息如下：

a.cpp: In member function `void B::foo()':

a.cpp:11: error: `a' was not declared in this scope

就是在 B 里找不到 A 定义的成员变量 a 。

如果 A 不是一个 template ，那么这个问题就没有。

我琢磨着这个问题跟编译器为 template 生成代码的行为有关，但是不确定。

注：这段代码在 VC6 里是可以正常编译的。

最后，我试了一下，把代码改成

    void foo() { 
        this->a=0;
    }

那么是可以编译通过的了。可是，这是新标准规定的么？

btw, 其实我写 C++ 的最后一年，都养成了显式用 this 指针的习惯。这样比较少犯错误。

翻了几页杂志，回想到当年最终幻想X 出的时候的惊艳。当时看到公司里有同事在玩，也是周末。第二天去去买了台 PS2 和游戏。之后，我就成了这个系列的死忠（之前我也玩过七和八，但是都没有十给我的震撼）。后来我补上了五和六，并且把七和八重玩了；再之后就是 XI 和 XII ，以及 X 和 VII 的外传。

很久没玩游戏了，想想真是忙呢。又或者是长大了？但是，我得承认，我心里那点感觉又回来了。星期天一起床，吃完饭就直接去了附近的游戏店。价钱很黑，但是我急着想要。不到五分钟就拿下了 FF13 连 PS3 的套装。

我想这一作可以超过 X 在我心中的地位了。

不过一开始没有买 HDMI 线，文字相当模糊。昨天又在网上订了跟线，今天到了。换成高清模式舒服多了。看来这线是玩 FF13 必备的。

这次的战斗系统做的非常简洁明快。爽快感十足。还解答了我前年的一个疑问：

之前我做个一个战斗设定：回复 HP 技能可以来得比较轻易，并且几乎无消耗。强调爽快感，不要有太多繁杂操作（比如磕药，复杂的加血技能）干扰战斗。但是沙盘了半天都觉得很难做平衡，没有想出和高回复力对应的设定应该是什么。

FF13 告诉我，可以有一个 Break 系统做一个对应的补充。玩家重点在于控制操作的次序即可。（当然还有职业更换的策略）

之前我的构思里有个类似的设定，但是思维产生了个死角，没有把系统做成非线性的。而用了一个高斯分布。其实加一个 Break 临界点，就好玩了许多。

这些都是闲话了，等对此作的战斗系统有了更深刻理解后，再总结一下。

看网上介绍，这次的剧情通关应该在 40 小时左右，我现在游戏时间才 20 小时。争取这周先一周目吧。

别的银行我也用过几家，也骂过。比如农行早几年取款难。每个季度我都去转工资，每次要排 3 小时的队。后来花了 100 办了网上银行，居然跨行转帐最长等了我一周。后来工资转发到招行，总算解决了问题。愤然去消户，跑了两趟银行，交通费花了几十，手续费花了十块（补交年费，还有把卡弄坏的挂失费等等）。

中国银行的人再给我打了两个电话，并陆续索取了一些我的个人材料后，通知我，审核没通过。不给办信用卡…… 看着满大街送上门的卡（我抽屉里还有张没开的广发信用卡），我彻底无语了。看来跟谈恋爱一样，只要是你主动找上门去的，立马掉价了。

此外，我还用过邮政储蓄，在读大学时办过张交通银行的卡（当时唯一在校园里有网点的银行）。读书时有次邮政储蓄内部系统错误，导致有些取款机异地取了不钱。我当时身无分文，（没钱买公交车票）在长沙市区里步行了 4 个多小时找可以取款的柜台。

最近因为需要，在建设银行以及交通银行都办了些业务。

早几年建设银行硬件水平之滥我早有耳闻。前几年，我作保，给朋友贷了一笔钱。资金打在了北京的建设银行里。这个朋友想从杭州把钱取出来，被告之，建设银行内部南北不通，是两个系统。这么转帐要收四位数的手续费。当时我就惊诧了。如果不考虑时间和精力，还不如自己北上去柜台办呢。

这些年应该好了些。可今天去建设银行转帐。柜台上手续繁杂不说。同城跨行居然要收 25 。还是打了 5 折的。我在招行免费转帐习惯了，还真有点不适应。（招行即使没有金葵花卡，同城跨行也只要 2 元）末了，银行的人推荐我开通手机银行，说是汇款 3 折。头三个月免费。

注意，是头三个月，以后每个月还是要收 6 元的。至于网上银行，必须买个 USB key 。

然后是交通银行，我免费开通的手机密码登陆网上银行。毫不怀疑的打开了 IE ，我想 Chrome Firefox 铁定是支持不了的了。

结果，弹出个 javascript 出错框，唉，习惯了，见怪不怪。安装了所谓安全输入控件后。我登陆了两次硬是没进去。不是我密码错误，而是那个图片校验码错…… 然后，我的帐户被锁定了。告之，去银行柜台解锁吧。

嗯，在其它银行软硬件不跟进的情况下，我就不指望招行能出跨平台的网银了。谁叫咱别无选择呢。

我们都知道，层次分明的代码最容易维护。你可以轻易的换掉某个层次上的某个模块，而不用担心对整个系统造成很大的副作用。

层次不清的设计中，最糟糕的一种是模块循环依赖。即，分不清两个模块谁在上，谁在下。这个时候，最容易牵扯不清，其结果往往是把两者看做一体去维护算了。这里面还涉及一些初始化次序等繁杂的细节。

其次，就是越层的模块联系。当模块 A 是模块 B 的上层，而模块 B 又是模块 C 的上层，这个时候，让模块 C 对模块 A 可见，在模块 A 中有对 C 导出接口的直接调用，对于清晰的设计是很忌讳的一件事。虽然，我们很难完全避免这个问题，去让 A 对 C 的调用完全通过 B 。但通常应尽力为之。（注：以后写书的话，我争取补充一些实际的例子来说明）不过，对语言不原生支持的数据类型，以及基础设施，但却有必要创造出来给系统用的。可以有些例外。比如内存管理，log 管理，字符串（C 语言用原始库函数管理比较麻烦）等等，我们可能以基础模块的形式提供。但却可能被不同层次的模块直接使用。但，上到一定层次后，还是需要去隐藏它们的。

下面来一点更实际的分析。

那么模块 A 看起来就是一堆 'A_xxxxx' 为名字的方法。我个人主张单个模块不宜过大，在实现时适合放在同一个 .c 文件里即可。通常，一个模块会围绕一类对象处理。这些对象可以用整数 handle 来表示，也可以用一个特定类型的对象指针。两种方案各有千秋。先来谈对象指针的方案。

一个模块 A 的接口描述文件很可以是这样的（希望以后能补上更现实的代码）:

#ifndef _A_h
#define _A_h

struct A;
struct B;

struct A* A_create(void);
void A_release(struct A *self);
void A_bind(struct A *self , struct B *b);
void A_commit(struct A *self);
void A_update(void);

int A_init(void);

#endif

这里，我们定义了 A 这种数据类型。我个人反对用 typedef 或宏来减少代码输入。除非有特别的理由，都写上 struct 前缀，而不是定义出新类型。尤其是在较底层的模块设计时更是如此。在接口描述时，struct A 的细节是绝对不应该暴露出来的，它的数据结构应该仅存在于实现的文件 a.c 中。

关于 A 的接口通常分两类，一类是对 struct A* 做一些处理的，那么就让第一个参数传入 self 指针。这相当于 C++ 的 this 指针。比如上例中的 A_commit ；另一类接近于 C++ 类的静态成员函数，通常用于对这一类对象全部做一个处理，如 A_update 。

注：我无意用 C 去模拟 C++ ，但基于一类数据类型做一些处理的方法，对于 C ，这样的写法也是一个常规的范式而已。至于面向对象等在构建复杂系统时常用到的方法，以后我会谈谈我自己常用的另一些范式。或许像 C++ ，也可以不像。怎么写更好，是个见任见智的问题。不用过于拘泥。

这里的例子中，我们还提到了另一个数据类型 B 。显然，它是放在 B 模块中的。

我们通常不会在 a.h 中去 include b.h ，而只是声明一下 struct B 。（对于 C 语言来说，这并不必要，但写上是个好习惯）。这是因为，如果 B 是位于 A 之下的模块，既在 A 模块的实现中，会用到 B 的方法，我们通常不会让用到 A 模块的人，可以看见 B 的接口。包含 a.h 的同时隐式包含 b.h 就是不必要的了。

从范例代码中，我们可以猜想，struct A 是对 struct B 的某种封装，可以通过对 A 的操作，间接操作到其中的 B 类型。在 A 的模块初始化 A_init 中一定就会初始化 B 了。如果是这样，B 的层次就位于 A 之下。

往往 struct B 中还会保留一个 struct A 类型的引用。首先，我们应该尽力避免这种情况。即：位于下层的 B 应该对上层的 A 一无所知是最好的。如果在 B 模块中必须出现 struct A，那么我们应该至少保证，仅仅是 struct A * ，一个引用，而绝对不能出现任何对 A 模块内接口的调用。不要认为使用巧妙的方法，绕过循环依赖初始化问题就够了。这应该是一个设计原则，不要去违反。

btw, 草率的接口设计往往是日后系统脆弱的根源。图一时之快，随意暴露一些接口，或是自以为聪明的用一些“巧妙”的方法，甚至是语法糖来绕过设计原则，都是很危险的。

一个常见的难处理的问题是：如果 struct A 和 struct B 相互有双向引用。怎样建立这个引用关系？这个建立的过程，到底是 A 的方法，还是 B 的方法？我的答案是，谁在上层，就是谁的方法。

但是 A 和 B 相互都看不见内部数据布局的细节，让 B 的内部对 A 类型做一个引用，比如也需要从 B 模块中暴露一个接口出来。这个接口，可能仅供 A 使用。在这个例子里，就是仅供 A_bind 这个方法去使用。

如果是 C++ ，我们或许会采用 friend 。也可能使用其它一些技巧。反正 C++ 里可以挖掘的语法太多了。但 C 怎么办？下面给个我自己的方案。

原本，我们在 B 中导出的 api 是这样的：

void B_set_A(struct B *self,struct A * a); 

现在写成：

struct i_A;

void B_set_A(struct B *self,struct i_A *a);

在 b.c 的实现中，加一个函数用于 struct i_A * 到 struct A * 的转换。

static inline struct A * A(struct i_A *a) { return (struct A *)a; }

然后在 a.c 的实现中，加一个类似函数用于转换 struct A * 到 struct i_A * 。

这样，在 a.c 之外，其它模块因为不能得到任何 struct i_A 类型，而不会错误的使用 B_set_A 这个接口了。

模块化是最高原则之一（在 《Unix 编程艺术》一书中， Unix 哲学第一条即：模块原则），我们就当考虑如何简洁明快的使用 C 语言实现模块化。

除开 C/C++ ，在其它现在流行的开发语言中，缺少标准化的模块管理机制是很难想象的。但这也是 C 语言本身的设计哲学决定的：把尽可能多的可能性留给程序员。根据实际的系统，实际的需要去定制自己需要的东西。

对于巨型的系统（比如 Windows 这样的操作系统），一般会考虑使用一种二进制级的模块化方案。由模块自己提供元信息，或是使用统一的管理方案（比如注册表）。稍小一点的系统（我们通常开发接触到的），则会考虑轻量一些的源码级方案。

依赖关系可以放由链接器或加载器来解决。尤其在使用 C 语言时，简单的静态库或动态库，都不太会引起大的麻烦。

C++ 则不然，C++ 的某些特性（比如模板类静态成员的构造）必须对早期只供 C 语言使用的链接器做一些增强。即使是精心编写的 C++ 库，也有可能出现一些意外的 bug 。这些 bug 往往需要对编译，链接，加载过程很深刻的理解，才能查出来。注：我并不想以此来反对使用 C++ 做开发。

我们需要着重管理的，是模块的初始化过程。

对于打包在一起的一个库（例如 glibc ，或是 msvcrt ），会在加载时有初始化入口，以及卸载时有结束代码。我想说的不是这个，而是我们自己内部拆分的更小的模块的相互依赖关系。

谁先初始化，谁后初始化，这是一个问题。

在 C++ 的语言级解决方案中，使用的是单件模块。要么由链接器决定以怎样的次序来生成初始化代码，这，通常会因为依赖关系和实际构造次序不同而导致 bug （注：我在某几本 C++ 书中都见过，待核实。自己好久不写 C++ 也没有实际的错误例子）；要么使用惰性初始化方案。这个惰性初始化也不是万能的，并且有些额外的开销。（多线程环境中尤其需要注意）

我使用 C 语言做初期设计的时候，采用的是一种足够简单的方法。就是，以编码规范来规定，每个模块必须存在一个初始化函数，有规范的名字。比如 foo 模块的初始化入口叫

int foo_init()

规定：凡使用特定模块，必须调用模块初始化函数。

为了避免模块重复初始化，初始化函数并不直接调用，而是间接的。类似这样： mod_using(foo_init);

mod_using 负责调用初始化函数，并保证不重复调用，也可以检查循环依赖。

在这里，我们还约定了初始化成功于否的返回值。（在我们的系统中，返回 0 表示正确，1 表示失败）然后定义了一个宏来做这个使用。

#define USING(m) if (mod_using(m##_init,#m)) { return 1; }

注：我个人反对滥用宏。也尽可能的避免它。这里使用宏，经过了慎重的考虑。我希望可以有一个代码扫描器去判断我是否漏掉了模块初始化（可能我使用了一个模块，但忘记初始化它）。宏可以帮助代码扫描分析器更容易实现。而且，使用宏更像是对语言做的轻微且必要的扩展。

这样，我的系统中模块模块的实现代码最后，都有一个 init 函数，里面只是简单的调用了 USING 来引用别的模块。例如：

#include "module.h"

/*
  我个人偏爱把 module.h 的引入放在源文件最后，初始化入口之前。
  它里面之定义了 USING 宏，以及相关管理函数。
  这样做是为了避免在代码的其它地方去引入别的模块。
*/

int
foo_init()
{
  USING(memory);  // 引用内存管理模块
  USING(log);  // 引用 log 模块

  return 0;
}

至于模块的卸载，大部分需求下是不需要的。今天在这里就不论证这一点了。

中午 12 点 50 到的，一看，好家伙，买票的人排了一层从楼梯都排到楼下了。周六下午场都卖完了。正打算去吃个饭再来排队的。结果一黄牛过来，说要不要 13 点的。我一看表正好 12 点 55 。100 快一张成交。

不错，就是没吃中饭，爆米花充饥。

电影不错，iMax 3D 感觉是不一样。屏幕大，才有足够的纵深。坐的位置估计也满重要。反正我坐在中间靠后一点，感觉正好。

这部片子啊，就是看效果了。情节就那样了，但是设定很严谨。适合我们这样做游戏的人看。

看来我的 blog 还是还是有点影响力 :) 好多人都下载了那本书。

Derek Jones 同学提醒我书已经有了新的版本。我已更新了原帖的下载链接。

btw, 机器翻译真是恐怖啊。当然，毕竟这位同学填对了 7 。 :D

做 LuaJIT 的牛人 Mike Pall 对 bit 库没有采用他做好的现成方案那可是相当的不客气。

不过，欢呼雀跃的人还是比较多的。每次 lua 升级个小版本，改动都非常大。对成熟项目，不给你伤点筋骨，那就不是 lua 三巨头的风格了。当然，对于时不时重写代码的我，欣赏这种风格 ;) 我喜欢更健康的 lua 语言。

嗯，无论如何，lua 的源代码是非常值得阅读的。

不过新加的 in exp do block end 语法是我喜欢的东西。比用 setfenv 去做一些 DSL 的活方便多了。主要是不太容易出错，代码也更漂亮了。

这个玩意如果用 setfenv 去模拟，就难看多了。可以参考我前几年写的短篇 最后，模拟 pascal 中的 with 这段。

其它许多改动，对老代码都或多或少会有点影响。但是可以促使大家把代码重新写的更规范一些，好事儿。

我想，把代码写正确的话，性能也会提高一点的吧。

话说那本书，我自己是不太满意的。04 年写的时候，基本只能总结 03 年之前的一些东西，还差许多火候。写完之后，我给自己打了 70 分，慢慢的，觉得有 60 分就不错了。勉强及格吧。

其实，写语言是次要的东西。除了 C++ ，我看没几种语言需要有一本以上谈语言的书了。关键是借语言谈点事儿。我们并不是用不好语言，是不知道到底该怎么解决复杂性这个问题。

我们会有很多方法解决问题，可能也不会存在某种通用的伎俩。不过每个有 10 年以上编程经验的程序员，只要他不是天天重复昨天。那么总会有自己的一套东西，值得拿出来供人参考一下。可以是编程习惯，编码风格，常用的范式，刻意规避的问题。

近三年来，我用 C 语言堆砌了大量的代码。想了很多问题。加上之前一共 19 年（1991 年到 2010 年）的 C/C++ 经验，总算觉得稍微摸到点门道。唉，最近项目还是太忙了。忙过了，真想写写，总结一下。绕开各种语言表面的浮华，看清问题的本质，用 C 这样貌似简陋的语言工具，去构建一个由许多人共同维护的复杂项目，还是一件挺有趣的事情啊。

问题的实质往往不是你是否能找到一个精巧的结构，完美的表达它；而是找到一个最通俗易懂，不需要同伴付出额外学习负担的方式。所谓“大巧若拙”吧。

这个光源模块设计要解决的问题在于：

GPU 的处理能力，目前看来比较有限，不可能实时处理无限数量的光源。所以，当你的场景里设置了许多的光源时，必须可以拣选出最可能影响被渲染物体的光源信息，把这个信息交给驱动去处理。

增加关于光的新特性也会相对复杂。

经过一些思考后，我决定重新设计和实现。

虚拟场景是树状层次结构的，这个是很自然的设计。但是树状结构也比较难操作。而光源的管理，假设不处理复杂的遮挡（暂时我们游戏也没这个需求，有的话，也不违背以下设计），其实我们要的仅仅是知道所有激活光源在世界中的绝对位置。

所以，我把光源的位置管理藏在光的管理模块内部，在接口上并不暴露出这一信息。

作为光管理模块，我们需要的仅仅是把逐个光源设置进它自己内部维护的一个虚拟场景中（无层次结构）。然后在真正渲染时，取回空间中某个位置附近的光源而已。

为了给以后的优化留下足够的信息。我增加了一个受光体的概念。受光体保留自己在光场景中位置。我们向光的管理模块提供受光体对象，而不直接提交位置信息。这样可以留下 cache 层，加快查询速度。

这样，渲染流程就变成了：遍历场景树，将每个场景节点提交到下一层次。若是可渲染物，就提交到了渲染队列；若是光源，就把光源提交到了光管理模块。

在低一个层次，处理渲染队列时，经过若干排序和筛选操作后，真正渲染前，依据每个渲染物绑定的受光体对象，去光管理模块查询附近的光源，把这些光源包含的光信息提交给驱动层。

这里可以做的优化：

每个渲染帧，从接口上看，其实都从头构建了光源和受光体构成的场景（藏于光管理模块的内部，独立于场景树）。我们可以 cache 上一帧的场景，并加以比较。对于不变的对象，从受光体的内部取出以前计算好的值，直接返回。

光源位置管理，可以使用八叉树。如果是固定第三人称视角的游戏，四叉树也足够了。或者更简单一点，使用网格。设置光源坐标时，帧之间加上脏标记，可以轻易的获知是否需要重复运算。这个优化手段，可以把所谓静态光源和动态光源的处理细节隐藏在接口的背后。

打格子的方法可能是最简单有效的优化手段，比用其它复杂的算法计算一个受光体附近最近的若干光源更符合 KISS 原则。为了使格子简单有效，可以把格子的边长设置为略小于一个点光源大约可以影响的半径之内。每个点光源提交的时候，以围绕其坐标，以等边三角形的方位，提交三次即可。最终，只需要遍历受光体所在格子，就可以快速查到其附近的光源。

当然，一开始，我们不需要作任何优化手段。用最苯的 O(N*N) 的算法，检索所有提交的光源即可。先做对，再做好。