Unity CEO：Unreal投机 Unity简单实在
　　来源：【07073】　　我们和Unity首席David Helgason谈论关于Unity最新版本，并它将如何影响游戏行业。
　　你能告诉我们关于Unity的历程以及现在的发展状况吗？
　　那我能说上大半天了[笑]。是这样，十年前我们三个哥们儿想要做游戏，但是没有我们买的起的引擎，除非我们都有钱或者资助。所以我们只有自己开发一个引擎。当我们这样做的时候，我们意识到，比起实际做游戏，我们更加热情于做我们自己的引擎。因此，我们改变了发展方向，七年前我们发布了第一代Unity版本。
　　我们不想让这个引擎和别的引擎看起来一样，所以我们觉得一定要让它变得特别。这对没有足够资金预算但仍想要进行游戏的家伙们来说是个很好的机遇。因此我们决定全心全力投入做游戏上了。我们想要使游戏开发大众化，引导我们所做的一切。Unity所引导的经营模式：具备低花费，可负担得起、并且方便得到许可权。它必须要是非常简单，明朗简洁，并且还有一个很好的社区，这样人们可以去购买它也能了解如何使用它。然后我们必须要关注大部分人的需要。最初我们发布的是基于PC、Mac和Web的版本，因为这些都是开放平台，人们没有开发资金也一样能发布出去，到后来Iphone启用的时候，我们对它都很奋，人们可以成功地使用它的各种小工具。之后我们很快投入开发Iphone以及Andriod。那之后我们得到越来越多用户，因为这个技术很容易上手。Unity能够节约他们时间，让他们不必在工作上花太多精力，他们能专注于娱乐、创造力和开发上面。
　　现在我们大约有十万用户，其中四分之一的人在使用Unity开发一些东西。我们没再计算平台上有多少游戏，但我认为介于10000范围内，可见有多么迅猛。
　　我们期待的Unity4有什么新特点?
　　好的，我们目前所发布的仅仅是Unity4的第一阶段；我们可能要发布很多阶段。但是有一些新东西，一个就是Mecanim，这是一个动画技术，它能允许你做更多，比你之前能做的还多的事情。你可以从其他应用程序上引入动画或者直接把mo-cap data入进去，并且Mecanim不是独立存在的，它只是Unity的一部分，Mecanim把动画作为对象并应用于你的任意网格上。你不必手操作让mesh和rig固定，它是自动的。以前这些难做的事情现在变得容易多了。
　　Mecanim还能给新人或缺乏经验的人带来哪些其他帮助？
　　在社区和软件市场，那里的人们可以出售一些东西或免费分享一些东西给其他人，因此，如果你是很牛的动画师而且你会着手用Mecanim灵活自如地做出各种各样的东西，我们也在商场中放了很多动画数据资料，因此你能直接下载他们并应用于你的模型中，不必去在其他图层上查找动画。人们一般难以购买动画资料，因为它在你做东西的时候实际上用不到太多，由于它有能够自动重新定位目标的功能，你可以购买这些动画，并将它们应用到你的角色，他们将正确地工作，你无须去清理或去手动定位操作。
　　还有哪些新的？
　　新东西一直在发展，然后我们有一大堆要渲染的东西。我们支持Direct X11，并且我们正在手机上做更先进的渲染，所以你能得到和实时阴影一样的东西。我们同样致力于帮助人们把自己想做的作品带给广大客户。因此我们正在做一件事就是Unity4的测试版本，这会持续一段时间，但这个测试版将会最终完成并且正式出售的，这样你就能很轻松做出的IOS、安卓、主机平台、PC和Mac这些平台的游戏了，而且用还能在浏览器上用Flash运行，因此不需要***别的插件，直接把你做的东西放到网上就行了。
　　在Unity新版本中是否重点支持Linux?
　　我们已经观察了其他的客户，其中开发经验不足或者非专业的客户做的游戏都支持Linux.通常Linux系统是他们获取收入的重要原因。那些懂Linux的客户都很渴望做游戏，因此我们决定在Unity4中支持Linux.我认为现在主流的引擎几乎都支持Mac、Windows，同时也要支持Linux。
　　你是否有计划开始把Unity4引入主机平台？
　　是的。我们仅有少量的在主机平台上制作的游戏，但是我们发现大量的团队都用Unity，当然我们能做更多，我们会优化一大批东西来使得开发制作变得快。这个引擎真正激起人们兴趣的是你可以做自己想做的任何事，不会受到限制，并且在制作过程中你能决定你想要发布的平台。举一个例子，Rochard这个PS3游戏已经在Mac应用超市上面发布，我觉得我们也能在其他主机平台上看到这款游戏。
　　最近另一个超级引擎Unreal4也发布了。那是一个非一般的引擎。你如何让用户不被它的魅力吸引，而且U3D不会被U4取代？
　　我当然是希望用户不要一味地追求代替品，这是因为那个引擎基本上是运行于未来的硬件，这些新硬件是我们目前在市场上找不到的并且不实际的，它甚至超越了下一代的控制台，这都只是他们的投机行为。我认为他们关键是觉得Unityl现在发布得太快，这是因为我们正在做的是在实际的硬件上解决实际的问题。这才是主要的不同之处。你会发现这两个引擎，很多工具都是一样的，很多功能也是一样的。
　　你是否考虑过下一代的控制台，或者只是一直关注？
　　我们对于即将发生的事情做了很多打算，你会觉得现在的软件都很好用，因为升级不是件难事。我们仅需很快地做几遍，而不是每隔五年去实验室做点儿新东西。我们最近的升级周期仅持续了两年，其中我们发布了8、9个升级版本，其中几个实用性和完整度很强。我们是一个不停进步并不断适应时代的公司。
　　从主机平台到网络游戏，Unity能满足这两种规格是否很重要？
　　我不确定那个是重要的，但我们想要这么做，并且我们能够这么做。我们认为Unity就像给独立开发者出售武器装备一样，EA和一些最大的公司都用我们的东西，但是我们也在同时间也给独立开发者或者学生提供免费产品来用，它们差不多功能都一样。我们保持软件的简单，让那些大型工作室的人觉得简单易用而感觉愉快。那些大型工作室也会重视他们雇佣的Unity开发者，学生或者独立开发员，同时独立开发者们也会重视他们所使用的全部开发出来的技术。
　　Unity对比其他大多数引擎都惊人的便宜，你觉得在将来这种价格竞争还会重点保留么？
　　是的，我们不会做任何改变。我们永远记得我们一穷二白的那些时光，因此保持超低的价格让每个人都购买我们的产品一直是我们的梦想，我们会做好我们想做的事。我们绝不抬高我们产品的价格的，额。。是真的。Unity4的价格也不会改变。
　　Unity能否改变当今产业？
　　在某些方面我们已经做到了。最近一份“询问移动平台游戏开发者使用哪种技术”的调查表明，其中之一就是Unity。与其自己破费资金开发一个技术，倒不如使用一个引擎要快上好几倍，昂贵的引擎系统是你百万元收入的重要原因，我们节约了人们的钱，让他们无需自己创建源代码或者浪费资金。人们能够花更多的钱、时间、爱和精力投入到的工作或者游戏艺术，当然，要协调分配。很多游戏开发者相信剩余30%的工作是用来调试游戏各个部件的，这就是你游戏最终取得成功的地方。我认为Unity允许让人们在那个地方花更多时间。
　　找网页游戏，就上07073！
& 15:46:44
& 15:43:40
& 14:03:40
& 17:10:42
& 16:12:34
& 14:13:52
& 14:13:52
　　中国网络游戏排行榜(China Game Weight Rank)是由新浪游戏推出的目前国内最全面、最专业、最公正的最新网络游戏评测排行榜，涵盖内所有新游戏，力图为中国游戏玩家打造最值得信赖的新网游推荐平台。
　　新浪中国网络游戏排行榜是以由新浪游戏专业评测员组成的评测团队为核心，以游戏的画质、类型、风格、题材等游戏特性为依据，对中国(大陆港澳台)、欧美、日韩等地区正在进行测试或正式运营的新网游产品进行评测并打分后产生的权威游戏排行榜。新浪中国网络游戏排行榜将网络游戏从六大项、二十八个小分项与同类游戏进行横向比较，再将该游戏与自身的不同版本进行纵向对比后，由评测中心根据加权平均数得出最后的游戏分数，并以游戏测试及上线时间点为分组，根据每款游戏的CGWS分数在每个季度发布排行榜榜单，实现了排行榜的透明化和实时化，帮助玩家准确、迅速地找到心目中的理想游戏。
　　评天下游戏、测产品深浅—新浪中国网络游戏排行榜CGWR！　
Copyright &
SINA Corporation, All Rights Reserved谢邀。相比高度工业化的Unreal，不管是Unity的早期用户群还是今天的用户里，独立游戏开发者都占了相当大的比重。使用Unity的团队，能获得最佳用户体验的团队规模区间在1人-10人，20人靠上就必须要靠专门定制的工作流程和辅助工具来保证协作质量和效率。Unity开发团队需要的角色，视项目的不同也有很大的区别。下面列出每个类型的团队成员和他们适用的项目范围。逻辑实现者：工作是实现从游戏主循环到每个游戏元素的逻辑。在小团队里一般是唯一的一名程序员，在大团队里是GPP（Gameplay Programmer）。注意如果是独立游戏项目的话，借助第三方插件，非程序员也可以担任这个角色。内容设计者（读作ce hua）：在大团队里基本上就是策划职位，和传统策划的区别是因为Unity团队里负责这个任务的人基本上是一定要摆弄场景、制作prefab的，没有点动手能力光会写文档可不行。美术：工作包括从游戏概念图的设计到模型动画等美术资源的设计制作。具体细分可以参考游戏工业标准，Unity团队也不例外。交互设计和实现：界面设计、界面实现编程，由于Unity下有很多不错的UI插件，所以这份包括设计师和程序员的工作我给合并到了一起。在Unity下就算是由设计师自己来做交互实现编程也不会很难。主程序/架构设计师：适用于大项目或大团队的高端职业，他们的主要任务不是生产用户能玩到的具体游戏性，而是为其他团队成员搭建一个可以沟通协作的框架或工具集。对大型Unity项目来说，如果团队里没有这么一个经验丰富思路清晰的高手，很快项目就会被各种突飞猛进（因为Unity开发新功能原型实在太快了，很容易让人忽略结构问题）的feature生产搞的累赘不堪，然后在没有人指导项目重构的情况下，生产效率从每周一个feature下降到每个月一个feature，还伴随无数难以修复的bug。服务器程序员：网游项目必备，其描述适用于游戏工业标准，这里不赘述。版本管理员：适用于大项目，最好精通Git或plastic scm这类分布式版本控制系统，好处是方便做branching而且可以拆分项目为多个子项目，Unity项目大了以后运行效率是很差的，拆分项目也有利于控制不同分工的团队成员的权限。音效设计师：可选，推荐还是外包音效+内部实现的做法，因为Unity并没有一个完全封装好的音效中间件，如果音效设计师要进行实际调试，就要完全掌握Unity组件系统，在国内来说这个要求还是比较高的。怕麻烦的话拿到外包的文件然后让程序员或策划去导入和测试就好了。和工业标准的游戏团队配置也差不多，不过可以注意到很多角色都打破了传统程序、美术、策划铁三角的分界线，更提倡全面发展。因为Unity的场景和组件系统决定了它很难像Unreal一样把工作流程完美封包然后让程序美术策划各负责流水线上的一环。场景里的一个重要物体，可能不同分工的团队成员都要掌握其配置方法，否则就无法单独对其进行修改和测试，这应该是Unity团队的最大不同吧。实际项目经验证明，不懂游戏引擎的美术或策划，在Unity项目里连测试都要拜托别人，非常影响效率。所以看到这个***的相关开发人员不妨多学点游戏编辑器知识。
程序员是大工，美术是小工，项目经理是工头，来来，赶紧盖房子。
程序员是大工，美术是小工，项目经理是工头，来来，赶紧盖房子。
已有帐号？
无法登录？
社交帐号登录
Cocos Creator 制作人同时看过 unreal4 和 Unity 源代码的人觉得哪个引擎架构更好？
最近在看unreal4源代码, 之前看的比较多的是unity, 感觉unreal4看起来有点头疼,可能是本身不熟悉unreal4的缘故,很多代码看起来不如unity结构简单, 请各位大大发表下看法, 从结构上分析下那个引擎更好, 不考虑渲染质量啥的.&br&&br&我举个简单的例子吧, 比如Vector3这种类吧&br&unreal是&br&&div class=&highlight&&&pre&&code class=&language-text&&struct FVector
/** Vector's X component. */
/** Vector's Y component. */
/** Vector's Z component. */
&/code&&/pre&&/div&unity也差不多, 这里我就比较好奇,为啥他们不写为&br&&div class=&highlight&&&pre&&code class=&language-text&&struct Vector {
float v[3];
float x,y,z;
&/code&&/pre&&/div&&br&然后看[]重载的写法,&br&unreal是&br&FORCEINLINE float FVector::operator[]( int32 Index )const&br&{&br& check(Index &= 0 && Index & 3);&br& if( Index == 0 )&br& {&br&
return X;&br& }&br& else if( Index == 1)&br& {&br&
return Y;&br& }&br& else&br& {&br&
return Z;&br& }&br&}&br&&br&unity是这样&br&const float& operator[] (int i)const
{ DebugAssertIf (i & 0 || i & 2); return (&x)[i]; }&br&&br&但其实最简单的写法不是? 如果采用union的定义方法.&br&return v[i] &br&但好歹unity的是取地址x后,数组访问.&br&&br&在比如Actor这个类, 与之对应的unity是GameObject, unity对gameobject抽象就很简单, 代码看起来也简单, 反观unreal&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&/** Event when this actor takes ANY damage */
UFUNCTION(BlueprintImplementableEvent, BlueprintAuthorityOnly, meta=(FriendlyName = &AnyDamage&), Category=&Damage&)
virtual void ReceiveAnyDamage(float Damage, const class UDamageType* DamageType, class AController* InstigatedBy, AActor* DamageCauser);
* Event when this actor takes RADIAL damage
* @todo Pass it the full array of hits instead of just one?
UFUNCTION(BlueprintImplementableEvent, BlueprintAuthorityOnly, meta=(FriendlyName = &RadialDamage&), Category=&Damage&)
virtual void ReceiveRadialDamage(float DamageReceived, const class UDamageType* DamageType, FVector Origin, const struct FHitResult& HitInfo, class AController* InstigatedBy, AActor* DamageCauser);
/** Event when this actor takes POINT damage */
UFUNCTION(BlueprintImplementableEvent, BlueprintAuthorityOnly, meta=(FriendlyName = &PointDamage&), Category=&Damage&)
virtual void ReceivePointDamage(float Damage, const class UDamageType* DamageType, FVector HitLocation, FVector HitNormal, class UPrimitiveComponent* HitComponent, FName BoneName, FVector ShotFromDirection, class AController* InstigatedBy, AActor* DamageCauser);
&/code&&/pre&&/div&&br&这种成员方法放在Actor里? 杂糅的业务逻辑的回调,我看的倒胃口.&br&&br&还有这什么鬼&br&&div class=&highlight&&&pre&&code class=&language-text&&#if WITH_EDITOR
virtual void PreEditChange(UProperty* PropertyThatWillChange)
virtual void PostEditChangeProperty(FPropertyChangedEvent& PropertyChangedEvent)
virtual void PreEditUndo()
virtual void PostEditUndo()
virtual void PostEditImport()
&/code&&/pre&&/div&&br&Actor直接继承UObject, 中间没有类处理editor的逻辑? 导致成这样, 这样的引擎结构真的不敢恭维.&br&&br&这这是简单举个例子, 因为我看了unreal4后,感觉很多代码明显可以很简单的, 在比如他实现的反射框架, 我也感觉设计的不够简单,它的blueprint脚本不知道为谁设计的, 程序员不会用它来写游戏, 但为了这个东西时间的反射框架真是累赘, 为啥不直接使用支持反射的js/lua/mono等(如果有脚本需求), 所以想问问大大们大家的看法.&br&&br&大家不要被unreal4渲染质量唬住了,认为都好, 我真心认为unreal4的设计不如unity 甚至不如ogre. 我认为unreal4就是代码写的格式漂亮, unity看起来缝缝补补的感觉.&br&&br&如果有不同看法请详细说明
最近在看unreal4源代码, 之前看的比较多的是unity, 感觉unreal4看起来有点头疼,可能是本身不熟悉unreal4的缘故,很多代码看起来不如unity结构简单, 请各位大大发表下看法, 从结构上分析下那个引擎更好, 不考虑渲染质量啥的.我举个简单的例子吧, 比如Vector3这种类吧unreal是struct FVector
/** Vector's X component. */
/** Vector's Y component. */
/** Vector's Z component. */
unity也差不多, 这里我就比较好奇,为啥他们不写为struct Vector {
float v[3];
float x,y,z;
谢邀。这是一个很难的问题，而且不容易回答，很容易引起争论，老实说我并不想在公开场合评论到底哪个更好或者更坏，这并不明智，其实每个人心底都有自己的***。我只想聊一些我的看法。一、关于Unreal4和Unity很不幸，我并没有看过Unity代码，我们没有购买，而我也并不是特别想看。或许有人说：装！嗯，其实写了很多年代码了，什么没见过？看过并不一定能写出那样的产品，没看过也不代表你不能写出超越它的代码。很多人对待引擎代码的态度其实和追女孩差不多，没追到的时候，天天时时刻刻想着，到手了，就呆在硬盘里，其实真正每个文件都读过的人，凤毛麟角，读懂的人可能更少。在刚开始学习游戏引擎的时候，需要读一定数量的代码，但积累了一定的代码量和经验之后，需要的更多是观察、思考、总结。所以比较资深的程序员，会花更大量的时间思考，而不是学（chao）习（xi）别人的代码。回到这两者的对比上，我没看过，所以就不知道怎么对比了，只能说各有各的好，咸鱼青菜各有所爱，而且游戏界的金科玉律就是，谁能出产品，谁能大卖，谁就是赢家。至今Unreal3已经被证明了是一个伟大的引擎，有足够的title说明问题了。Unity有不少作品，但还缺乏一锤定音的作品，和AAA不沾边有关系吧。但用户足够多，增长率高也可以说明问题。Unreal4还欠缺证明自己的作品，等战争机器吧，Epic还需要向别人演示怎么使用这个引擎。二、关于题主提出的几个对比很直接说一句，那都不是什么问题，或者可以说，根本不是比较的重点。Unity那种写法，上世纪就已经有人在用，不见得是什么高明的写法，这种c/c++的奇技淫巧，只有初学者或者刚刚学会一点儿的人会感兴趣。我顺手可以拈来好多类似的，比如gcc的tree node结构，初读感觉那个精妙，后来发现也就那样儿。这种union我大概10年前在写高速raytrace引擎的时候已经用过，而且用在xmm上面，即现在DirectXMath的写法。至于你说不明白为什么Unreal这么写，看不懂if。为什么？很简单啊，因为这是“历史问题”。那个年代过来的代码都是这么写的，就一直这么写了。很多人搞错了一点，以为数学库要效率高，这也是我刚开始写引擎和图形程序时候的错觉。后来发现，不是的，游戏引擎的数学库，不是全都要求效率高的，数学库最重要的是“稳定”。因为真正在跑的，AAA游戏，或者重度的MMORPG，最重要的，不是数学运算，而是“架构”。反而数学运算，需要稳。稳到什么程度？havok曾经推销他们的物理引擎，最引以为傲的的，并不是它有多快，而是它的所有物理运算在所有平台上的计算结果都完全一致（评论有朋友修正了这个说法，应该是同样的计算在同一平台上每次计算都一样）。这简直吊炸天啊有木有！！！如果你不明白这句话背后的意义，那么我想你没必要讨论数学库了。回到问题本身，一个字，编译器优化，可以回答一切问题。现代游戏引擎的瓶颈，有两处，一处是runtime的执行效率，一处是content creation的pipeline生产效率。后者太庞大太宽泛，没实战过的人，不理解，这里不展开细说，只讨论第一点，runtime。runtime部分，现代引擎面对的问题，主要是越来越复杂的场景，越来越多的drawcall，越来越重的资源。这里面最麻烦的就是提交。所以新一代的API，都注重提高提交效率，即更薄的driver层。这就是DX12标榜的十万drawcall的意义。这里我必须提一点，这两个引擎，Unreal4和Unity，都有一个架构上的严重欠缺，就是没有从原生上支持多线程。即使Unity5，也只是用了一种thread pool的分发的策略，把一部分集中的繁重的事务分发到其它线程计算，但它并不是真正的“原生多线程”，即任意的不相关的任务都可以随意分发到不同的线程上。考虑每个entity自己更新自己的逻辑，可以并行，有100核心就可以几乎真的并行更新100个entity，这才是真正的原生多线程。这种引擎，目前公开的只有Frostbite 3是这么做的。（当然我不会告诉你，我们……）。至于Component架构，这方面我有另一种看法。游戏引擎是一个很重度的工程项目，而非科研项目，干净与否并不能成为评判标准，实用性才是金科玉律。我认为unreal这么做（把业务相关的东西放到底层），是基于一种发展的眼光看。很简单，我也会这么做，如果我开发了一套非常超前的架构，但我又对它没有足够的底，不知道接下来应该怎么写，我认为总体方向是对的，但我不清楚业务和他如何结合，那么我就采取折中的方式来处理，即把一部分业务嵌到架构中，先把业务应用起来，验证架构的正确性，然后通过重构和迭代，逐步把业务细节划分出去。显然UObject是继承Unreal3而来的，Unreal4非常大胆，blueprint是一种非常超前的想法，而且非常有前途，也非常好，但这个改变太庞大了，太重了，要一下子割裂和Unreal3的关系是不切实际的，稳妥的方式是逐步修改过来，并且验证之后再完全迁移过去。所以迁入一部分实际业务的想法很现实。而且要考虑，引擎开发本身应该依附具体项目。我认为Unreal4应该依附在战争机器游戏本身的开发身上，才可以保证它不会走弯路。所以在底层重度嵌入一部分FPS相关代码，无可厚非也没有任何问题。老实说，我有代码洁癖，但我也会这么做，因为引擎不是独立产品，是依附游戏的附带产物，一切应该以游戏业务为优先。这也是为什么我一直对Unity有一些负面看法的原因，它的开发商本身并没有任何游戏，一切反馈是来自于用户，二手数据。所以Unity看起来似乎很“干净”，但就是太干净，干净得出奇，变得不接地气，这才是为什么它缺乏AAA。三、渲染质量之谈题主似乎不断在强调不要被Unreal4的渲染质量吓唬住了，我觉得这句话是很有问题的，直接地说，这句话是不专业的，一点都不professional的。显然题主是有倾向性的，因为Unity本身就是一直被Unreal4的渲染所吓唬住了，所以每个版本的升级都在重点强调自己的渲染特性得到了提升。老实说，这并不明智。因为Unity的提交效率。。。上面提到了一点，现代引擎的瓶颈一个很重要的点就在于渲染批次的提交上面。这里请看我一直所赞誉的Frostbite 3,的数据----BF4一些场景的DP数量达到了。吊炸天啊！这需要非常高的提交效率，非常优异的渲染组织。这就是引擎真正的架构技术核心所在。另一个碉堡了的是CryEngine，提交效率很高。所谓“渲染质量”是什么鬼东西？搞了差不多二十年图形，我很少听到专业人士提到这个词。我听过渲染效率，听过画面质量，听过各种shading model。同一张显卡，同样的shading model如果还用同样的模型，同样的算法，有什么质量不质量的？难道Unreal4算的 1 + 1 = 2 比 Unity 算的 1 + 1 = 2 质量要高？那个 2 要更好看？不是的，这是业余的看法。专业的看法是，你要对画面有取舍，有调控。引擎是一个大的系统，系统设计最重要的一环是控制和分配。图形学没什么算法是不公开的，Unreal4用到的所有算法都是公开的，所有的siggraph paper你都能access到，没什么秘方，没什么magic code。关键是，你的取舍，你花多少资源在哪个部分，省了哪个地方的东西。这部分的功力，是源自于游戏开发本身，源自于积累，源自于TA。这也是Unity欠缺的地方，因为Epic自己开发游戏。所以Epic在资源的调配上，有取舍，有经验，在开发战争机器的时候，在开发游戏的时候，有各种纠结，填了不少坑。写好代码只是开始，教会TA和美术使用引擎、正确使用你写的技术、配合并创造出美丽的画面，才是真正有绝对价值和意义的工作，这占了99%。图形学是工程的图形学，是trick和cheat的集合。正如你堆钱买奢侈品是不能除掉身上浓浓的杀马特山寨风的，必须读书、读书、读书、思考、思考、思考、沉淀、沉淀、沉淀。光靠堆一些feature，不是正确的姿势。这就是为什么Unity 5堆了那么多feature，看起来还是远不如Elemental Demo。四、双生对比Unreal、Unity，同样的例子，请看CGFX领域的MetalImage和Pixar。MentalRay非常?，有很多先进设计，一直坚持用raytrace，早就开发出电影质量的全局光渲染，但它一直被死对头Pixar的RenderMan所压制。Pixar的RenderMan，采用“落后的”渲染算法REYES，直到13.0版本之前一直不支持raytrace，且价格昂贵，更新缓慢，但广受电影制作喜爱，上世纪好莱坞特效渲染标配渲染器。为什么？很简单，Pixar自己是做电影的，RenderMan本身一直为Pixar的电影服务，获得各种第一手电影制作需求。而反观MentalImage一直只是一家软件公司，没有电影业务，只卖软件，只卖技术，所以无论改进得多好，一直不懂电影制作者的心。我对Unreal和Unity的看法，也基本基于此案例。当然，现在disney有更强的渲染器，可以完全干死RenderMan，不过这货是不卖的，正如Frostbite，也是不卖的。世界上最好的引擎技术，不会出现在商业引擎里面，只会在In house engine中。五、寄望我聊了许多，然而这并没有什么卵用，工作中该用哪款的，还是要用哪款，这不是技术人员能够决定的。不过我一直以来的信念，都是我们始终是要做自己的引擎的，并不是为国争光什么的狗屁高大上理由。很简单，技术人员存在的意义，就在于用技术碾压对手。你的技术，到底是用在给别人打补丁上，还是给自己充实力量上？所以我对所有这些第三方引擎的态度，都是批判地学习。好的，我兹词，不好的，我谨记并绕开。其它不参合任何个人感情，也不需要卖任何情怀，只需要记住，所有的这些----Unreal、Unity、CryEngine、Frostbite、SnowDrop、Fox等等等等，都是他人的嫁衣裳，我们真正需要的，是自己的遮羞布。题主的批判态度，已经带有点私人感情了，这并不理智，希望你可以成长，客观看待这些东西。----------------------------------------补充一点，题主说Unreal4不如ogre，我觉得这真有点太过了。ogre实在是渣渣渣渣渣。不多说，自己领悟吧。----------------------------------------再最后补充一点，评判这些引擎的时候，如果你不是对自己的实力有足够的把握，如果你不是很清楚到底自己是否真的彻底了解这些设计背后的原本意义，那么千万千万千万别开上帝视角。要很清楚这些引擎是世界最顶尖的脑袋架构出来的，一些显而易见的问题，比如用if是否很2b，难道你以为可以架构出blueprint、能够做到c++hot load这种吊炸天的人，他们想不到？不可能的事情！去看看Unreal4的Multicast delegate怎么设计，怎么构建，C++用的多好，多纯熟，对语言的压榨多极致，能够有这种把握深度的人，会不知道用书本上写的条条框框“千万别用if啊”什么的？不可能的事情！Tim Sweeney这些人的脑袋太好用了，太厉害了。比如Component的结构，坑超级多，你想到的，别人不会没想到。我遇到这种情况，不会第一时间想别人是否2b了，而会先考虑、是否自己没想到更深刻的问题？或许还有其他坑？就连Voxel Cone Tracing这种?炸天的算法都能想到，不可能想不到你看出来的小问题。所以，每当要开启上帝视角，请换一下角度，如果是你，你怎么设计，你怎么处理，真的就没有问题？如果你真的设计的比他们好，请别犹豫，站出来，战胜他们。
unreal4...没得说更新1：- blueprint我觉得是神器啊，可以给策划拿来用（可视化编程），程序员也可以用的很开心~这个比你随便写几行，就要重新编译运行一遍强多了~- FVector这个确实有union更方便，不过我觉得没有也可以接受~- Actor里有很多业务逻辑接口，按照你的观点怎么设计更合适呢？ 我理解的是这样更多的是为了性能考虑。至于你说为什么不用支持反射的js/lua/mono，可以看下这个 我觉得到ue这种工程的代码，有时候不得不做一些tricky的写法了……而且有一个很有意思的区别就是，UE之前是做过游戏，而Unity是纯卖引擎的……更新2：我想确认下，题主说的“ 从结构上分析下那个引擎更好, 不考虑渲染质量啥的.”是指不考虑引擎效果、功能，单纯从代码质量分析么？
都好又都不好。个人感觉，到了这种程度的引擎已经不是靠一两个漂亮的写法或者实现取胜的了。我还没到看引擎代码的地步，但是最近客户端框架看了不少。我发现无论多么火爆的游戏他们的框架和实现都有蹩脚甚至丑陋的地方。我可以写出比它们更加优雅的实现。然而这并没有什么卵用。
代码里不仅包含着算法，还包含着历史和政治。历史问题例如，unity告诉你他们在新版本中优化了底层的某个接口使得你可以用一种更优雅的方式去实现你之前的功能而不会有额外的性能消耗，你真的会翻出你之前写的所有代码把每一次调用都更改掉么？至于程序员的政治，只要涉及到政治总会让原本简单的东西变得复杂，程序也不例外。举一个最简单的例子，你长期独立负责你们公司一个核心项目的重要模块，你觉得把你的代码可读性和健壮性都维持得很好，真的是对你百利而无一害么？
unity就是个黑盒子上写代码 有问题难找 改动不了引擎
而虚幻4就不一样了 代码可以找更深去了解修改引擎
这个没有什么可比性。最符合业务需求的就是最好的架构。unity主要是适配移动手机的。而unreal，至少从目前来看，移动这一块做的还是不大行。
我只想问哪有unity源码看。。。unity不是不开源吗？
并不是大牛，第一次回答这种高端问题。总觉得题主有点死抠细节。写这篇回答的时候，我也并没有滚去看Unreal的源码查证。而且我自己也没见过Unity的源码并且对Unity完全不了解。我觉得题主举的第一个例子中，如果Unreal通篇总共没几个地方用到FVector的operator[]重载的话，那这种写法也无伤大雅吧。只能说Unity的写法更优雅【然而对UE来说也许并没什么卵用。谈架构不是谈代码是否“优雅”吧。其实题主抛弃Unreal4的渲染质量谈“架构”也算***吧。Unity不是也有材质系统么？造出跟Unreal类似的效果也不难？但是去看看同等效果下的效率啊。我猜肯定是Unreal完胜。删***了，没什么卵用。
unity之前是靠便宜迅速占领了市场。unreal比他还是要成熟一点的。
两个引擎思路设计是不一样的:Unreal注重的是工业化流程, 强调整体性, 官方性. 所以你会发现Unreal很少会有那么多的插件和扩展(普及程度是最大原因, 但还是和设计有关系). Unity3D的思路就是全脚本化, 让大家来给它做各种Mod, 可以说是用互联网思想来做引擎. 有了流量和用户, 普及就不是啥问题, 更可以说自己的哲学是正确的题主所说的, 用带反射的语言来做. Unity3D就是这么完成的编辑器. 可以说, 编辑器本身完完全全都是用引擎本体写出来的. 但引擎本体本没有编辑器支持. 而虚幻呢, 由于老的一些架构和思想下, 还是使用引擎本体糅合编辑器的功能, 通过宏控制来制作. 但多年的编写经验证明这么做其实也还好. 这是用C++做脚本这点. 我也感觉不大好, 至少来说, 开发效率和普及就受到很严重的牵制.另外我觉得, Unreal这种整合方式的思想和Unity3D这种MOD开发的思想肯定会长期存在的, 各有各的好处.
有的人喜欢完善, 有的人喜欢自定义. 就像Windows和Linux一样萝卜白菜而已, 不必纠结
已有帐号？
无法登录？
社交帐号登录