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,原生的整合功能还是很方便的。


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
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)。但是无法解决会议参与人由于能力和对主题认识的问题,无法很深入讨论获得结论的能力。在讨论的时候,很容易分不清主次,陷入到和主题无关的细节中去,到最后大家精力都耗光了,主题反而没有结论。所以,我觉得对于第一种类型的会议比较可行的是:

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

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


  • 15
    Jul 12

    The Art of Doing Science and Engineering

    这本书是根据Hamming在美国海军研究院授课的课堂录音整理成的,主要内容是用自己做计算机相关研究的亲身经历讲述科研和工程的心得。对这本书感兴趣纯粹是因为Bret Victor同学给了一个6星级评分。看下来感觉还可以(虽然稍微贵了点。。。)。计算机和通信相关专业的同学对Hamming应该都不陌生,86年就因为在数值方法,自动编码系统,错误检测和纠错码的贡献获得了图灵奖。这本书因为只是课堂录音整理,并且估计也没什么Marketing之类的,所以影响力似乎并不大。中间的一些部分如果不是专业出身可能也比较枯燥,所以我想发行量不会很大。好在这门课程全部数字化了,大部分内容都可以在这里找到,有些章节只是节选,如果不想花31刀买书的话,就看这里的电子版吧。95年的最后一学期讲课的全部录像在这里也能下到,感觉那时候思维还很敏捷啊,怎么96年就挂了。。。他还有一个很有名的演讲,You and Your research,这里有一篇还不错的翻译。下面是一些很有意思的摘要(Kindle做这个还是很方便的,只是因为我经常在PC/手机/Kindle上同时看一本书,多设备同步还是有bug,有时候会覆盖掉。。。)

    Education is what, when, and why to do things, Training is how to do it.

    In science if you know what you are doing you should not be doing it. In engineering if you do not know what you are doing you should not be doing it.

    All of engineering involves some creativity to cover the parts not known, and almost all of science includes some practical engineering to translate the abstractions into practice.
    Often it is not physical limitations which control but rather it is human made laws, habits, and organizational rules, regulations, personal egos, and inertia, which dominate the evolution to the future.

    you must try to foresee the future you will face. To illustrate the importance of this point of trying to foresee the future I often use a standard story. It is well known the drunken sailor who staggers to the left or right with n independent random steps will, on the average, end up about steps from the origin. But if there is a pretty girl in one direction, then his steps will tend to go in that direction and he will go a distance proportional to n. In a lifetime of many, many independent choices, small and large, a career with a vision will get you a distance proportional to \(\sqrt{n}\), while no vision will get you only the distance In a sense, the main difference between those who go far and those who do not is some people have a vision and the others do not and therefore can only react to the current events as they happen.

    To what extent history does or does not repeat itself is a moot question. But it is one of the few guides you have, hence history will often play a large role in my discussions—I am trying to provide you with some perspective as a possible guide to create your vision of your future.

    In forming your plan for your future you need to distinguish three different questions: What is possible? What is likely to happen? What is desirable to have happen? In a sense the first is Science—what is possible. The second in Engineering—what are the human factors which chose the one future that does happen from the ensemble of all possible futures. The third, is ethics, morals, or what ever other word you wish to apply to value judgments.

    Lastly, in a sense, this is a religious course—I am preaching the message that, with apparently only one life to live on this earth, you ought to try to make significant contributions to humanity rather than just get along through life comfortably—that the life of trying to achieve excellence in some area is in itself a worthy goal for your life.

    It has often been observed the true gain is in the struggle and not in the achievement—a life without a struggle on your part to make yourself excellent is hardly a life worth living.
    Notice I leave it to you to pick your goals of excellence, but claim only a life without such a goal is not really living but it is merely existing—in my opinion. In ancient Greece Socrates (469–399) said: The unexamined life is not worth living.
    Indeed, one of the major items in the conversion from hand to machine production is the imaginative redesign of an equivalent product. Thus in thinking of mechanizing a large organization, it won’t work if you try to keep things in detail exactly the same, rather there must be a larger give-and-take if there is to be a significant success.

    You must get the essentials of the job in mind and then design the mechanization to do that job rather than trying to mechanize the current version—if you want a significant success in the long run.
    We must not forget, in all the enthusiasm for computer simulations, occasionally we must look at Nature as She is.

    The Buddha told his disciples, "Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense". I say the same to you—you must assume the responsibility for what you believe.

    "Almost everyone who opens up a new field does not really understand it the way the followers do". The evidence for this is, unfortunately, all too good.

    It has been said in physics no creator of any significant thing ever understood what he had done. I never found Einstein on the special relativity theory as clear as some later commentators.

    The reason this happens so often is the creators have to fight through so many dark difficulties, and wade through so much misunderstanding and confusion, they cannot see the light as others can, now the door is open and the path made easy.

    Hence I expect a lot of trouble until we do understand human communication via natural languages. Of course, the problem of human-machine is significantly different from humanhuman communication, but in which ways and how much seems to be not known nor even sought for. Until we better understand languages of communication involving humans as they are (or can be easily trained) then it is unlikely many of our software problems will vanish.

    There are many things we can do to reduce "the software problem", as it is called, but it will take some basic understanding of language as it is used to communicate understanding between humans, and between humans and machines, before we will have a really decent solution to this costly problem. It simply will not go away.

    "Is programming closer to novel writing than it is to classical engineering?" I suggest yes!

    Give the same complex problem to two modern programmers and you will, I claim, get two rather different programs. Hence my belief current programming practice is closer to novel writing than it is to engineering. The novelists are bound only by their imaginations, which is somewhat as the programmers are when they are writing software.

    What you learn from others you can use to follow; What you learn for yourself you can use to lead.

    Mathematics is nothing but clear thinking. Mathematics is the language of clear thinking.

    Platonic school (most) formalists When rigor enters, meaning departs. logical school intuitionists constructionists fallacies: 1) we do not actually "prove" theorems! 2) many important programming problems cannot be defined sharply enough so a proof can be given, rather the program which emerges defines the problem!

    Man is not a rational animal, he is a rationalizing animal.

    I often suspect creativity is like sex; a young lad can read all the books you have on the topic, but without direct experience he will have little chance of understanding what sex is—but even with experience he may still not understand what is going

    An expert is one who knows everything about nothing; A generalist knows nothing about everything. In an argument between a specialist and a generalist the expert usually wins by simply (1) using unintelligible jargon, and (2) citing their specialist results which are often completely irrelevant to the discussion.

    All impossibility proofs must rest on a number of assumptions which may or may not apply in the particular situation. "If an expert says something can be done he is probably correct, but if he says it is impossible then consider getting another opinion."

    What you did to become successful is likely to become counterproductive when applied at a later date. "There is never time to do the job right, but there is always time to fix it later." especially in computer software.

    Hamming’s rule: 90% of the time the next independent measurement will fall outside the previous 90% confidence limits!

    Most of the time each person is immersed in the details of one special part of the whole and does not think of how what they are doing relates to the larger picture. It is characteristic of most people they keep a myopic view of their work and seldom, if ever, connect it with the larger aims they will admit, when pressed hard, are the true goals of the system. This myopic view is the chief characteristic of a bureaucrat.

    Systems engineering is the attempt to keep at all times the larger goals in mind and to translate local actions into global results.But there is no single larger picture

    The first rule of systems engineering is: If you optimize the components you will probably ruin the system performance.

    Rule 2: Part of systems engineering design is to prepare for changes so they can be gracefully made and still not degrade the other parts.

    Rule 3: The closer you meet specifications the worse the performance will be when overloaded.

    Westerman believes, as I do, while the client has some knowledge of his symptoms, he may not understand the real causes of them, and it is foolish to try to cure the symptoms only. Thus while the systems engineers must listen to the client they should also try to extract from the client a deeper understanding of the phenomena. Therefore, part of the job of a systems engineer is to define, in a deeper sense, what the problem is and to pass from the symptoms to the causes.

    The deeper, long term understanding of the nature of the problem must be the goal of the system engineer, whereas the client always wants prompt relief from the symptoms of his current problem. Again, a conflict leading to a meta systems engineering approach!

    You may think the title means if you measure accurately you will get an accurate measurement, and if not then not; but it refers to a much more subtle thing—the way you choose to measure things controls to a large extent what happens.

    For example, in school it is easy to measure training and hard to measure education, and hence you tend to see on final exams an emphasis on the training part and a great neglect of the education part


    26
    May 12

    对游戏开发工具的一些思考

    本周主要任务是尽快把暗黑3通关,所以博客就简单一些了。。。随便写一点工具方面的思考,我们都知道开发工具是衡量一个团队制作实力的重要标准,很多时候工具是和团队的制作流程绑定的,人和工具必须匹配,一些使用很先进的商业引擎的团队最后却出现各种低级制作失误。不能不说是团队驾驭不了先进的工具和引擎造成的。所以很多工作室也比较喜欢自己开发工具,虽然前期费点事情,但是后面可以任意定制,根据自己的流程来做各种优化还是非常强的核心竞争力积累吧。做了这么几年的MMO,也算是经历了一轮完整的工具积累了,还是有不少问题值得反思的。

    1.概念一致性

    目前的工具链,缺乏统一视觉识别规划,所以不同的工具,可能都用的不同的色系,不同的按钮图标,并且在术语一致性上有各种小问题,毕竟是不同的程序/美术/策划在制作不同的工具,而这些工具通常是随着制作需求和流程的完善逐渐长出来的,进度和开发压力一直很大,所以不统一也是比较正常的,不过我想下一版工具一定要统一工具的视觉标识,这样会进一步提高工具的易用度,减少培训难度。

    除了视觉标识和术语的一致性,工具设计的一致性也很重要,之前项目中,凡是不好用的工具基本都有一个共有的毛病,就是设计思想不统一,比如做一个事情,需要很多步,这些功能分布在很多切页中,并且不同的情况,要用不同的顺序去点这些功能按钮,一旦出错,就前功尽弃,不熟悉的人很难上手。这些工具往往是由不同的人在不同时期负责不同的功能,而由于缺乏统一的规划,所以很多细节就是按不同的假定去进行。导致做出功能OK,但是非常难用的工具。这也是我觉得工具的设计一定是自上而下进行的原因。

    2.视野

    好的工具应该首先完成功能,然后能够尽量减少繁琐的操作需求,提高使用效率,这并不容易。所以放宽视野,多参考其他工具的设计是非常有必要的,评估相同的功能,其他商业引擎的编辑器和自己家编辑器的生产率差别是必修课。了解工具设计背后的思想。不光是游戏制作的工具,很多其他类型的工具软件也是很好的样板,以后真的要考虑用用Mac平台下的那些工具了。

    3.原型迭代

    工具开发也是不小的工作量,之前遇到过几次花费1-2个月人力做出来的工具完全达不到设计目标的情况,所以先在纸上设计好UI和使用流程,纸面推演完成后再PS设计实际的界面,最后再进行原型迭代是不错的流程。但是由于工具开发绝对是一个长期的流程,所以要做好准备完成第一版可用原型后就开始进行不断的检讨优化工作。开发人员最好能实际的和用户一起工作,观察工具使用中的行为,有时候还是能发现不少问题的。

    4.需求收集与改进

    工具的最终目的是提高制作效率,而由于游戏的复杂性,流程和制作方法总是在不断变化的,所以一定要定期进行新需求的收集,以及现有功能的反馈,比如以前就遇到过这样的事情,一开始做场景编辑器的时候,为了提高客户端效率,模型是需要进行同步操作才能在引擎中使用。由于初期资源量少,同步很快,但是一年之后,模型数量巨大之后,同步一次也需要很长时间了,对美术的工作效率有不小的影响。所以以后做工具,一定会加入固定的工具优化讨论,比如让每个人列出Top5 浪费时间的任务等等。

    5.反馈速度

    对游戏内容的制作者来说,修改内容->IN GAME的循环需要的时间越短,越能更好的进行游戏的调试,如果策划随便修改一个数据,都需要重新启动客户端和服务器才能看到结果,那制作效率是非常低的。工具一定要提供很稳定,快速的热加载和IN-GAME预览功能,但是这里需要注意的是,视内容的不同,IN-GAME预览不一定要100%匹配。因为要做到100%匹配需要的成本是比较高的,很多时候也是不必要的。举个之前项目遇到的问题,我们的预览器是提供给美术的场景制作人员预览场景的IN-GAME效果的,由于想做到和客户端完全一致,于是这个工具就是客户端的一种特殊编译配置,结果在后期这个工具经常会由于客户端改动一些协议而不能使用,比较影响美术正常的工作,并且对于美术的应用来说,并不需要预览逻辑部分的内容。比较好的方法应该是把效果部分的代码共享即可,这样就把和逻辑层网络层的耦合解开了。

    6.并行编辑

    并行的效率肯定是比串行高的,我们的场景编辑器一开始就考虑到这个问题,能支持大地图的并行拼图。但是策划工具就比较差了,实际上很多策划的填表工具,用Web化的方式实现是很方便的,这样能比较容易的支持并行编辑。所以工具引入HTML5+CSS3+JQuery技术是很有价值的技术积累。这也是之前项目比较欠缺的。


    18
    May 12

    关于Unicode和字符串处理的一些笔记

    这篇文章的主要目的是梳理目前的主流Unicode字符串格式相关知识点,包括历史的演化,一些需要注意的事项。

    Pre-Unicode

    1.ANSI 标准

    是最早的单字节编码格式,兼容英语与欧洲语言的显示。0-127是标准字符集,128-255则引入了Code Page的概念。Code Page可以看作一个映射表,不同的国家有不同的Code Page,对相同的128-255的字符有完全不同的映射关系。但是这种编码显然是无法容纳海量的亚洲文字的。

    2. DBCS或者MBCS标准

    当一个字节已经无法满足字符编码需求的情况下,这种单双字节编码出现了。根据当前系统的Codepage,会约定当遇到某个范围内的字符时,这个字符会被认为是Leading Byte,标记后面的一个字符也是当前表示的一个文字的一部分,需要一起解析,所以使用这种编码,遍历字符串做处理的时候就要小心了,不能直接用s++,s–,否则会出现字符被截断,和后面的字符形成转义字符之类的东西,造成解析错误。由于历史原因,Leading Byte的处理非常繁琐,你不会想自己实现一个的,所以必须使用_mbsinc和_mbsdec等系统API去处理

    3.用MBCS支持国际化要考虑的问题

    是的,用MBCS也是可以做国际化的,虽然比较麻烦,但是一些遗留的系统和代码如果改成Unicode太痛苦的话,可能用这种方法也是一个Option。主要注意的东西有下面这些:

    • 使用_mbsinc和_mbsdec去做字符串指针的迭代操作
    • 用_mblen获得字符串长度,比如下面的代码是扫描转义字符的,我们需要对字符串数组进行索引操作,就需要考虑到变长的编码
    while ( rgch[ i ] != '\\' )
        i += _mbclen ( rgch + i );
    • 用_getmbcp 获得当前的CodePage
    • 使用_mbscpy拷贝字符串
    while( *sz2 )
    {
        //注意如果不是X,那么要使用_mbccmp!!
        if( *sz2 != 'X' )
        {
            _mbscpy( sz1, sz2 );
            sz1 = _mbsinc( sz1 );
            sz2 = _mbsinc( sz2 );
        }
        else
            sz2 = _mbsinc( sz2 );
    }
    • 正确的字符串比较方式是用系统函数进行,if( !_mbccmp( sz1, sz2) ),如果知道比较的是ANSI字符,则可以直接进行,但是不建议这样做
    • 小心Buffer Overflow的陷阱

    比如下面这段代码,如果sz是MBCS编码,就有Buffer Overrun的危险

    cb = 0;
    while( cb < sizeof( rgch ) )
       rgch[ cb++ ] = *sz++;

    正确的做法是这样,注意while里面还需要判断最后一个字符的长度!

    cb = 0;
    while( (cb + _mbclen( sz ))

    或者直接使用_mbsnbcpy( rgch, sz, sizeof( rgch ) );

    参考文献:

    Unicode

    简要的发展历史

    Unicode是一种希望一种编码搞定地球所有语言字符的标准。但是由于种种原因,Unicode也经历了多种版本才总算把有多少字符搞明白。以至于到后来的标准和前面完全就不一致了。1988年Becker发布了第一版Unicode草案,提出用16 bit来表示所有的字符(也就是当时人们认为65535个字符就够地球人用了),91年正式标准发布,也就是UCS-2标准,有很多新的系统和框架使用了这种标准,比如QT,Widnows NT,Java等。但是实际使用后人们才发现,16位根本不够。96年,又出现了UTF-16标准。允许2-4个字节的编码,到目前为止一共有109449个字符,其中CJK占了74500个.

    在Unicode标准中所有的字符都用一个叫做CodePoint的唯一数字来代表。但是具体的编码方案可以各异,目前最常用的是三种方式

    • UCS-2,把所有的字符用2 Bytes保存,在Windows下wchar_t就是UCS-2
    • UTF-16是用2-4 Bytes来保存,为了效率,兼容Big/Little Endian,通过一开头的FE FF Mask位来指定当前文档的字节序。UTF-16是UCS-2的超集。UTF-16的一个字符,有可能在高8位或者低8位上等于0×0,所以不能兼容ANSI标准。这也是Thompson发明UTF-8的主要原因之一
    • UTF-8,是Ken Thompson在贝尔实验室参与Plan 9系统开发的时候设计的,<128的CodePoint用一个Byte来编码,然后大于的依次根据其大小用2-6个Byte进行编码。因为兼容ANSI,并且只要做比较少的改动,就能正确的处理多语言支持的问题,所以是Unix/Linux/Web的主流编码格式
    Bits  Hex Min  Hex Max  Byte Sequence in Binary
     
    1    7  00000000 0000007f 0vvvvvvv
     
    2   11  00000080 000007FF 110vvvvv 10vvvvvv
     
    3   16  00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
     
    4   21  00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
     
    5   26  00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
     
    6   31  04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv

    关于Unicode:

    • UTF-8和UTF-16都是变长的编码标准,最大都是4个Bytes(UTF-8定义的时候还有5,6Bytes的情况,不过现在这部分还没有用上,所以可以认为是1-4 Bytes)
    • UTF-8是Endianness的,UTF-16分为UTF-16LE和UTF-16BE
    • wchar_t在一些平台上是2 Bytes,在一些上是4 Bytes
    • UTF-16编码纯中文字符比UTF-8要小一些(2 Bytes,而UTF-8需要3 Bytes),但是一般情况下游戏数据文件还是ANSI字符占大头。所以使用UTF-8编码还是能有效节省带宽和内存的
    • 任何byte oriented的字符串搜索算法都可以直接用于UTF-8,编码方式保证了一个字符的字节序是唯一的
    • UTF-8不会出现FE FF,也就是不会和UTF-16混淆
    • UTF-8可以有BOM用来标志这是一个UTF-8文档,但是现在也有很多文档选择忽略这个标记
    • UTF-8可以编码任何Unicode字符,不需要考虑CodePage之类的,能够同时输出到多种语言
    • 直接把UTF-8字符串当作unsigned byte进行排序的结果和将其当作Unicode CodePoints进行排序,结果是一致的,这是很方便的设计!
    • 没有所谓的Plain Text,必须知道当前的字符串是用什么方式编码的,才能正确的解析。举个例子,对于网页解析来说,首先服务器上由于托管了大量的页面,编码各有不同,所以不能由服务器发编码,那么就交给客户端的浏览器去决定,客户端会先读取页面,去寻找ContentType的字段获得页面的编码,然后再重新Parse整个页面,如果找不到编码方式,不同的浏览器有不同的处理方法,比如IE,就会根据词频之类的特征,猜测当前页面最可能的编码

    4.UTF-8实际使用中要考虑的问题

    • 工程全部使用UNICODE编译,避免错误的把Narrow String传给Windows API
    • 除非特别的指定,所有的std::string和char*都当作UTF-8编码处理
    • 可以考虑使用Boost.Locale等高质量的第三方库
    • 上层逻辑代码不使用wchar_t,_T(),L”"等,只在底层使用
    • 由于MSVC的fstream等文件类,不能支持UTF-8编码的文件名,所以只能使用一个非标准的扩展,就是把UTF-8的文件名转换成UTF-16传给fstream,所以对于文件操作,还是由底层进行封装比较好,比如使用_wfopen_s()。
    • 在上层使用的字符串默认都是UTF-8的,底层提供UTF8::Iterator迭代器,供需要进行字符串操作的模块使用。相对MBCS的复杂情况,UTF-8是比较简单的编码,从Leading Byte判定长度是统一的,获得字符的算法也都是字节位操作,还是比较高效的。比如这样:
    template <typename octet_iterator>
    uint32_t next(octet_iterator& it)
    {
        uint32_t cp = internal::mask8(*it);
        typename std::iterator_traits<octet_iterator>::difference_type length = utf8::internal::sequence_length(it);
        switch (length) {
            case 1:
                break;
            case 2:
                it++;
                cp = ((cp << 6) & 0x7ff) + ((*it) & 0x3f);
                break;
            case 3:
                ++it; 
                cp = ((cp << 12) & 0xffff) + ((internal::mask8(*it) << 6) & 0xfff);
                ++it;
                cp += (*it) & 0x3f;
                break;
            case 4:
                ++it;
                cp = ((cp << 18) & 0x1fffff) + ((internal::mask8(*it) << 12) & 0x3ffff);                
                ++it;
                cp += (internal::mask8(*it) << 6) & 0xfff;
                ++it;
                cp += (*it) & 0x3f; 
                break;
        }
        ++it;
        return cp;        
    }
    • 所有的数据文件也都使用UTF-8编码
    • 代码中不直接出现UTF-8字符串,全部从文件读取,避免源代码文件编码问题

    参考文献:


    29
    Apr 12

    支持多重触摸手势的场景制作工具

    Pixar一直是我很喜欢的工作室,技术和艺术的结合堪称完美,他们的研究院主页上有很多有意思的Paper,最近有几篇和利用新一代人机交互技术来提高制作效率的,还比较有趣,随着支持多重触控的平板设备普及,也许在不久的将来,这些技术也能运用到游戏制作的编辑器里?虽然没有Pixar内部实际如何运用的信息,但是从09年开始,他们已经开始探索利用支持多重触摸手势功能的编辑器进行场景制作了。主要有两个项目EdenProton。都是和Berkeley合作的项目,主要解决的问题是电影中有大量物件的3D场景制作效率( set-dress 3d scenes)。Eden是多重触摸界面的编辑器,而Proton是为了支持大量复杂手势的定制和自动匹配的工具,可以说技术上已经比较成熟了。我们都知道目前不管是电影还是游戏的主流的场景制作工具还是类似Maya这样的,完全基于鼠标和键盘的传统UI交互。Eden就是想颠覆这个传统,Berkeley的研究人员+10年经验的Pixar场景美术的团队。09年首先是进行了科学的测试,证明多重触控的操作确实能够有效的提高效率,论文在这里。于是首先开发了Eden,论文里面列出的多重触控手势设计原则还是比较有意思的,以后做平板的软件说不定能用得上,记录一下:

    • Use simple gestures for frequently used operations
    • Conjoined touch as a modifier,引入Conjoiner Touch的概念,使得两个手指的触摸操作可以表示三种语义,方便操作
    • One operation at a time,两只手分别操作多个物体的需求很少,而且不直观
    • Split touches across both hands
    • Use at most two fingers from each hand,不是每个人都是练钢琴的,所以每只手最多用两个手指
    • Interchangeability of hands,手势是可以互换完成的
    • Motion of gesture reflects the operation,手势反映出操作的特点,方便记忆与实施
    • Combine direct and indirect manipulation,直接和间接操作需要结合使用
    • Control at most two spatial parameters at a time,每次最多控制两个空间参数,这也是和美术实际测试下来最方便的操作

    最后Eden测试的结果是,制作效率提升20%,由于工作分摊到两只手上,可能可以减轻老美术的RSI(repetitive stress injury,就是鼠标手了…)。感兴趣的同学还可以去论文页面下载演示视频。

    参考文献:

    1. Determining the Benefits of Direct-Touch, Bimanual, and Multifinger Input on a Multitouch Workstation

    2. Eden: A Professional Multitouch Tool for Constructing Virtual Organic Environments

    3. Proton: Multitouch Gestures as Regular Expressions


    22
    Apr 12

    对游戏制作层面问题的一点思考

    制作层面的问题非常多,今天写一个小点,就是工具化的问题。做过大规模项目的人都知道,总是有一些职位,在整个项目中特别重要,但是由于各种原因,比如事情特别琐碎,重复性劳动比较多,未来也没有明确的发展方向,所以大家都不愿意做。这就是典型的“垃圾职位”。举个游戏制作的例子,比如版本发布。往往涉及非常多的组,资源也比较复杂,而且往往是加班最多的,但是这个工作本身又没有什么技术含量,之前经历的一个项目,做这个工作的是QA组的毕业生小伙。由于他干的不错,虽然也出过事故,但是由于没有人愿意接手,也就这么干下来了,后来虽然做了一整套工具去把大部分工作都自动化了,但是这个职位似乎是理所当然需要继续存在的。现在回头想想,什么样定位的人愿意做这样的工作?在早期没有工具化的情况下,人肉干掉这些Dirty Work是必须的,但是我们不能把这样的工作固化,而是应该在开发有余力的情况下,把这样的工作工具化,减少上手度,从而能够把这种工作分摊到任何人手上。

    对流程的优化应该是一个动态过程,不应该墨守成规。看一个团队的研发实力,其实就是看这个团队的工具做的好不好。而“工具化”其实是一个很重要团队文化。拿我们引擎组来说,每个新人必须掌握至少一门动态脚本语言,比如Python,并且鼓励遇到问题宁愿多花一点时间写脚本解决,这样以后遇到类似的问题就不用再手动实现了。这样慢慢的也积累了很多小工具,而且由于就是解决自己日常工作中繁琐事务的工具,大家也愿意去不断修改和完善。

    再举一个反面例子,之前一个项目的调试控制台的开发,控制台开始是专门的工具组制作的,通过脚本扩展各种调试命令,交付给策划和系统逻辑程序使用。后面效果并不好,现在看来主要几个核心原因

    • 控制台的后续开发并没有列在项目计划中
    • 工具组的人不参与逻辑系统开发,并没有大量调试需求,从而不会主动去改进控制台
    • 系统逻辑组的人认为控制台应该由工具组完善和发布,两边沟通的障碍导致这个工具没有专门的发布和维护人员,造成后期一些调试命令失效后,只是由需要用到这个功能的策划找自己熟悉的程序去修复,而这个修复的版本也没有统一发布,结果其他策划并不知道功能修复了
    • 系统设计没有贯彻方便调试的原则

    怎么解决这种问题,也有几种思路:

    • 工具的开发应该列入项目计划,工具是产品的一部分,并且需求是自上而下传达,也就是设计某个模块的时候,Leader就应该把相关工具的需求也一并提出,交给下面负责实现的人员完成
    • 上面这种方法相当于把工具需求放到Leader级别去控制,虽然对大工具是不错的解决方法,但是对于一些小工具,可能只有具体实现的程序才会有好的工具想法。所以如果能把工具化当作一种团队文化去贯彻,结合第一种方法,应该是最理想的了

    暂时写这么些,工具化的思想和实时反馈方便调试的思想是一致,一般来说,做不好工具化,实时反馈也做的不好。而对游戏制作来说,迭代速度越快,让修改内容的人越快获得反馈,意味着更高的质量,更好的游戏。顺便提一下,神级程序出身的前苹果UI交互设计师Bret Victor的Inventing on Principle非常值得一看。