理性的激进 http://blog.sina.com.cn/flymemory Tue, 05 Jan 2010 14:25:04 GMT+8 FEEDCREATOR_VERSION zh-cn Copyright 1996 - 2009 SINA Inc. All Rights Reserved. Tue, 05 Jan 2010 06:25:04 GMT+8 自然，华丽，Gemini http://blog.sina.com.cn/s/blog_55288aa20100gafh.html GEMINI在手头已经几个月了，一直想为它写篇听感，可惜一直忙于工作，最近工作稍松，让我有时间来完成这篇听感文章。

 

 

器材篇：

 

我的系统普普通通，为007搭建的新系统也正在构思中，先看看我这次试听的系统：

CD Transport - Philips LHH500R

DAC - Lavry DA11

Amp - Gemini MX

对比Amp - Rudistor RP010B，SOLO豪华版

headphone - RS1i，HD600, HD540G 600ohm, AKG K701

AC Cable - MOON2代电源线

Interconnect - Copper Colour 周年纪念版信号线

 

SOLO是我原来的耳放，010B是专门为这次试听从北京的朋友那里借来的。

 

聆听篇：

 

个人偏爱古典，以及乡村音乐，本次试听的CD如下：

《Tchaikowsky：Klavierkonzert No.1 & Scriabin：Four Pieces, op. 51》（第一钢琴协奏曲）

古典我偏爱用HD600来聆听，听这种较大编制的交响我首先关注的便是音场以及乐器的定位。在Gemini下，600体现的一种大气，中心的钢琴,后排的铜管，小提琴交相辉映，定位及其准确，结像清晰。大的动态冲击力也是极强，尤其在末尾处的大合奏，自己仿佛也置身于那激情澎湃的音乐大厅。

换上540g，在音场，乐器的分离度上虽不如600，但表现出来那种华丽的钢琴味道却是600怎样也达不到的。

 

《What about ths?MR paganini》(七把名琴)

这张cd是我最喜欢的碟之一，之前在SOLO驱动下，怎么样都达不到在010b系统中600那种细节度和密度。只能勉强在SOLO+701下欣赏了：（。由于我的版本是高阻版本，而众所周知540G在小提琴下的那种华丽，贵气是其他耳机无法匹敌的。一开声我便被声音完全吸引住了，那种自然，华丽的声音是我在010b+600下都不曾体验到的。甚至于琴弦泛音的细节都能够清晰再现，那种透明和通透是我在以往的540G前所未闻的。

可以说，gemini给我最大的惊喜在在于540G的驱动上了。那种声音久久在耳边不能抹去，以至于我这些天一直在回味这种感觉。

 

《Big Shoes - DAVID MUNYON》

这张CD是老虎鱼最近录制的乡村专辑，录音质量相当的好，貌似SACD版本被作为很多SACD机器的专用试音碟。乡村自然是RS1了……我的Gemini是专门的高阻版本，本来不对这套组合抱有太大的期望。拿来直接跳到第九首purple rain，没了在ra1上朦胧感，换来的是极高的解析，在提高了解析的同时，还保存了RS1那份特有的松软感，给朋友听，朋友连声说这是今天听到最好素质的耳机了。唯一不足的是，背景不够干净，会有一些轻微的底噪。

 

比较篇：

 

 使用10倍于Gemini价格的010b来做作为比较似乎有些不太公平，但在试听过程，发现我这台gemini的声底和010b及其相似，在整体的素质上虽不如010b，但某些素质，特别是中高频上，已经能和010b一较高下，音场虽然稍小，表现也算是极为出色了。另外需要提及的是，我的这个版本在密度上和010b相比有一定的差距。

 

在听完Gemini之后，再去听SOLO，原本感觉通透，明亮的SOLO是那么不自然。原谅我这么说，我本身也是SOLO用家，不可否认701在SOLO下的声音也是相当的耐听。但就是缺少那种自然的感觉。

 

整个试听，我也试着用DA11的耳机输出口直接和Gemini小小的AB一下，在gemini下，da11的耳机口显得相对干涩。

 

总结篇：

这次试听我最大的惊喜在于540G在GEMINI下的表现，余音绕梁，久久不能忘记。

而和我认为动圈极致组合010b+600比较下，我不敢冒然说有几成010b的功力，但聆听的感受已经非常接近了。

我的GEMINI是高阻版本，也是悲总之前试做的版本，据说是悲总亲自焊接，感谢：）在推低阻耳机的时候，确有少许的底噪。

另外说到我对gemini一个不太满意的地方，就是低频了，量感不是很足，我也打算配上一些量感更好的电源线来调整，据说新版的已经很好的解决了这个问题，我也帮朋友订了一台，到时候再PK一下：）

GEMINI的调试时间历时1年多，从小圈子的试做，到今天的量产（20台算不- -），希望看到gemini一直这样踏踏实实的走下去。成为国产的骄傲。

 

 

]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa20100gafh.html#comment Sat, 07 Nov 2009 10:35:08 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100gafh.html 2009年06月30日 http://blog.sina.com.cn/s/blog_55288aa20100eb61.html 知道MJ去世的消息是从早上的手机报上，无法形容自己的心情……

车上开着HIT FM，平常早间节目轻松幽默的风格被一种凝重和悲伤而取代。

耳边飘来他的Earth Song，心中竟有一些哽咽。

第一次知道MJ是小时候从街机的游戏里，还记得游戏的名字叫做月球漫步（Moon Walker），精彩的动作和极富动感的音乐，让我至今还历历在目。从那时起，我便记住了MJ。

我一直惊叹一个人能够如此的融入到音乐和舞蹈中，好像他的灵魂一样，挥洒自如，天衣无缝。

如今他已经离我们而去，前些日子在听说MJ的告别演唱会的时候，还暗暗的想象能够置身其中。没想到如今却只能是一种奢望了。

他的死也许对他真的是一种解脱，媒体和公众让他离开他喜爱的事业已经太久了，无数捕风捉影的丑闻如影随行，也许他再也承受不了了……幸好，他也终于无须承受了。

我们也无须再去追究所谓的真相了，MJ留给我们的，是一个执着，坚定，把生命和灵魂都献给了自己事业的背影。

ByeBye,Micheal jackson, ByeBye, King of Pop.

]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa20100eb61.html#comment Wed, 01 Jul 2009 15:24:03 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100eb61.html 漫谈游戏中的阴影技术 http://blog.sina.com.cn/s/blog_55288aa20100e2fk.html 随着硬件的越来越高端化，各种以前可望而不可及的效果越来越多的应用到网络游戏里。本篇文章是介绍目前游戏中影子的实现方式，它们的优缺点以及应用的场合。

一般来说，在游戏中，应用比较多的影子技术有三种，Projective shadow, Shadow map以及Shadow map.我们接下来便依次的介绍它们。

Projective Shadow

 

投影的原理可以应用在任意贴图上

 

就是我们通常所说的投射影子，它的实现比较简单，具体有两个步骤：

1．  以光源为视点，渲染有影子的物体到一张预备好的Shadow texture中。要注意的是，这里的渲染在计算投影的时候，需要把顶点从设备空间转换到贴图空间，以便于后面的贴图。

2．  渲染被影子覆盖到的物体，然后把影子覆盖到物体上。这里是整个Projective shadow的最为关键的步骤。通过上面提供的Shadow Texture，可以使用一个PASS把受影子影响的物体渲染出来。也可以根据实际应用通过Blend，使用多个PASS来渲染。在渲染Shadow Texture的时候，需要API来为它生成最后的贴图坐标。在DX中，你需要把D3DTSS_TEXCOORDINDEX设置成D3DTSS_TCI_CAMERASPACEPOSITION；同时把D3DTSS_TEXTURETRANSFORMFLAGS设置为D3DTTFF_PROJECTED。如果你使用OGL,可以把GL_TEXTURE_GEN_MODE设置GL_EYE_LINEAR, 同时设置纹理矩阵为投影纹理矩阵。

 

Projective Shadow原理简单，实现方便，对于硬件配置的要求很低，效果也不错。对于对影子效果要求不高的游戏来说，只需要不多的代码就可以加入。但是由于Projective Shadow是需要计算能被影子投射到的对象，需要根据影子Caster来计算出它所对应的Receiver，这个步骤当场景对象过多的话会大量消耗CPU时间。同时，对于场景中物体渲染的管理也是对于实时应用的一个挑战，我们必须小心的管理物体渲染的层次关系。

 

Shadow Map

Shadow Map是一种成熟已久的技术，对于它的原理，很多初涉图形学的爱好者都能够很清晰的讲出他的实现步骤。简单来说，它是一种基于图像空间的技术。首先它需要根据光源的位置作为视点把整个场景渲染出来以得到它们相对于光源的深度信息，然后再使用这些深度信息去决定场景中哪一个部分是处于阴影之中的。

                                          

判断点是否处在阴影中

 

标准的Shadow Map，在DX SDK中你就能找到它的例子，看起来它的实现也并不复杂。但不幸的是它的作用也只是停留在能够教学。换句话说，它一点都不实用，即使在例子中，你也能很容易的发现它的缺点。

首先它的精度不够，虽然DX的例子还能看得过去，但由于Shadow Map是基于整个场景来渲染的，也就是说，它会用一张贴图来渲染整个场景的影子。这样来说，用于存储信息的贴图大小就直接影响到影子的质量。小场景还勉强能够应付，但只需要碰到稍大的场景，影子就有可能出现很严重的锯齿，影响到影子的质量。另外深度缓冲的精度也是难于解决的，特别是当影子的Caster和Receiver很接近的时候，Z-Fighting的情况发生得非常明显。

当然Shadow Map也有自己的优点，实现方便，效率较高，易于理解等，尤其是由于它是基于图像空间的一项技术，可以用不大的代价就实现软阴影的效果。所以近些年来，很多图形学的学者也基于Shadow Map的原理提出了很多改进型的算法，Shadow Map也越来越多的应用到了大型的游戏中。我们要介绍的也是一种Shadow Map很重要的改进算法的思想――Perspective Shadow Map（PSM），需要注意的是，这种思想的本身也是不尽完美的。但是以它为主导思想，近些年来提出了不少新型的算法。

PSM是在当前摄像机的透视后的空间中计算中，用传统图形学的说法，就是归一化后的设备空间中计算的。它的基本想法是首先把场景映射到Post－perspective空间中，然后在这个空间中通过把变换后的光源转换到一个归一化空间里生成一个标准的Shadow map。

如下图，S是场景Bounding，L光产生的视锥，V是视锥，而M包含了所有从V到L的涉嫌。这个算法比较关键的是最后能够生成下图中黄色的区域H，H包含了所有Shadow Map所需要包含的空间。这也是生成Post－Perspective空间的最小Bounding。

 

有了Bounding之后， Post-Perspective空间的视点就很容易得到了。

根据以上的计算得到Post－Perspective空间的矩阵之后。其他的步骤就和标准的Shadow Map是一致的了。

标准的Shadow Map

Perspective Shadow Map

 

同样的视点，同样的贴图大小，使用PSM我们可以得到更加细致的效果。

但PSM也有一些缺陷，比如说影子的质量比较依赖视点，影子近处和远处所得到的Z分布差异过大等。近些年提出的TSM，LISPSM都基于PSM的原理使得这些问题得到了一些改进，也使得Shadow map更多的使用到游戏中。

Shadow Volume

Shadow Volumes技术是一种基于几何形体的技术，它需要几何体在一定方向的灯光下的轮廓去产生一个封闭的容积，然后通过光线的投射就可以决定场景的阴影部分（通常来说使用模板缓冲去模拟光线的投射）。

这种技术最大的优点就是影子可以精确到像素级别。影子的效果会很细致。但它也有一些缺点，首先对几何体有一定的要求（必须是闭合的），同时对于效率的损耗也非常大（高填充率）。

为了构造阴影体，我们需要从灯光的位置引出通过要投射影子物体的每个顶点，这些投射的射线组成了一个封闭的体积，任何处于这个体积中的点我们便可以认为它是被阴影覆盖。反之，处于体积之外的点便是处于光照中的。

 

处于阴影体中的物体才会接收到影子

 

通常来说，判断物体是否处在阴影中有两种基本算法：Z-PASS和Z-FAIL。简单来说Z-PASS算法是从视点引一条射线，当射线进入阴影体的时候，stencil加1，当射线出阴影体的时候，stencil就减1。这样的话，如果stencil的值在计算完成后为0，就代表物体不处在阴影中。对于Z-Fail算法，不同的是在渲染阴影体的时候，对于back face和front face的情况做了一些特殊的判断，当对于back face 的Z test失败的时候，stencil值加1，而对于front face的Z test失败的时候，stencil值减1。

对于构建Shadow volume来说，找出物体的轮廓线很重要。基本的思想就是找出所有朝向相反的两个三角形的共享边，最终组成整个物体的轮廓。

 

总结

本文讲解了目前主流的几种生成阴影的方式。总体来说，各自都有应用的场合。Projective shadow比较适合应用在对效率要求比较高，对影子要求不是完全真实的场景中。Shadow map比较适合用于场景中静态物体的影子渲染，它也能实现比较柔和的软阴影。而Shadow Volume更适合于场景中的动态物体，比如说角色，怪物，风车等。大家可以根据自己具体项目的特点和需求来选择合适的技术。

]]> flymemory 3D技术 http://blog.sina.com.cn/s/blog_55288aa20100e2fk.html#comment Wed, 10 Jun 2009 12:22:24 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100e2fk.html 关于数学以及程序员的职业生涯 http://blog.sina.com.cn/s/blog_55288aa20100c2qg.html 之所以有这么一篇博文，是因为我最近读到的另外一篇文章--浅谈程序员的数学修养。这篇文章比较系统的阐述了在国内被称为和妓女一样所谓吃青春饭的程序员这个职业和数学之间的关系。

长久以来，在中国越来越庞大的程序员群体，被大家看作不善言谈，邋遢，典型“宅男”的颓废形象。以至于我面试过的很多人，当问及他们未来的职业规划的时候，大部分都在憧憬在程序员岗位上混够足够年头以后能够干上管理。而究其理由，就是因为程序员是吃青春饭，还得一直追求先进的技术，太苦，太累。每当听到这样的言论，我只是一笑了之，是的，很多时候，有些问题不是能够用言语表达的。首先不说若干年以后，这些所谓的管理岗位位置够不够。单说性格，能力，大部分人就不适合做管理的。

话有些扯远了，上面一段完全可以当成我的一些牢骚。

工作这么多年，认识的程序员也算不少了，做游戏的，做安全的，做网站的，还有不少是MM程序员。老实说，除了个别在技术上很有追求，以及在技术地位暂时难以被人撼动的人以外，不少好的程序员都走上了管理的道路。说到底，这都可以理解，毕竟单纯的做程序，在地位和薪水上都无法达到自己所理想的高度。我想国内公司真正想在技术上有所突破的话，不妨也提高对技术岗位的重视，设置一些纯粹的技术岗位，谁说一个技术高手的薪水不能比管理者高呢？

专注于技术又大致可以分成两类，一种是往深度发展，一种是往广度发展。当然也存在两者兼有的，那就是真的牛人了。个人观点，当自己还是一个菜鸟的时候可以扩展自己的知识面，可以说越广越好，一旦找到自己的方向了，就必须往深度来发展了，简而言之，就是不要做一个该死的弹药车，要做一支来复枪。“一个大学生将来的作为与他的数学修养有很大的关系”。这句话可以应用到所有立志于在技术领域想要有所作为的人。不说其他的领域，在程序员这个行当里，数学不过关的程序员是一定成不了最好的程序员的。曾经也和国外的程序员一起共事过，如果一定要说他们什么比国内的程序员强的话，那一定是平均的数学水平了，一个已经固定的数学算法，他们都会反复去论证寻找最优的解法。

我们常常会去惊叹国外程序员做出来的系统的强大，以为他们掌握了什么新技术，有多么有用的经验，其实，那些都不是本质，本质在于，我们所打下的基石就已经远远落后于人了。

]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa20100c2qg.html#comment Wed, 10 Jun 2009 11:04:01 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100c2qg.html GDC 08见闻（一） http://blog.sina.com.cn/s/blog_55288aa2010095od.html    懒了这么久,该写些东西了.
   今年的2月,我终于有幸去美国参加了一直梦想参加的GDC,8天的美国之旅,我看到了很多,学到了很多,也有些许的遗憾.
   首先说说GDC吧,作为一个全世界游戏产业从业人员的大会,会议的组织,管理都非常非常的到位,各种服务都让人感觉到很舒服.参加会议基本没有太多的后顾之忧.信息提示,会场管理都还不错.我参加的是会议的第二部分,也就是演讲的部分.这部分大都是属于是各个公司推选出来的技术和管理的骨干来对自己公司在开发过程中用到的各种方法来讲解。也是大会最精髓的部分。
   和普通的游戏展一样，GDC上出风头的开发公司不是财大气粗，就是所开发的游戏如日中天。在我看来，这次GDC出尽风头的无非是两个游戏，一个是《德雷克船长的宝藏》，另外一个就是大名鼎鼎的《HALO3》了。在后面的叙述中，大家应该能很明显的感觉到这一点。
   首先是《德雷克船长的宝藏》，来GDC之前，因为自己没有PS3，并没有太多的关注这个游戏，但这个游戏和咱们公司有一定的渊源（原因是一直担任我们公司技术顾问的NOAH先生，也是这款游戏的技术顾问，去年他过来的时候，也给我们介绍了一些这款游戏的开发情况和技术）。
   说它出风头，是因为他们公司的课程多，并且听课的人也很多，不管美术还是程序的演讲，总是人满为患，以至于很多人听课的人还需要坐在过道上。程序方面有两篇演讲是值得听的，一个是《德雷克船长的技术》，顽皮狗的技术总监系统的介绍了在游戏中使用到的各种技术，包括渲染，物理，光影，工具等。另一个是《在德雷克船长中创建一个角色》，主要是专项介绍游戏中在角色方面和AI方面用到的一些特别的技术，讲课的是他们里面一个非常普通的程序员，这个程序员在自我介绍中说到自己加入顽皮狗公司两年，一直在做动画系统和一些AI相关的工作，这点起初让我感觉到不以为然，一个动画系统做两年这样的效率是不敢恭维的。。。但随着演讲的推进，这样的看法被慢慢转变成钦佩。。这一套动画系统从实时和环境物件交互，到可以在各种高度，各种形状的掩体后采用合适的动作来躲避敌人的攻击，其复杂度在我看来是不可想象的。他系统的介绍了他们的一些解决方案，走过的弯路，以及一些特殊情况处理的经验。
]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa2010095od.html#comment Tue, 27 May 2008 14:19:29 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010095od.html 无聊的广告 http://blog.sina.com.cn/s/blog_55288aa2010095nb.html  很久没来,是因为懒吧..
 先做个广告...
 http://www.flickr.com/photos/flymemory/
 没多少思想在里面,更多的是记录,慢慢的,我的感觉会上来吧
]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa2010095nb.html#comment Thu, 03 Apr 2008 15:55:38 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010095nb.html Smile Again http://blog.sina.com.cn/s/blog_55288aa20100806a.html     忙过了第一次对外技术封测，总算稍微能闲下来。说是闲下来，松口气，实际上也只是心理上的，每天还是要针对这次测试出现的问题进行反复的测试和修改。另人兴奋的是，我第一次到了这个阶段，有很多未知和值得探索的地方需要我去做，特别是对于游戏的玩法和设计的发掘，我第一次发现自己真正跳出了功能和实现的框框，去真正的做一些我们认为好的玩法，这让我重新有了真正做一个游戏的成就感。同样，玩家的反馈也给我了不少信心，他们验证了我们不少设计上的想法。
    除了这些积极的东西，同样也有不少消极面。。。公司对游戏行业的不熟悉，让游戏代理的路显得不是那么明朗，我也只是爱莫能助，现在我也做的，也许就只是把游戏做好，尽可能的保证它的可玩性和稳定性。
    不知道为什么，最近总受到一些白痴的骚扰，无聊的针对我们的团队和公司，漫天的谣言，但，希望你们下次能高明点。。。能让我能觉得有所挑战。
    希望，我不再和你们玩这场无聊的游戏。
]]> flymemory http://blog.sina.com.cn/s/blog_55288aa20100806a.html#comment Tue, 11 Dec 2007 15:02:05 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100806a.html Take It http://blog.sina.com.cn/s/blog_55288aa20100096o.html  
 
    突然心情很差。我始终相信人的任何一种心情都有道理，理性可以战胜所有情绪化。但我还是可悲的发现，有时候人并不愿去挖掘心中埋藏的秘密。有的时候烦恼的事情也会密密麻麻的来，就像一张网，很多洞，你却很难去选择一个去战胜它。
    基本上，我是一个保守的人。谈不上坚持原则,只是什么事情都喜欢往最坏的方面去考虑，这给我带来不少的意外，有惊喜也有烦恼。尽管我尽力去挖掘，去解析它们，可惜我的知识实在有限，更多的是徒劳无功，也许我越挖得深，它们就藏得越深吧。
    其实我很讨厌这种无病呻吟的文章，第一段是我3月份写的，这一年到现在最难熬的时间，还好，挺过来了，莫明其妙的还有些怀念那段日子，一段没有回头路的日子，很喜欢那种义无反顾的日子。至少它最大程度的改变了我。改变，总是很困难。
    图片来自我很喜欢的一部电影《Blood Diamond》，看了很久了，那种感觉仍然挥之不去，个人认为这是一部很男人的电影，贪婪，勇敢，逃亡，绝望和自我救赎构成了这部电影。莱昂纳多静静的躺在大山中，对他来说，这是最好的解脱。。。。
 
]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa20100096o.html#comment Mon, 23 Jul 2007 12:25:35 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100096o.html 关于场景管理 http://blog.sina.com.cn/s/blog_55288aa2010009ea.html 这两天由于工作的原因,又回头看了不少场景管理的文章.
有讨论FarCry,HL2的,也有针对WOW的场景管理方式进行的一些深入讨论.
除了HL2以外,我对FarCry和WOW并没用很多的研究.
HL2严格意义上就没有对室外场景进行支持.它的场景管理方式个人认为也并不适合目前的一些网游的制作.虽然我个人并不喜欢做网游....可惜做单机实在没饭吃..
大体上,几乎所有人都支持室内和室外采用QuadTree+Portal+BSP来实现整个完整的场景管理,而且这里每一种技术都非常成熟,并得到了广泛的应用,无须做太多的解释.
但从实现方式上,特别是制作方式上,大家存在这不少的想法和意见.主要的问题是由于中国的美术人员几乎都没有经历过BSP时代..而且连做一个符合Shadow Volume标准的模型都要再三解释,实在不要期望他们能在MAX里面真正建出符合标准的场景.最好的方式就是提供给他们CG编辑器,也无须讲解太多原理,从规格上就去限制住美术.但是..做一个成熟的CG编辑器谈何容易..哪个老板又愿意花钱给你去做这种不能带来直接经济效益的东西呢(不要跟我说自己业余做...你能做的很成熟我佩服你)?
我们必须用一种更简便的方式来达到我们的目的,老板高兴,我们也不用花太多的时间就可以达到我们的目的.
说了那么多废话,终于要进入正题了....=.=
国内不少人应该知道Torque这款便宜的引擎,而且鉴于中国程序员的无私的精神,相信已经人手一份了.很多程序员对于一款如此便宜的引擎不以为然,甚至觉得它一无是处..可是,你并没有真正去了解这款引擎.试问,国内有几款所谓的商业引擎能够做到把脚本编译器做到引擎里,并且和所有的引擎元素完整的结合起来,不要告诉我没意义,这对策划的意义不是一点半点(有问题的话欢迎深入讨论.)更重要的是,它以一个方便的方式实现了我们想要的场景管理.基本的做法是这样的:
 
室外场景我想不必多说,采用QUADTREE的地形管理方式,很多人都把它作为3D入门做的第一项技术.
真正重要的在于它对室内场景的处理,TORQUE编辑器本身并不支持室内场景的编辑。在Torque中,室内场景作为一个单独的实体(Entity)存在,和模型,场景物体一样,它被Torque称作"interior"。internior就是一个完整的BSP Tree，在torque里，程序员通过portal把各个区域分成一个一个的zone。在引擎中,Torque只是实现了BSP的加载渲染,它的室内部分采用了一款叫做Quark的免费CG编辑器,并专门为这款编辑器制作了导出插件,来导出自己引擎所需要的元素(例如材质,Portal),并且从原理上来说,DOOM编辑器和WORLDCRAFT导出的文件它同样可以使用.
从CG编辑器里把场景导出后,室内场景和其他的引擎元素(模型,角色)一样,是一个独立的实体,我们只需要把它放置在场景中就可以了.
在渲染的时候,先在地形上做一遍裁减,而一旦interior在渲染列表中,那么它在渲染的时候会获得外部的frustum并根据自身的Portal来对frustum做进一步的裁减,这样一层一层下去,最终得到了室外和室内场景相结合的效果.如果当前摄像机在室内,从内往外看的时候,只需要判断摄像机的Position,然后采用同样的裁减逻辑,对室外的地形和物体进行裁减.
 
写了这么多,也不知道有几个人能明白我的意思..欢迎任何人进一步的探讨,目前公司的引擎也实现了这个方法,从技术上验证了这个方法的可行性.只是没有大规模的应用(万恶的网游..).而且Torque对于编辑器的扩展也很好,对于自己引擎中Portal和材质等特定元素的完美支持,也显出了这种方法的灵活性.
BTW,这种方法比自己写编辑器会麻烦一些,但的的确确节省了程序员的工作量,而且,现在BSP渲染代码满天飞,你甚至不用去理解什么SECTOR,LEAF这样晦涩的概念就可以很轻松的把它们加入游戏,技术就是为游戏服务的,不是么?
 
以上只是解决了渲染的问题，到实际的应用中，我们还会面对更多的问题:
碰撞的问题,如果你的游戏可以允许基于逐三角形的碰撞，那么恭喜你，你已经解决了这个问题。。。
在编辑器中给室内场景中加入实体，一种简单的方式是让实体只是成为整个室内的一部分，附属在特定的zone上。裁减时根据Portal裁过的frustum来计算，虽然粗糙，但是却很有效。
]]> flymemory 3D技术 http://blog.sina.com.cn/s/blog_55288aa2010009ea.html#comment Wed, 21 Mar 2007 14:00:48 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010009ea.html 自我救赎 http://blog.sina.com.cn/s/blog_55288aa2010008g6.html 救赎是一个很宗教的词，之所以用它是因为最近又重新开始播放的《24 Hours》S6。
从我的理解来说，这个词一般用在人犯了很大的错误，或者是做了很多错事以后，需要上帝干的一件事。。。之所以要自己来做，那一般是因为自己已经很绝望了，不相信任何神明和命运。
我平常会玩WOW，这是一个网络游戏，和很多一知半解的社会学家所说的一样，它就像是电子海洛因。深知危害却不能轻言放弃。我自认不是一个意志很坚定的人，自然也抵挡不了这种诱惑。当然说这个和标题没有太多的关系。游戏只是实现了自己另外一种愿望。
从小就希望自己是一个考古工作者，去追寻那些古人的足迹。也曾幻想自己能够和古人一样，为未来的人留下一些值得关注的东西。但为什么走上游戏制作这条路，我也说不清。可能是我没有考古工作的耐心和潜质吧：）
做游戏已经将近5年了，从一开始懵懵懂懂对未来充满期待的少年，走到今天，道路似乎都不那么崎岖。天下没有免费的午餐，道路也不总是会平坦，就像一天早上醒来，突然发现世界变了，再也不是那个自己曾经以为的世界，自己的处世之道在在这个陌生的世界里显得那么稚嫩，那么可笑。人总是在自我怀疑和自我安慰中不断的冲撞成长，有这样的意识，也许生活能够快乐一些。但，不论你有怎样乐观的心态，始终都无法抹去你做过的，也无法再消除它们已经造成的结果。仍然怀念刚开始做游戏的时候和郭老大一起奋斗的日子，那让我受益匪浅，让我明白了什么是游戏，更重要的是，我明白了什么是理想。
一直单纯的认为做游戏就是一个追梦的过程,但事实却远远不是理想中样子。曾经认为自己离自己的理想那样的接近，换来的确是狂喜之后的失落以及对于不成熟行为的无限懊恼。。。没错，从某种程度来说，我成了背叛者，一个共同理想，共同兴趣，富有朝气的群体的背叛者。我想为我做过的负责，想面对面的和曾经一起奋斗的战友说抱歉。然而一切却显得那么无力，那么苍白。
无论怎样，生活都要继续，我也没有自我了断的勇气。前进的路上依然显得那样障碍重重，但我再也没有理由让自己继续堕落。
最后以尼采的话与同仁共勉。
“他沉沦，他跌倒。”世人一再的嘲笑，须知，他乐极生悲，可他的强光紧接这你们的黑暗。
]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa2010008g6.html#comment Wed, 17 Jan 2007 07:41:19 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010008g6.html 把C++对象绑定到Lua(一) http://blog.sina.com.cn/s/blog_55288aa20100068d.html 游戏中的使用脚本语言已经成为了一个标准应用。脚本语言能够在游戏开发中扮演一个重要的角色，并且让数据结构化，计划事件，测试和调试这些工作更加容易。脚本语言也能够允许像美术，策划这些非程序专家通过一个高层的抽象脚本来为游戏编写代码。这个抽象层的一部分也能够允许提供给玩家来定制整个游戏。
 从程序员的角度上来看，把一个脚本语言嵌入到游戏中最主要的问题是如果为脚本语言提供对宿主对象的访问（通常是C/C++对象）。在选择一个脚本语言的时候有两个关键的特性：嵌入相关问题和绑定相关问题。而这些是Lua语言的一些设计的初衷。可是，Lua语言并没有提供任何自动创建绑定的工具，因为这是出于另外一个设计初衷：Lua只是提供机制，而不是策略。
 因而，就有许多种策略可以用来在Lua中绑定宿主对象。每一种策略都有它的优点和缺点，游戏开发者必须在得到在脚本环境中所需要的功能需求之后确定最好的策略。一些开发者可能只是把C/C++对象映射成简单的数值，但是其他人可能需要实现运行期类型检查机制，甚至是在Lua中扩展宿主的应用。另外一个需要处理的重要问题是，是否允许Lua来控制宿主对象的生命周期。在这篇文章中，我们将探究使用Lua的API来实现不同的宿主对象绑定策略。

绑定函数
 为了说明不同策略的实现，让我们考虑把一个简单的C++类绑定到Lua中。实现的目标是在Lua中实现对类的访问，因此允许脚本通过导出的函数来使用宿主所提供的服务。这里主要的想法是使用一个简单的类来引导我们的讨论。下面讨论的是一个虚构游戏中的英雄类，有几个将会被映射到Lua中的公用方法。
class Hero{
public:
 Hero( const char* name );
 ~Hero();
 const char* GetName();
 void SetEnergy( double energy );
 double GetEnergy();
};

要把类方法绑定到Lua中，我们必须使用Lua的API来编写绑定功能。每一个绑定函数都负责接收Lua的值作为输入参数，同时把它们转化成相应的C/C++数值，并且调用实际的函数或者方法，同时把它们的返回值给回到Lua中。从标准发布版本的Lua中，Lua API和辅助库提供了不少方便的函数来实现Lua到C/C++值的转换，同样，也为C/C++到Lua值的转换提供了函数。例如，luaL_checknumber提供了把输入参数转换到相对应的浮点值的功能。如果参数不能对应到Lua中的数值类型，那么函数将抛出一个异常。相反的，lua_pushnumber把给定的浮点值添加到Lua参数栈的顶端。还有一系列相类似的函数来映射其他的基本的Lua类型和C/C++数据类型。我们目前最主要的目标提出不同的策略来扩展标准Lua库和它为转换C/C++类型对象所提供的功能。为了使用C++的习惯，让我们创建一个叫做Binder的类来封装在Lua和宿主对象中互相转化值的功能。这个类也提供了一个把将要导出到Lua中的模块初始化的方法。
class Binder
{
public:
  // 构造函数
  Binder( lua_state *L );
  // 模块（库） 初始化
  int init( const char* tname, const luaL_reg* first );
  // 映射基本的类型
  void pushnumber( double v );
  double checknumber( int index );
  void pushstring( const char s );
  const char* checkstring( int index );
  ….
  // 映射用户定义类型
  void pushusertype( void* udata, const char* tname );
  void* checkusertype( int index, const char* tname );
};

类的构造函数接收Lua_state来映射对象。初始化函数接收了将被限制的类型名字，也被表示为库的名称（一个全局变量名来表示在Lua中的类表），并且直接调用了标准的Lua库。例如，映射一个数值到Lua中，或者从Lua映射出来的方法可能是这样的：
void Binder::pushnumber( double v )
{
 lua_pushnumber( L,v );
}

double Binder::checknumber( int index )
{
 return luaL_checknumber( L,index );
}

真正的挑战来自把用户自定义类型互相转换的函数：pushusertype和checkusertype。这些方法必须保证映射对象的绑定策略和目前使用中的一致。每一种策略都需要不同的库的装载方法，因而要给出初始化方法init的不同实现。
一旦我们有了一个binder的实现，那么绑定函数的代码是非常容易写的。例如，绑定函数相关的类的构造函数和析构函数是如下代码：
static int bnd_Create( lua_state* L ){
 LuaBinder binder(L);
Hero* h = new Hero(binder.checkstring(L,1));
binder.pushusertype(h,”Hero”);
return i;
}

static int bnd_Destroy( lua_state* L ){
 LuaBinder binder(L);
 Hero * hero = (Hero*)binder.checkusertype( 1, “Hero” );
 delete hero;
 return 0;
}
 
 同样的，和GetEnergy和SetEnergy方法的绑定函数能够像如下编码：
 static int bnd_GetEnergy( lua_state* L ){
  LuaBinder binder(L);
  Hero* hero = (Hero*)binder.checkusertype(1,”Hero”);
  binder.pushnumber(hero->GetEnergy());
  return 1;
 }
 static int bnd_SetEnery( lua_State* L ){
  LuaBinder binder(L);
  Hero* hero = (Hero*)binder.checkusertype(1,”Hero”);
  Hero.setGetEnergy( binder.checknumer(2) );
  return 1;
 }
 注意绑定函数的封装策略将被用于映射对象：宿主对象使用对应的check和push方法组来进行映射，同时这些方法也用于以接收关联类型为输入参数。在我们为所有的绑定函数完成编码。我们可以来编写打开库的方法：
 static const luaL_reg herolib[] = {
  { “Create”, bnd_Create },
  {“Destroy”, bnd_Destory },
  {“GetName”, bnd_GetName},
  …
 };

 int luaopen_hero( lua_State *L ) {
  LuaBinder binder(L);
  Binder.init( “hero”, herolib );
  return i;
 }

绑定宿主对象和Lua数值
把C/C++对象和Lua绑定的方法就是把它的内存地址映射成轻量的用户数据。一个轻量的用户数据可以用指针来表示（void *）并且它在Lua中只是作为一个普通的值。从脚本环境中，能够得到一个对象的值，做比较，并且能够把它传回给宿主。我们要在binder类中所实现的这个策略所对应的方法通过直接调用在标准库中已经实现的函数来实现：
void Binder::init( const char *tname, const luaL_reg *flist ){
 luaL_register( L, tname, flist );
}

void Binder::pushusertype( void* udata, const char* tname ){
 lua_pushlightuserdata( L, udata );
}

void *Binder::checkusertype( int index, const char* tname ){
 void *udata = lua_touserdata( L, index );
 if ( udata ==0 ) luaL_typerror( L, index, tname );
 return udata;
}

函数luaL_typerror在上面的实现中用于抛出异常，指出输入参数没有一个有效的相关对象。
通过这个映射我们英雄类的策略，以下的Lua便是可用的：
 Local h = Hero.Create(“myhero”)

 Local e = Hero.GetEnergy(h)
 Hero.SetEnergy(h, e-1)

 Hero.Destroy()

 把对象映射成简单值至少有三个好处：简单，高效和小的内存覆盖。就像我们上面所见到的，这种策略是很直截了当的，并且Lua和宿主语言之间的通信也是最高效的，那是因为它没有引入任何的间接访问和内存分配。然而，作为一个实现，这种简单的策略因为用户数据的值始终被当成有效的参数而变得不安全。传入任何一个无效的对象都将回导致宿主程序的直接崩溃。

加入类型检查
 我们能够实现一个简单的实时的类型检查机制来避免在Lua环境中导致宿主程序崩溃。当然，加入类型检查会降低效率并且增加了内存的使用。如果脚本只是用在游戏的开发阶段，那么类型检查机制可以在发布之前始终关闭。换句话说，如果脚本工具要提供给最终用户，那么类型检查就变得非常重要而且必须和产品一起发布。
 要添加类型检查机制到我们的绑定到值的策略中，我们能够创建一个把每一个对象和Lua相对应类型名字映射的表。（在这篇文章中所有提到的策略里，我们都假定地址是宿主对象的唯一标识）。在这张表中，轻量的数据可以作为一个键，而字符串（类型的名称）可以作为值。初始化方法负责创建这张表，并且让它能够被映射函数调用到。然而，保护它的独立性也是非常重要的：从Lua环境中访问是必须不被允许的；另外，它仍然有可能在Lua脚本中使宿主程序崩溃。使用注册表来存储来确保它保持独立性是一个方法，它是一个全局的可以被Lua API单独访问的变量。然而，因为注册表是唯一的并且全局的，用它来存储我们的映射对象也阻止了其他的C程序库使用它来实现其他的控制机制。另一个更好的方案是只给绑定函数提供访问类型检查表的接口。直到Lua5.0，这个功能才能够被实现。在Lua5.1中，有一个更好的（而且更高效）方法：环境表的使用直接和C函数相关。我们把类型检查表设置成绑定函数的环境表。这样，在函数里，我们对表的访问就非常高效了。每一个函数都需要注册到Lua中，从当前的函数中去继承它的环境表。因而，只需要改变初始化函数的环境表关联就足够了――并且所有注册过的办定函数都会拥有同样一个关联的环境表。
 现在，我们可以对binder类的执行类型检测的方法进行编码了：
 
 void Binder::init(const char* tname, const luaL_reg* flist){
  lua_newtable(L); //创建类型检查表
  lua_replace(L,LUA_ENVIRONINDEX ); // 把表设置成为环境表
  luaL_register( L,tname, flist ); //创建库表
 }

 void Binder::pushusertype(void *udata, const char* tname){
  lua_pushlightuserdata(L,udata);   //压入地址
  lua_pushvalue(L,-1);     //重复地址
  lua_pushstring(L,tname);    //压入类型名称
  lua_rawset(L,LUA_ENVIRONINDEX);   //envtable[address] = 类型名称
}

void* Binder::checkusertype( int index, const char* tname ){
 void* udata = lua_touserdata( L,index );
 if ( udata ==0 || !checktype(udata, tname) )
  luaL_typeerror(L,index,tname);
 return udata;
}

面代码使用一个私有的方法来实现类型检查：
int Binder::checktype(void *udata, const char* tname){
 lua_pushlightuserdata(L,udata);  //压入地址
 lua_rawget( L, LUA_ENVIRONINDEX); //得到env[address]
 const char* stored_tname =  lua_tostring(t,-1);
 int result = stored_tname && strcmp(stored_tname, tname) ==0;
lua_pop(L,1);
return result;
}

通过这些做法，我们使得绑定策略仍然非常高效。同样，内存负载也非常低――所有对象只有一个表的实体。然而，为了防止类型检查表的膨胀，我们必须在销毁对象的绑定函数中释放这些表。在bnd_Destroy函数中，我们必须调用这个私有方法：
void Binder::releaseusertype( void* udata ){
 lua_pushlightuserdata(L,udata);
 lua_pushnil(L);
 lua_settable(L,LUA_ENVIRONINDEX);
}

]]> flymemory C++深度探索 http://blog.sina.com.cn/s/blog_55288aa20100068d.html#comment Fri, 22 Sep 2006 09:13:39 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100068d.html 夏日情怀 http://blog.sina.com.cn/s/blog_55288aa2010004os.html 不知道什么时候开始，很喜欢一个人漫步在黑夜里的感觉，空洞，寂静，一切都那么自然。

七月，北京，公式般的生活并没有因为炎热而改变什么。令人激动的世界杯算是枯燥生活中的一丝色彩。

然而，岁月仍然在无情的流逝，不论在哪，你都能够感受得到人世间的悲欢离合，浮躁的情绪总是会抹过一丝淡淡的哀愁。一个人置身在空荡的大街，微凉的夏风迎面而来，人们擦肩而过，仿佛世界对你来说已然无存。

这一刻，你就是你，没有哀伤和快乐，没有欲望和争斗，这一刻，你来得如此纯粹，仿佛已不再是那个你。美丽的夏夜就像母亲温暖的怀抱，而你，静静的，静静的，尽情享受这片刻的宁静...

]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa2010004os.html#comment Wed, 05 Jul 2006 11:31:46 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010004os.html 基于安全的设计（三） http://blog.sina.com.cn/s/blog_55288aa2010004or.html

结构化你的威胁模型

即使你是正在做一个简单的游戏，你也能在很多单独的攻击方式中快速的生成一个TM，而且TM的表示常常有必要利用结构化的表。简单的分类没有什么作用，主要是因为大多数的攻击方式都很难严格的归到一个种类中。

       很多人更多的使用攻击树（Attack Tree）【Schneier99】结构来构造他们的威胁模型。一棵攻击树通常都是以黑客特定的目标或者是动机为起点，每一个树节点都是一些让他们能够达到最终目标的一些操作。你很快就能构建出一棵树，因为大部分的操作都能从多种途径达到目标，并且因此你需要把主要操作的多种子操作都列出来。

       使用攻击树主要的优势有几点：

1．  是一个记录攻击信息，剔除多种攻击方式的重复的公共部分的一个非常有效的途径；

2．  在提供了良好结构的前提下，还保证了大部分攻击条目的无关性；

3．  在如何组织攻击条目的问题上，得到的结果通常都不会有太多的争议。

 

       并且，树形结构本身也同时记录各种攻击之间的联系的额外信息。它也使得威胁模型非常易读，因此你就能快速的找到特定组或者类别的攻击。它也同样提供了一种对细节抽象的模式，使用它你就有可能仅仅阅读每棵攻击树的最上面几层而并不需要详细的遍历树的每一个节点就能得到一个攻击方式的总体看法。

       它的主要的缺点在于它怂恿了限制性的思维方式，这将导致我们更有可能遗漏一些攻击方式。有一个通用的方法是把那些难于处理的清单做一次或者多次的迭代，然后把它们转化成攻击树的方式（比如说，你在不同组中同时把TM都做一次合并）。

       还有一个重要的问题是如何用电子文档的方式来编辑这样一个庞大的树型结构。有少数的团队使用了一些像WORD这样普通的工具来编辑树型结构。对于复杂的系统来说，结构化大型的威胁模型，使用这个方法带来的实惠远远大于使用它所带来的不便。如果文档无论从阅读还是修改方面都难到然人发疯的地步，人们就会放弃这个这个文档，对文档使用和更新的频率就会降低。从根本上来说，这会给整个过程毁灭性的打击，所以对于所有团队维护一个简单易用的表是非常重要的。

       一个优秀的系统的整个威胁模型通常是由多个无关的攻击树构成。实际上你也不需要严格的把所有的攻击都放到一棵攻击树中（这会经常需要一个强制性的对攻击描述）。

]]> flymemory 游戏项目管理 http://blog.sina.com.cn/s/blog_55288aa2010004or.html#comment Wed, 05 Jul 2006 11:30:26 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010004or.html 基于安全的设计（二） http://blog.sina.com.cn/s/blog_55288aa2010004oq.html 目标

就像【Schneier03】所指出的那样，如果你不知道由谁实施安全保证工作，并且你不知道这个工作被完成多久，那么“安全”基本上就没有什么意义。因此，我们的第一个目标是形式化到底什么是我们要表达的。这是一个分项目执行的过程，没有一个适用于所有游戏的答案。

       假定我们知道我们要试图保护什么，我们也需要一个方法来衡量我们的成果。现在的开发人员习惯于使用通用的制度去评估代码改进在一个项目的开发阶段：BUG列表，单元测试，可玩的演示等等。我们同样需要一个类似的精确的衡量方法来确定“安全度”。

       那么就会有一个成本的问题：如果每一个游戏项目拥有无限的时间和一个无穷的预算，它就能够简单的通过小心的编码以及广泛，严格的测试来达到目标。不过，假设我们的资源非常有限，我们就需要能够分级别的来决定把资源分配在哪里。我们也需要能够制定一个分级的“安全度”的标准并且让它们之间互相比较。因此，另外一个目标是兼容性。

       以上的两个目标都同样要求结果可以重现，不仅仅是最开始的测量者，其他人也需要得到同样的结果。我们不可能让整个过程都是可重复的，从一个安全的视角－在系统上被发现的攻击－是固有的。如果这种不确定能够严格的用一些方法来限制，那么它将非常有用。

       重新估计整个系统的每一个分支同样是很昂贵的，并且我们还需要一些方法来限制我们的对比。理想的解决方案将是一些标准的测量方式，所以我们只需要重新测试那些被改过的部分就可以了。

 

]]> flymemory http://blog.sina.com.cn/s/blog_55288aa2010004oq.html#comment Wed, 05 Jul 2006 11:29:12 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010004oq.html 基于安全的设计（一） http://blog.sina.com.cn/s/blog_55288aa2010004oo.html 一个系统的稳定性不会比它最薄弱环节的稳定性强多少，所以说单单在此系统的某几个方面上花大量的时间和金钱通常来说是一种浪费。你必须对一个单独的连接都进行检查，并对它们在安全方面又足够信心。到现在仍然有大部分的项目负责人甚至连他们有什么连接都不知道，不理会如何评估连接的安全。

评价安全的能力对于任何多人游戏和在线游戏都是相当关键的，然而现在的软件工程师却喜欢在游戏的完成阶段和发布测试后的阶段来改进安全问题，而不是在设计阶段。我们需要在项目最开始的阶段就把安全性加入到我们的游戏当中。

本篇文章将讲述如何将一个分成多个阶段的过程方便的加入到你的现有项目中。在理想情况下，你可以在项目的开始就根据这个流程来做，但是它对于已经开始的项目仍然是十分有效。这篇文章以及例子特别关注服务器的安全，但是也同样适用于客户端的应用程序。

我们需要以一个不安全的系统为基础进行完善，它的定义通常是从目前的威胁模型（TM）发出一个或者更多的攻击但没有被目前的安全策略（SP）所处理。如果我们构建一个完整的TM并充分的遵守SP，我们能够就通过简单的阅读这两个文档来计算出我们的系统到底有多安全。这就是我们这篇文章的主要目标。

TM和SP一起充分的验证了系统的脆弱性，它的解决方案和足够的信息可以用来快速的重建并且重新评估最初的假设和结论。

 

安全问题真的如此重要么

       安全缺陷像软件bug一样，在修复它们时候的耗费往往是根据发现它的时间长短而成指数增长。但是，安全缺陷引起的问题甚至会比普通的BUG更严重。例如，一个暴露你所有客户的信用卡细节的缺陷和在发布它之前你就改正它相比，所造成的耗费是非常巨大的。

       大多数的人通常把安全和加密，密码和认证策略联系起来，但是这些仅仅只是一些工具，而且并没有它们本身并没有和安全结合起来。从全局的观念来讲，关于游戏安全性的实现现在主要有三种方法：

1.       一直等到发布，再检查有什么缺陷，然后尽可能快的拼命发布补丁。

2.       委派其他的人（个人或公司）并且希望他们有足够的原因害怕因为碰巧解决了系统的安全问题而被责怪。

3.       对偶然的方式配置一个已知的策略，希望你可以应付过去并让它“破解起来稍微难一点”。

 

在几乎所有的情况下，在开发过程中修复安全问题过晚那将会非常昂贵和困难的。一个公认的常识是安全并不能逆向的添加，因为它简直太昂贵了；它需要从一开始就设计进来。如果你的开发过程没有在安全问题上考虑得很周到，你就有可能面临制作没有尽头的安全补丁的风险，而没有一个补丁能够完全的解决这些问题，当玩家伤心到在你的游戏里抓狂时，就会毁了这个游戏和玩家，而且将会直接导致很坏的评价并且减少销量。

从另一个方面说，也许你的游戏是一个大型多人在线游戏（MMOG），而且就像你的游戏世界里受到伤心的玩家影响而支离破碎，你的用户也将会成群的离开。更糟的是，这些漏洞中的一个有可能暴露你的客户的信用卡细节，造成财务和名誉上的双重损失，那就完全是另外一个级别的事情了。如果你的游戏服务器安全性不够，任何你拥有或者控制的－数据，硬件，带宽，甚至你的公司ID－都可能被轻易的毁坏或是偷走。

幸运的是，本篇文章要描述的过程简单而又经济，而且在一开始就会有很多优势。每一个游戏开发者－从专业的工作室到独立的爱好者－都能够简单并且有效的实施这个过程。

]]> flymemory 游戏项目管理 http://blog.sina.com.cn/s/blog_55288aa2010004oo.html#comment Wed, 05 Jul 2006 11:27:56 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010004oo.html 世界杯狂想 http://blog.sina.com.cn/s/blog_55288aa2010003xb.html 请注意聊天记录的后面一段。。。

 

2006-6-8  9:33:26  Sun  flymemory  哈哈
2006-6-8  9:33:36  flymemory  Sun  ?
2006-6-8  9:33:41  flymemory  Sun  怎么了
2006-6-8  9:34:03  Sun  flymemory  果然世界杯前不要跟中国队 热身
2006-6-8  9:34:17  Sun  flymemory  西塞 被废了
2006-6-8  9:34:31  Sun  flymemory  郑智进球中国1-3法国 亨利破门西塞重伤 
2006-6-8  9:36:04  flymemory  Sun  哈哈
2006-6-8  9:36:20  flymemory  Sun  血的教训
2006-6-8  9:36:27  Sun  flymemory  西塞在与中国队郑智拼抢后倒地受伤，无缘世界杯
2006-6-8  9:36:30  flymemory  Sun  也好
2006-6-8  9:36:38  flymemory  Sun  成全了谁啊
2006-6-8  9:37:14  Sun  flymemory  不知道
2006-6-8  9:37:43  Sun  flymemory  但是这个球郑智防守得还是不错的
2006-6-8  9:37:49  Sun  flymemory  http://sports.sina.com.cn/teamchina/bn/2006-06-08/0421671.html
2006-6-8  9:37:53  Sun  flymemory  看看视频
2006-6-8  9:38:03  flymemory  Sun  带Anelk我觉得不错
2006-6-8  9:38:30  Sun  flymemory  现在是亨利，萨哈，和特雷则盖
2006-6-8  9:38:43  flymemory  Sun  应该还要补一个啊
2006-6-8  9:39:33  Sun  flymemory  戈武？
2006-6-8  9:40:34  flymemory  Sun  有可嫩。。
2006-6-8  9:40:59  flymemory  Sun  带我去吧，我没代表中国国家队出场过。。
2006-6-8  9:41:16  Sun  flymemory  :D
2006-6-8  9:41:38  flymemory  Sun  没准还能进一个
2006-6-8  9:42:03  Sun  flymemory  有可能拿到大力神杯
2006-6-8  9:42:11  flymemory  Sun  挖
2006-6-8  9:42:26  flymemory  Sun  你赶快打电话给法国主教练
2006-6-8  9:42:32  flymemory  Sun  让他带我
2006-6-8  9:42:34  Sun  flymemory  他会找你的
2006-6-8  9:42:37  Sun  flymemory  不用我打
2006-6-8  9:43:02  flymemory  Sun  听不懂。。。
2006-6-8  9:43:29  flymemory  Sun  我的体力应该能够支持15分钟
2006-6-8  9:43:38  Sun  flymemory  好
2006-6-8  9:43:56  Sun  flymemory  你就当齐达内的替补
2006-6-8  9:44:14  flymemory  Sun  。。。为什么不是亨利的替补
2006-6-8  9:44:43  flymemory  Sun  我要罚任意球
2006-6-8  9:45:47  Sun  flymemory  亨利不需要替补
2006-6-8  9:45:57  Sun  flymemory  哈哈
2006-6-8  9:46:36  flymemory  Sun  你觉得我能够把亨利挤到替补席么
2006-6-8  9:47:03  Sun  flymemory  完全有可能！
2006-6-8  9:47:07  flymemory  Sun  我打15分钟首发，他再上
2006-6-8  9:47:52  Sun  flymemory  恩
2006-6-8  9:48:03  flymemory  Sun  那我去世界杯也不冤了
2006-6-8  9:48:12  Sun  flymemory  更能显示他的神奇，在0：5 落后的情况下力挽狂澜
2006-6-8  9:48:22  flymemory  Sun  。。。。
2006-6-8  9:48:30  flymemory  Sun  我是个前锋好不好？
2006-6-8  9:48:50  flymemory  Sun  怎么会导致球队0:5呢
2006-6-8  9:49:10  Sun  flymemory  怎么说也是10打11啊
2006-6-8  9:49:17  Sun  flymemory  0：5 有可能
2006-6-8  9:49:25  flymemory  Sun  。。。我半个都不算?
2006-6-8  9:49:45  flymemory  Sun  我实力很强地，完全有可能进球
2006-6-8  9:50:10  Sun  flymemory  :D
2006-6-8  9:50:38  Sun  flymemory  我跟你说，你踢点球都进不了，别人守门员都是世界级的
2006-6-8  9:51:02  Sun  flymemory  昨天齐大内面对安齐就射飞了点球
2006-6-8  9:51:18  flymemory  Sun  大哥，我不提点球
2006-6-8  9:51:40  flymemory  Sun  别人守门员，后卫什么的总有个失误啥的吧？
2006-6-8  9:53:00  Sun  flymemory  哈哈
2006-6-8  9:53:37  Sun  flymemory  当然中国队在拥有亚洲第一前锋和德甲射手的情况下4场未进一球
2006-6-8  9:53:51  Sun  flymemory  对方也不是没有失误
2006-6-8  9:54:18  flymemory  Sun  这不同啊，我有强大的后盾啊
2006-6-8  9:54:25  flymemory  Sun  没准一不小心就打个空门啥的
2006-6-8  9:54:32  Sun  flymemory  哈哈
2006-6-8  9:54:48  Sun  flymemory  放心吧，你会踢疵的
2006-6-8  9:54:53  flymemory  Sun  。。。
2006-6-8  9:55:46  flymemory  Sun  10个总能进一个
2006-6-8  9:56:42  Sun  flymemory  法国没那么强
2006-6-8  9:56:48  Sun  flymemory  我建议你加入巴西队
2006-6-8  9:57:03  Sun  flymemory  你后面是卡卡和小罗，边上是阿德
2006-6-8  9:57:23  flymemory  Sun  恩，为了我的前途我会慎重考虑
2006-6-8  9:57:34  flymemory  Sun  巴西队风格和我的更接近
2006-6-8  9:58:17  Sun  flymemory  卡卡和小罗可以给你创造无数机会，阿德可以把所有后卫都拉走
2006-6-8  9:58:24  Sun  flymemory  你绝对有机会射空门
2006-6-8  9:58:29  Sun  flymemory  就象胖罗
2006-6-8  9:59:15  flymemory  Sun  我就不能晃过守门员啥的？
2006-6-8  10:00:02  Sun  flymemory  不行，告诉你了守门员是世界级的
2006-6-8  10:00:34  flymemory  Sun  我是什么级的？
2006-6-8  10:00:58  Sun  flymemory  如果按照FM里面的算的话，你算是没有描述的那一级
2006-6-8  10:01:25  flymemory  Sun  也就是传说中的妖人？
2006-6-8  10:01:40  Sun  flymemory  不是，没有记录，查无此人
2006-6-8  10:02:06  Sun  flymemory  各项属性都是问号，派球探一看，都是1
2006-6-8  10:02:33  flymemory  Sun  那也不妨碍我成为妖人啊
2006-6-8  10:02:50  Sun  flymemory  恩，绝对妖，妖得让人目眩

]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa2010003xb.html#comment Fri, 09 Jun 2006 07:17:53 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010003xb.html 二难推论 － 博弈论的问题起源 http://blog.sina.com.cn/s/blog_55288aa2010003ln.html 我们总是会把自己置于一个困境中，不管这种困境是自造的，还是别人无心之失。但当你困惑的时候，在为进退维谷而两难的时候，你也许需要一种理性的方法来指导你作出理性的决策。
 
让我们来看一个经典的二难推论命题（The Book of Quesions, 1987）：“你和你深爱的人被隔开着关在两个房间中，两人身边个有一个按钮，而且都知道，除非两人中又一人在规定的60分钟过去以前按一下按钮，否则两个人都要被处死；而先按按钮的人可以保住对方的性命，但自己将被立即处死。你想你该怎么办呢？”
看起来这是一个非常残酷的命题，但是为却能为我们更好认识到博弈论在我们身边的应用。
当然，现实生活中的二难推论通常不会如此残酷。往往是由于我们的个人利益同其他人的利益发生碰撞，或者是同社会利益发生冲突而以各种各样的方式建立起来的。我们天天都面临着艰难的选择；有时候，作出选择的方式同我们期望的方式很不一样。由二难推论引出的内在问题虽然简单，然而令人十分困惑；是否对每一种情况都存在合情合理的行动路线呢？
]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa2010003ln.html#comment Fri, 26 May 2006 07:14:38 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010003ln.html 近期读的书（2005年5月份） http://blog.sina.com.cn/s/blog_55288aa2010003b5.html 最近在读两本书，《Unix编程艺术》和《志愿军战事珍闻》。
 
《Unix编程艺术》简直是一本讲述编程哲学的书，即便我并不是一位UNIX程序员，但是也为其精辟的哲学思想所折服。虽然是一本讲述编程的书籍，但在整本书中却找不到几行代码。而是极力的灌输编程的理念和策略。在我看来，整本书简直就是大师们对自己思维的一种阐述。所以强烈推荐给那些需要提升自己编程方法的程序员。同时推荐给把编程作为毕生事业的同仁，因为UNIX文化也是计算机行业最重要的一个分支。
 
《志愿军战事珍闻》是一本讲述朝鲜战争的书籍，只所以去阅读它，是因为对于这段历史的好奇。虽然我对此书的出发点持有怀疑，但至少它反应了一家之言，也许再过上百年，会有对这段历史的一个公正的评价。
]]> flymemory 感想和观点 http://blog.sina.com.cn/s/blog_55288aa2010003b5.html#comment Wed, 10 May 2006 08:43:55 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010003b5.html 游戏项目中的迭代开发 http://blog.sina.com.cn/s/blog_55288aa2010003a8.html 文章是同事翻译的，英国读项目管理回来的老大^_^我稍加整理，文中提到的RWPP实际上是一种软件工程的方法，类似于传统软件工程中的迭代式开发，但文中提到的理论比传统的方法具体并且实用了不少，而且非常适合以创新为目的的游戏开发。很多人问我，国产游戏为什么比欧美，日本的游戏差，从我被老美打击的经历来看。主要有两点，首先是他们对开发基础的重视，比如说数学，3维理论等，研究得相当深入；另外一个就是软件工程，我们中国的开发人员一直说游戏不需要软件工程，实际上老外对软件工程的要求简直到了令人咋舌的地步。

Rolling Wave Project Planning (RWPP) 是一种阶段重复式的项目开发手段，适用于新产品开发，信息系统和其他技术开发领域。对于创新性的工作，它是一种极好的，正规的开发手段。如果应用得当，RWPP将会把严谨的进程和灵活性平衡的很好。它适用于生命周期属于渐进式的项目。（螺旋形，原形进化等等）

项目执行中的差距

在很多的组织中，项目计划和执行过程结合的不是很好。过去的两年里，我问过千余位项目从业者“为什么项目会失败”并且收集数据。表一列出了关于项目计划，执行和控制（PMBOK中提到的项目管理过程中的三个）方面的一些主题并且提出了项目执行中的差距。

计划过程相当于一个过滤器，将复杂的，动态的，充满风险的“开放式”的组织环境系统转换成“闭合式”的项目系统。项目计划必须要在提供一个架构的同时，保持一定的灵活性，特别是那种含有开创性工作的项目，在很多情况下，这类项目的执行很难得出精确的答案或者指定具体的计划。我们需要一种“感知并回馈”的方法来应对变化和突然出现的变革。在这种环境中，项目计划必须在项目目标和实施能力（现有的资源和知识）上做一个平衡。


计划过程假设和开创性项目

在选择RWPP策略之前，项目计划组应该首先考虑到组织的climate和基本的计划过程假设。项目计划人可以能有很多假设，或者被组织行为所影响而建立某些假设。一般来说，这些假设有。

l         假设一：解决问题的最好方法就是把问题分解成小问题去处理

l         假设二：计划和执行是分开来的项目功能

l         假设三：未来是不可预测的；计划将会指导行动的过程

l         假设四：项目是简单的（深层次的调查发现，表一中所列出的差距很多情况像是因为项目计划者作了过于简单的假设）

这些假设就导致了一个直线型的，一步一步地问题解决方式。当然，有很多项目是紧凑的，定义很好的，并且是有规可循的（因此，以上这些假设是可行的）。但是，如果这些假设都不成立，那么项目经理就应该考虑一下使用RWPP。

开创性的工作有一个很大的特点就是探索，随着项目的逐步成型，需求就会一步一步地出现并且发展。例如，在建设-展示-评估-修改这种循环中，会有很多的努力会用在制作原形或者DEMO中来确定客户的需求。早期的，精确的项目定义很难应用到创新性项目中。

RWPP式工作分解结构策略

工作分解结构（WBS）对于项目管理来说绝对是一个最基本的技巧，它能为所有的计划和执行活动提供一个架构。一个失败的WBS将会破坏所有的项目计划，执行和控制工作。项目范围管理，或者说WBS的最终目标就是抓住项目需要且仅仅需要的所有工作。

WBS并不是一个进度，并且在项目组开始制定项目时间轴之前就应该被制定出来了。WBS只是一个工作的等级关系，并没有任何关于工作包之间关系的信息。WBS是项目进度制定，风险管理，成本估算和其他项目管理所涉及到的工作的一个输入信息。

RWPP的一个核心的前提就是在WBS的高层级使用时间段结构。并且在每一个时间段结束后，项目组开始制定下一时间段的工作计划。

表二说明了如何将工作进化的分解成工作包的。在RWPP中，计划者将用连续的计划编制波来实行精心细化的不连续的计划编制范围。


RWPP方法的应用

应用RWPP之前，项目必须进行一些基本工作，例如项目宪章（立项），项目概况。我列出了实行RWPP的程序并将在下边进行进一步讲解：

1.         从产品和项目生命周期的角度来评估开发策略

2.         制定time buckets

3.         高层估算

4.         细化第一层WBS

5.         基准线

6.         实施第一部分

7.         对下一部分重新计划

第一步——研究产品和产品开发策略的本质。评估生命周期策略和组织约束（例如受委托的方法）。评估Rolling Wave的优缺点，是否是最好的解决方法。

第二步——制定计划可视距离的标准，包括可视距离的数量，每一组的时间。我们也把这个计划分组称之为“time bucket”。类似的，你可以思考一下架船在未知海域内行驶。你的可视距离在二十英里左右，但是你认为对岸在九十到一百一十英里之间。你应该停船，并且依据可视距离重新确定你的航线至少五次。也就是将实际总距离被可视距离除。

第三步——根据你现有的知识和现在正确的假设，制定高层级的对于各个计划可视距离的成本和资源评估。不要试图在细节上钻牛角尖，也不要尝试从底层向上评估。那么你的团队就会深陷到细节的泥沼里。我会在后边纤细介绍“大块概况”

第四步——这一步将作为一个并行的计划会议进行实施。项目参与人为第一个项目计划可视距离制定一个个人的工作包计划，“从底层向上”。这部分包括评估工期，资源和成本。同时，用“从上层向下”的方法确定将会在以后的计划可视距离中出现的工作。在开创性的项目中，需求是日益增多，日益详细的。为了下一个可视距离的计划重新编制而评估一个工作包并且定日期。记住，工作包会在创造价值的同时消耗时间和资源。作为重新规划工作包的可交付成果，就是一个不断更新的RWPP计划。计划人能够修改日期和可交付任务之间的关系，或者检察现在项目完成的情况。

第五步——和你的项目执行人，赞助商，用户，项目经理和其他项目参与人一起为项目计划制定基准线。 这个制定基准线的过程需要包括事先的风险分析。修正三角制约（时间，资源，项目范围）并建立管理上的预案。

第六步——对第一部分的计划进行实施，并且完成重新编制计划的工作。

第七步——评估执行中的经验、教训，为下一个可视距离重新编制计划。

时间和成本的基准线有时候是很精确的，工作范围的基准线（WBS）是会变化的，并且反映不断增加的细节工作。

项目团队需要重复这个重新编制计划并执行这一循环。

大块概况和承诺的维护

分解目标和工作是项目计划的基础。有时候概况会很好的描绘出问题所在，但是有时候概况只能模糊的反映出技术或解决方案。在RWPP中，很重要的一点就是对概况进行大块划分并且进行管理。可视化模型，严谨的需求陈述，还有项目相关人的参与是几个重要的手段。

维持能量和热情也是项目管理很重要的一个任务。RWPP参与性的本质在这里也会发挥作用，因为这里会有一个在大的层面上对阶段工作成果的强调。

在一个案例中，我有五个项目组接受了一个表面上不可能完成的目标，并且将概况按两个月大块划分，与集中到最终目标不同，集中精力完成一些中间目标。这种简化会帮助项目组避免被动的玩世不恭的态度。

完成RWPP大约需要多长时间？

我看到过很多团队建立并开始实施RWPP在一个很短的时间内，比如一天，这样并不好，因为计划的质量和可行性是和你在计划编制时付出的努力成正比的。后续的计划编制一般会耗费几小时到几天。

另外项目在编制计划时候要按比例投入一定的努力在风险，复杂性和创新性上。

大多数的项目参与人会很习惯反复，“从来没有时间来计划，但是有时间返工”。编制计划经常会表现为压倒性的困难，RWPP能够为那些因为计划编制的困难而逃避编制计划的人提供一个简单的出发点。一个好的项目计划是付出最少的努力来保证组织最大的需要。

在似是而非中掌握RWPP

当精确的管理制约和不精确的数据同时存在时，人们会感觉到很不舒服（无论是个人还是集体）。在大多数案例中，我发现这种不舒服可以追溯为对过失的恐惧，和稍微有点不切实际的预期一个“正确”的计划是可能的。项目经理必须对维持项目计划编制中的规范负责。因为人们的不满和企业的惯性很容易创造出一种跳过重新编制并直接进行即兴式的实施当中。

有很多项目或者企业的计划是似是而非的。这种似是而非是达成“是”的必要条件。比如，量子物理认为能量和物质在亚原子层级上是相同。在组织中，人们必须有个人身份和团队身份。两个主要的似是而非的论点将在下辩论述，其余的会在表三中列出来。


l         方法（过程）VS结果——我们的项目团队需要完成一个结果，但是要达成一个长期的，稳固的结果必须要经历一个不断重复的过程。如果项目本身只有过程，那么这个项目其实没有完成任何工作。反之，如果项目本身只有结果，那么就会出现即兴式的实施，一个不稳定的结果，和建立在个人英雄主义上的组织文化。

l         知识（探索）VS任务（解决问题）——在技术领域这是一个比较普遍存在的问题，并且经常导致科学家和工程师之间的冲突。项目引入可以进度化的工作“任务”，但是开创性的项目必须要包含进攫取知识的概念（“你不能够为一项技术性的突破制定进度”）

要想完全的掌握RWPP，必须要能够理解这些似是而非的论点。一个帮助理解这种似是而非的论点的方法是画象限法，像表4那样。他取似是而非的论点的两极，并将两极的优势和劣势结合起来。箭头指明了管理这种似是而非涉及到的利害关系的先后顺序。一个“改革者”应该学会这种方法来在过程和结果中取得一个平衡。


现在，很多组织已经开始使用“项目管理办公室”。在很多案例中，那些办公室会强硬的期望他们有“正确”的方法，并期望其他人顺从。你经常会发现这种“方法论政策”并不是RWPP。他们更重视官僚的系统和程序上的控制。要想RWPP起作用，在过程中相互信任是达到一个好结果的本质。

在企业层级上更有活力的计划编制——平衡企业计划

项目实现企业战略的一个工具。通过一个又一个的项目，组织来寻找并达到他们既定的目标，但是机会经常会从单个的项目成面升级到企业层面。计划编制会促进组织内部的交流过程并使攫取支持成为可能。

RWPP就像一个“策略的泵”，会将机会推向企业的高层并让他们注意到。企业经常会在具体的项目身上发现很多机会。这个论调也从“民主的计划”支持了同时期的战略领导思想。

RWPP手段和很多企业的财务上的分配，还有预算编制过程是一致的。举例来说，有些企业使用five-quarter rolling wave的投资方式。

RWPP还和项目开发中phase-gate方法相一致，会为项目投资组合提供一个缓冲或出口。这一方法认定计划和环境不适静态的，而是根据客观实际时刻变化着的。

总结：在多变的环境下保持平衡

计划编制和执行技巧是项目经理资格的核心。合格的项目经理会从多方面对策略进行评估，并且去一个平衡点作为行动的标准。RWPP比传统的线性计划编制方法有很多优势，能够广泛的适用于创新型的工作。

在一个多变的环境中，项目经理必须要制定一个灵活的政策来回应动态的环境。就像浪潮冲刷沙滩一样，RWPP会推动风险和机会，创造价值和杠杆作用。它是动态的，鼓励适应性的，灵活的计划和执行。对创新性项目和那些主体范围经常变化的项目。潮流从来都不会完完全全的“是”或完完全全的“非”；他们有似是而非的特点。RWPP能够帮助项目经理提供一个灵活的方式来进行项目计划编制

]]> flymemory 游戏项目管理 http://blog.sina.com.cn/s/blog_55288aa2010003a8.html#comment Mon, 08 May 2006 05:47:21 GMT+8 http://blog.sina.com.cn/s/blog_55288aa2010003a8.html 无病呻吟 http://blog.sina.com.cn/s/blog_55288aa20100031o.html 最近无聊到了一定的程度。。。把《魔戒》三部曲的书又看了一遍。。。看完了，又是无比的茫然。
有时候阅读文学作品真是打发无聊时光的最佳方法。当然，说到文学作品，每个人都会给我列出它的无数好处，什么陶冶情操，增加对生活感悟之类。。
当然除了一些古代的一些文学巨著以外，我们现代人也在创造着属于自己这个时代的文学，并深深为之而陶醉。。
如果我要说文学不好，我肯定会被无数人追着砍。。。但我对文学的态度始终不会变－文学其实说白了就是古老一点的肥皂剧，无数人借以释放或者说寄托自己对美好愿望的憧憬和对丑恶事物的厌恶，它被人们所需要。
但要说得难听一点，文学就是无病呻吟，是一种人类释放情绪的极端方式。国家要发展，社会要稳定，自然就要打发那些无聊的闲人，期待他们之间引起共鸣，进而一起无病呻吟。即使到了世界末日，还是有很多人充满希望。。。期待吧！小说中的那个救世主。
]]> flymemory 无厘头 http://blog.sina.com.cn/s/blog_55288aa20100031o.html#comment Thu, 20 Apr 2006 11:47:53 GMT+8 http://blog.sina.com.cn/s/blog_55288aa20100031o.html