和大部分原创游戏一样，游戏定名总是晚于项目启动的。01 年 4 月我正式入职网易时，大家还并不知道这个游戏会和周星驰的著名影片《大话西游》同名。micro 他们只是想做一个以西游记为背景的网络游戏。这个想法来至于当时有名的 mud 《西游记》。我对国内 mud 的历史没有什么了解。大约知道有《西游记》的巫师（yesi）被招聘进来工作，大家对《西游记》情有独衷并不奇怪。

月心是 micro 的合伙人，也是最早天下的策划。理所当然的承担了新项目的设计任务。因为我对网络游戏本身没有兴趣，所以我对这个人也不太熟悉。倒是和另一个策划私交不错，大猫猫。严格意义上来说，他不是大话西游的策划，进入网易前，我想他的身份多半是一个资深玩家。他以前做什么的也不记得了。不过我倒是很早听过这个人，似乎混迹过 sina 的游民部落和后来的 mop 。他的朋友圈子里的人见过不少，salala 、commando 还有后来加入网易的 ali 等等，大多是做游戏媒体的人。

《大话西游》这个名字是大猫猫的主意，马上得到了大家的认同。一开始我们有点担心版权的问题，丁磊说网易有个董事认识周星驰，而后大猫猫就去香港找星爷去了。两年后，大猫猫离开网易，据说在跟星爷混，不知道现在咋样了。

---

初到广州的那段日子，虽然工作比较紧张，但是进行的有条不紊。我绝不主动过问游戏方面的事情，只做 engine 。这一快其实没太多东西好做，至少我的进度比大进度要来的快。大都是早就深思熟虑过的东西，只需要把细节完善一下，补上缺少的模块就好了。偶尔有些技术点要攻克的，突击几个晚上，剩下来的大多数时间，并不需要加班。

丁磊很喜欢泡酒吧，而公司附近就有许多。他带我去各个酒吧转，介绍一些他认为有特色的吧，和各式各样的朋友与我认识。我想那些朋友于他也只是点头之交，跟我也不会有啥关系，往往记不住名字。他喜欢的吧都很喧闹，比如公司对面的 wine flower ，去的很多。

我不喜欢太吵的地方，不明白为什么有人喜欢。据说是为了放松一下紧张的神经？或是找个宣泄的场所？可我不觉得自己有什么放松和发泄的需要。从来没觉得什么叫紧张，什么叫压力，什么叫累。平常写写程序挺有乐趣的，写累了，睡觉是最好的放松。我也不喜欢用酒精把自己灌的神智不清，思考是人最重要的能力，脑子烧坏了可不太好玩。

不过有时候老丁也专门约些朋友聊天，当然不能去那些需要对着耳边大喊的场所。这就需要找个安静之处喝点红酒。有一次，我们学来了杀人的游戏，一伙聪明的人在一起，玩的特别带劲。后来的几年，我都很喜欢这个游戏，并且自行扩展了诸多规则，几乎每周玩一次，直到腻味。

喝酒的时候，丁最放的开，像一个大孩子。当然他也喜欢在我这样比他小上七八岁的同事面前摆出老成的样子，讲一些道理。但总的来说很随意，他有些别人没有的优点，也有点不至于让人讨厌的缺点。他是个普通人，一个好人。

---

肖海彤曾经跟我提过一次，能不能以后上班也打一下卡，因为公司需要整顿一下风纪。其实，我在北京上班时都很守时的。不过这次，我想了下说，能不能少点约束。胖肖几乎没有考虑就回答，公司得有个规章，但一两个人的例外倒没太大问题，而且对于自律的人，的确也不需要约束。所以我再也没有打过卡。

的确，我自信对的起这份工作。那段时间做了许多事情。没有人给我分配工作任务，没有人告诉我该做什么，项目需要什么。我想，我写点程序会有用，那么就写了，结果也就用上了。一个最重要的模块就是在最初那段时间完成的，一直用了很多年。

昨天提到网游客户端对内存占用量控制的问题。我们定的最低配置要求 64M 内存（实际上，最终放宽到了 96M ）。最占用内存的是那些角色动画。因为希望有好的效果，我决定让所有图片都使用 alpha 通道。这可以让精灵的轮廓和背景融合在一起，没有锯齿。现在这几乎是 2d 游戏的标准配置。但那时，由于硬件限制，采用的游戏并不多。

实现的困难在于处理速度以及内存消耗，尤其是内存。假设一个人物的单帧图片为 64 * 128 像素大小，采用高彩模式带 8 bit 的 alpha 通道，那么这一帧图就会消耗掉 641283 = 2.5 K 内存。若是有 8 个朝向，做行走的动作，一组动作 8 帧。那么合计的图片量就达到了 1.5M 。这还仅仅是一个人物的一组动作而已。

网络游戏中，由于玩家的个性化需求，以及内容的丰富，我们需要数以百倍的数据量。用 64M 内存储存下这些数据，简直是天方夜谭。

许多人会联想到图片压缩技术，莫说非技术人员，前段时间连我们公司的程序员都在 maillist 上询问，为什么我们公司的游戏都使用自己的图片压缩格式。他极力推荐 gif 和新版的动画 png 。

其实，图片压缩算法往往都是为了节省硬盘空间和缩短加载时间而设计的。进入内存后，这些标准格式大多还是展开为平坦的数据结构 —— 非压缩数据，方便图象引擎处理。而我们亟待解决的问题是内存的消耗。（这个问题到了今天 2G 内存已是标准配置时依然存在，因为暂时还是主流的 32bit 操作系统，虚拟地址空间依旧有限，容不下日益扩大的 client 图象数据。这是 2d engine 需要处理的一个难点）

我的解决方案是设计了一种可以把解压过程推迟到渲染时再进行的压缩数据格式。原理很简单，RLE 行程压缩算法而已。只是让数据结构组织的更适合实时解压。甚至比不压缩的图象数据处理的更快（因为总的数据量减少，降低了内存总线带宽的需求）。图象也采用了 8bit 调色盘技术，对于 alpha 通道则只保存轮廓线的少量部分。

即使《大话西游》的后继维护人员意识不到，我自己倒是觉得早期的这些精打细算，在内存占用和 CPU 处理速度上的平衡估量，为日后的资料片连续推出铺平了技术道路。策划们肆无忌惮的向资料片里添加素材时，client 不至于膨胀的过快。我们的最低硬件配置要求可以随着玩家的硬件水平提高，需要控制的只是不要增长的太快就行了。《大话西游》一直可以在低配置的机器上流畅运行（包括同一机器上多开客户端，多重登陆，针对这些，我也花了些工夫优化），是它可以顺利推广的一个原因。

图象格式设计好之后，渲染代码花了半个月实现。并额外用了半个月时间用汇编重写，在当时的机器上较之 C 版本提高了 1.5 倍的速度（如今的机器可能差不了这么多了）。图象压缩的工具初版是果子做的，后来我也当学 MFC 而练手做了一个替代品，其中复制了果子代码中的一小部分。如今，网易的许多 2d 项目还在用我那个简陋的工具，点出 about 会看见当年留下的一行字：“云风出品 质量不能保证”。

游戏之作会用这么久，是我编写之时没有想到的，而道理很快就想通了。大多数人都有一种习惯，只要工具还能用，就会一直将就下去。项目开发中，需要做的事情永远比完成了的事情要多，那么只要老的东西还能用，就无心去改进它了。

明白这个道理后，让我以后的工作都特别谨慎。因为写的每一行代码，做的每一个决策，都可以一直被用下去，除非自己想重新来过。指望有人改进它们，是不切实际的想法，即使你在 log 中标上 todo 写的明明白白也不例外。

那个时候，大家还在用 vss 做代码管理。我没怎么用，因为我不太相信有人会来和我一起来共写一块代码。所以我一直自行维护那块相对独立的 engine 部分。稳定了就送去古越那里让他使用。稳定的接口很重要，不至于让大家疲于奔命的重构代码。直到后来做大话 2 时，我才和大家一起移到 cvs 下，一起维护。

那时我对内存的锱铢必较甚至反映到对美术的抱怨上。例如，当时游戏里有四种女娲的形象，其实是用的同一套模型和动作渲染出来的。只是四种颜色，美术人员在渲染时换了四种光源而已。我看到后，抱怨着为什么这样浪费，其实 engine 已经提供了调色盘更换技术，可以方便的用程序做到同样的效果。

最终并没有执意要求换掉这四色女娲。因为我在和大猫猫聊这件事时，自己明白了一个道理。当时他并没有立刻理解我的想法。如果他都没有马上明白，那么，解释给众多人听将是一个浩大的工程。当多人合作做一个项目时，应该为每个参与人员保留最简单的要求和规范。因为一旦项目人多，沟通成本远大于技术成本。一切复杂的手段都是不切实际的。如果真的想按我的想法去做的话，也应该由我自己来写一个额外的程序去自动化处理美术提供的冗余数据（这个案例中，四色女娲共同拥有的模型就是冗余数据），而不是增加制作规范的复杂度（要求美术人员额外去调调色盘，并输出成指定格式，再交给 client 开发人员调用）。

---

老实说，我觉得当时的工作做起来比今天闲的多。白天总有时间在办公室瞎转悠。我喜欢跟同事打交道。不管是不是我的分内的事情，都爱关心一下。我想这也是我的历任上司们都对我的工作放任不管的原因之一。当我的事情做完，总能找出点活儿来做。我在网易乃至游戏部门一直没有安什么特别的职位，手下没有兵，头上没有将。很多东西都是随口问问，看看能不能帮上忙，或是提一些自己的看法。同事们也不会有太多的排斥，反正我不是他们的上司，不会指责他们的失误。偶尔起兴趣了，还可以帮忙写点程序辅助一下。因为我天生看不得有人做重复机械劳动的苦力，宁可自己多花点时间写程序自动化一下，也不愿意见人一整天在那白辛苦。忙的要死，其实没做什么东西出来。

那个时候，游戏的 server 比 client 更晚进入轨道。记得随口问过写 server 的同事（忘记是谁了）的进度。4 月底的时候，他们还在弄一些相当基础的模块，内存分配之类的，让人有点担心。更晚一点，我参加过一次他们 server 组的讨论会，讨论服务器的架构。那个时候，我对 server 开发没什么概念，也没什么兴趣。只是觉得白板上圈圈和连线过于花哨，不觉得有太大意义。最终 dingdang 的加入拍板说，就用单进程单服务器结构好了，这是后话（几个月以后的事情），而且我也记不太清细节了。

micro 挺喜欢让我参加他们的各种讨论会议。这倒不是我特别主动要求，因为开始的几个月，游戏项目不足以引起我的兴趣。

策划的会议参加过一次，乱糟糟的，大家商量游戏里的战斗模式。即时制起先就被我给否决掉了，因为我更喜欢回合制的 RPG 。说起即时战斗模式，我只说 engine 不支持，并摆出大堆理由。其实支持也不是太难，但是我就是不喜欢。而正好当时石器时代正处在上升期，听说已经为华义赚入大量钞票，足够让丁磊流口水的。石器是一个典型的受玩家欢迎的回合制网游，正面典型在前，大家也不怀疑它的潜在用户数量。

剩下的问题是，做一个怎样形式的回合战斗系统。似乎大家都倾向于做的特别一点，比如黄华，当时的另一个策划，提出来要做成在战斗场景上移来移去有方位感的形式。我和大猫猫比较反对，我认为，徒劳增加一些表现力，而不增加对应的游戏系统是没有什么意义的。当时黄华找不到一个合适的游戏系统来支持这种玩法，最后也就作罢。月心是一帮策划的头儿，很沉稳，慢条斯理的，不跟大家吵。他主持了那次策划会议，但没有结论。这可能是我参加的唯一一次《大话西游》的策划讨论会。最终，游戏的战斗系统就是现在这个样子了。

其实回合制的游戏也可以做的丰富多彩，形式多变。我想说，起初大话的策划们也想过很多，只是最终没有实施而已。有很多因素：项目进度、技术因素、硬件限制、等等一些我知道和我不知道的原因。

比较遗憾的是，这么多年，包括我们公司自己的开发团队在内的许多国内开发组，制作回合制网游时，都不敢越雷池一步。在根本形式上少有创新，是让人很可惜的一件事。也许我当年能多点兴趣，支持一些有趣的想法，并做出技术上的支持，在没有定型的网络游戏市场上，会出现别样的回合制战斗形式来。谁知道呢？很多事情也不是一个人可以改变的。

甚至在开发的前两个月，我还参加了一次美术的审核会议。起因是我在调试地图加载模块时，指出了一处场景中的图象错误：有两个建筑的影子方向不一致。其实也不是什么大不了的问题，玩家多半不会在意。micro 决定让我和大家一起统一审一下做好的图。我不是美术人员，也不会跟人争论美术风格应该是怎样，哪里做的不好。但是，一些诸如影子这样的小毛病挑了不少。建筑的力学结构，墙壁上的花纹，哪些植物不应该长在一起之类的。后来觉得这些其实都不太所谓，追究的太多对项目也没多少益处。之后也没再干了，美术的队伍越来越专业和成熟，也勿须我这样的外行插嘴。

那段时间真是过的挺快乐。我对整个游戏开发项目的影响很奇怪，人的职位是属于网易技术部的。游戏项目中名义上的专职工作是做 client 引擎。但实际上做了大量万金油的事情，挺琐碎，以至于自己都记不清干了些什么。就是没让自己闲着而已。

---

早期的那帮同事都混的挺熟。micro 也定期组织大家聚餐唱 K ，我一点不会唱歌，就知道跟人摇骰子。美术部的刘琪周云他们都是爱玩的主，我虽然自己不会晚上主动出去娱乐场所玩，但也不反感有大帮认识的人一起闹腾。哦，古越倒是顾家的好男人，每次我们出去玩，他都不去，要按时回家。这代表了网易游戏开发团队中截然不同的两种性格。我想，一直以来，网易游戏的程序和美术部门都没能完全融合到一起，除了后来的部分行政划分的原因，还缘于最早的这种性格差异。

日子过的挺快，甚至都没觉得项目有什么进展，就这么过了。除了我自己做的那块东西还比较满意，我想我对项目没有信心，当时谁有信心？

Perl is a powerful scripting language that can meet your day-to-day scripting needs as a database administrator, and if used prudently, and responsibly, as a language to build large web-based applications. Here's a quick introduction to using Perl with Oracle.

dbanotes posted a photo:

©作者：eygle 发布在 eygle.com

记得以前我曾经写过一篇《年关临近 谨防数据库事故》，那的确是有感而发。
根据统计我们发现，每逢节假日前后，都是数据库事故多发期。

而其实90%以上的数据库故障，威胁来自数据库之外。
列举一下最近的几次数据库事故及原因，警示一下这些来自数据库之外的威胁：
1.4月25日淘宝网的数据库故障
淘宝网的这次故障是由于IDC停电事故导致的，断电导致所有设备失效。这样即使考虑向备用数据库（Standby）切换，也不得不面对损失数据的麻烦。

2.5月2日前公司数据库故障
放假期间，前公司的EMC存储出现故障，EMC CX500的一个控制器损坏，导致一个数据库实例Crash。
这是存储的故障，最终数据库要直接面对服务中断。

3.5月5日客户数据库故障
今天一大早收到客户电话，存储设备出现故障，导致数据丢失，需要进行恢复。
到达客户现场才了解到IBM DS4700，在增加新的磁盘，在新磁盘上划分RAID磁盘组时，莫名其妙的，生产卷的数据全部消失。
而且类似的故障并不是第一次出现。用户对DS4700彻底失去了信心。

由于存在有效备份，数据可以及时恢复，但是还是损失了Online Redo中的数据。
这次故障是存储的问题导致的。

只想说明两点：
1.节假日前后一定要注意数据库安全
2.密切关注数据库周边环境

DBA这份工作有时候并不简单。

-The End-

相关文章|Related Articles

• DBA警世录:root操作需谨慎
  
• DBA警世录:使用ASM应当具备充分认识
  
• DBA警世录:年关临近 谨防数据库事故
  
• DBA警世录：职业生涯误操作之误删除篇
  
• DBA警世录:where条件很重要
  

评论数量(5)|Add Comments

本文网址：http://www.eygle.com/archives/2008/05/thread_from_outside.html

Author:丹臣 posted on Taobao.com

庆祝淘宝第一个使用MySQL的前台商业项目（画报项目）正式发布。下面是网址：
http://poster.taobao.com/index.htm
此项目还没有对外推广，大家先去看看:)

Add Comments(4)