06
May 12

本博方针说明

只发本人原创文章,欢迎转载但请大家注明出处。基本保持至少每周一文的更新频率。内容主要是游戏制作相关的,包括引擎开发,图形学,工具制作,项目管理,读书笔记等。


03
Nov 13

Last of Us的光照技术

最近一年异常的忙碌,博客更新就耽搁下来了,现在总算有时间了。还是继续保持每周一篇的分享吧。先来一篇SIGGRAPH2013中比较实用的,由Naughty Dog的二号工作室带来的Last of Us中用到的小技巧分享。这个游戏前不久也买了数字版,虽然也许是不喜欢打僵尸,个人觉得游戏性上不如Uncharted,但是画面还是非常漂亮的,技术和美术的结合非常好。

写一下最感兴趣的部分,解决光照图接缝问题的Trick

Last of Us也大量使用了预烘培光照图技术,并且也遇到一个经典问题,就是一个模型在3D空间连续的面,实际上在2D的UV空间里面是不连续的,这样烘培之后的光照图就会有硬边出现。
Photo & Video Sharing by SmugMug
解决办法出人意料的简单,虽然不是物理正确的,但是也足够了。就是在这种会被分离的三角形边上定义一系列的焊接点,由于需要的是让纹理空间中相同的焊接点位于不同位置的采样点的值相同,所以定义一个Error Function为

\(E_i=(C_{i0}-C_{i1})^2\)

接下来的工作就是如何让整个光照图中所有E最小化。用经典的最小二乘法即可,有很多现成的库可以用。比如这个Eigen。大致想了一下实现方法,因为我们现在的贴图平铺算法也是自己实现的,而大部分模型美术都是依赖工具自动平铺的,人工干预的并不多。所以这个焊接点的标记也可以在平铺算法中自动标记,这样集成这个算法到我们现在的GI烘培流程中并不太困难。以后也许还可以分享一下具体实现的效果。
Photo & Video Sharing by SmugMug
相同的思想也能用来减少3D LUT后期算法的量化误差,通过对PS中的图像和实际的IN-GAME图像使用最小二乘法修正用于后期处理的Volume Texture。可以保证IN-GAME效果和PS中差别不大。
Photo & Video Sharing by SmugMug
总结一下,光照图和静态烘培技术对提高画面品质作用非常大,但是必须要技术和美术的密切结合才能做到出效果,并且需要一套能够实现这些定制渲染算法的工具。虽然开发和维护成本很高,但是确实是衡量一个团队是否有自己的核心技术的标准。现在的通用引擎非常多了,像Unity3D之类的更是以极低的价格集成了大量的中间件。但是从另一个角度来说,能否用好这种引擎,还是要看团队的内功。建立自己的工具管线才是提高制作效率保证效果的王道。


15
Feb 13

关于小型研发团队内部沟通的一些思考

游戏开发本质上是一个跨学科的大型协作项目,不同知识背景和思维方式的人在一起完成一个复杂项目想着就觉得很有挑战性, 最大的困难恐怕就来自沟通了,不少公司基本都会陷入会海之中不能自拔(当然之前公司也遇到过以马拉松会议为乐趣和权利象征的制作人,这就是另外的问题了)。但是依靠强大的体能(比如每天工作18小时,一周七天)。也能杀出一条血路来,不过这实在太不健康了。之前也写过相关的博客,这次再整理一下。

基本上我们需要的是三种不同类型的沟通工具

1.快速/实时的信息交流,可以是当面的口头沟通,也可以是任意的即时聊天工具,但是这种交流不适合内容的归档和后续的查阅。

2.非实时/特定话题的持续深入讨论,这个需要能支持交互性比较强的群体讨论工具,并且要能方便的进行归档和追溯。有了这个工具,很多以前用会议讨论的话题,可以用异步的方式进行,节省大家的时间和精力。并且可以有一些更深入的思考,应该能提高讨论的质量。

3.信息的沉淀/整理,也就是协同写作平台,比如各种制作规范的整理和演化。策划最新的设计文档唯一的发布平台。

对于1来说,随便一个聊天工具都可以满足需求,不继续讨论。从2开始,这种需求在以前的公司,一般是通过无尽的会议完成的,同时会产生大量群发的垃圾邮件(主要目的是为了日后相互推托责任时取证之用)。现在看来是效率极其低下的。并且很大程度上并不能真正完成任务。所以一定要革新这个流程。虽然说引入新工具就能一下提高效率的想法看起来有些不现实,因为工具代表的是一种理念,如果无法很快理解就没法真正把工具用起来,不过小团队可能真的能很快的适应新工具带来的流程变化,从而改变做事方法吧。所以这几天乘着春节假期,一直在找有没有适合的,看了很多,最后发现discourse也许是一个不错的选择,下面介绍介绍次世代讨论组框架discourse吧。

discourse是由问答网站Stackoverflow和StackExchange的联合创始人,同时也是著名博客Coding Horror的博主 Jeff Atwood发起的一个开源项目,是一个“100% open source, next-generation discussion platform built for the next 10 years of the Internet.”。在这篇博客里面,Jeff讲述了Discourse的缘起和核心团队的背景。而在Discourse的主页,有详细的特性说明,让我们看看比较关键的革新:

  • 扁平的信息流形式组织帖子,而不是传统的按页面的形式,不需要手动翻页,只需要不断下滚动就会自动刷新出后面的帖子
  • 帖子不是按板块进行分类,而是通过用户自定义的标签进行自动聚合,更有灵活性,但是还是需要前期引导,避免分类过乱。不过一开始可以不提供过多的分类,而是让分类标签慢慢随着讨论平台的成长而成长。
  • 更好的讨论机制:可以用@语法提到其他用户,方便讨论。其他人引用或者回复你的帖子,也会自动接到通知。一个帖子一共有四种通知模式:

   

  • 帖子的分支机制,如果出现偏题的讨论,可以很方便的开一个新帖子,同时能保持新旧帖子的关联性。方便以后来回追溯。结合本身的多元的通知机制,对研发内部讨论平台来说特别适合。

   

  • 其他的一些特性:帖子信息实时更新,不需要重新刷新页面,新帖会出现在顶部。外部链接可以自动展开。直接拷贝粘贴或者拖拽就可以上传图片

从上面的特性来看,确实是比较吸引人的讨论组工具平台。目前discourse已经进行了一年的开发,并且获得了First Round、Greylock 以及 SV Angel的风险投资。盈利模式是提供便宜的托管服务和企业私有服务器定制服务。因为在Github上提供了完整的源码,所以自己搭一个应该也不麻烦,顺便还能学习学习现代的Web前后端技术(Rails/Ember.js/Redis/PostgreSql)。看上去很好,准备年后搭起来试试。

对于第3点需求,也就是协同写作平台,目前看来似乎还是只有Wiki比较适合,但是MediaWiki之类的传统Wiki确实不太友好,看来看去,最后发现atlassian的Confluence可能是一个比较好的方案,虽然要花一点钱,但是易用性上巨大的改进还是值得了。Confluence的客户列表:

主要特点:

从一个Dashboard作为入口,一个项目的文档被放置在不同的Space中,Space可以赋予不同的权限,以便区分内部和外部文档,一个Space包含了两级的页面结构,不同Space中的Page,可以通过标签来进行再次的聚合。方便搜索。页面的编辑非常方便,这也是比普通Wiki强大的地方。可以通过内置的宏系统很方便的嵌入图片和视频以及各种动态内容。感觉使用上会比Wiki简单不少。另外考虑到我们的Bug和问题管理系统也是他们家做的JIRA,原生的整合功能还是很方便的。


08
Oct 12

博客重开一周年了

不知不觉上一篇博客已经是快一个月前写的了,所以这个题目多少让人有点不好意思。但写博客是需要平静的生活的,最近一个月来,团队发生了一些事情。几乎没有心情继续保持每周更新博客了。这个状态估计还得持续一段时间。但是不管怎么样,用博客和照片记录自己的成长和生活的习惯是一定会坚持下去的。从去年10月重开博客到现在,刚好一年。一共写了57篇,考虑到大部分博客更新频率都大于120天(来源在这里:Technorati)。所以给自己打个及格分吧。

不管从什么角度,这一年也算是标准的Gap-Year。工作上没有什么重要的事情或者说进展吧。反而多出不少时间来读书和写博客。前几年跑得太快,魂都丢了。生活上,恋爱十年今年终于有时间带老婆去了一次日本,虽说是“穷游”但还是很有纪念意义的,不过要完成当年大学里许下的各种目的地还是很艰巨的任务(丹麦的古堡可没那么便宜啊)。另外值得欣慰的是今年开始认真的研究摄影技术,至少个人感觉进步还是比较明显的,比如这次日本的照片,我就动用了计算机图形学的高级知识进行后期处理,得到了不错的效果。并且最近开始把所有照片逐步托管到专业的网站上(Smugmug!)这样我就再也不担心丢失照片的问题了。这次国庆回家展示照片都是把笔记本外接到家里的大电视直接用Smugmug的幻灯片功能进行的,效果非常理想。不过暂时还买不起更好的相机让我还是感到有些遗憾。

至于工作上,这一年也许最重要的收获是意识到创业团队成员之间,即使只有一个人开始玩政治,耍心计,基本上这个团队完蛋是迟早的事情。就像这篇尸检报告说的:“把联合创始人之间的关系比喻成婚姻,几乎都有些陈词滥调了,但却是不争的事实。在创业阶段,你和TA见面的时间、和TA协作的时间,要比生命里的任何人都长。如果关系紧张——你们不能好好地搭档,也无法在事业起伏里相互激励——那公司估计也活不长了。不幸的是,你所能做的,只是在确定和TA朝创业目标前进之前,好好地把TA看个清楚。”很遗憾,我们的团队就出了这样的人,这就是成长过程中必须付出的代价吧。大家一直埋头做事,却没有好好看人,所以说“读万卷书,不如行万里路”。学会看人是第一步,做人和做事是分不开的。一个私心很重,贪图小便宜,没有诚信的人,绝对不是一个能够一起走下去的伙伴。发现这样的人,最好的办法不是妥协,而是远远的躲开,重新开始。还好,我们及时的做出了正确的决定。至于其他的,我不准备再多说什么了,让时间来证明一切吧。现在最重要的事情,就是尽快调整好心态,确保一切走能快速走上正轨。当然作为一名严肃的程序员,一想到有这么多有挑战和有趣的问题等着我去解决,并且会议质量和方式终于有望得到本质性的改变时,还是感到十分欣慰的。


13
Sep 12

Valve的故事

今年4月份,因为偶然的原因,订阅了Valve的博客。一路看下来越发觉得这真是一家神奇的公司。最近纽约时报也已Game Maker Without a Rule Book为标题做了报道。当然EA也一直表现出对Valve强烈的收购欲望。对于大部分中国玩家来说,Valve最有名的作品肯定是CS啦。但是很多人可能不知道,Valve的网上游戏发布平台Steam,已经占据了PC游戏数字发布市场70%的份额。Steam可以看作是游戏发行界的iTunes,03年开始运营,最开始只是想作为Valve自己游戏的数字发布平台,到05年开始,陆续有其他游戏进驻,功能也越来越强大。最近甚至加入了一种适合电视机操作的叫做BigPicture的界面。除了软件,Valve最近也开始自己搞硬件了。Michael Abrash(搞图形的老程序多半看过他的Black Bible吧)在博客上写了很多构想,看起来非常有意思。这家公司创办16年了,没有外部的股东,是一家私人持有的公司,所以可以没有股价和盈利的压力。可以不公开财务状况。如果按37signals的说法,这是一家典型的“慢公司”。不过在公司组织方面,Valve显然走得更远,300人的公司,运营着Steam这样的平台,却号称没有管理层的存在。按2012版的员工手册的说法,公司的组织是完全扁平化的,这里是一副员工对公司组织架构的想象图:当然这并不是说Valve内部没有任何结构,根据项目的不同,员工会自发的形成组织。这也是我最感兴趣的部分,下面的内容主要来自Valve的员工手册和他们的经济学家的博客文章,以及M.Abrash讲述的自己在Valve体验的文章。讲一讲我理解的这样的自组织结构是如何工作的。以及我觉得有疑问的地方,因为光从这些描述来看,Valve简直是太过理想的公司了。以至于我们很难相信这样的公司真的能存在。

起源

Valve的创始人GabeNewell还在微软的时候(他把自己称作Windows前三个大版本的制作人)曾经做过一个调查,当然是90年代早期的了,发现Windows是用户最常安装的第二大软件。第一名居然是一家只有10多人的小公司(id)开发的游戏-Doom。这件事情对Newell冲击很大,他开始重新思考现代公司的组织结构,传统大公司的阶层结构很适合不断重复做一件模式固定的事情,每个雇员都是一个螺丝钉。并不需要太多的创造力,没有决定公司战略的权利。决策是少数人掌握的。大部分人只是执行。但是对于软件行业来说,最大的价值来自于创新和设计。而不是生产。由于开源和很方便的知识获取。山寨一个软件是很容易的事情,但是只有原创者才能获得最大的价值,比如愤怒的小鸟从程序实现角度很简单,但是第一个把这种物理元素引入平板和手机创造出可玩游戏的公司显然能获得最多的用户。所以未来的软件公司的关键在于催生这种创造力的组织结构。从另一个角度来看,就是公司层面如何决定资源的分配,从而产生最大的价值。从历史上看市场经济是资源调配最大的革新,给资源定价,让市场以去中心化的方式自动决定最优的配置。但是矛盾的是,市场经济中的实体-公司,还是采取的中央决策的模式。这就是"market-free-zones"。所以自然能想到的问题就是,如果公司内部的组织也是市场模式呢?是否能有组织可以达到哈耶克口中的"spontaneous-order"?如果人人都有权利决定自己做什么事情,是不是大家的创造力会被激发出来,从而在公司层面产生更大的价值?如果大家都自由决定自己的时间如何分配,是不是最好的项目就能自动获得最多的资源?关于Theory of the firm维基百科上有一个专门的页面。Valve可以看作是公司组织结构的一次改革尝试,这个过程已经有16年了,看上去产出还不错。

组织架构

没有正规管理结构的超扁平组织。按M.Abrash的说法,这种组织结构是如此独特,新员工基本上要花6个月才能接受这个现实:公司里没有老板,没人告诉你干什么,没有固定的经理的角色来评估自己的工作,加薪什么的是大家相互投票决定的,如果说Google、3M之类的公司给员工20%工作时间做自己感兴趣的任意项目,那么Valve其实是100%时间做“个人项目”,也就是完全由自己去挑选项目。对员工来说,这就像一个自由市场,自己付出的时间需要给自己带来最大的收益,就要寻找靠谱的项目,那么最好的办法就是(1)和老员工交流,(2)观察其他人的行为,(3)了解各个项目的具体信息帮助判断。这样就在公司内部形成了类似市场经济的资源配置体制。局部最优带来全局最优。

如何做决策

每个员工都是决策者,如果有好的想法,自己先做原型,拿出计划和文档给其他人看,只要能够吸引到其他人加入,就能启动起来获得公司资源。公司所有信息对员工都是公开的(比如所有产品的源代码对所有员工都是开放的),所以员工能参与到所有决策过程中去。如果说自由选择项目还比较好理解,那么决定公司投放资源做新东西也是等待某个员工来“自下而上”推动,就让人觉得很惊讶了。但是纵观Valve的公司发展史,他们确实是在不断做对的决策,每次都能让公司更上一层楼。这说明Valve这样的利用群体智慧做决策,在信息能够自由流动的组织中,确实能够起到鼓励创新的作用。并且在手册中也提到,Valve会不断的检验决策的正确性,虽然也有错误的决策,但是很快就能纠正,可惜没有更多的细节。可以说Valve的决策模式是The wisdom of crowds的典范。心理学和行为经济学的研究早就证明,当一个决策团体有一个成员非常强势,并且和其他成员有信息不对称的情况下。讨论问题往往是没有效率的,很难有创新的想法。可见信息透明是多么重要。Valve如果真的如这些文章和手册所述,能够做到这种程度的公开,那么一群没有私心的人聚在一起,大家彼此已经默契的配合了很多年,怎么可能做不出伟大的产品?

绩效考核

Valve的绩效考核和薪资调整都是Peer-Review的形式进行的。主要说下Stack Ranking,分为4类标准,大家相互之间打分,综合之后就是员工对公司的总体的贡献,这个Rank用来决定员工的薪酬待遇如何调整。确保员工的产出可以获得匹配的物质回报。顺便说一下Valve的员工平均创造的价值比Google,Amazon,Microsoft都高。这个4类标准是:

  • Skill Level/Technical Ability:这个指标是由工作的技术难度决定的。也是技术深度的体现
  • Productivity/Output:完成了多少可发布的工作,不管是对内的还是对外的,只要是对公司有价值的产出
  • Group-Contribution:对团队的贡献,这些贡献主要是指对工作流程的改进,提升工作效率,招聘,完成好的工具等
  • Product-Contribution:这是除了本职工作之外的更偏向产品层面的贡献,比如对顾客行为的预测,在发布阶段的可玩性测试,帮忙发现Bug之类的

不过由于公开的员工手册并没有包含这个绩效体系的全部细节,很多内容只是说在公司内部的Wiki里面,我们发现所有公开的Valve模式的文档并没有提到Valve是如何解雇员工的。员工相互打分并不会涉及谁被淘汰?难道Valve的招聘是如此成功,所有人都能很适应这样的环境,人人都能保证对公司持续的贡献和成长,以至于没有人会被淘汰掉?所以这个流程也就没有必要提了?

为什么Valve能这么做

  • 从一开始Valve已经是一个盈利的公司,没有经济压力,可以花大价钱雇最好的人,这样的人基础素质本身就是很高的,Valve在员工手册里面明确说了,喜欢T型人才,即广又专的人。
  • Valve是由Newell自己全资持有的,没有外部股东,所以没有上市的压力,没有为了增长而增长的压力。Valve的IP都握在自己手里,对几家巨头(Vivendi,Blizzard)的版权官司都打赢了
  • 半条命系列给Valve带来了巨大的声望和影响力,所以他可以不用在乎Time-To-Market和开发成本(大家甚至造了一个词,叫做Valve-Time,指Delay的时间)。只需要专注于边际效益最大的创新产品。所以可以允许员工去自己挑选项目,去试错。
  • 300人也不算很大的规模,并且软件开发和游戏开发是创造性工作,和体力工作计件工作并不一样,这个行业的人真的喜欢自己做的事情,更有激情,更能自我管理。所以没有强大的管理结构并不会造成很失控的情况,可以放心让大家相互监督

参考文献


05
Sep 12

日本旅行游记汇总(更新完毕)

本来想转载领导的游记的,不过似乎QQ空间的外链很难搞,所以还是直接在帖子里面引用吧:

  1. 日本旅行-准备篇
  2. 日本旅行-关西之大阪
  3. 日本旅行-关西之奈良
  4. 日本旅行-关西之京都寻访
  5. 日本旅行-东京之吉卜力朝圣
  6. 日本旅行-北海道之函馆
  7. 日本旅行–北海道之札幌
  8. 日本旅行-北海道之富良野/美瑛
  9. 日本旅行-北海道之小樽
  10. 日本旅行-归程

另外,最近准备把照片的备份和分享服务从Flickr迁移出来,主要原因是Flickr的速度和对雅虎未来的不信任。对比了很多家,最后还是决定搬到Smugmug上去。这是一家02年就成立的,专注于家庭照片分享和备份的网站,无论是上传还是浏览速度都飞快,并且不限制照片的数量,也能保留高质量原始照片文件,作为备份之用。公司的理念非常简单但是很有力量,让人看了觉得把珍贵的照片托管在这里很放心:

Most Internet companies dream of selling to bigger ones, and getting rich. We do not. We dream of an independent company devoted to nothing but your priceless photos. A company that backs up your precious memories so they are safe and sound. A profitable, debt-free company. That earns your fanatical loyalty. We are living that dream.

这是他们核心团队的照片,蛮有趣的:

最后,这次日本之行的大部分照片我都传到这个相册中了。大家看看体验如何。


26
Aug 12

旅行的照片

这周刚结束11天的旅行,还没有缓过气来,没状态写技术文章,就分享一些照片吧,这次一共照了2000多张,不过水平有限,能看的也就400张左右,感觉这次构图虽然有进步了,但还很差啊,一定要继续努力。不过这几天处理照片还是挺有趣的,写ToneMapping的Shader是一回事,用这个理论来处理照片又是另一回事了。这次只传了很小一部分到flickr上(主要是还没有想好要不要升级成付费帐号)。图片点击之后可以链接到大图。总的来说,这次因为是自由行,所有事情全部要自己安排(不得不说一下我家领导的计划做的真好!),虽然很辛苦,但是收获还是很多的。近距离的观察日本还是让人很感慨的。留到以后游记写吧。

———————————

先从风光开始,下面几张都是在美瑛照的(刚才看新闻这地方好像地震了,不过只有6级)。

IMG_8074_5_6.jpg

个人最喜欢这张,层次很丰富,云层的光感也比较舒服。

IMG_8066_7_8.jpg IMG_8073_tonemapped.jpg IMG_8079_tonemapped.jpg这张做了色调映射,喜欢树的剪影效果 IMG_8100_1_2.jpg这张因为是放在草堆上照的,所以前景不太好,但是云很漂亮,所以还是留下了。 IMG_8105_tonemapped.jpg这张是在住的旅店前面拍的

IMG_8106.jpg因为住的美马牛车站旁边6点以后就没吃饭的地方了(汗。。。),所以晚上坐火车(其实不远。。)到了镇上去吃饭,正好拍到了晚上的美瑛车站,这张没有做色调映射,直接出片就很漂亮了。

IMG_7963_tonemapped.jpg

虽然这次去时间很不好,薰衣草都开过了,不过还是能看到一些很漂亮的花田,这个地方我们去的这一天是最后一天开放,冬季就会变成一个滑雪场

——————————-

IMG_7271_tonemapped.jpg

伏见稻荷大社的狐狸

IMG_7173_4_5.jpg

京都塔,玻璃反光。。

IMG_6839.jpg

穿和服逛街的人们,这种拉车的小伙专门挑这种结伴而行的和服小妹妹搭讪。。。人力车价格非常贵。。。

IMG_6998_6999_7000.jpg

京都的传统建筑都保护的非常好

IMG_7057_8_9.jpg

京都御所的小花园

IMG_7220_1_2.jpg

京都车站顶上一家豆腐料理店拍出去的,玻璃有反光。。。

——————————-

IMG_8276_tonemapped.jpg

札幌的电视塔,也可以上去

IMG_8313_tonemapped.jpg 

小樽的运河IMG_8323_tonemapped.jpg IMG_8338_tonemapped.jpg

这张其实应该取点前景。。。

——————————-

来两张全景图,都是用三张照片合成的,没有带脚架,不过看起来效果还行。

IMG_7950_51_52_全景图_tonemapped.jpg

这张是从富田农场步行到火车站的路上拍的,最好点大图来看。

7688_89_90_全景图.jpg

这张是在函馆拍的

———————————-

最后贴几张旅途中偶遇的喵星人。。

IMG_7583.jpg IMG_7751.jpg IMG_7373.jpg


10
Aug 12

SIGGRAPH 2012 PPT 发布链接

今年SIGGRAPH的PPT也开始陆续放出来了,现在看到的有三个,后面再继续更新:

周日就要和我家领导出发去日本旅行了,算是Gap Year的完美结束吧!估计博客更新会暂停两周。因为没有跟团,两个不懂日语的人自由行所以要准备的东西很多,不过好处是活动范围可以很大(日本高铁专门对外国人短期旅行的通票还是非常划算的)。行程也很自由,希望不要碰上大台风什么的。回来更新游记和照片~~

05
Aug 12

为什么认识自己这么难

因为也许人类思维注定是偏颇的。

最近一直在看《思考,快与慢》这本书,作者是决策领域的大牛,诺贝尔经济学奖得主(虽然他并不把自己当经济学家!)。这是一本让人感觉大开眼界,并且不断意识到自己思维局限性的书。虽然阅读这本书并不能解决我们思维上的缺陷(作者自己也说了连自己也无法克服这些思维缺陷!),但是能意识到这一点并能在以后的生活中做出一些改变也是不错的。说两个由这本书想到的有趣的事情。

1)“C++是垃圾,我们应该用C”

最近微博上看到一年N度的语言大战又开始了,这次是一个C++特性造成的内存泄漏话题引发的,于是正在用C语言的人纷纷表示自从抛弃C++,Bug少了很多,代码质量一下有了质的飞跃,并严重鄙视还在使用C++的人。表示完全无法理解怎么还有人会用这门特性如此之多、如此复杂的语言。这次看到这种争论很自然的想到了Narrative Fallacy,叙事谬误理论认为,能够吸引我们眼球的那些说法往往是很通俗易懂,具体而不抽象的,关注的往往是少数几件已经发生的大事,而不是无数件并没有发生的事情,任何新近发生的有影响的事都有可能成为一个存在因果关系的故事的核心情节。你会不由自主的去处理手头有限的信息,好像这些信息就是全部事实了,我们会最大限度的忽略自己的无知。而人类大脑的局限使得它没有足够的能力重构过去的知识结构或信念。一旦接受了一种新的观点,人们就会丧失很大一部分回忆能力,无法回想自己观点改变之前的那些想法了。

2)“Regression to Mean”

所有表现都会回归平均值,这个原理也是很有意思的,心理学的研究已经证明,在进行技能训练的时候对良好表现的嘉奖比对错误的惩罚更有效。但是很显然很多教练并不这么认为,前段时间刚考过驾照,教我们的教练就经常说:表扬没用要多骂一点才能让大家学得更好,因为很多时候如果一个学员开得不错,稍微表扬了一下,结果往往下一次表现就会变差,而那些被骂的学员,往往下一次就能做的好一些。现在想起来,我们这个教练的观察不正是Regression to Mean么?糟糕的表现常常会有所提高,而好的表现会变差,这跟表扬和惩罚都没有关系,我们不能把不可避免的随机波动和因果解释联系起来!不过能认识到这一点并不容易,直到万有引力和微积分理论出现两百年之后才有科学家发现这一个原理。

“认识你自己”,相传是刻在德尔斐的阿波罗神庙的三句箴言之一,也是其中最有名的一句。现在越发觉得,这真是一件很难的事情。


28
Jul 12

GDC 2012 Build and Test Automation

A Two-Part Technique for Efficiently Scaling Build and Test Automation

一篇老PPT了,主要是讲如何用虚拟化技术来进行快速的版本发布和自动化测试的,还是挺有借鉴意义的。在硬件环境越来越复杂,需要支持的平台和OS越来越多的情况下,资源量巨大的游戏如何做构建/测试的自动化。我觉得是每个工作室都得面对的,当然一开始肯定都是暴力解决,但是效率实在太低了(上一个MMO项目,在一开始的时候,编译一次版本,需要大概40-60分钟,包括Exe编译,资源打包,拷贝,安装包制作之类的)。小作坊这样搞还行,要真正的做工程,还是得用工具来解决。否则完全无法扩展,组合爆炸之后也无法维护了。下面看看EAC Burnaby的解决方案。

在应用这个技术之前的工程效率是这样的:

2-3个平台,每个平台至少4种编译配置,每种配置编译耗时15-30分钟,每天40-100+次提交。每次集成耗时60-120分钟!每一次提交后自动测试要等上1到2小时,显然一天提交不了几次。

首先想到的解决方案是把编译和测试拆开,并行化:

但是这样下来,需要的服务器数量也会很多,带来很多管理开销:

于是引入虚拟化技术是很自然的了:

要进一步效率还要对瓶颈所在进行定量分析,想当然可不行:

于是流程变成这样的:

但是数据拷贝还是很费时的,比如同时开5台测试虚拟机进行5组测试,那每台机器都得拷贝一份数据,如何避免拷贝?

具体的实现方法是利用SANiSCSI技术:

SAN可以看作一个巨大的虚拟磁盘阵列,可以从这些磁盘中划分出单个的逻辑磁盘单元,也就是LUN,利用iSCSI协议,这个LUN可以被局域网中的任何机器装载,就好象是本地磁盘一样使用(并不是通常意义上的网络共享磁盘)。当编译的虚拟机完成版本构建,我们可以生成一个包含编译版本的Snapshot,这个Snapshot可以用很低的成本进行一次Clone操作,生成的Clone磁盘可以被其他机器转载,这样就能达到快速的把版本构建结果交给测试机器使用的目的,并且Clone镜像可以生成N个,这样,可以用不同的虚拟测试机,同时并行跑不同的测试用例!

最后的流程就是这样的了:

实际使用的硬件:

最后的结果还是非常好的:

  • 150种不同的编译配置,高峰期每天800-1000次版本构建,只需要一个非全职工程师维护
  • 200+组测试用例,高峰期每天跑1200-1500次,一个非全职工程师维护,虚拟机支持150种测试环境

24
Jul 12

对会议效率的一些思考

可能不少人都听说过著名的"Team Meeting Driven Development",也就是会议驱动开发模式。而很有可能有更多的人都亲身经历过持续数小时,甚至数天的“无尽模式”的会议。大家在痛恨之余,不知道有没有想过怎么才能避免陷入天天实践TMD模式的囧境。对于大型项目来说,沟通效率基本决定了一切。而这一点也是研发的本质复杂度所在,并不能随着开发语言和工具环境的改进而提升。这几年做项目对这个也有很多思考,今天写写一些想法吧。

估计大家都经历过这样的阶段:开会效率低,大家就去找各种如何高效会议的手册什么的,比如这本大名鼎鼎的《罗伯特议事规则》,正好以前还做过一点读书笔记,附在后面,没有看过的同学可以快速的了解一下这本书的主要内容:

  • 基本思想
  • 平衡:保护各种人和人群的权利,包括意见占多数的人,甚至是每一个人,即使那些没有出息会议的人,从而最终做到保护所有这些人组成的整体的权利
  • 对领袖权利的约束:集体的全体成员按自己的意愿选出领袖,并将一部分权利交给领袖,但是同时,集体必须保留一部分权利,使得自己能够直接控制自己的事务,避免领袖权利过大
  • 多数原则:多数人的意志将成为集体的意志
  • 辩论原则:所有决定都必须是经过了充分的自由辩论协商之后才能做出的,每个人都有权利通过辩论说服其他人接受自己的意志,甚至一直到这个意志变成总体的意志
  • 集体的意志自由:在最大程度上保护集体自身,在最大程度上保护和平衡集体成员的权利

    具体的会议规则如下:

    最小构成

  • 会议开始之前必须确定使得会议结果有效的法定人数
  • 保证会议结果代表了多数人的意见
  • 避免出现一言堂

    基本组成

  • 主席:主持会议,秉持规则。主持人不得发表意见也不能总结别人的发言
  • 秘书:形成会议的书面记录

    基本礼节

  • 任何成员只能对主席发言,即使要对另外一名成员发言,也只能通过主席
  • 成员在发言前要避开直接引用另外一名成员的姓名
  • 成员必须取得发言权才能发言,发言必须在时限之内
  • 不得进行人身攻击,只能就事论事
  • 主席对自己也只能用第三人称,不能直呼成员姓名

    动议

  • 由成员提出动议,动议必须是具体的,明确的,可操作的行动建议
  • 从文件或者报告中产生动议
  • 遗留问题中产生动议
  • 动议是会议的基本元素

    会议的过程

  • 提出动议
  • 另外一名成员附议
  • 附议不等于同意,即便不同意一个动议,也可以采取附议的方式让动议进入讨论,尽快用讨论来否决
  • 附议的作用是帮助主席确定动议是否值得讨论
  • 主席陈述议题
  • 主席通过陈述议题将其正式提交会议考虑
  • 主席需要准确的陈述动议的文字,并表示辩论可以开始了
  • 辩论
  • 发言前要取得发言权,并得到主持人的允许后才可以发言,发言要起立,别人发言的时候不能打断
  • 辩论过程中,每个成员的发言次数是有限的
  • 发言是有时限的
  • 发言必须以主席为发言对象,不能和其他成员直接对话,绝对不允许攻击其他成员的道德动机
  • 主席不能参与辩论
  • 只要还没有用尽辩论权的成员,主席就不能结束辩论
  • 主席有权打断违规发言的人,被打断的人应该终止发言
  • 发言人应该首先表明赞成或反对,然后说明理由
  • 主席应该尽可能让意见相反的双方轮流得到发言机会
  • 讨论问题不能跑题,主席应该打断跑题发言
  • 提请表决
  • 主席应该再一次陈述议题,保证全体都准确的了解当前要表决的问题是什么
  • 主席应该先请赞成方举手,再请反对方举手,但不要请弃权方举手
  • 无论正反表决结果多么接近一致同意,主席必须请反方表决
  • 宣布表决结果
  • 主席在提请表决之后,在反方表决之后,应该立刻起立宣布表决结果
  • 赞成方多于反对方,动议通过,平局等于没有通过
  • 主席必要时需要对不明朗的结果进行验证

    这本书本身还是非常好的,对于处理大型团队决策问题,定义非常详细的技术细节。比较类似的还有这个Hold a 22 minute metting.但是经过各种实践和思考之后,我觉得这些技术细节并不能解决会议效率低下的根本问题。首先,我们需要把会议分为两种大类型

  • 一种是在对一个事情还没有明确的组织开展思路的时候的核心决策会议
  • 一种是已经有明确的开展思路的时候向下面执行层面的人员传达的会议

    对于第一种类型的会议,显然要比第二种难很多。一般的讲会议方法的书籍都会强调会议前详细的准备,会后的会议纪要之类的技术细节,但是忽视了一个很重要的问题,就是会议如果讨论的是没有成型的东西,那么要求会议的参与人都必须对这个主题有比较多的背景理解,否则,会议讨论往往会陷入无关紧要的细节,无法达成共识,浪费大量的时间,这就是第一种会议面临的“本质复杂度”(essential complexity)。会议前准备之类的,能够降低“非本质复杂度”(accidental complexity)。但是无法解决会议参与人由于能力和对主题认识的问题,无法很深入讨论获得结论的能力。在讨论的时候,很容易分不清主次,陷入到和主题无关的细节中去,到最后大家精力都耗光了,主题反而没有结论。所以,我觉得对于第一种类型的会议比较可行的是:

  • 限定会议的时间,不能开马拉松会议,毕竟大家的时间都很宝贵,还有这么多事情要做
  • 在黑板上不断细化要讨论的主题,对于跑题的讨论,记录下来,留到以后的会议讨论
  • 如果限定时间不能获得结论,那么确定下次会议的主题和时间后,结束会议,但是在下次会议开始前,大家都要积极的思考主题,争取下次会议能得出结论,或者获得更深入的见解
  • 好好利用文档形式进行异步沟通,对于比较复杂的议题,可以提前以文字的方式,描述自己的想法,会后继续跟进的议题也可以是邮件和文档的形式进行,直到有需要面对面会议需求的时候再进行后续的会议
  • 提高个人能力,必须意识到会议讨论效率低最难解决的就是参与者能力不足

    研发的核心是沟通,而高效的进行各种讨论会议是沟通的核心,也是各行各业做大型工程必然面对的相同问题。所以其实可以从多种途径去了解,比如看历史,当年共产党是如何组织会议的?这里记录的只是目前阶段的理解,也许以后还会有新的想法,到时候再分享。