来自子话题：
引擎这些工具，我们是永远跟不上别人的脚步的。&br&你现在需要学习的是什么？&br&1、精通一门语言（从语法，到多线程，到数据操作，到网络等等方面）。&br&2、掌握数据结构与算法。&br&3、熟悉设计模式。&br&4、多看他人的游戏源码，学习下来。&br&学习一些以一变应万变的，会让你在以后面对所以问题不会感到无力。&br&以后你也不会问选择哪个引擎的问题。&br&COCO，unity等等是标，不是本，是加分项而不是基础分。&br&我见过不少没有语言基础的直接上手学习UNITY的，恩，是学过一段时间，但是，当我看见问他们“事件”，“委托”，“四元素”,&线程池&“计数器”等等名词时的表情，我知道没有基础给他们带来的苦果。这样的程序员，也只是从一个地方换到另一个地方的码农。&br&当你自信满满的以为学好了UNITY就能找到工作时候，人家笔试提上一堆的数据结构与算法，指针，设计模式，网络，数据库，少年，你怎么办？&br&切记，把UNITY,COCO当做工具，把任何语言当做工具。&br&unity,COCO只是加分项，如果你基础分没修满，这个时候是考虑多修基础分的时候，而不是考虑多修加分项的时候。-FOR
A GAME PROGRAMMER
引擎这些工具，我们是永远跟不上别人的脚步的。你现在需要学习的是什么？1、精通一门语言（从语法，到多线程，到数据操作，到网络等等方面）。2、掌握数据结构与算法。3、熟悉设计模式。4、多看他人的游戏源码，学习下来。学习一些以一变应万变的，会让你在…
很多人并不知道游戏引擎或渲染引擎是怎么回事就开始思考如何做游戏引擎，这是不对的。&br&首先应该深度掌握渲染的基本原理，因此我非常同意其他答案关于先自己实现一个软件光栅化渲染器的建议，你应该按照最新的标准自己大概实现一遍DirectX(例如要支持tessellation, shader, MSAA, blending, anisotropic filtering, 正确处理各种corner case如退化三角形等情况)。实现的过程中请参考DirectX的specification以学习相关细节。这个文档可能是只对硬件vendor公开，不过还是很容易获得的。实现软件光栅化还能极大地锻炼你的底层C++编码能力，并行程序设计能力和优化技巧，顺便还能把主流的GPU架构搞熟。&br&&br&一旦搞清楚光栅化渲染的本质，你就能理解各种所谓“高级渲染技术”的精髓，基本上看paper只需几秒钟扫一扫图就能看懂了。这样一来短时间内就能理解大量算法和渲染架构(例如各种shadow map, AO, volumetric scattering, deferred lighting, forward+等等)。&br&&br&当你对图形管线的本质以及各种可能的应用都了然于胸的时候，剩下的就是高层架构设计问题了。这个属于软件工程的范畴，没有捷径，只能通过大量试错来获得经验了(不停地重写)。&br&&br&其实当你知道了这些所谓的技术之后，你会发现大部分都是肤浅的hack而已。现在引擎的重要课题不在于谁掌握了更牛逼的渲染技术，而在于谁能设计出更好的开发流水线，内容制作以及美工反馈才是最大的难题。前段时间和bungie的图形总管聊destiny的engine，他们表示任何新的技术他们都可以在两天内实现出来，但最大的难题是1)如何使这些新技术在各种情况下都能鲁棒地工作；而大部分时候都很好，偶尔会挂掉的技术都是不可取的；2)如何构建好的工具让美工能够控制各种情况。举个例子，tessellation是个很酷的技术，但是应用到游戏中并不容易，因为1)创建好的displacement map很困难; 2)一旦引入LOD，则牵动全身：如何保持场景在各个视角的一致性？如何让displacement geometry正确地与阴影、碰撞、贴花和可见性等系统交互？&br&&br&此外不同平台上还有很多底层优化问题，这里就不展开了。
很多人并不知道游戏引擎或渲染引擎是怎么回事就开始思考如何做游戏引擎，这是不对的。首先应该深度掌握渲染的基本原理，因此我非常同意其他答案关于先自己实现一个软件光栅化渲染器的建议，你应该按照最新的标准自己大概实现一遍DirectX(例如要支持tessella…
来自子话题：
我自己简单尝试了一下写HTML5版本。地址在这里：&br&&a href=&http://ben7th.github.io/flappy-html5-bird/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&ben7th.github.io/flappy&/span&&span class=&invisible&&-html5-bird/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&源代码可以从github上拿。&br&&a href=&/ben7th/flappy-html5-bird& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/ben7th/flapp&/span&&span class=&invisible&&y-html5-bird&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&&b&比较了一圈，相比于其他高手的实现，我写的和IOS原始版的相似度尽力做到比较高，从界面元素的切换到分数数字等细节，都很接近原作了。&/b&&br&&b&&br&缺点在于没使用任何框架，所以对于一般意义上的游戏开发而言，参考性不强。&br&&/b&&br&只用jQuery，用coffeescript来写。&br&除此之外没用其他框架或者库。完成结果是&b&500行左右的js-coffee&/b&。注释和调试语句都没删，结构上也还有很大的优化余地。&br&图片是从IOS原始版里扒的。边做别的事情边写，零零散散用了&b&一天半左右&/b&的时间。&br&如果包括画图部分，思路确定的情况下，&b&三天时间&/b&是合理的。&br&&br&总体来说我觉得相对简单。游戏中用到的可动角色以及判定运算并不多。&br&基本上，搞定了小鸟的跳起下落的重力计算就OK，套用加速度公式而已，没有什么太难的。&br&&br&小鸟和管子的碰撞判定十分容易做。因为小鸟的x坐标是不变的，变化的只是y坐标。小鸟和管子都可以看成矩形，矩形的碰撞计算很简单。无需用到任何游戏引擎都可以手写。&br&&br&&b&基本上前端基础稍强的，有一些面向对象编程思路的程序员，都应该可以写出来。&/b&&br&大部分人下意识里觉得难写的原因可能是不敢试。&br&&br&&img src=&/2c7f97ce5effb73cc56f6de2fa6907a3_b.jpg& data-rawwidth=&392& data-rawheight=&520& class=&content_image& width=&392&&&br&&img src=&/27112cfd1df657bdb050ad5b27cc4849_b.jpg& data-rawwidth=&392& data-rawheight=&520& class=&content_image& width=&392&&&br&&img src=&/56d0c87ae32bd8af16e377a_b.jpg& data-rawwidth=&392& data-rawheight=&520& class=&content_image& width=&392&&&br&&br&更细节的东西这里还贴吗？好像没什么必要。。&br&因为想看的朋友自然会看源码的吧。
我自己简单尝试了一下写HTML5版本。地址在这里：源代码可以从github上拿。比较了一圈，相比于其他高手的实现，我写的和IOS原始版的相似度尽力做到比较高，从界面元素的切换到分数数字等细节，都很接近原作了。缺点…
首先在这个贴里我不会谈技术，因为这个问题根本不是技术问题。目前的主流“次世代”引擎（我痛恨这三个字，跟痛恨动漫与全息一样）大部分采用的延迟渲染管线，这等于把各种各样的效果分化成了一张张RTT过程最后进行合成，简直就像是三维做完了去AE里合成，光影和色彩焉有不漂亮的道理？而各路人马发明的各种shader又极大的丰富了质感的表现，所以你看看这两年，在终极的实时RAYTRACE方法发明出来之前，各家引擎的效果是不是极为接近？所以说技术不是问题。（文内的国内CG制作圈野史略多，不懂的请自行百度百度）&br&&br&但我要说你这想法，你这是花样做大死大赛。为什么？&br&&br&1、作为水晶石前员工，可以负责任的告诉你，水晶石在CRY家本身根本还没想到做CINEBOX的时候，就已经购买了SANDBOX（当时还没免费也极少盗版）开始尝试制作直接输出建筑动画（包括室内动画）此时lumion/lumenRT/twinmotion刚出来还找不到盗版，况且这三位基本基于quest3d的画面只能说够格远谈不上精美，彼时康妥耶夫大侠所说的那家国外公司还没开始用到CRY。而水晶石的另外一组人马已经用UE频繁的制作汇报用VR场景---------------什么叫汇报用场景，比如一个规划馆一亿投资，所以竞标的各方（凡拓、丝路、力方等等）根本不是用设计图、效果图、PPT和标书来比试了，而纷纷把自家设计方案直接渲染出商业级建筑动画博甲方领导的欢心。（规划馆的汇报对象都是地方行政主官，又几个懂得设计的？不看HIGH了能跟你谈下一步？）所以再进一步，直接上引擎来演示，带个小投影，带个外星人，去给甲方领导看，岂不爽哉？所以我要说的是，这些事啊，一早就有人在做尝试了，可为啥后来没音了？尝试的人也多了去了，水晶石还只能算后知后觉的。这还不说CRY对美工的种种不友好。&br&&br&2、房地产类的VR，始于2000年前，盛于2004年前后。有一大波使用着VEGA、OGRE、OSG，&br&的规划类数字城市研发企业在给规划局做项目之余顺便搞些地产类项目来做做。而剩饭被一众使用盗版quest3d、virtools的小公司所瓜分。（当然还得顺便提一下国产：早已死去的3DVRI以及活到今天的VRP) 。当然当时还没有延迟渲染管线，而VRAY的烘焙还有缺陷不能用。但那时凭借渲染师的精湛功力，地产类VR（烘焙）的视觉效果已经做的非常棒了，有些完全不输于今天twinmotion或者lumion的效果。但这阵风很快就过去了，伟景行之类公司继续壮大做规划局的数字城市，其他VR企业很快销声匿迹了。为什么？原因其实很简单：你做条地产动画宣传片（或设计院用的设计方案报审片），刻张DVD出来每个人家里都能播，网上也能放视频，地方电视台还能当广告放，传播成本最低化，传播效应最大化，而且当时几个行业领头公司的建筑动画已经做的十分精美了，比这些VR的效果还是好的多的多。那时乔布斯还不知道在什么地方度假，IPAD是科幻片的产物。而一般人家里的电脑的内存与显卡你觉得能运行的动动辄几个G的VR场景？最苦逼的虚拟现实行业用的都是最贵的电脑好不好？我要是开发商我用这东西，除了大脑被门夹了没有别的解释----除了放在售楼处装逼，售楼小姐还不太会操作，而她们放碟可是很熟练的。换了你，为了传播面，你会选哪个？&br&&br&3、太阳底下没有新鲜事。在往前几十年的红蓝立体眼镜和片子咱按下不表，就说国内CG圈，2000年很多人就在玩红网立体眼镜了（快门式的哟）。这时恒润给常州恐龙馆做的片子已经是立体的。而水晶石2003年给北京规划馆做的规划片也是立体的了。可是谁能想到十年后阿凡达又平白无故的掀起立体的热潮，还带动了一帮傻逼电视机厂家和不明真相的消费者。而引爆这一波VR热潮的两千元的occlus和搜维尔十年前就开始代理的那些十几万软妹币的VR头盔，除了分辨率略大之外，有啥区别？笔者2002年就玩ZPRINTER打粉的3D打印机了，所以不能理解近三年来全社会对玩具级热熔融3D打印机的热情（参看拙作&a href=&http://user./973256/blog/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&user./97325&/span&&span class=&invisible&&6/blog/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）。&br&&br&当然了，新出来的东西拉低了价格，引爆了应用，创造了新的蓝海，就像是BMD公司愣把非线性编辑板卡从十几万拉到了几千人民币，此时刚好顺应了5D2所带来的微电影自己拍的热潮，所以商业上非常成功。&br&&br&但，从一个相当长的时间跨度来看，这些东西，跟以前，本质并没有什么不同。十年前如此，十年后没有什么根本的变化。VR本身就是个非常虚的概念，就像云计算一样，什么萝卜白菜都能往里装。VR最好的一个实例就是游戏行业。但除此之外，VR本身并不能独立成为一个价值创造者，你必须依附一个强大的行业应用才能变现（其实就是现在最时髦的羊毛出在猪身上）。这一点在VR技术有新的大爆炸之前是不曾变的，VR给城市规划用(就是3D GIS），政府买单。VR给建筑设计用（就是BIM），设计院和施工单位买单。（给应急指挥用，给军队和航天做战场仿真用，做驾驶模拟器用------等等等等这里不一一赘述）。&br&&br&但你单独拿建筑出来做个浏览-----------结合我前面说的第二点-----------有多少人买单？有人，的确有人，可有几个人？说大了这跟土地政策，房地产政策走势息息相关。跟国运有关。现在除了北上广往世界级城市世界级价格迈进之外，其他的地方，真的有这么奢侈的需要么？相信关注房价的人心里自然明白。这成本比做建筑动画片可只高不低啊。你说你是真爱，没问题。自己喜欢做可以，但开公司，一伙人是要等着发了工资回去买奶粉的。&br&&br&4.今年的UNITE大会我也去了。满眼的头盔们，不禁让我想起了手环们。我只能说炮灰你们好，虽然20年后我可能是将智能设备植入体内的最踊跃的人之一，虽然知道将来更美好，但是只能说目前这科技发展的必经之路上，你们还太样太森破。在某个技术奇点来临之前，你们与十几年前并无大的不同。&br&&br&保持对新技术的触觉和警觉是必要的，但为此欢呼雀跃乃至献身那是幼稚的。况且UNITY本身问题多多------为上市冲业绩，宣传各种非游戏行业应用（因为卖的实在太便宜了，又不像苹果一样在APP STORE上能收那么多钱）----------憋的EA来的新老板只好炒云和增值服务的概念了，你们信了，大中华区的艾伦他自己信么？就像是做果粉不要做成果蛆，信人信七分，剩下三分还须提防。&br&&br&5、扯远了，曾与一个干过几年用CRY做建筑VR漫游的哥们聊（当然现在不干了，不是画面做的好不好的问题，他做的很好），简直是字字血泪。他的结论就是-----------这是个伪需求。
是啊，这就跟KINECT虚拟试衣一样，真真是个伪需求。或者至少目前绝对是个伪需求。&br&&br&我就不分析VR了，我分析分析虚拟试衣吧-------如果是放在商场，其实女人逛街要的是一种感觉，甚至是在高档成衣店被伺候的感觉，你的KINECT能提供的么？所以在专卖店放台虚拟试衣是你们这帮臭技术屌丝的一厢情愿罢了。所以有人说试衣最合适的是在线上，对，淘宝的确合适啊，可是-------KINECT2数千元(因为是TOF的所以成本很难降下去）的成本谁来承担？就算是KINECT免费送，可不要忘了衣服模型谁来做？除非国内任何一个家庭成衣作坊都使用电脑裁片，激光切割-----------否则你的成衣模型谁来做？是20元一件还长三角包邮的淘宝店主来做么？？？&br&&br&也许有人会说，随着技术的发展，这些问题会解决的，没错！ 可能过几年某种技术大爆炸之后这些不是问题，不过那个时候，自动化程度那么高，你还能赚的到这份钱么?我看很难说。&br&&br&聪明如你，应该想到了我不只是在说kinect，我其实还是在说VR。
过几年手机或者虚拟头盔强悍到比PC性能还强时，画面也许不是问题了。建模贴图的成本也不是问题了，可你还能转到这份钱么？我看很难说。
首先在这个贴里我不会谈技术，因为这个问题根本不是技术问题。目前的主流“次世代”引擎（我痛恨这三个字，跟痛恨动漫与全息一样）大部分采用的延迟渲染管线，这等于把各种各样的效果分化成了一张张RTT过程最后进行合成，简直就像是三维做完了去AE里合成，…
&b&别把这种货色归入国产引擎的行列！&/b&&br&&b&别把这种货色归入国产引擎的行列！&br&&/b&&br&&b&别把这种货色归入国产引擎的行列！&/b&&br&&br&国产自研引擎真的不是这样子的，啊，大哥我求求你别拉低外界对我们的认知啊，我捐钱给你别再继续做下去好吧……
别把这种货色归入国产引擎的行列！别把这种货色归入国产引擎的行列！别把这种货色归入国产引擎的行列！国产自研引擎真的不是这样子的，啊，大哥我求求你别拉低外界对我们的认知啊，我捐钱给你别再继续做下去好吧……
泻药。我是 &a data-hash=&744f33e9e597ca0759251& href=&/people/744f33e9e597ca0759251& class=&member_mention& data-editable=&true& data-title=&@伟大的春春& data-tip=&p$b$744f33e9e597ca0759251&&@伟大的春春&/a& 中提到的光栅化软件渲染器SALVIA的作者。&br&&br&下面是小广告时间：&br&SALVIA的主页： &a href=&/p/softart/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/p/softa&/span&&span class=&invisible&&rt/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&这篇文章大概可以算是SALVIA从07年开始做到12年的一个整体回顾&br&&a href=&/lingjingqiu/archive//2858177.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&开源光栅化渲染器SALVIA的漫长五年（准·干货）&i class=&icon-external&&&/i&&/a&&br&&br&下面是针对你的情况做的一些补充：&br&&br&&ul&&li&首先你说你只有C#的基础，对C++这种需要手工管理资源的方式不是很适应。所以首先你需要阅读C++方面的书籍，尤其是C++11方面的内容，这会对你的开发大有助益。&br&&/li&&li&&b&掌握OpenGL或者D3D API的用法。&/b&你必须要知道你做的东西是用来干什么的，是怎么用的。&/li&&li&“光栅化渲染器”的关键，其实并不完全在于“光栅化”算法本身，更重要的是围绕着光栅化而做出来的一系列结构。&a href=&/en-us/library/windows/desktop/ff476882(v=vs.85).aspx& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&此篇内容&i class=&icon-external&&&/i&&/a&会给你一个很好的概念。当然出于简单起见，DX9级别的管线要更加简单。&/li&&li&在这整个结构中，实际上光栅化、插值以及Pixel的处理都相对简单，难点反倒是在Primitive的生成（也就是三角形的生成、变换、裁切）。光栅化算法可以使用教科书上的经典算法，就是先把三角形按照水平线切割成上下两个部分，再来按照斜率来计算水平像素的范围。比如说下图这样。这是我当时在ADSK做Team sharing的时候所讲的内容。&img src=&/ef317abd755e34b1da2ca39_b.jpg& data-rawwidth=&781& data-rawheight=&694& class=&origin_image zh-lightbox-thumb& width=&781& data-original=&/ef317abd755e34b1da2ca39_r.jpg&&&/li&&li&我当年的用的唯一“图书”，是&b&OpenGL 2.0 Specification&/b&。这一版的复杂度和DX9对应，既有提纲挈领的架构描述，也会精细到每个算法，&b&非常适合拿来开发&/b&。比OpenGL 2.0 Specification更好的材料当然也有，比如Direct3D 10 Functional Specification和D3D Reference Rast，但是这些都是在微软的NDA协议保护下，是很难见到的。&/li&&li&关于平台，你可以考虑先&b&把场景渲染成图片&/b&。&/li&&li&如果说着手的话，&b&顶点变换，基本的光栅化算法，再加上把覆盖到的像素以黑色，覆盖不到的像素以白色的方式，绘制成一个图片，这应该是最最基本的功能。&/b&在你的程序能将空间三角形能变成2D的图像后，你就可以慢慢往里面增加光照纹理等功能了。&/li&&/ul&&a data-hash=&1e2cccc3ce33& href=&/people/1e2cccc3ce33& class=&member_mention& data-tip=&p$b$1e2cccc3ce33&&@Milo Yip&/a&
泻药。我是
中提到的光栅化软件渲染器SALVIA的作者。下面是小广告时间：SALVIA的主页： 这篇文章大概可以算是SALVIA从07年开始做到12年的一个整体回顾下面是针对你的情况做的…
1. 高層&br&&br&深入了解各種計算圖形學及數字圖像學的算法，要知道它們要解決什麼問題，現存有那些解決方案，每個方案的優缺點是甚麼。書籍太多，不在此列舉，可參考本人的豆列：&br&&ul&&li&計算機圖形: 入門/API類 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445744/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: 進階/專門 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445680/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: Gems類 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445745/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: 專欄結集 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445806/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: 動畫 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445716/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: 相關數學 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1445735/&i class=&icon-external&&&/i&&/a&&br&&/li&&li&計算機圖形: 其他參考 &a href=&/link2/?url=http%3A%2F%%2Fdoulist%2FF& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&/doulist/1447740/&i class=&icon-external&&&/i&&/a&&br&&/li&&/ul&遊戲圖形程序員必讀的是《Real Time Rendering》（見進建/專門豆列），和shader有關的較前沿著作有《GPU Pro》叢書（見Gems類列）。&br&&br&計算機圖形學並不是追求物理上完全正確的解，而是觀眾／玩家看上去覺得好看。為了優化，有些問題可以通過近似化來減少運算，學習一些擬合函數（也需了解底層提供的現成函數），並作出嘗試。例如基於物理着色中的BRDF擬合[1]、SSS模擬[2]。&br&&br&有時候，可以分解一些複雜的函數，生成查找表（LUT）減少運算量，如下面[1]的示例：&br&&img src=&/32247cbadd61ae399fcbcabd_b.jpg& data-rawwidth=&668& data-rawheight=&307& class=&origin_image zh-lightbox-thumb& width=&668& data-original=&/32247cbadd61ae399fcbcabd_r.jpg&&&br&&br&2. 底層&br&&br&通常shader是圖形算法實現的一部分，程序員需要了解shader語言提供的指令，以及它們如何影射至更底層的匯編指令，有時候還要了解具體的GPU架構和特性。有些指令可能較少用，例如ddx/ddy這些，有時候能用於優化。可以參考shader語言手冊、各GPU廠商的官方文件，以及GDC的一些講座[3][4]。&br&&br&3. 數學&br&&br&如題主所言，數學佔了很大的部分，建議閱讀[5][6]，之後可以找相關數學的豆列。&br&&br&參考&br&&br&[1] Brian Karis, &Real Shading in Unreal Engine 4&, &i&ACM SIGGRAPH 2013 Courses: &/i&Physically based shading in theory and practice, ACM, 2013. &a href=&/publications/s2013-shading-course/& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/pub&/span&&span class=&invisible&&lications/s2013-shading-course/&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&[2] Colin Barré-Brisebois, Marc Bouchard, &Real-Time Approximation of Light Transport in Translucent Homogenous Media&, &i&Gpu Pro 2&/i&. Vol. 2. CRC Press, 2011. Slides: &a href=&//gdc-2011-approximating-translucency-for-a-fast-cheap-and-convincing-subsurface-scattering-look/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GDC 2011 – Approximating Translucency for a Fast, Cheap and Convincing Subsurface Scattering Look&i class=&icon-external&&&/i&&/a&&br&[3] Emil Persson, &Low-Level Thinking in High-Level Shading Languages&,
GDC 2013. Slides: &a href=&http://www.humus.name/index.php?page=Articles&ID=6& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Humus - Articles&i class=&icon-external&&&/i&&/a&&br&[4] Emil Persson, &Low-level Shader Optimization for Next-Gen and DX11&, GDC 2014. Slides: &a href=&http://www.humus.name/index.php?page=Articles&ID=9& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Humus - Articles&i class=&icon-external&&&/i&&/a&&br&[5] Lengyel, Eric. &i&Mathematics for 3D game programming and computer graphics&/i&. 3rd Edition, Cengage Learning, 2012.&br&[6] Schneider, Philip, and David H. Eberly. &i&Geometric tools for computer graphics&/i&. Morgan Kaufmann, 2002.
1. 高層深入了解各種計算圖形學及數字圖像學的算法，要知道它們要解決什麼問題，現存有那些解決方案，每個方案的優缺點是甚麼。書籍太多，不在此列舉，可參考本人的豆列：計算機圖形: 入門/API類 計算機圖形: 進階/…
来自子话题：
刚好我现在同时在开发两个2D游戏，一个是用Cocos2d-x，一个是用Unity3d。&br&&br&对于“&b&学习&/b&”而言，&br&Cocos2d-x是比较好理解的。它是传统的OOP结构，对于有编程经验的人来说，是最好不过了。就连Unity3d上，也有一个很火的2D框架，Futile，是模仿Cocos2d-x的架构和代码风格。从Cocos2d-x上手接触一下游戏引擎，是一个不错的选择。&br&&br&而Unity3d是Component-Based结构，对于OOP背景的程序员来说，一开始会觉得别扭。而且Unity3d有很多针对3d模型、3d动画、优化等等的商用功能，对于初学者来说会有点overwhelming的感觉。而且无论如何使用Unity3d，总需要在editor里进行大量操作，对理解游戏引擎和代码架构来说，并不是一个很好的方式。&br&&br&然而，从“&b&开发&/b&”的角度来说，&br&Cocos2d-x正如 &a data-hash=&d2cefa55c2bf& href=&/people/d2cefa55c2bf& class=&member_mention& data-tip=&p$b$d2cefa55c2bf&&@周华&/a& 所说，是一个“纯正”的引擎——仅仅只是代码库。虽然可以利用CocosBuilder和其他一些工具进行图形化操作，但效率始终不够Unity3d高。而且暴露过多的底层代码，对于&b&研究&/b&是一件大大的好事，但是对于&b&创作&/b&而言，未必是福音。&br&&br&而Unity3d则是一个高效的IDE+代码库。它很好地封装了底层代码，提供许多简便的图形操作，还有商业级的高级功能。对于开发而言，我认为是更好地选择。之前大多数开发者对Unity3d的认识还停留在3D开发，但2013年末的2D支持让更多人选择Unity3d进行2D开发。&br&&br&&br&所以我的结论是，通过Cocos2d-x或者是Unity3d上的Futile框架来入门，熟悉之后再过渡到Unity3d进行开发。:)
刚好我现在同时在开发两个2D游戏，一个是用Cocos2d-x，一个是用Unity3d。对于“学习”而言，Cocos2d-x是比较好理解的。它是传统的OOP结构，对于有编程经验的人来说，是最好不过了。就连Unity3d上，也有一个很火的2D框架，Futile，是模仿Cocos2d-x的架构和代…
任何图形引擎，都只是工具而已。游戏开发者们选择不同的引擎，是在考虑不同引擎带来的投入产出，但对玩家们而言，纠结于此并没有什么必要。开发者所使用的工具并不能决定作品的质量，跟外表是否炫目也没有必然关系。上图，给诸位直观的感受：&br&&br&&img data-rawheight=&841& data-rawwidth=&1440& src=&/fcc98cd5b41bb_b.jpg& class=&origin_image zh-lightbox-thumb& width=&1440& data-original=&/fcc98cd5b41bb_r.jpg&&良心厂家ATLUS的创意佳作Catherine，使用Gamebryo引擎&br&&br&&img data-rawheight=&800& data-rawwidth=&1280& src=&/1c90de3566eada132d82a1547ba8acc3_b.jpg& class=&origin_image zh-lightbox-thumb& width=&1280& data-original=&/1c90de3566eada132d82a1547ba8acc3_r.jpg&&Bethesda的传世佳作Fallout 3，使用Gamebryo引擎&br&&br&&img data-rawheight=&487& data-rawwidth=&780& src=&/ceeefca7f_b.jpg& class=&origin_image zh-lightbox-thumb& width=&780& data-original=&/ceeefca7f_r.jpg&&呃……古剑奇谭，使用Gamebryo引擎&br&&br&然而我又歪楼了……&br&图片来源于网络。&br&&br&-----------------------------------日添加-----------------------------------&br&感谢@徐若疾指出错误。修改原图的同时，寡人决定不那么含蓄……不然部分观众可能没法理解为何小众游戏Catherine可以被称为“创意佳作”。&br&&br&因为它，有创意，并且，呃……有张力……对。&br&&img data-rawheight=&275& data-rawwidth=&620& src=&/70eddffa937efb713bc9022_b.jpg& class=&origin_image zh-lightbox-thumb& width=&620& data-original=&/70eddffa937efb713bc9022_r.jpg&&&br&&img data-rawheight=&720& data-rawwidth=&1280& src=&/457d33c9c_b.jpg& class=&origin_image zh-lightbox-thumb& width=&1280& data-original=&/457d33c9c_r.jpg&&
任何图形引擎，都只是工具而已。游戏开发者们选择不同的引擎，是在考虑不同引擎带来的投入产出，但对玩家们而言，纠结于此并没有什么必要。开发者所使用的工具并不能决定作品的质量，跟外表是否炫目也没有必然关系。上图，给诸位直观的感受：良心厂家ATLUS…
来自子话题：
所谓整体架构，我的一点浅见：&br&&ul&&li&视野开阔，知道可以直接用哪个开源项目来满足这样那样的需求。多数时候其实我们并不需要重复造轮子。视野窄的架构师会放着捷径不走，不断让团队重复造轮子，直至把项目拖死。&br&&/li&&li&精通设计模式，但又不泛用。不设计过度，不在各种细节问题上需求蔓延。所有架构设计都是为了满足产品需求的，不满足需求或者过度设计都是菜鸟行为。&br&&/li&&li&把系统拆分成多个子系统或模块，模块之间尽量松耦合，使得原先只能串行的开发任务，可以并行开展，也就是说良好的设计可以通过投入更多人力来缩短工期。反之拙劣的设计需要一个人维护一大坨代码，无法通过加人并行开发来缩短工期。&br&&/li&&li&能清楚地知道系统的瓶颈在什么地方，不断地定位技术难度、研发进度、性能、内存等各方面的瓶颈，不断调整骨干力量解决瓶颈，在风险爆发之前就消除隐患。&br&&/li&&li&行业经验带来的直觉和预见性，可以预先需求可能产生怎样的变化，提前把可扩展性、后向兼容性设计好。但仍然不要过度设计。&/li&&/ul&所以直接回答楼主的问题：多看各种类型上比较知名的开源项目，多看别人的框架和技术成品，看看高手们是如何设计架构的，然后加上工作经验，之前趟过的坑都是你未来的知识财富。
所谓整体架构，我的一点浅见：视野开阔，知道可以直接用哪个开源项目来满足这样那样的需求。多数时候其实我们并不需要重复造轮子。视野窄的架构师会放着捷径不走，不断让团队重复造轮子，直至把项目拖死。精通设计模式，但又不泛用。不设计过度，不在各种细…
来自子话题：
玩《傳送門》眞哭過的滾來答題。&br&個人認爲《傳送門》絕對不是沒有淚點。衹不過它的淚點安排得相對含蓄而微妙，並不直白，而是可能需要細細品味、思攷。而品味之後，感觸可能更加深刻。&br&&br&&u&注意：以下內容嚴重劇透&/u&&br&&br&《傳送門1》和《傳送門2》在氛圍和敘事上已是兩種完全不同的風格，所以淚點類型自然不同。&br&&br&玩《1》時幾近落淚的瞬間，大多是後期某些關卡絞盡腦汁冥思苦想之後終於找到了解法時的歡喜和成就感吧。再加上《傳送門》系列獨特的設計和機制所鼓勵的特有的解題方式——衹要是實驗室的白色牆面，不管是往哪箇位置、哪箇角度、哪箇方向射出一箇傳送門，都可以使用（這也是《1》和《2》的一大不同：《1》的關卡裏白色牆面幾乎隨處可見，而《2》裏黑牆面的面積則普遍遠大於白牆面，很大程度限制了可玩性，有些關卡甚至可以說通關方式便是「找白牆」而已），這在鍛鍊玩家逆向思維的同時還讓玩家感受到手握Portal Gun時，可能性是多麽地無限大，通關方式可以多麽變幻無常，這都使成功通關時的那一份感動倍增。當初打通《1》第18關的那一刻，那份激動和蕩氣迴腸，依舊印象深刻（雖然那一關跟後來《2》的雙人模式最後一系列關卡相比簡直不是事儿好嗎）。&br&&br&但沒過多久，這遊戲讓玩家感受到的心情就TMD比這複雜了。&br&《傳送門1》中後期從單純的益智解謎遊戲到劇情逃殺遊戲的轉型是鄙人心中最經典的作品超展開之一。GLaDOS原本機械平淡的臺詞和語調漸漸變得冷酷惡毒，牆壁的裂縫中偶爾能瞥見的警示文字和塗鴉皆是先前的逃亡者苟且偷生時留下的痕跡，初體驗的玩家應該無不感到後脊樑一陣發涼吧。而當劇情迫使Chell孤身潛入光圈科技龐大繁雜而鏽迹斑斑的幕後時，眼前情景無不暗示着此處曾經發生過一場巨大的悲劇，玩家應該會發出這樣的感嘆：&br&「次奧，原來這是這樣一部遊戲啊！」&br&……這雖然還不足以戳淚點，但也足以讓玩家感到恐懼和一絲傷感。&br&&br&切入正題。&br&凡是提到《傳送門》系列卻不提靈魂角色GLaDOS的評論都是耍流氓。&br&&br&《1》裏我們對GLaDOS瞭解並不多：賤嘴毒舌、捉弄人心、謊話連篇、心狠手辣、殺人如麻，卻又能用她那份黑到超越三觀的幽默感讓你一邊笑得停不下來一邊又得甘拜下風。&br&《1》的劇情走入高潮之際，GLaDOS的定位看來是穩穩處在大反派位置沒錯了。最終章的一番苦戰之後，Chell和GLaDOS皆失去戰鬭能力，但都依然存活，《1》的故事告一段落……&br&而這時我們卻看到，啊不，聽到了GLaDOS與我們想像中不一樣的一面。&br&片尾主題歌（遊戲界無爭議神曲）《Still Alive》。&br&&blockquote&This was a triumph.
勝利已達成。&br&I'm making a note here:
我要記錄在案：&br&HUGE SUCCESS.
大成功！&br&It's hard to overstate
我心中喜悅之情&br&my satisfaction.
難以言傳。&/blockquote&這時我們聽到的GLaDOS的聲音，是之前從沒聽到過的，沒有被後期人工處理調節成電腦音的，清澈的人聲。與之相伴的曲調，輕鬆平靜。&br&&blockquote&I'm not even angry.
我都不生妳氣。&br&I'm being so sincere right now.
我現在眞心一片釋然。&br&Even though you broke my heart
任妳把我心打破&br&and killed me.
把我殺。&br&……&br&So I'm GLaD I got burned.
若能用這新知識&br&Think of all the things we learned
造福未死之人&br&for the people who are
被投入火海又&br&still alive.
算甚麽！&/blockquote&此刻我們方纔體會到，這臺親手殺了光圈科技幾乎全部員工的暴走AI（其實從某種角度上來講，她作爲超人工智能，如果認爲殺死人類員工後自己全面接管公司纔是使工作效率最大化的最佳方法的話，也實爲常理之中），心中也仍是會爲自己最初設定中的目標的達成——科學的發展進步——而感到眞切的喜悅的。拋開在《2》的一開頭，她和Chell重逢時忍不住的冷嘲熱諷挖苦辱罵，起碼在這一刻，軀體已經支離破碎的她，獨自回想起今天的這一場「空前成功的實驗」、Portal Gun展現出的神奇能力、以及最佳實驗對象Chell的優異表現，心中也許是滿足與自豪呢。（你看光圈科技畢竟是箇幹啥都以失敗告終的逗逼公司嘛，好不容易成功了一件事……好了，不黑了。）正是GLaDOS這兩面之間的強烈反差使得她的人格（沒錯，就是人格）如此耐人尋味吧。&br&而《Still Alive》其他段落的歌詞也頗有亮點，比如：&br&&blockquote&Now these points of data
數據點點相連&br&make a beautiful line.
成美麗一條線。&br&And we'
告別測試階段，&br&we're releasing on time.
趕上發售時間。&/blockquote&這種稍帶專業性的詞彙相互押着韻，配着副歌甜甜的旋律唱出來，還眞是俏皮得可愛呀。再加上最後的那幾句「老孃就是活得比你長比你滋潤比你好」，大家熟悉的賤賤的GLaDOS簡直又要從屏幕上的製作人員表裏躍出來一樣。&br&這裏一定要給GLaDOS的聲優Ellen McLain奶奶（人家身爲專業古典歌劇女高音，唱功必然了得，可給電子遊戲角色配音居然也這麽傳神眞是太棒）和機智幽默的作詞作曲家Jonathan Coulton點讚。玩家走到這裏，帶着打通全關的成就感聽到這首《Still Alive》，若是一邊笑一邊落下幾滴淚，相比也誰都能理解吧。&br&GLaDOS，妳這單純得跟孩子一樣的小魂淡。&br&&br&至此《傳送門1》結束。而我們從《傳送門2》得到的最大收穫，便是瞭解了GLaDOS的前世今生。&br&《2》的神展開，應該就是第五章最後GLaDOS的管理員身份被Wheatley強行奪取（她那一聲撕心裂肺的尖叫我聽一次心揪一次，Ellen奶奶您辛苦了），隨即在第六章開頭和Chell一起被放逐至50–80年代的「老光圈」設施內吧。&br&隨着玩家在荒廢的老實驗室裏的探索，真相逐漸浮出水面：光圈創始人Cave Johnson對科學研究的熱忱和執着，光圈陷入的一次又一次危機，企業的破產，Cave的中毒病逝，以及老光圈在走向滅亡之前最後的一次絕望的自救方案：強行將人腦轉化爲人工智能。而Cave曾經的得力助手Caroline便是在極度的不情願之下被強行改造成AI，喪失了道德和前世的記憶，名正言順地成爲了煥然一新的光圈科技領導者GLaDOS。&br&龐大空曠、年久失修的老光圈，此景便已足以讓玩家對這羣曾經一心爲科學奮鬭的人們感到唏噓不已。私以爲，第六章標題《The Fall》絕不僅是指Chell和GLaDOS順着電梯道跌落數千米的場景，更是指代了老一輩光圈科技悲哀的墮落史。&br&而GLaDOS在老光圈一遊之後，回想起了自己的前世，腦中更是聽見Caroline的聲音——也就是自己的聲音——喚醒並指引着自己心中的善良。她自然也是在竭力抑制，不讓這一面外露，但在接下來的一路上，和Chell並肩（不對）作戰、和Chell一起吐槽Wheatley的傻叉樣、和Chell逐漸化敵爲友，無不體現出她內心的轉變。對付Wheatley時，不惜冒着自己可能會死的風險大喊邏輯悖論（“This statement… IS FALSE! Don't think about it don't think about it don't think about it…” 矮瑪簡直萌哭了），幫Chell製定作戰計劃，在Chell差點要被吸入外太空之前一秒救她一命，GLaDOS所做的這一切可以說都是Caroline的功勞。&br&重新奪回管理員身份的GLaDOS，在Chell痊癒之後，對她說的第一句話是：&br&&blockquote&Oh, thank god. You're all right.&/blockquote&《1》裏的GLaDOS，又怎麽會如此簡樸直白地說出自己對另一人的關心？&br&她不再試圖殺死Chell，也不再刁難她，而是讓她自由地離開，回到外面的丗界。&br&道別前，她告訴Chell，她已經把Caroline的人格和記憶從自己的腦中刪除。&br&她眞的刪了麽？&br&私以爲，&b&絕對沒有&/b&。&br&她若是眞的想刪，又何必一直等到Chell醒來再刪呢？&br&唉，其實光是「她想以人類的身份感受一下和自己唯一的朋友告別」這箇解釋就已經很讓人傷感了吧。但並不是這樣。&br&&b&她一直把Caroline保存在自己的腦海裏。&/b&&br&在GLaDOS主控制室上方數十米，無數光圈炮塔爲乘着電梯緩緩上昇的Chell唱出了一首送別曲（每臺炮塔都是Ellen McLain本人配音）——歌詞是義大利文：&br&&blockquote&Cara bel,
親愛的，&br&Cara mia bella,
美麗的，親愛的，&br&Mia bambina,
我的孩子啊，&br&O! Ciel.
唉，天哪！（雙關：與「唉，Chell！」同音）&br&&br&Che ella stima,
她（指GLaDOS）如此尊重妳，&br&Che ella stima.
她如此敬佩妳。&br&O! Cara mia,
哦，我親愛的，&br&Addio.
再見了。&br&&br&La mia bambina,
我可愛的孩子，&br&Cara,
親愛的，&br&Perché non passi lontana,
妳何不從此遠離，&br&Sì, lontana da scienza?
沒錯，遠離科學呢？&br&&br&Mia cara,
我親愛的，&br&La mia cara,
我最親愛的，&br&La mia bambina.
我的孩子。&br&O! Cara,
哦，親愛的，&br&Cara mia…
我親愛的……&/blockquote&生前的Caroline和成爲實驗對象的Chell當年究竟是甚麽關係，我們無從得知。遊戲給出的線索表明Chell確實是光圈科技某位員工的女兒，該員工在200X年光圈組織的「帶自家女兒前來參觀工作日」連同數百位其他員工被失控的GLaDOS用神經毒素殺害（Chell爲此活動還做了箇土豆電池來參展，就是後來展廳裏那顆和Chell本人一樣頑強，長得大到能夠到天花板的土豆，展版上能看到Chell的署名）。Chell於此事件中倖存，之後被俘於實驗室，成爲光圈實驗對象之一。官方給出的短篇外傳中的隻言片語似乎表示了Caroline並不是Chell的母親（況且還有Chell生父母養父母不同之理論，實在不好得出確切的結論），但從送別曲的歌詞能夠看出，Caroline在被強行轉化爲機器人之前，對Chell來說也一定是一位如母親一般親近的存在。&br&而現在的GLaDOS，一定也回想起了當年尚是人類的自己，曾經照顧過、關愛過Chell。&br&她之所以放她走，讓她永遠離開這座險惡的實驗室，&b&是爲了保護她愛的這箇孩子啊&/b&。&br&而她特意宣告自己已將Caroline刪除，是想告訴Chell：「不要以爲妳認識的那箇人還會在這儿——這樣妳應該就沒有理由再回來了吧。」&b&爲了Chell的安全，GLaDOS撒了她的最後一箇謊&/b&。&br&眞的，她怎能忍心刪掉Caroline？&br&&br&聽着送別曲的尾聲，看着Chell走向一望無際的麥田，已經不由得落淚。&br&&br&但《2》的片尾曲《Want You Gone》纔是&b&最後一擊&/b&。&br&那彷彿是一箇即將與往昔常常撕逼後來卻又共同患難的長年老友分道揚鑣，心中雖充滿不捨，卻強顏歡笑，裝作漠不關心的人的話語。&br&&blockquote&&p&You want your freedom?
妳想要自由？&/p&&p&Take it.
拿去吧。&/p&&p&That's what I'm counting on.
我正期望如此。&/p&&p&I used to want you dead but
我曾恨不得妳死，&/p&&p&now I only want you gone.
現在我衹求妳走。&/p&&/blockquote&&p&（副歌這兩下猛地往上一提的高音讓我服得五體投地）&/p&&blockquote&&p&She was a lot like you.
她跟妳還蠻像。&/p&&p&Maybe not quite as heavy.
比你稍苗條一點。&/p&&p&Now little Caroline
現在小Caroline&/p&&p&is in here too.
也在我這儿。&/p&&/blockquote&（看，承認沒刪了吧）&br&&blockquote&&p&You've got your
妳還有&/p&&p&short sad
苦短&/p&&p&life left.
人生。&/p&&p&That's what I'm counting on.
我正期望如此。&/p&&p&I'll let you get right to it.
趕快開活吧妳就。&/p&&p&Now I only want you gone.
現在我衹求妳走。&/p&&/blockquote&&p&聽到這裏答主已經像剛打完《1》時一樣一邊笑一邊哭了……&/p&&blockquote&&p&Goodbye my only friend.
再見啦，好朋友。&/p&&p&Oh, did you think I meant you?
哦？妳以爲我說妳吶？&/p&&p&That would be funny
根本不好笑，好嘛，&/p&&p&if it weren't so sad.
簡直悲哀。&/p&&/blockquote&唉，其實我們還不是都知道，眞正悲哀的，正是GLaDOS她自己。&br&&blockquote&Well you have been replaced.
妳已經被取代。&br&I don't need anyone now.
我不需要別人啦。&br&When I delete you maybe
等我把你也刪掉，也許&br&&b&[REDACTED]
［此句不予顯示］&/b&&/blockquote&屏幕上的字幕，打出一行「此句不予顯示」，但我們同時卻清清楚楚地聽見，GLaDOS唱出的，是這樣的一句——&br&&blockquote&&i&I'll stop feeling so bad.
我就也不會這麽難受了吧。&/i&&/blockquote&眼淚奪眶而出。可惡。妳箇可憐的死傲嬌。（不過確實GLaDOS是極少數我非常喜歡的傲嬌系角色之一，其傲嬌有理有據，有因有果，讓人深有感觸，不像某些其他角色，衹是爲了湊設定而被硬加了這箇特點，咳咳，遠坂凜，咳咳，牧瀨紅莉棲。）&br&她當然刪不掉對Chell的回憶啊。&br&在《2》的雙人模式中，GLaDOS依然會在實驗途中通過廣播向ATLAS和P-body提到當年和Chell經歷的種種往事。Chell已經得到最好的結局。GLaDOS更怎忍心忘掉。沒有這份人類情感，又哪來後來那箇會被一隻小鳥嚇得驚慌失措的可愛的GLaDOS。&br&&br&其實《傳送門》系列很多其他角色的故事也很戳淚點，比如中傳漫畫《Lab Rat》裏爲拯救Chell一命不惜犧牲自己的Doug Rattman，他與Companion Cube之間的友愛，Chell對生存的執着和解決一切艱難險阻的決心，等等。&br&&br&不過鄙人本命衹有那誰啦。
玩《傳送門》眞哭過的滾來答題。個人認爲《傳送門》絕對不是沒有淚點。衹不過它的淚點安排得相對含蓄而微妙，並不直白，而是可能需要細細品味、思攷。而品味之後，感觸可能更加深刻。注意：以下內容嚴重劇透《傳送門1》和《傳送門2》在氛圍和敘事上已是兩種…
视野放开阔点，行业发展到高级阶段，会朝两个方向发展：标准化和组件化，分离出各种上下游的中间商出来，逐渐形成完善的产业链。不当包括引擎，图形，未来游戏还会分离出越来越多的服务提供商和中间技术：&br&&br&比起端游时代，除去熟知的引擎外，页游和手游形成了各种上下游的中间技术：&br&&br&帐号服务：页游时代演化出来，多个运营平台，一套唯一的接入模版，省去每家对接的工作。&br&统计服务：比如友盟&br&社区服务：比如给游戏提供通用好友系统，私信系统，提供统一论坛&br&视频服务：给游戏提供视频录制和点播分享服务&br&广告服务：积分墙服务等&br&商城服务：通用内嵌道具帐号交易平台&br&云主机：大规模VPS，代替自己采购服务器弄 IDC&br&加速云：提供网络接入加速&br&图片云：提供图片缓存&br&更新云：下载更新，增量更新，灰度更新服务&br&数据云：CDN，对象存储，游戏玩家数据文件夹云端同步&br&语音云：给游戏提供语音识别（比如百度和讯飞），语音聊天等功能&br&数据库服务：统一的数据库 mongo/ 分布式 mysql/ redis 服务&br&测试云：云评测&br&。。。。&br&太多了，还有各种标准模块：&br&标准 AI 技术：框架 + 编辑器&br&标准地图编辑器：比如 tiled&br&标准界面编辑器：各引擎&br&标准特效编辑器：各引擎&br&即便是写代码本身，各种库和第三方的插件也已经越来越成熟&br&&br&对于开发游戏而言，无疑是更加便捷和简单的。就连美术外包，也可以很快速的按照u3d, cocos2d的规范进行出图，这就是标准化的好处，游戏能够更快捷的使用各种标准化的组件合成。&br&&br&对于注重游戏实现的程序员来说，可以把精力放在如何用好各种引擎和中间技术上来。游戏开发本来就应该越来越简单，才能符合发展规律。现在游戏开发是组合各种现有技术，过两年估计会直接发展成拖控件（看国外一些编辑器，基本快做到这个地步了）。&br&&br&难说以后有一天，中间技术充分发展，不需要游戏程序员了，策划对着话筒说一句：“我要个 SLG，Clash of Kings 那种，美术用哥特式，恶魔城那种，故事背景是《权力的游戏》月流水2000万以上的”，然后点一下 “生成”，一个游戏就出来了。。。。&br&&br&任何一个行业都是这样，比如前两年热门的医疗行业，现在也出分离出各种上下游的中间商来，形成了成熟的产业链。游戏也一样，从最早研发运营一家做到页游时代的研发运营分家，又到现在的研发继续分离出各种上游服务提供商和下游产品整合商来，运营也进一步分成很多互相依存的上下游。&br&&br&对于注重游戏技术的程序员来说，分工越来越明确，如果觉得实现游戏没难度，大可以去各种中间技术提供商那里寻求工作，比如你爱开发引擎，可以去cocos2d开发去，未来还会有更多图形引擎出现，不单cocos和 u3d，游戏类型不同，引擎各有侧重，可能还会有更多的 xxxx3d, xxxx2d 出现，喜欢图形的程序员自然可以去这些公司寻求工作，这样分工以后，开发引擎的引擎会越做越好，开发游戏的也会越做越熟练。&br&&br&不会存在扼杀程序员对技术探索这样一个情况出现，你如果想探索技术，选择你感兴趣的方向在别人没能力的情况下，给游戏提供更好的中间技术服务（或者去这些技术服务提供商工作，不需要专门开发游戏），并且说服游戏可以降低他们的各种成本，比如七牛云，未来会有越来越多的各种中间技术以云服务的方式提供出来，供游戏使用。只要你够牛逼，提供出来的技术有价值，你总能活的很滋润。
视野放开阔点，行业发展到高级阶段，会朝两个方向发展：标准化和组件化，分离出各种上下游的中间商出来，逐渐形成完善的产业链。不当包括引擎，图形，未来游戏还会分离出越来越多的服务提供商和中间技术：比起端游时代，除去熟知的引擎外，页游和手游形成了…
来自子话题：
整个 CG 领域中这三个概念都是差不多的，在一般的实践中，大致上的层级关系是：&br&材质 Material包含贴图 Map，贴图包含纹理 Texture。&br&&br&纹理是最基本的数据输入单位，游戏领域基本上都用的是位图。此外还有程序化生成的纹理 Procedural Texture。&br&&br&贴图的英语 Map 其实包含了另一层含义就是“映射”。其功能就是把纹理通过 UV 坐标映射到3D 物体表面。贴图包含了除了纹理以外其他很多信息，比方说 UV 坐标、贴图输入输出控制等等。&br&&br&材质是一个数据集，主要功能就是给渲染器提供数据和光照算法。贴图就是其中数据的一部分，根据用途不同，贴图也会被分成不同的类型，比方说 Diffuse Map，Specular Map，Normal Map 和 Gloss Map 等等。另外一个重要部分就是光照模型 Shader ，用以实现不同的渲染效果。
整个 CG 领域中这三个概念都是差不多的，在一般的实践中，大致上的层级关系是：材质 Material包含贴图 Map，贴图包含纹理 Texture。纹理是最基本的数据输入单位，游戏领域基本上都用的是位图。此外还有程序化生成的纹理 Procedural Texture。贴图的英语 Map…
按照以往的经验，Source2或将会是Source系列最后一代游戏引擎。
按照以往的经验，Source2或将会是Source系列最后一代游戏引擎。
来自子话题：
2014.02更新：请放心选择 Lua 吧。触控已经收购了 quick-cocos2d-x，2014年肯定会大力强化 cocos2d-x 的 Lua 支持。&br&&br&----&br&&br&我个人肯定是推荐 Lua 的，原因如下：&br&&br&1. 运行效率：Lua 的性能在各种测试里都比 JavaScript 快不少。而移动设备上存在不支持 JIT 的情况（未越狱的 iOS 设备），Lua 对比 JavaScript 的性能优势就更明显。&br&&br&2. 安全性：现在 cocos2d-x 使用 LuaJIT 来执行 Lua，所以可以把 Lua 代码编译为字节码再打包到游戏里。由于 LuaJIT 的字节码是高度优化过的，所以目前还没有反编译工具。而 JS 虽然也可以用字节码，但从目前的情况看还达不到 LuaJIT 的安全性。&br&&br&3. 与 C/C++ 的交互：Lua 原本就是作为嵌入式语言来设计的，所以天然和 C/C++ 很容易交互。JS 这方面是个劣势。&br&&br&4. 与 Java/Objective-C 的交互：不管是 quick-cocos2d-x 里提供的 luaoc/luaj 模块，还是 wax, luajava 这些开源项目，都让我们可以绕过 C/C++ 层实现 Lua 和 Java/Objc 的交互。这个优势在游戏发行阶段，集成各种第三方 SDK 时绝对会节约巨量时间！！！&br&&br&----------------------------------------&br&&br&当然，cocos2d-x 目前明显是在主推 JS 的解决方案，因为 JS 可以跨越移动设备、桌面的界限，实现一套程序跑任意平台。不过我个人认为以当前 HTML5 的发展情况，对于要强调体验的游戏来说，HTML5 还要一些时间。&br&&br&从目前的市场情况来说，Lua 明显是更理性的选择：成熟、安全性高、众多大作采用。&br&&br&----------------------------------------&br&&br&前面提到 JS 更容易面向对象，我想可能是因为大家对 Lua 还不够了解造成的错觉。实际上，Lua 和 JS 实现面向对象的机制几乎是一样的。JS 基于 prototype，Lua 基于 metatable，在我看来仅仅是名字不同而已。&br&&br&----------------------------------------&br&&br&最后，不得不向大家推荐 quick-cocos2d-x 这个基于 cocos2d-x + Lua 的扩展版。quick 在 cocos2d-x + Lua 的基础上提供了诸多简化开发的扩展功能，以及开发框架。&br&&br&quick-cocos2d-x 中文站： &a href=&http://cn./& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&cn./&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&
2014.02更新：请放心选择 Lua 吧。触控已经收购了 quick-cocos2d-x，2014年肯定会大力强化 cocos2d-x 的 Lua 支持。----我个人肯定是推荐 Lua 的，原因如下：1. 运行效率：Lua 的性能在各种测试里都比 JavaScript 快不少。而移动设备上存在不支持 JIT 的情…
来自子话题：
你说的这个东西一点都不新鲜，而且已经被历史证明是失败的——它就是任天的WIIU的运行原理。&br&&br&WIIU就是主机运行游戏，然后投射到带显示器的手柄上。&br&&br&而微软走的更远，即所谓的云游戏概念——玩家的输入指令通过XBOX ONE传递给微软服务器，游戏本身运行在微软的大型机上，能实现好莱坞电影级别的画面，将压缩后的视频流传递给玩家的屏幕。我觉得这个方案在商业上基本属于是幻觉，但是技术上确实可行。&br&&br&“解决了目前大部分游戏不支持Linux的问题”，哪有这回事？&b&你还是需要原来的主机——不管是PC还是MAC——来运行游戏本身，STEAM本身的兼容性仍然是0，而且永远都会是0。&/b&你觉得大多数人是愿意不花钱把主机搬到另一个房间，还是再花几百买STEAM？&br&&br&这东西甚至还不如老式的游戏机，PS3只要视频用无线HDMI输出到电视上，手柄就用原来的，照样也能实现在隔壁玩游戏。&br&&br&串流技术最大的潜力，是单主机运行多个进程，然后通过无线网络分配给几个玩家，可以实现一台主机供多人玩不同的游戏，STEAM就相当于当年的NETPC终端。&br&&br&我是希望，看不起传统主机游戏的行业新贵们，能稍微花点时间，学习一下游戏史。&b&我这些年看到的新兴游戏业的所谓“创新”，九成都来自抄袭者出生前的某个古董产品。&/b&重新发明轮子还好，重新发明三角形的轮子，那就是有病了。&br&&br&&img data-rawheight=&533& data-rawwidth=&800& src=&/b6dc85c0b10a510a8e7ed8ff_b.jpg& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/b6dc85c0b10a510a8e7ed8ff_r.jpg&&
你说的这个东西一点都不新鲜，而且已经被历史证明是失败的——它就是任天的WIIU的运行原理。WIIU就是主机运行游戏，然后投射到带显示器的手柄上。而微软走的更远，即所谓的云游戏概念——玩家的输入指令通过XBOX ONE传递给微软服务器，游戏本身运行在微软的…
来自子话题：
准确地说，代码作为Unity项目里的一种资源，此问题应该扩展到如何组织Unity资源。简单说说我们的经验：&br&- Unity有一些自身的约定，譬如项目里的Editor,Plugins等目录作为编辑器，插件目录等等。知名的插件会自己存放一个目录，譬如NGUI等。&br&
所以我们自己的代码，一般目录名会以下划线开头，譬如 &_Scripts&, &_Prefabs&等。&br&
对于场景，文档等目录，用两条下划线，以便他们能排在最顶部。&br&- 代码用C#，别用JS。必要的话用namespace将自己的代码括起来。我们是用namespace把自己积攒的公用库包住。&br&- C#的注释要认真写，打///就能帮你补全了，没理由偷懒。&br&- 每个程序文件开头要用一段注释写修改Log，谁改过什么简单留一条说明。就算用了Unity的版本管理或者Git，那些log终究会丢失，只有认真把log写在代码里，才会有意识去认真优化它。&br&- Unity的脚本逻辑，就功能而言大体分为两种，一种是比较独立的，譬如爆炸之后1秒钟消失，这种单独写个脚本绑定到目标上即可。&br&
更多的是脚本里与其它的脚本进行交互。Unity里提供了一种万金油的方法是SendMessage, 这种方法性能略差，如果你调用的频率不高，随便用也无妨。另一种方法是直接通过对象的实例去调用。&br&&br&
我们的做法是写几个公用的控制器，让它们各司其职，负责各自的事情：&br&- 写一个一个GlobalManager.cs来控制游戏的全局变量及全局方法。静态类模式。譬如当前玩到第几大关第几小关，玩家的金币数量等。&br&- 写一个GameController.cs来控制当前关的游戏进程。单实例模式。游戏的主循环也是用它控制。初始化，胜利、失败判定等等。&br&- 写一个InputController.cs来控制所有的用户输入。单实例模式。鼠标、键盘、触摸屏，我们做游戏是保证同时支持这三种输入的，因为大部分时间是在PC上测试。&br&
关于GameController与InputController的联系，有点让人纠结。一般来讲是在InputContoller里调用GameController.Instance.Foo()执行方法。或者直接对Input写成Listener的模式，让GameController去监听。&br&- 其它的类似菜单控制器，声音控制器，成就控制器，IAP虚拟道具控制器等等，也是采用类似的方法管理。&br&- 关于PlayerPref的操作，统一写成静态类的get/set模式，程序中哪里要用则直接读写。&br&- 如果你的项目里场景的数量少(&5)，那么拖入场景的资源可以很随意。如果场景数量很多（几十个，有的解谜游戏每个关卡就是一个场景），那么拖入场景的prefab数量一定要少。&br&- 设计你的prefab资源里，你要想像当其他人拿到这些资源，是否直接拖入一个空场景里就能run，顶多再简单设置几下。如果你设计的资源不能做到这些，那么得好好重新想想。&br&&br&&br&写了这些，感觉写不下去了。&br&想吃透Unity，起码得真做出几款产品放上线才行。真正做产品的过程中会碰到各种各样意想不到的问题，代码不断地被重构和妥协，不存在什么最佳的方案。&br&暂时就写这些吧，希望能抛砖引玉。
准确地说，代码作为Unity项目里的一种资源，此问题应该扩展到如何组织Unity资源。简单说说我们的经验：- Unity有一些自身的约定，譬如项目里的Editor,Plugins等目录作为编辑器，插件目录等等。知名的插件会自己存放一个目录，譬如NGUI等。 所以我们自己的代…
1、不作。&br&&br&这两个字是最重要，在出来前没有大肆宣传画面多好，没有宣传故事多么感人，甚至也没怎么谈情怀，降低了大家对于游戏的心里预期，拿到以后一看卧槽远超预期，自然口碑就好了。&br&&br&2、游戏性强。&br&&br&无论是开放式的游戏剧情还是战旗的战斗模式都打磨的非常合适，无论正邪，无论专心练武还是专心泡妞都能在游戏里找到自己的位置，而且整个过程完全不觉得乏味，这在国产游戏里是极其少见的。&br&&br&3、有骨气。&br&&br&仙剑系列最坑爹的就是受现在网游和海外游戏影响太严重，总是想要在游戏内借鉴一些其他的东西，把这么多年积攒下来玩家对游戏真正的爱消耗殆尽，不是说创新是错的，但是你至少留着你游戏的主心骨。《侠客风云传》好就好在了很有骨气的坚持了当年的东西，事实证明是完全正确的。&br&&br&4、没有犯大错。&br&&br&《侠客风云传》有一堆零零碎碎的小问题，比如进度条太多，比如画质也有点渣，比如也有一些零零碎碎的Bug，但都没有出现让人无法玩的问题。仙剑6就坑爹多了，那个配置首先就阻止了多数人游戏，之后各种跳出的硬性bug，很难相信游戏上线前经过测试。
1、不作。这两个字是最重要，在出来前没有大肆宣传画面多好，没有宣传故事多么感人，甚至也没怎么谈情怀，降低了大家对于游戏的心里预期，拿到以后一看卧槽远超预期，自然口碑就好了。2、游戏性强。无论是开放式的游戏剧情还是战旗的战斗模式都打磨的非常合…
来自子话题：
为啥日报上王哲得回答跟这里不一样？
为啥日报上王哲得回答跟这里不一样？
针对题主问题一条一条写吧，想到哪写到哪，本身水平也有限，未必是什么真知灼见。&br&&ol&&li&cpu 的数学性能一般不是热点，且 vector 的下标用法不多（至少本人如此），UE 暂时没有优化到我可以理解，相反，读过一些执着于一点点 math 之类的小优化，虎头蛇尾的开源引擎；&/li&&li&与其纠结于这点优化，倒不如看看 U3D 的 Mathf 在 c# 和 cpp 的扯皮中消耗的上百倍性能损失，参见：&a class=& wrap external& href=&/threads/pinvoke-mono_add_internal_call-c-and-c.172886/& target=&_blank& rel=&nofollow noreferrer&&PInvoke, mono_add_internal_call, C and C#；&i class=&icon-external&&&/i&&/a&&/li&&li&位于 GameFramework 层的 Actor 这么重要的类的 TakeDamage 接口确实刺眼，哪怕只是在 GameFramework。但官方为一个接口来写一篇博客也是极为罕见的，参见：&a class=& wrap external& href=&/blog/damage-in-ue4& target=&_blank& rel=&nofollow noreferrer&&Damage in UE4&i class=&icon-external&&&/i&&/a&，或许可以试图理解下 Epic 的这个观点：“Damage” is a common concept in games, so I wanted to give a quick
primer on the damage functionality we’ve included in the UE4 game
framework.我觉得这是务实；&br&&/li&&li&系统扩展相关的，UE 在这方面确实做的有点不一样：通过类型系统来扩展功能，大量使用虚函数和向下类型转换，但配合 blueprint 拥有继承 cpp 类这个能力后貌似并没有那么糟糕，类型非常的廉价，这也是另一种探索吧；&br&&/li&&li&我也认为 UE 在编辑器架构上不如 U3D，曾经写过：&a class=&internal& href=&/question//answer/&&为什么Unity3D能够产生如此多的插件（中间件）？ - 无瞳的回答&/a&，甚至 UE 也承认，诸如：Lightmass is an old tool, and it takes some tender loving care to be used properly.（来源：&a class=& wrap external& href=&/showthread.php?67479-Feature-Request-Fix-Heavy-Optimization-and-something-to-think-about&p=277207&viewfull=1#post277207& target=&_blank& rel=&nofollow noreferrer&&Feature Request/Fix&i class=&icon-external&&&/i&&/a&），但是以我浅薄的见识，我还没见过第三个在工作流、扩展性、易用性等方面和他们能抗衡的引擎，当然，适不适合特定的项目那是另一回事；&/li&&li&退一步说，编辑器架构上，UE 也不是一无是处，比如 UE 这个级别的资源引用关系处理，U3D 根本做不到，更新 5.0 之后也不过是稍微做了点改善。UE 毕竟是几十年的演化，不好看是事实，但是多数功能要强 U3D 太多了：U3D 的时间轴编辑、寻路、动画、资源管理甚至粒子等都是糊涂账，哪怕是上面一条刚刚批判过的 UE 的 Lightmass，U3D 不支持分布式烘培更加灾难；&/li&&li&cpp 反射不是一个罕见的问题，从几十年前的 mfc、基于模板、基于宏、基于特定的 parse 工具、基于调试符号分析、基于 LLVM 等等，这么久的努力大家还不放弃，其作用远远不止为了支持 BP 这么单纯（比如编辑器、序列化、网络同步），其实稍微靠谱点的 cpp 引擎都会实现个类似的东西，用处太广了，甚至可以说是一些架构方案的核心。具体到 UE，属于非常的务实的基于自定义 parse 工具，比 qt 的实现功能多和杂点，但不乱，设计出来的都是作为程序员有痛点的，不能因为个别功能、实现暂时用不到或不理解，就否定他的价值，毕竟各种程序语言的 feature 在工业使用的时候，大凡出现了总有它诞生的目的，总存在适不适合当前场景的问题；&/li&&li&当然，再怎么改造 cpp，结果可能都不如 U3D 直接用 C# 完善（毕竟以微软之力当年也在 com mfc 改造 cpp 失败之后从此粉转黑搞 .net 了），比如 U3D 在移动平台的 ByteCodeStripper 来减少内存，比如 UE 代码写起来格格不入。不过我觉得这也还是能理解和接受的，并不是说 UE 做的对或者不对，凡事总有取舍，而 UE 选择了这条路，仅此而已，这篇著名的帖子很多地方都有贴，就不再多阐述了，链接：&a class=& wrap external& href=&/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1& target=&_blank& rel=&nofollow noreferrer&&Why C++ for Unreal 4? &i class=&icon-external&&&/i&&/a&
在 cpp 体系下，UE 已经是翘楚，很难和 .Net 一个平台的积累抗衡，另一方面 .Net 也有自己的取舍，后面有简单提到一些；&/li&&li&就是因为 UE 代码写的不舒服，Epic 在官方文档手把手教配置 VS、VA （&a href=&/latest/INT/Programming/Development/VisualStudioSetup/index.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/l&/span&&span class=&invisible&&atest/INT/Programming/Development/VisualStudioSetup/index.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&），写好了 VS 的代码片段提示 .snippet（Engine\Extras\VisualStudioSnippets），VS 自定义数据结构显示优化 .natvis（Engine\Extras\VisualStudioDebugging），开源了 UnrealVS（&a href=&/latest/INT/Programming/Development/VisualStudioSetup/UnrealVS/index.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/l&/span&&span class=&invisible&&atest/INT/Programming/Development/VisualStudioSetup/UnrealVS/index.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）。而 U3D，官方直接拿开源的 MonoDevelop 就当交差了，剩下的社区自己想办法解决。并不说 UE 做的多好，但起码可以看出这是一个世界顶尖团队负责任做出的决策；&/li&&li&Blueprint，代码里面代号是 Kismet2，是 UE4 对游戏业务逻辑层编程在 UE3 Kismit 之后新的探索，是 Unreal 对游戏架构设计层次的理解，这套理解在 UE3 这么多年实践中应该算是经受了时间的考验。这个领域并不罕见，U3D 也有 playmaker 这样的插件，暴雪的炉石传说里面也用到了，只不过不同于 playmaker 易懂（也更脆弱）的状态机模型，bp 选择了另一条更复杂的路而已。当然可以不认同这种设计，但我觉得是需要在真正的理解了创造者的想法之后；&/li&&li&具体对 Blueprint 的个人理解，因为需要拿出同层次的方案（诸如基于脚本（跨语言）的多种设计思路、可视化状态机思路、类 IOC 配置思路等）来横向对比，非三言两语说清，且多数都是个人浅薄的理解，评点高层的设计需要更高的水平和经验，没有足够的把握也就不多卖弄了。这里只简单针对 bp 的大规模使用，感觉确实还不够成熟：我的理念里把一件事做好要么简单到使用者都能轻松理解，要么完善（也往往意味着复杂）到使用者不需要理解，bp 貌似走的是后一条路，如今却只走了一半。而小规模使用，比如基于关卡级别的独立逻辑、独立对象动画的流程处理等场景，用蓝图很合理；&/li&&li&Blueprint 现阶段最大的问题我觉得可能是这样的：官方在还没把它做完善的情况下就急着大规模推广，启动器默认的例子大片的 Blueprint，让很多开发者对其产生了不必要的幻想（也许市场部是 U3D 挖过来的：美术不需要写代码就能做游戏）。但与此同时，官方也把虚幻竞技场2014（UnrealTournament）开源了，里面对蓝图的使用非常的节制，但真正有必要用到蓝图的地方也不会随便用 cpp，属于非常正规的商业项目例子，我在阅读过程中受益匪浅；&br&&/li&&li&当然，如你所说也有走脚本+配置的流派，并且做的也很优秀，比如暴雪星际争霸的银河引擎：galaxy语言+网状连线配置，公认的复杂。当复杂到这个级别，需要考虑诸如资源引用维护、配置完善的序列化反序列化、工具链支持（无论是 editor 还是 runtime 的反射等支持）、跨语言中间层扯皮的性能和维护等等等等，所需要付出的也许并不会比 UE 做的少。另一方面，如果不付出这些努力，可能会发现这些体系依然非常难用，具体例子可以在研究银河系统之后假想，没有它那套可视化资源链接关系处理，设计一套复杂的网状技能引用是否现实（本人山寨一半放弃了，换用折中思路）；&/li&&li&Wow 使用 Lua+XML 做 UI 层次的插件体系也很成功，在规模和复杂度降下来之后这类方案也拥有简单到人脑可以接受的范围内的好处（很高兴，山寨成功过），归根结底，是这个行业的先驱的不懈探索，没有银弹，游戏的复杂性远不是一句加上 js lua 做脚本就可以解决的，所谓的 KISS 都是有前提的，做的越多想保持简单越难，规模和复杂度经常是指数关系；&br&&/li&&li&如果坚持要做第三方脚本支持， UE 官方也有方案：ScriptPlugin（Engine\Plugins\ScriptPlugin\Source\ScriptPlugin\Private\LuaIntegration.h），链接：&a class=& wrap external& href=&/showthread.php?3958-Scripting-Language-extensions-via-plugins& target=&_blank& rel=&nofollow noreferrer&&Scripting Language extensions via plugins&i class=&icon-external&&&/i&&/a& 。回头看 U3D 在这方面的支持：iron 系语言受制于 jit ios 无法使用；c 系语言受制于 c#、c、脚本本身的沟通性能瓶颈，犹如隔靴挠痒。凡事看两面，.Net 带来的巨大好处反而约束了这些场景；&br&&/li&&li&游戏行业一直就有定制语言的传统，哪怕把 lua 推广出来的暴雪，war3 用的是 jass，sc2 用的是 galaxy，至于原因：性能、类型强弱，静动态，语言集成的状态机、协程等异步、需不需要脚本继承 cpp、面向对象支持的程度、粘合中间层的处理、对反射属性等语言特性的支持程度，还有很多不一一去想了。pl 领域的优秀实践从来就没有停止过，比如今天 await 这种优秀的异步实践，python js 等都开始支持了，为什么游戏领域就不能尝试一下呢，再比如 rx、linq 这类的设计理念也需要语言层做直接支持；&/li&&li&一如下文对 Unreal4 和 U3D 的评价：U3D 的优秀很多时候只是因为做的更少，Unreal 4 is still young compared to Unity (let's be honest, you can
hardly call Unity 5 a new engine either). Comparing the two is
relatively futile, since they both have completely different end-users
in mind. &b&Unity might run better on lower spec hardware but that's not
because it's more optimized or 'better' - it's because it's less complex
and doing less stuff. Of course there's always room for improvement in
places hence the case above&/b&... but it's still a young engine, which has
changed a lot in the last year alone.（来自上面的链接的另一楼：&a class=& wrap external& href=&/showthread.php?67479-Feature-Request-Fix-Heavy-Optimization-and-something-to-think-about&p=277120&viewfull=1#post277120& target=&_blank& rel=&nofollow noreferrer&&Feature Request/Fix）&i class=&icon-external&&&/i&&/a&&/li&&li&无论如何，出生在这样一个群雄逐鹿的年代，真是人生的幸运。&/li&&/ol&
针对题主问题一条一条写吧，想到哪写到哪，本身水平也有限，未必是什么真知灼见。cpu 的数学性能一般不是热点，且 vector 的下标用法不多（至少本人如此），UE 暂时没有优化到我可以理解，相反，读过一些执着于一点点 math 之类的小优化，虎头蛇尾的开源引…