虽然下个月要在 Unite 会议上做个最后一天压轴没人看的 Unity 技术讲座，到时候会各种吹捧 Unity，但是我还是深深的建议楼主不要随便碰 Unity，这玩意比几乎所有人和你说的都危险。

UE 和 Cry 想要用，你必须要去爬很长时间的学习曲线。因为这些引擎为实现某些特定功能做了大量的优化，很多目标有约定的做法。你就像要背单词一样记忆很多工作的步骤和流程。

Unity 则是灵活 …… 灵活的换一种说法就是封装少，路径开放。你可以做你想做的几乎所有事情，但是在没有人给你设计好开发架构的时候，你除了做个 3D 漫游之外啥也做不出来。

indie 想要使用引擎，先做好苦练6个月的准备。精通一个引擎的难度基本等于精通一套 3D 制作工具。譬如说你之前没用过 Blender 这个 3D 工具，学用一个 3D 引擎做游戏要花的时间和你能用 Blender 灵活的渲染一段 CG 影片难度大致上差不多。

So，没什么好挑的。如果要挑选的话，我只能说因为现在 Unity 很火，专业版的盗版业很容易找到。其他两个引擎相对难找。门槛的话 UE 最高，Cry 其次。

引用:

原帖由 业内消息 于 2014-3-23 23:52 发表
posted by wap, platform: BlackBerry (Z10)

说明一下，做游戏就我一个人。以前做过ios, android 和 wp的app，精通java和网站，没接触过3d.

按照现在这个阶段来问引擎的话，可以先自问几个问题

1 我要做的游戏是什么
2 3D 对游戏有什么用
3 我打算什么时候做出来

答案摸底是这样的

第一个问题，一般很多时候动手时都能说个一二。我要做个 XXX 的玩意，这个我们就不解说了
第二个问题，如果你想说的是我希望游戏看起来好看，或者说我希望画面牛逼 …… 那你搞错了，拼画面的事情委实轮不到 indie 来干，除非你自己是艺术家
第三个问题，这个问题意味着你是要成果还是享受过程，享受过程不在意结果，那用多复杂的工具都没所谓，享受结果 …… 那只能用会用的，没有会用的要算学习成本

最后的悲剧结果一般是这样的，最后滚回去修改问题1的答案 …… indie 就是这样子的
成功的 indie 作品大多数是垃圾堆砌起来的一个偶然作品 …… 那些成功了得牛逼了的 indie 很多根本就是有行业背景的正规军出来搞小分队
很多多年 indie 之后逐步获得了成功的 indie 其实去行业里也是挑公司的节奏

所以LZ，其实你现在先摸个容易弄到的引擎先研究起来 …… 譬如 Unity，之后呢，慢慢一边实践一边修改自己的创意。会有成果的。
有人说你为啥推荐 Unity …… 我想说我其实更想推荐 Cocos 2D-X 但肯定会被 LZ 鄙视不够高大上

引用:

原帖由 yilaguan2k2 于 2014-3-24 01:16 发表

讨论就好好说话，口气大上天也就C#编译速度快这么一个论据，整篇帖子就你嘴臭还说别人嘴炮。

对于新人Unity Editor不用学吗？再加上Unity editor就一残废，需要搞一堆Asset与Extension，是不是学习成本？C#本身 ...

说的好，赞 ~

虽然技术角度来说，是管道越死的引擎越容易出效果 …… 但是我觉得这些引擎都是坑死美术不偿命的类型 …… Unreal 的可视化材质编辑器也就稍微好那么一点点

咱不能眼睁睁的看着楼主往坑里跳啊 …… 伸手拉一把吧 …… 没海量美术还是赶紧好好回头想想自己的初心吧

引用:

原帖由 业内消息 于 2014-3-24 01:19 发表
posted by wap, platform: BlackBerry (Z10)

主要是个人爱好，我在微软做full time ba，做3d游戏不为赚钱，也不会收钱。

那我真心实意的给LZ推荐一条不坑的路 …… 你看加分的人就知道可定是在努力帮你。看到好的一定给分了啊

3D 游戏其实有两种设计流派。我们姑且把它分为中西 …… 因为你主要看到的就是这两类。

中式游戏重内核，轻表现 —— 说实在我很多时候认为这和计算机教育有关系，很多程序相关的课程设计都是从实现一个数据管理模块开始的（不跑题了）。这个所谓的轻重，已经形成了行业特性，你在将来咨询别人的时候，特别是深入到行业，会听到一些有意思的名词。这里趁早给你解惑一下。国内的策划经常挂在嘴上和策划沟通的词儿是“数据结构”，譬如玩家属性结构，任务数据结构等等。这种数据至上的表现从本质上代理着一种观点 —— 游戏本身是一个数值系统，画面是它的表现形式。所以国内也常常会说这游戏有没有必要 3D 之类的讨论。

这种内核本质上是两样东西，一个玩家的数据集，一堆数据集的操作器，以及一堆约束器。譬如从国内的思考的方式，打怪这件事情是 [数据]/玩家/ 以 [修改器]/每秒5米的速度向怪物的方向移动/ 当 [约束器]/距离小于1米/ 时 [修改器] /攻击/ …… 接下来就是根据武器，攻击方式，敌人什么的一项一项分析下去。这个思路里是有很强的主次关系，目的性的。

你如果选择这样的游戏，其实引擎可以延迟决策。因为实际上你的内核做完了才会出来驱动外面的表现。而且对工具的依赖不多。UE 这样的工具反而不是很适合你，Unity 这种灵活的结构会比较让你开心。当然你资源不多的时候直接用 XNA 的接口在画面上画点东西也没什么困难。国内很多公司用 Unity 也是按照上面的思路用，在场景里有个硕大的单件类 ……

而西式游戏，以最近 @miloyip 翻译的书《游戏引擎架构》中为代表，是现有表现定义，后有游戏内核的。看起来好像不能接受，但却是现在很多 3D 引擎的一个基本入门敲门砖。这种架构有一个基本假设 “在 3D 空间里玩耍本身就是很好玩的事情”。 因此这些 3D 引擎一开始 “毫无游戏性”，它们解决的第一个问题是 3D 空间的描述问题 —— 如何记录，如何编辑，如何渲染，如何声响，如何播放动画，如何渲染画面特效，etc。然后接下来，游戏性寄托于这些基础的表现之上 ……

同以打怪为例，到了西式思维力就变成了“一个摄影机追踪着的”“移动受到玩家控制的”“活动3D物件” 移动了 “位置”，“活动3D物件”“对周围半径一米实施了碰撞检测”“碰到了另外一个活动物件”。然后这两个 “活动3D物件” 各自开始‘琢磨’。发起碰撞检测的扣除了自己的“体力”属性（注意，体力是这个特殊活动3D物件的扩展属性），被碰撞的物体发觉撞到了一个东西，扣除了自己的“生命值”属性。这里面有种莫名的民主 …… 玩家和NPC没有主次，只有属性数量之别，对3D世界世界的响应不同。

很多技术人员会说，这其实一个是从设计角度一个是从技术角度说的嘛 …… 非也。现在的引擎大多有了内容制作工具，北美的游戏设计师（“策划”）们提出这样的工具需求必然是其设计出发点的差异导致的。就像国内的策划从来都是画个平面图，然后写文档，然后和程序商量着去哪里填数据表 —— 国内的游戏设计师还不知道如何创造一个游戏世界的时候就被行业的制作流程给弓虽女干了。以至于多年之后还在一边和美术和程序吵架说游戏看起来不是自己想要的感觉，一边又无奈的接受现实。除了位子坐的更高可以骂人骂的更理直气壮了之外毫无本质区别。此外这也是很多国外引擎到了国内来被反映没什么实际用途的主要原因之一。思路不同，拿来有个屁用 …… 只能使用一点交集。

说了这么多，回到开头。

实际上西方来的游戏引擎，基本上都是以后一种思路为出发点的。所以如果想玩好 3D 引擎做 3D 游戏，掌握一门 3D 制作工具基本上是必须的。这是我给楼主的真心建议，推荐你系统的玩弄一下 3DSMax ，特别是 2015 版开始引入场景层级结构视图之后。因为 Max 也是一个 3D 空间思维的软件。你在其中新建一个物件，然后给它塑性，然后安排动画，最后把它渲染。除了不能和你实时交互之外，真的和做 3D 游戏区别不大。你不需要做的像个 CG 艺术家 …… 哪怕是一堆弹跳的小球也是一个很有意义的过程。逛逛书店会发觉这种贯穿设计、建模、动画、灯光、材质、渲染、剪辑 的书和资料都比较难找，但这恰恰就是游戏设计师要理解的“全栈”。

当这些都没有问题之后，需要什么样的引擎来帮你实现什么样的游戏，心里也就有底了。这时候来讨论，问题也会问的不一样的。因为真的“懂3D”了

国外是不是就没有重数值抽象的游戏类型呢 ？ 那显然不是的，文明有战略视图，模拟城市有独立的模拟引擎“Glass Box”。它们也是类似上面中式游戏设计思路来制作的。甚至还有“Fritz” 这种把画面渲染当插件用的结构呢 ！

如果 LZ 真的是想做个 3D 游戏娱乐一下身心，扩充一下业余生活。可以从快速的玩一款 3D 制作软件开始。而如果还是不能理解怎么才是 用“3D”引擎 做游戏的话，那不如先就做做游戏内核，然后做好了内核之后再来研究怎么表现合适。也许也能找个“靠谱程序员”帮你把图形的部分做了。亦或者有人对你有兴趣拉你创业了。

[ 本帖最后由 FXCarl 于 2014-3-24 02:20 编辑 ]

引用:

原帖由 yilaguan2k2 于 2014-3-24 23:02 发表

你又开始瞎猜了，你哪里有看出我10多年没参与开发？我列举的都是全程参与的项目。
再有了，你知道技术支持是干嘛的不？腾讯、完美、盛大搞不定的时候才让我们去，去了就得几小时内帮人家搞定。初期说不定还得帮着 ...

今天去 unreal 官网转了一圈 …… 能有好心人士把视频从管子上往优酷般般就好了 …… Blue Print 看起来非常喜感

正好有个好奇向问一下，为什么 Unreal 至今还是把 BSP 放在非常重要的位置上，一看到关卡设计/空间规划的时候我就能感觉到 BSP 的“存在”（也许总是看到从空间割取，然后内部装填这样的流程所致）。技术上来说 BSP 的确有其价值，继承上来说策划直接边际关卡也有方便的地方。但是对于没有经验的群体来说，这玩意相当的不好理解 —— 相对于八叉树、AABB 层次包围盒、体素的空间管理来说 ……

每次看到 Unreal 的户外场景的时候，总觉得有种莫名的“这不是引擎亲儿子”的感觉 …… 求解惑

引用:

原帖由 karsus 于 2014-3-25 09:48 发表

没实际用过这种开发模型，一直觉得这是定制化项目或者需求不明确时才需要的方式。不过从你的目标来看，过于追求图像表现了，初始阶段，图像不过是你逻辑的视觉表达罢了，行走边界体现在逻辑上不过就是个数，视角问 ...

电梯直达 …… #38楼 …… 继续等 yilaguan2k2 答疑 #71 楼问题

引用:

原帖由 yang117 于 2014-3-25 10:59 发表


很失望UE4还保留BSP，brush用起来到方便，特别是各种volume的建立
但是相对还是小家子气，做室内和小场景比较方便，但是室外开阔场景就明显不如cry和 Frostbite 了
可能UE4 epic打算走中小开发者的路线了， 这 ...

#79 #82

"EPIC的Designer很少先做Paper design，都是引擎里直接干Prototype的"

看到这句话有种 …… “尼玛果然是这样啊” 的感觉 …… 第一人称地牢式FPS的基础一传就是几十年 …… 关卡编辑是蚁穴式的 …… 比较忙来不及细说了。回头我们可以另外开个帖子聊聊关卡编辑工具设计思路的话题

前面有人提到 Maya，我一直对 Killzone 把引擎直接整合进 Maya 的设计出发点很有兴趣