很多人并不知道游戏引擎或渲染引擎是怎么回事就开始思考如何做游戏引擎，这是不对的。&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…
来自子话题：
刚好我现在同时在开发两个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的架构和代…
来自子话题：
为啥日报上王哲得回答跟这里不一样？
为啥日报上王哲得回答跟这里不一样？
来自子话题：
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 的情…
来自子话题：
整个 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…
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類 計算機圖形: 進階/…
虽然目前排名第一的 &a data-hash=&306224beb6353ccda2ebcf32c92da359& href=&/people/306224beb6353ccda2ebcf32c92da359& class=&member_mention& data-editable=&true& data-title=&@邓鋆& data-tip=&p$b$306224beb6353ccda2ebcf32c92da359&&@邓鋆&/a& 的答案说得很有道理，但是我依然要强烈反对这个答案。&br&－－－－－－－－－－－－－－－&br&应该放弃，确实没有什么意义。&br&－－－－－－－－－－－－－－－&br&几乎每个厉害的游戏客户端程序员都想着开发自己的引擎。就算自己还做不到，至少也不愿意看到unity这种引擎流行，使得不厉害的程序员甚至策划、美术来抢自己的饭碗，所以他们会使劲黑unity的。&br&还有不少人在其他问题的回答里面质疑我的&做游戏开发不一定要用c++, 只学脚本也能开发好游戏&的观点呢，问我是否确定，说这是SB观点，怀疑我是否会开发游戏。&br&但是历史的潮流不是觉得自己很厉害的程序员就能阻挡的！&br&－－－－－－－－－－－－－－－－－－－－&br&大公司的程序员，当然会提倡&自研引擎&啦，引擎怎么做，做成什么样，什么进度，都是自己说了算，不必被策划牵着鼻子走，不必管美术；可以养着一帮人，做这么高端大气上档次的东西，以后出来报上名来说:&我是在XX公司开发自研引擎的！你居然还问我unity这种弱智引擎会不会用?! & &br&----------------------------------------------------&br&但是，对公司来说，对游戏开发来说，应该放弃，确实没有什么意义。&br&－－－－－－－－－－－－－－－－－－－－&br&好吧，下面给出反对的理由。&br&特定类型的游戏需要特定类型的工具，这一点我非常赞同 &a data-hash=&306224beb6353ccda2ebcf32c92da359& href=&/people/306224beb6353ccda2ebcf32c92da359& class=&member_mention& data-editable=&true& data-title=&@邓鋆& data-tip=&p$b$306224beb6353ccda2ebcf32c92da359&&@邓鋆&/a& 所说。而且，更进一步，我认为每个游戏都需要自己的特定工具集；游戏开发本来就应该工具先行。&br&可是，工具和引擎并不是同一个概念。说点实际的，有了unity之后，每个游戏的工具集都是围绕unity来做的，只是写代码的时候稍微关心一下如何方便unity editor调用就够了；偶尔自己写一些editor下的绘画，成了稍微专业一点的unity插件，仅此而已，而不会进化成独立的引擎。如果cocos2d进化的更好一点，以后某类游戏的特定工具也会演变成cocos2d地图编辑器的插件，而且不是通用插件，而是针对这个特定游戏的插件，甚至都不是特定类型游戏的插件。&br&这种工具，可以认为自古以来就是特定游戏的不可分割的一个组成部分，而不是一个独立的可以拿出来号称“自研引擎”的东西。&br&对于刚才这一句话，我是存在疑问的。也可能，因为这些东西做得确实很好，确实能够通用，某些公司里面确实就可以把这样的东西拿出来称作自研引擎；那么，目前排名第一的 &a href=&/people/tdzl2003& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&邓鋆&i class=&icon-external&&&/i&&/a& 的答案就是完全正确的。&br&－－－－－－－－－－－－－－－－－－&br&这一点我也非常理解。我自己专做围棋应用开发，每次也都是把处理棋谱和棋盘绘画、操作的部分全盘拷贝到新项目，重新组织外围代码，改变游戏逻辑，做成新的游戏。对我来说，这些就是处理围棋游戏的核心引擎，虽然很小。&br&这种引擎，也许和各位看官心目中的引擎差别很大。&br&----------------------------------------------&br&
是否仅仅给这个特定项目用，还是会给接下来的三四个项目用？如果不具备通用性，我们应该称呼它为项目工具，还是游戏引擎？如果只是这一个项目用到，那么项目代码和引擎代码的分界在哪里？如果没有分界，那即使用在下一个项目中，我们是否可以认为，下一个项目继承了上一个项目的所有代码而不是所谓“引擎部分”的代码？ 如果针对特定游戏的工具是建立在其它引擎比如unity的基础上的一个插件，那我们应该称呼它“插件”，还是“引擎”？ 我的意思是，工具肯定是必须的，但是通常是不具备多少通用性的unity插件，少量是独立的解析数据格式的其它专用工具，不值得被称为“公司自研的独立引擎”；自研引擎只是一个很响亮的口号而已，背后当然有其正知涵义，也就是说需要有独立的引擎开发组至少也是引擎工程师，可以不那么关心项目的需求，有一些独立的话语权去空想一些可能会出现的为下一个游戏准备的通用需求；怎么称呼无关紧要，这种人员结构正是我所反对的。&br&------------------------------------------------&br&至于那些实实在在开发渲染引擎的公司，那就切合题主所问的了，在unity和cocos2d-x这么流行的今天，在通用引擎做得这么好还这么便宜的今天，继续做下去没有意义，应该放弃。&br&这些东西不是今天才做的，是历史遗留产物。当初没有这么便宜这么好用的引擎可用，只好自己写渲染，写引擎。那时候，要不就花大价钱买unreal这种，要不就自己开发引擎，做引擎这件事情太有意义了，不仅是核心竞争力，而且是不做引擎你根本就无法做游戏。&br&可是到了今天，这些意义就荡然无存了。
虽然目前排名第一的
的答案说得很有道理，但是我依然要强烈反对这个答案。－－－－－－－－－－－－－－－应该放弃，确实没有什么意义。－－－－－－－－－－－－－－－几乎每个厉害的游戏客户端程序员都想着开发自己的引擎。就算自己还做不到，至少…
来自子话题：
问题很对胃口，我来答一记，水平有限，先说说在Tiled 地图方面的经验(多图流量预警！)。&br&&br&1、一开始是打算做个《英雄无敌3》的独立Unity游戏，最先想到要做的就是Tile地表编辑器，先贴张《英雄无敌3》编辑器的图。&br&&img src=&/f97fde996a31eff4b0adc127be454952_b.jpg& data-rawwidth=&1235& data-rawheight=&813& class=&origin_image zh-lightbox-thumb& width=&1235& data-original=&/f97fde996a31eff4b0adc127be454952_r.jpg&&&br&要说2D Tiles地图的美术表现，除掉斜45度的《暗黑破坏神2》，顶视图的冠军非《英雄无敌3》莫属。另外，&b&刷地表功能的一个要点在于能以各种笔刷（泥地、沙地、海、草地）随意的刷地表，地表跟临接其他类型地表的衔接关系一定是对的，有了这个，不仅是策划或者美术编辑修改方便，而且&u&自动生成关卡&/u&才有可能。&/b&&br&&br&《英雄无敌3》的NB之处就在于多种Tiles之间的衔接非常自然，注意上图中宝物1右边的红框区域，这个格子里有泥地、草地、沙地三种纹理衔接，这在基于Tiles的2D地图里非常少见。&br&&br&所以呢，我先把《英雄无敌3》的资源解出来，看看怎么才能做得如此NB：&br&&img src=&/33d6c40ff6aefd423cd946_b.jpg& data-rawwidth=&1265& data-rawheight=&805& class=&origin_image zh-lightbox-thumb& width=&1265& data-original=&/33d6c40ff6aefd423cd946_r.jpg&&所以为啥人家这么NB呢？素材规划强啊，刚才提到的红框区域泥草沙三种纹理混合图就在最后一排的中间（做了水平镜像的操作）。&br&&br&简单的说，沙地和泥地，算是基础地形，其他地形都有跟跟沙地和泥地衔接的图素，所以如果其他地形之间要衔接，就在中间夹沙地或者泥地（注意第一张图中间区域的火山地形和草地衔接之间的泥地过渡）。&br&&br&明白了这个道理，又有了图素，就开始做呗，正式美术资源什么的等编辑器好了再找美术按着这个规则做吧。&br&&br&所以我就开始写代码了。写了几千行代码，弄了个这么个东西：&br&&img src=&/5c6b59cc487dd63ebc5f5e63b36d902b_b.jpg& data-rawwidth=&1264& data-rawheight=&911& class=&origin_image zh-lightbox-thumb& width=&1264& data-original=&/5c6b59cc487dd63ebc5f5e63b36d902b_r.jpg&&但做到这份上只做到了海面和两种基础地表的混合，接下来就要引入一张图素三种地形的类型了，我心里琢磨了一下算法，突然发现工作量比我想象的大，我似乎对这种Tile衔接的规则总结得不太到位，那么上网找找吧。&br&&br&--------------------------------------------------分割线，谢谢-------------------------------------------------------&br&&br&2、神器出现了：&a href=&http://www.mapeditor.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Tiled Map Editor&i class=&icon-external&&&/i&&/a&&br&&br&这简直是赤裸裸的打我脸啊，以后做啥事之前能不能先上网搜搜？造轮子再快能快过直接开车吗？&br&&br&Tiled是个开源项目，编辑器框架基于QT，有很多游戏都基于Tiled制作地图，斜45度或者顶视图都可胜任，贴几张图上来给大家看下：&br&&br&&img src=&/9a56d028f8298bdb4a8517fee5fd7d9d_b.jpg& data-rawwidth=&1006& data-rawheight=&654& class=&origin_image zh-lightbox-thumb& width=&1006& data-original=&/9a56d028f8298bdb4a8517fee5fd7d9d_r.jpg&&&br&&img src=&/6a50cc241fb_b.jpg& data-rawwidth=&1006& data-rawheight=&654& class=&origin_image zh-lightbox-thumb& width=&1006& data-original=&/6a50cc241fb_r.jpg&&&br&我试用了一段时间，这个编辑器最NB的就是对地表类型编辑归纳，并且自动衔接其他类型地表的功能。举例给大家看看：&br&&br&&img src=&/2f48cad91a3ce96897bf_b.jpg& data-rawwidth=&1483& data-rawheight=&810& class=&origin_image zh-lightbox-thumb& width=&1483& data-original=&/2f48cad91a3ce96897bf_r.jpg&&以上面斜45度地形的图素为例，如果美术给你做了所有的衔接图，你导入所有图素，选定某种类型的地表（左边列表中的Sea2），然后在右边图库中标识哪些图片的哪些区域（左上、右上、左下、右下）是该种类型（蓝色高亮区域）。标识完成后，你就可以在主视窗用该笔刷任意涂刷了，程序会自动为你做地表衔接。&br&&img src=&/0822bcc3ba797f69b97a74_b.jpg& data-rawwidth=&1640& data-rawheight=&862& class=&origin_image zh-lightbox-thumb& width=&1640& data-original=&/0822bcc3ba797f69b97a74_r.jpg&&&br&教学到此为止，那么，题主是要做Unity2d的Tiled地图啊，这个编辑器编辑的成果如何导入Unity项目呢？&br&&br&--------------------------------------------------分割线，谢谢-------------------------------------------------------&br&&br&3、Tiled to Unity&br&&br&Unity Assert Store里搜索“Tiled”,你会很容易找到将Tiled地图导入Unity的插件：&br&第一个是：Tiled Tilemaps &br&&img src=&/bdcf0b97be1ce88a12a5f_b.jpg& data-rawwidth=&797& data-rawheight=&762& class=&origin_image zh-lightbox-thumb& width=&797& data-original=&/bdcf0b97be1ce88a12a5f_r.jpg&&详细的去商店看介绍吧。&br&&br&另一个更神奇一点，名字跟我这节名字一样：Tiled to Unity&br&这玩意儿能把Tiled 2d地图映射到3D元素上，生成Unity3d地图。&br&&img src=&/06fc52d1aae1c74f0f7e8b14_b.jpg& data-rawwidth=&792& data-rawheight=&900& class=&origin_image zh-lightbox-thumb& width=&792& data-original=&/06fc52d1aae1c74f0f7e8b14_r.jpg&&我想2D转3D应该不是题主的需求吧，但这东西看起来确实吸引人，就是不知道渲染效率如何，不知道有没有做渲染批次合并...而且有点贵......本人没试用过，看起来评论区 钟磊 同学有经验，感兴趣的同志可以移步向他请教。&br&&br&总之呢，基于开源软件的Tiled地图本身地图存储格式也是很清晰的，就算自己写读取地图也不会太难。&br&&br&--------------------------------------------------分割线，谢谢-------------------------------------------------------&br&4、Tiled图素资源&br&题主问到美术素材，一看就是准备单人Solo的节奏，遇到这样的同学我就很高兴，虽然知道十之八九是死路一条吧，但就是喜欢这种“虽万人吾亦往”的调调。单人Solo最麻烦的是素材的版权问题，&br&&br&以下是我觉得可以考虑的素材来源：&br&1) Google + Tileset:国外网站有很多免费开源的美术资源，比如&a href=&http://opengameart.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&OpenGameArt.org&i class=&icon-external&&&/i&&/a&，使用前请仔细区分基于什么开源协议，就是里面要挑出刚好合适有好看的不容易。&br&&br&2）Unity Assert Store:虽然大多是收费，但一般品质相当高，举个例子：&br&&img src=&/3bea8c73c_b.jpg& data-rawwidth=&825& data-rawheight=&900& class=&origin_image zh-lightbox-thumb& width=&825& data-original=&/3bea8c73c_r.jpg&&&br&3）淘宝，非常惭愧，介绍这玩意儿简直是助涨无视知识产权的邪恶力量。但如果是做前期技术准备，这里真能找到不少合适的资源。&br&&br&--------------------------------------------------分割线，谢谢-------------------------------------------------------&br&5、没想好....其实是有个念头，大家干嘛非得单人Solo呢？要不咱们跟GitHub上弄个开源游戏项目可好？
问题很对胃口，我来答一记，水平有限，先说说在Tiled 地图方面的经验(多图流量预警！)。1、一开始是打算做个《英雄无敌3》的独立Unity游戏，最先想到要做的就是Tile地表编辑器，先贴张《英雄无敌3》编辑器的图。要说2D Tiles地图的美术表现，除掉斜45度的《…
来自子话题：
准确地说，代码作为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等。 所以我们自己的代…
&b&Unity 3D正在革命游戏开发市场。&/b&
&br&&br&我从Unity1.0开始关注它，并且从1.5开始使用。我感觉Unity 3D是一款革命性的游戏引擎，它（和一些同样具有创新精神的引擎）正在改写开发游戏的历史。
&br&&br&【高风险的大型游戏开发】
&br&&br&传统上来说，开发游戏是一件费时费力的事情，而且80%的情况下开发游戏这件事就是一个灾难。因为游戏是一个交互艺术，这个交互不仅体现在娱乐方式上，也体现在开发过程中。修修补补是开发游戏的家常便饭。但是，由于传统的游戏开发至少涉及策划、美术和程序，因此任何一点微小的调整都需要各个环节通力合作才能勉强达成。而游戏的品质如何，往往要到最后开发出来一个版本才能看到。这时，项目往往已经开发到50%以上的进度了，无论做什么调整，都意味着巨大的先期投入。
&br&&br&然而幸运的是。虽然开发游戏的风险很高，但是传统游戏市场的回报也是丰厚的。次世代平台的游戏动辄可以获得几千万、甚至上亿美元的回报；某些大型网游也能达到近似的回报。为了拿到这么高的回报，当然无论从技术还是资金上都可以玩命的冒险。
&br&&br&因此，游戏开发的主要工具——引擎——就成了这个领域的一个关键性竞争要素。像&b&Unreal、Cry这些超级引擎，在其发展的初期就确立了两个指标，其一是贵；其二就是复杂。&/b&这些引擎有强悍的稳定性，但是调试过程和开发过程都相当复杂（我猜想是因为为了抢先实现一些视觉或功能上的效果，它们采用了很多层的技术来堆积引擎结构，导致引擎既庞大又难以驾驭），不过一开始他们不必担心这些问题，因为他们的客户都不差钱儿，而且有的是人手来“十年磨一剑”。
&br&&br&北京、上海、杭州每月都有几百万投资的新游戏项目启动，公司动辄4、50人，不少都能达到百人规模，购买昂贵引擎或者偷用昂贵工具的公司当然也不是少数。但其中大约七八成儿最终都没有获得预想的成功。足见游戏开发的风险之大。
&br&&br&【小型游戏、独立游戏开发】
&br&&br&当然，虽然每个做游戏的人都希望能搞一款大作，但不是每个公司都有机会做大型游戏的。因此几乎从游戏开发诞生那天起，小型游戏（中型游戏）开发就是这个领域的最主要项目形式。
&br&&br&中小型游戏一般规格不大，大多每次游戏时间都在1小时以内，也没有复杂的多人联线模式。因此开发起来相对有时间短、玩法鲜明的特点。在过去，中小型游戏大部分都采用开源引擎、Flash或者Java驾驭的自编引擎。这些特色让小型游戏迅速拥有了数量上的优势，占有了巨大的玩家时间。但是，小型游戏也有2个让开发者踌躇的问题：&ol&&li&这些引擎和工具大部分是基于二维技术的，因此我们看到的90%以上的中小型游戏都是二维的。视觉表现上越来越跟不上玩家的要求。&/li&&li&中小游戏的营收模式长期缺少保证，越来越低的投入导致品质越做越差。&/li&&/ol&【Unity】
&br&&br&Unity3D在发展之初，给自己的定位主要是中小游戏的开发。这个定位在一开始（Unity1.x时代）并不那么一呼百应，因为前面提到的两个问题里，Unity只能解决第一个，对第二个问题它开始也是束手无策的。
&br&&br&不过它有两个与大型引擎相反的特性，第一是便宜，第二是简单。它通过完善工具，解决了一些的确对游戏开发流程非常非常重要的问题：&ul&&li&容易上手。U3D有着与传统3D软件十分接近的界面，甚至某些方面比传统3D软件还要简捷易用，因此很快吸引了那些有3D软件使用经历的人。容易上手对一个引擎的普及非常重要，没人喜欢复杂难用的东西。&/li&&li&多语言编程。兼容JavaScript和.Net(C#)这两个比较主流的语种，方便程序开发。不过更重要的是，如果你对自己的逻辑和数学有信心，你也可以自己学这些语言来开发游戏。没你想的那么难。&/li&&li&节点堆积。U3D对所有场景物体“一视同仁”，通过堆积在上面的一条条功能来给它们添加各种属性。这让U3D成了世界上最容易理解的引擎结构之一。&/li&&li&傻瓜式调试和编译。只要点“播放”就可以马上测试（这个功能与大型引擎看齐）。&/li&&li&强大的扩展性。U3D有一个比较开放的结构，你可以自由添加一些自己编写的工具和插件进去，进一步完善U3D的功能，并且这些功能也可以跨平台使用。&/li&&/ul&还有很多特性可以自己去网上了解。
&br&&br&此外，Unity很“幸运”。iPhone和iPad突然火了，FaceBook也爆炸式增长，这让中小游戏突然有了全新的营收保障。目前全球增长最快的游戏领域是SNS游戏和手机游戏。而Unity正因为在这两个领域的强悍和实用性而变得成长更为迅速。
&br&&br&因此，我认为Unity可能并不是最为“强大”的引擎，但它一定是目前世界上成长速度最快，也是最好用的游戏引擎之一。
Unity 3D正在革命游戏开发市场。 我从Unity1.0开始关注它，并且从1.5开始使用。我感觉Unity 3D是一款革命性的游戏引擎，它（和一些同样具有创新精神的引擎）正在改写开发游戏的历史。 【高风险的大型游戏开发】 传统上来说，开发游戏是一件费时费力的事情，…
&p&&strong&Unity入门易：&/strong&&/p&&br&&br&&br&1、渲染对象上挂一个脚本组件就可以驱动该对象的逻辑，基于MonoBehaviour的脚本一上来就把初始化（Awake、Start），更新（Update、FixedUpdate）的接口留好了，初学者完全不用考虑程序框架一类的问题，直接填空就行。很像做早期flash游戏的感觉。&br&&br&2、编辑器非常强大，所见即所得的编辑方式，可以随时暂停、单帧执行游戏逻辑，提供场景和游戏多个窗口实时调试，观察效果。脚本组件面板上可以实时看到所有变量的当前值，这对于调试游戏逻辑非常方便。&br&&br&3、3D引擎功能很完善，与我们自研了5,6年的3D引擎相比，还是远远甩我们一大截，除了支持前向和后向的多种渲染管线，各种后渲染效果，还内置基于Beast的LightMap烘焙、基于Umbra的遮挡剔除这些商业中间件，要知道单采购这些中间件就得好几十万RMB，因此就算是个3D新手，要做个炫酷的3D效果也不是很难。虽然在渲染效果上可能比不上Unreal,Cry，但是U3D这玩意在中国，就算是免费的了，再说用U3D基本也是要发移动平台，目前的3D效果已经很够用。&br&&br&4、游戏其他方面的组件也很丰富，有基于PhyX的物理系统，你要做点什么疯狂小鸟、割绳子之类的游戏，真是很容易。另外还有基于NavMesh的导航系统、音乐音效系统（做音效的是FMOD的前开发者）等。&br&&br&5、良好的开发者社区生态系统。Unity最NB的就是建了个Asset Store，全世界的UNITY开发者在这里卖自己做的各种代码、组件、美术资源，分享经验。因此，学习成本大大降低。&br&&br&6、一键发布到各种平台，包括IOS、Andriod、WP、网页、Windows、Mac等，如果不是要接入其他平台相关的库（如内购等），几乎完全不用学习平台相关的编程知识（Object-C, Java等）&br&&br&7、作为证明Unity入门易的一个例子，本人在刚开始学Unity时，用了一个半月的业余时间，做了个推币小游戏，放在AppStore上，一个月基本上能收个几千块钱。给个链接吧，不算广告啊，只是说明下1个半月业余时间用Unity能做个什么样的出来：&a href=&/cn/app/id& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&iTunes 的 App Store 中的“小丑马戏团”&i class=&icon-external&&&/i&&/a&&br&--------------------------------------------------------------------------------------------------------------------------------&br&&br&&strong&Unity精通难：&/strong&&br&&br&1、基于MonoBehaviour的脚本，用得太顺手会有有很大的架构风险，你会情不自禁的A组件引用B组件，B组件又引用A组件.....项目一大写成一团乱麻。当然用其他引擎，其他语言也有这问题，但UNITY的一些特性必须用MonoBehaviour类来使用，所以要设计一个健壮的MVC架构需要顶住很多诱惑，绕一些弯。&br&&br&2、基于MonoBehaviour的脚本，组件的初始化顺序无法明确，这个坑也有回答提到了。&br&&br&3、底层代码不开源，尤其是Asset Store上卖的东西那帮开发者也习惯弄个dll封装起来，因此，一些底层修改需求没法改，有时候很头疼。&br&&br&4、C#的GC问题，这个不能说是Unity的错，C/C++的开发者会在长期的工作中变得对内存敏感，而C#开发者会弱得多，但游戏恰巧又是个内存敏感的应用程序。因此，开发者需要对C#的内存分配时刻非常敏感，否则就会出现频繁GC导致的顿卡现象。这里尤其要注意在每帧更新时的小内存分配。这方面要善用UNITY自带的内存和性能分析工具。&br&&br&5、Unity3D毕竟是个3D引擎，3D图形学知识毕竟门槛很高，要深入的做一个项目，需要对3D知识了解得很深，因此，在开发一些大型项目时，新手往往对于3D的各种需求和问题，如果Unity官方没有，或者Asset Store里找不到，就感到棘手。&br&&br&6、最大的坑！IOS发布时遇到跟AOT编译有关的运行时异常。简单说就是Unity采用mono对C#进行跨平台编译，但在iOS平台中，Mono是以Full AOT模式运行的，无法使用JIT引擎，于是引发了这个异常。所以经常出现的情况是在PC和Andriod上游戏都跑得很好，但在iOS平台会在运行时当掉！具体限制请参照：&a href=&/guides/ios/advanced_topics/limitations/#.NET.c2.a0API.c2.a0Limitations& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/guides&/span&&span class=&invisible&&/ios/advanced_topics/limitations/#.NET.c2.a0API.c2.a0Limitations&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&&p&7、作为证明Unity精通难的例子，我司跨时代炫酷国际大作秒杀Appstore前20的Unity项目，做了大概8个月了吧，估计要出来还得小1年....&/p&
Unity入门易：1、渲染对象上挂一个脚本组件就可以驱动该对象的逻辑，基于MonoBehaviour的脚本一上来就把初始化（Awake、Start），更新（Update、FixedUpdate）的接口留好了，初学者完全不用考虑程序框架一类的问题，直接填空就行。很像做早期flash游戏的感…
&b&某小妖口头禅，在文中如果出现TMD、NND、2B、狗屎……之类，请自动屏蔽，仅为口头禅，与人身攻击神马的无关。&/b&&br&&br& 游戏引擎是指一些已编写好的可编辑电脑游戏系统或者一些交互式实时图像应用程序的核心组件。这些系统为游戏设计者提供各种编写游戏所需的各种工具，其目的在于让游戏设计者能容易和快速地做出游戏程式而不用由零开始。大部分都支持多种操作平台，如Linux、Mac OS X、微软Windows。游戏引擎包含以下系统：渲染引擎（即“渲染器”，含二维图像引擎和三维图像引擎）、物理引擎、碰撞检测系统、音效、脚本引擎、电脑动画、人工智能、网络引擎以及场景管理。&br&&br& =========分割线================&br&以上答案来自百度&br&对于游戏开发者来说，引擎可以理解为一个封装好的盒子，它的功能是提供调用接口，好让一些复杂的事情通过这个盒子之后变的简单。&br&&br& 举个例子，我们要在计算机上渲染一个3D的场景，而从实际上来说，显示在你的电脑屏幕上的只是一张带有深度感觉的2D图片。（不能理解的翻相册，看看自己的照片，您老不论多么3D的脸庞，印在照片上之后都是一个平面，就在那张纸上。之所以你还是觉得自己看起来是立体的，是因为有了深度感的颜色变化和光影变化。）&br&对于游戏场景来说是一样的。&br&&br& 首先美术创建了许多3D模型，而这些3D模型分解起来就是许多的三角形包围出来的密封体。然后在这模型基础上，美术绘制了一层叫做贴图的东西，这东西很像人的皮肤，于是……一个模型就诞生了。&br&&br& 接着，我们发现，通过画法几何，3D几何等学术内容的一大堆算数结果……（这点是凑字数的，看不懂没关系，我也不懂）&br&我们得到一个结论，我们在这个模型的前面摆上一个摄像机，摄像机的视角是扇形范围内的一小块，在这一小块范围内，我们能看到的内容，我们先称之为摄像机视角。不难发现，物体的背面，我们是看不到的（除非你丫转视角），两个物体之间的前后关系，是通过遮挡关系来实现的，除此之外，这个视角下的内容符合我们一切所熟知的光学原理……漫反射、反射、折射、光吸收、投影……想想你的高中物理知识，你不难得到结论：想要描述一个物体，我只需要描绘关于这个物体的全部光信息就可以了。&br&&br& 那么…………我们得到了一套可以通用的算法，我们把这套算法称之为绘制物体时所需要的算法。&br&&br& 转头看来代码层……&br&如果你每去创建一个物体，都用这种反锁的方式去写一套算法给这玩意儿……你不觉得你很脑残么……于是，就有了这个封装盒子。当然，绘制一个3D图形只是这个封装盒子其中一部分功能。&br&&br& 我们一般把引擎分为：客户端引擎和服务器端引擎。他们分别提供不同的借口，来解决不能的问题。&br&&br& 客户端引擎是我们接触的最多的，它关联的内容包括，骨骼动画、材质、shader、特效、渲染………………等等等。&br&&br& but！！！&br&&br& 这个非常重要，我因为我见过很多2B跟我在这儿瞎得得！&br&&br& 引擎并不包含功能，或者是引擎并不包含逻辑。比方说，你TM要写一套组队功能，对不起，引擎不管你这事儿。&br&&br& ================================以下是对程序猿同学的建议&br&程序猿分很多岗位。&br&对于不同开发需求，会要求程序猿会不同的语言和开发工具。&br&e.g：&br&游戏引擎程序猿一般要求是会C++，但是熟知数学、3D数学、至少你要明白四元数是个什么玩意儿，如何做矩阵叉乘。&br&&br& 客户端程序猿是看开发需求，一般要求是C++、C、或者是脚本语言，例如python。&br&&br& 页游程序猿，主要是服务器端程序猿和前端程序猿，前端程序猿的要求一般是as架构。&br&&br& 手游程序猿……以前是JAVA，现在是了解APP平台和APP开发工具，还有些什么玩意儿，不是很清楚。&br&&br& 此外，会有公司要求你熟悉引擎，比如说，熟悉BG、GB，UE，CE。还有一些引擎本身支持跨平台。例如UE，他支持家用机平台开发，手游开发，客户端游戏开发，等等。&br&&br& 但总体来说万变不离其宗，看好C++走遍天下都不怕~
某小妖口头禅，在文中如果出现TMD、NND、2B、狗屎……之类，请自动屏蔽，仅为口头禅，与人身攻击神马的无关。 游戏引擎是指一些已编写好的可编辑电脑游戏系统或者一些交互式实时图像应用程序的核心组件。这些系统为游戏设计者提供各种编写游戏所需的各种工…
泻药。我是 &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年的一个整体回顾下面是针对你的情况做的…
不管用什么引擎，游戏程序员的工作包括：&br&1、垒代码&br&2、和策划友善地开会&br&3、和策划不友善地开会&br&4、问策划要配置&br&5、指出策划的配置错误，催其去改&br&6、被策划催着赶功能（继续垒代码）&br&7、偷看美女美术的背影&br&8、因为赶着发版本而写出有问题的代码（继续垒代码）&br&9、因为赶着发版本而不做单元测试（继续垒代码）&br&10、版本发完了，抽烟喝酒和策划友善地联络感情&br&&br&刚进入公司应该注意的应该是…… 漂亮的女同事？&br&&br&---------------友善的分割线---------------------------&br&&br&下面认真地回答一下。&br&&br&作为直接面向业务的游戏程序员，你需要具备的基本素质应该包括：&br&1、熟练掌握所使用的语言、引擎，能够快速响应大部分日常需求。&br&2、分析问题的能力，抓住问题关键因素的能力。&br&3、态度友善，沟通良好。对面向业务的程序员而言，沟通就是日常工作中极重要的一部分。&br&4、热爱游戏，玩过大量游戏。这会极大的降低与策划沟通的成本，并提高产出产品的细节品质。&br&5、不要过于追求短期回报。成长环境和空间更重要。&br&以上五条，既是刚进入公司需要注意的内容，也是面对面试时需要准备的内容。&br&&br&你需要在工作中不断积累提高的高级素质可能包括：&br&1、技术攻坚能力，解决突发事件的能力等。&br&2、领导能力，工作协调分配能力，统筹安排能力。&br&3、面向客户、运营、老板等，或在其它重要场合的表达能力与临场发挥能力。&br&4、谈判能力。&br&5、各种各样奇怪的综合能力。
不管用什么引擎，游戏程序员的工作包括：1、垒代码2、和策划友善地开会3、和策划不友善地开会4、问策划要配置5、指出策划的配置错误，催其去改6、被策划催着赶功能（继续垒代码）7、偷看美女美术的背影8、因为赶着发版本而写出有问题的代码（继续垒代码）9…
Timeline上刷出这个问题，想起4年前我也问过学长类似的问题，便不请自来。&br&&br&相关：游戏研发技术人员&br&&br&首先说明，我没用过DirectX，只用过OpenGL，但相信题主已经在听说DirectX的同时也听说过OpenGL了。因此以下是以OpenGL的角度说的，DirectX存在一些细节差异。&br&&br&回答题主的问题。&br&&br&&b&1、DirectX 是什么？&/b&&br&OpenGL，直译过来就是，开放的图形库（&b&Open &/b&&b&G&/b&raphic &b&L&/b&ibrary）。如其名，它的作用，就是绘制图形，除此之外都不做。&br&OpenGL是跨平台的，windows、Mac、Linux、iOS、Android等等大家都能用。但所谓泛而不精，微软为了更好的性能，开发出了一套&b&“专门适配windows平台的OpenGL&&/b&，名为DirectX。同理，苹果在今年也开发出了一套&b&“&/b&&b&专门适配&/b&&b&Mac和iOS平台的OpenGL”&/b&，名为Metal 3D。&br&&br&&b&2、在游戏开发中常用吗？&/b&&br&游戏开发中，常用，或者说必用。&br&游戏开发是什么？无非就是根据一定的逻辑，给予玩家一定的反馈。这种反馈，大部分是视觉上，例如按钮点下出现的阴影，释放技能产生的特效。也可以是听觉的反馈（音乐音效），触觉的反馈（手柄或手机的震动）等等。那么用DirectX（或其他图形库）去实现视觉上的反馈，完成游戏，当然是最常用的。&br&&br&&b&3、如果用directX 配合微软的visual studio ，不借助其他引擎，能否完成一个游戏编程方面的工作。（和其他引擎有什么区别？）&/b&&br&这两个其实是一个问题。&br&由2的回答，题主应该知道了，单纯用DirectX可以完成视觉上的反馈，如果自己再加上一些音乐音效播放的库，通过代码逻辑的迭代，便足以组装出一个游戏了。&br&但，游戏是仅仅这么简单么？&br&也许你要模拟一个大雪的场景，你可能用DirectX画出一个雪花，然后让他们在屏幕的随机坐标出现，并设置一定的速度让他们缓缓落下。完成并调整好这个效果，你可能需要一天的时间，但如果你知道，这叫做粒子系统，并且在大部分游戏引擎中已经实现，那么这只需要一分钟的时间即可完成。&br&&br&如果把游戏引擎比作绘画，那其中部件可大致分为三类，&br&第一类，相当于颜料中的三原色，DirectX等图形库，OpenAL等音乐库，键盘、触摸屏或手柄的输入控制，他们是最基础的组成部分。&br&第二类，相当于形形色色的颜料，如前面提到粒子系统、如精灵、视差层、地图刷等部件，虽然它们可通过三原色调制出来，但由于实在过于常用，便集成进了游戏引擎里。&br&第三类，相当于颜料盘、画笔等等，它用于辅助游戏的完成。例如事件分发系统、定时器系统等，可简化在编程过程中的代码逻辑。&br&&br&游戏引擎是一套完整完善的游戏开发解决方案，而DirectX，是一个图形处理库，属于游戏引擎中的一部分。&br&&br&私货：&br&看题主的意思，我猜可能是打算不使用游戏引擎，自己开发一款游戏。我即不赞成也不反对，这可能会花费很多时间，并且对于刚接触游戏开发来说，难度不小。但这会是非常宝贵的经验。&br&我当年做的第一个游戏，也是自己完成，并且坚持不使用任何游戏引擎，连DX都没用，全用Windows API迭代的，很辛苦的一段时间，但是现在想想，非常难得。许多原理，是光用游戏引擎难以了解到的。
Timeline上刷出这个问题，想起4年前我也问过学长类似的问题，便不请自来。相关：游戏研发技术人员首先说明，我没用过DirectX，只用过OpenGL，但相信题主已经在听说DirectX的同时也听说过OpenGL了。因此以下是以OpenGL的角度说的，DirectX存在一些细节差异。…
哈哈哈，上市心切，结果被低估值，怒了。&br&&br&触控这几年自研能力比较差，除了捕鱼达人就没别的了。转型做手游代理以后业务发展倒是不错，可是行内人都知道，手游代理的利润薄，大头要给开发商和渠道。所以要按纯游戏公司估值的话，确实就这么多钱，美国人也不傻。&br&&br&但Cocos这个引擎的价值是真的，触控手里的Cocos引擎和UNITY引擎这两家是现在手游开发行业最常用的2个引擎。这些引擎现在还是免费的，各家都可以随便用，但是UNITY引擎需要高级的素材库和特殊功能就要收费，这也是为什么Cocos引擎作为一个开源项目在国内更受开发者欢迎的原因。&br&&br&目前Cocos引擎的市场占有率是超过其它引擎的。&br&&br&&img src=&/db37d0fc9f6c805cabc183d6_b.jpg& data-rawwidth=&504& data-rawheight=&477& class=&origin_image zh-lightbox-thumb& width=&504& data-original=&/db37d0fc9f6c805cabc183d6_r.jpg&&&br&&br&拥有引擎的公司有如下几个好处：&br&1，从最上游控制移动游戏行业的生态链条&br&2，亲密接触游戏开发商，挖掘黑马公司并进行投资&br&3，引擎内功能模块集成，可以有很多想象空间：&br&
A，平台化&br&
B，内建广告联盟，游戏间推荐&br&
C，大数据，PUSH系统&br&
D，底层存储和信息传输解决方案，云服务&br&
E，渠道SDK打包&br&
F，支付&br&4，垄断市场以后，还可以收服务费——虽然我不觉得他们会这么干&br&&br&我觉得6亿美金也就亚马逊出得起，但也不至于在估值的时候完全忽略引擎价值。
哈哈哈，上市心切，结果被低估值，怒了。触控这几年自研能力比较差，除了捕鱼达人就没别的了。转型做手游代理以后业务发展倒是不错，可是行内人都知道，手游代理的利润薄，大头要给开发商和渠道。所以要按纯游戏公司估值的话，确实就这么多钱，美国人也不傻…
来自子话题：
@谢邀&br&这是我在知乎第二次认真回答问题，第一次给了&a href=&/question/& class=&internal&&开发一个 Flappy Bird 需要多少行代码，多少时间？&/a&效果还不错。&b&首先表明我是一个代码帝，喜欢用代码说话，轻砸。&/b&&br&&br&开发这样的游戏难不难，我觉得不难，&b&玩通关比开发难多了&/b&，我一个礼拜才玩到第五关，开发两天就够了；&br&&br&有图有真相，我开发过&br&&img src=&/dff26e9efffd388e795fee_b.jpg& data-rawwidth=&224& data-rawheight=&442& class=&content_image& width=&224&&&img src=&/d5bbfba3f24c5d31e2ea316_b.jpg& data-rawwidth=&224& data-rawheight=&442& class=&content_image& width=&224&&&br&&br&&b&逻辑实现&/b&&br&基本的流程就是这样
创建10*10随机星星——触摸——检测颜色——消除星星——掉落移动——合并星星——检测死局——结束 大概如此&br&&br&&br&代码实现是基于js编程语言，cocos2d-x游戏引擎实现的；&br&&br&&p& 1
创建随机单个星星，并加入单个星星掉落动画&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.getRandomStar = function (colIndex, rowIndex) {
this.starSize = 72;
var stars = PS_MAIN_TEXTURE.STARS;
var randomStar = stars[getRandom(stars.length)];
var starSprite = cc.Sprite.createWithSpriteFrameName(randomStar);
starSprite.setAnchorPoint(cc.p(0.5, 0.5));
starSprite.setPosition(cc.p(36 + colIndex * this.starSize,
starSprite.starData = {name: randomStar, indexOfColumn: colIndex, indexOfRow: rowIndex};
starSprite.setZOrder(100);
var flowTime = rowIndex / 10;
var fallAction = cc.MoveTo.create(flowTime, cc.p(36 + colIndex * this.starSize,
36 + rowIndex * this.starSize));
starSprite.runAction(fallAction);
return starS
&/code&&/pre&&/div&&br&&br&&br&2 根据表格位置初始化10*10星星群，产生星星从空中坠落的效果&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.initStarTable = function () {
this.starTable = new Array(this.numX);
for (var i = 0; i & this.numX; i++) {
var sprites = new Array(this.numY);
for (var j = 0; j & this.numY; j++) {
var pSprite0 = this.getRandomStar(i, j);
if (pSprite0 != null) {
this.rootNode.addChild(pSprite0);
sprites[j] = pSprite0;
this.starTable[i] =
&/code&&/pre&&/div&&br&&br&&br&&p&3
10*10星星群检测触摸事件，通过this.sameColorList.length可以判断是第一次触摸还是第二次触摸 ；数组长度
&1表示第二次触摸，这里又有分支，触摸的是刚才同一颜色区域还是其他区域？如果是原来颜色区域，删除this.removeSameColorStars()，如果不是原来颜色区域，恢复原状，然后新的检测；数组长度 &=1表示第一次触摸
直接检测颜色相同区域&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.onTouchesBegan = function (touches, event) {
var loc = touches[0].getLocation();
this.ccTouchBeganPos =
for (var i = 0; i & this.starTable. i++) {
var sprites = this.starTable[i];
for (var j = 0; j & sprites. j++) {
var pSprite0 = sprites[j];
if (pSprite0) {
var ccRect = pSprite0.getBoundingBox();
if (isInRect(ccRect, this.ccTouchBeganPos)) {
if (this.sameColorList.length & 1) {
if (this.sameColorList.contains(pSprite0)) {
cc.AudioEngine.getInstance().playEffect(PS_MAIN_SOUNDS.broken, false);
this.removeSameColorStars();
for (var k = 0; k & this.sameColorList. k++) {
if (this.sameColorList[k]) {
this.sameColorList[k].runAction(cc.ScaleTo.create(0.1, 1));
this.checkSameColorStars(pSprite0);
if (this.sameColorList.length & 1) {
cc.AudioEngine.getInstance().playEffect(PS_MAIN_SOUNDS.select, false);
this.checkSameColorStars(pSprite0);
if (this.sameColorList.length & 1) {
cc.AudioEngine.getInstance().playEffect(PS_MAIN_SOUNDS.select, false);
&/code&&/pre&&/div&&br&&br&&p&4 建立单个星星的四个方向检测，上下左右，把颜色相同的放在一个数组里面，回调这个数组；其实最后用这个函数的时候主要是判断数组的大小；数组大于1，说明四周有相同颜色的；&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.checkOneStarFourSide = function (sprite) {
if (sprite == null) {
// cc.log(&checkOneStarFourSide&);
var fourSideSpriteList = [];
var color = sprite.starData.
var col = sprite.starData.indexOfC
var row = sprite.starData.indexOfR
if (row & 9) {
var upSprite = this.starTable[col][row + 1];
if (upSprite != null && upSprite.starData.color == color) {
fourSideSpriteList.push(upSprite);
if (row & 0) {
var downSprite = this.starTable[col][row - 1];
if (downSprite != null && downSprite.starData.color == color) {
fourSideSpriteList.push(downSprite);
if (col & 0) {
var leftSprite = this.starTable[col - 1][row];
if (leftSprite != null && leftSprite.starData.color == color) {
fourSideSpriteList.push(leftSprite);
if (col & 9) {
var rightSprite = this.starTable[col + 1][row];
if (rightSprite != null && rightSprite.starData.color == color) {
fourSideSpriteList.push(rightSprite);
return fourSideSpriteL
&/code&&/pre&&/div&&br&&br&&p&5 检测相同颜色区域，这里的算法比较复杂；有两个数组this.sameColorList和newSameColorList，前者是全局星星数组，后者是每次扩展新加入的星星；比如这样情况，一个星星左右上有相同的星星，上面的上面还有一个星星，总共五个相同星星：三次检测情况是this.sameColorList为1---4----5 ，而newSameColorList为1--3--1，各种曲折，读者好好理解下；&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.checkSameColorStars = function (sprite) {
if (sprite == null) {
this.sameColorList = [];
this.sameColorList.push(sprite);
var newSameColorList = [];
newSameColorList.push(sprite);
//by logic ,check the same color star list
while (newSameColorList.length & 0) {
for (var i = 0; i & newSameColorList. i++) {
var fourSide = this.checkOneStarFourSide(newSameColorList[i]);
if (fourSide.length & 0) {
for (var j = 0; j & fourSide. j++) {
if (!this.sameColorList.contains(fourSide[j])) {
this.sameColorList.push(fourSide[j]);
newSameColorList.push(fourSide[j]);
newSameColorList.splice(i, 1);
cc.log(&sameColorList length==& + this.sameColorList.length);
if (this.sameColorList.length & 1) {
for (var k = 0; k & this.sameColorList. k++) {
var simpleStar = this.sameColorList[k];
if (simpleStar) {
simpleStar.runAction(cc.ScaleTo.create(0.1, 1.08));
&/code&&/pre&&/div&&br&&br&&p&6
移除刚才选中的相同颜色的星星，并产生爆炸粒子效果&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.removeSameColorStars = function () {
for (var k = 0; k & this.sameColorList. k++) {
var simpleStar = this.sameColorList[k];
if (simpleStar) {
var col = simpleStar.starData.indexOfC
var row = simpleStar.starData.indexOfR
this.starTable[col].splice(row, 1, null);
this.rootNode.removeChild(simpleStar);
if (sys.platform != 'browser') {
var starParticle = cc.StarParticle.create(this.rootNode, (36 + col * this.starSize), (36 + row * this.starSize), &spark&);
starParticle.runAction(cc.Sequence.create(cc.DelayTime.create(0.8), cc.CleanUp.create(starParticle)));
this.sameColorList = [];
this.fallStar();
&/code&&/pre&&/div&&br&&br&&p&7 星星掉落 填充空缺，主要是如果一个地方有空缺，就把它上面的星星位置和数据交换，用到数组的方法splice，可到网上查看js数组的一些方法应用&/p&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.fallStar = function () {
for (var i = 0; i & this.starTable. i++) {
var sprites = this.starTable[i];
var length = sprites.
for (var j = 0; j & j++) {
var pSprite0 = sprites[j];
if (pSprite0 == null) {
var k = j + 1;
while (k & length) {
var upSprite = sprites[k];
if (upSprite != null) {
upSprite.starData.indexOfColumn =
upSprite.starData.indexOfRow =
this.starTable[i].splice(j, 1, upSprite);
this.starTable[i].splice(k, 1, null);
var flowTime = 0.2;
var fallAction = cc.MoveTo.create(flowTime, cc.p(36 + i * this.starSize,
36 + j * this.starSize));
upSprite.runAction(fallAction);
this.deadStar();
// bineStar();
&/code&&/pre&&/div&&br&&br&&p&8
合并星星，如果最底部有空缺，星星必须向左合并，不能出现空缺&/p&&div class=&highlight&&&pre&&code class=&language-text&&bineStar = function () {
for (var m = 0; m & this.starTable. m++) {
var mSprite0 = this.starTable[m][0];
if (mSprite0 == null) {
if (m == (this.starTable.length - 1)) {
for (var j = 0; j & this.starTable[m]. j++) {
this.starTable[m].splice(j, 1, null);
for (var i = (m + 1); i & this.starTable. i++) {
// this.starTable.splice((i - 1), 1, this.starTable[i]);
for (var j = 0; j & this.starTable[i]. j++) {
var pSprite0 = this.starTable[i][j];
this.starTable[i - 1].splice(j, 1, pSprite0);
if (pSprite0 != null) {
pSprite0.starData.indexOfColumn = (i - 1);
var col = pSprite0.starData.indexOfC
var row = pSprite0.starData.indexOfR
var moveAction = cc.MoveTo.create(0.1, cc.p(36 + col * this.starSize,
36 + row * this.starSize));
pSprite0.runAction(moveAction);
this.deadStar();
&/code&&/pre&&/div&&br&&br&&p&9
游戏到最后 会发生死局情况，程序自动判断消除；这里主要是循环检测每一个星星，如果所有的星星四周都没有相同星星的时候，就确认为死局，程序自动消除星星 &/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&MainLayer.prototype.deadStar = function () {
var isDead =
for (var i = 0; i & this.starTable. i++) {
var sprites = this.starTable[i];
var length = sprites.
for (var j = 0; j & j++) {
var pSprite0 = sprites[j];
if (pSprite0 != null) {
if (this.checkOneStarFourSide(pSprite0).length & 0) {
if (isDead) {
for (var jj = 9; jj &= 0; jj--) {
for (var ii = 0; ii & 10; ii++) {
var pSprite0 = this.starTable[ii][jj];
if (pSprite0 != null) {
var delay = 4 + 0.3 * ii - 0.4 *
pSprite0.runAction(cc.Sequence.create(
cc.DelayTime.create(delay),
cc.CleanUp.create(pSprite0)
var starParticle = cc.StarParticle.create(this.rootNode, (36 + ii * this.starSize), (36 + jj * this.starSize), &spark&);
starParticle.runAction(cc.Sequence.create(cc.ScaleTo.create(0, 0),
cc.DelayTime.create(delay), cc.ScaleTo.create(0, 1), cc.DelayTime.create(0.8),
cc.CleanUp.create(starParticle)));
&/code&&/pre&&/div&&br&基本就是这样&br&&b&想要源码到我博客里面找吧&/b&：&a href=&http://blog.csdn.net/touchsnow/article/category/2094455& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&blog.csdn.net/touchsnow&/span&&span class=&invisible&&/article/category/2094455&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
@谢邀这是我在知乎第二次认真回答问题，第一次给了效果还不错。首先表明我是一个代码帝，喜欢用代码说话，轻砸。开发这样的游戏难不难，我觉得不难，玩通关比开发难多了，我一个礼拜才玩到第五关，开发两天…
&b&以下仅代表个人观点，不喜请喷&/b&&br&&br&首先，我将引擎和市场进行分类（仅包括图形部分，下同）：&br&1. 按照引擎特性，分为先进引擎，优势引擎和普及引擎；（以2D/DX9.3/DX11为分界线）&br&2. 按照引擎的应用领域，分为高端（UE,CE,Unity），中端（鬼火，OGRE），自研引擎；&br&3. 按照目标人群，划分为小众与大众。&br&&br&举个例子，战争机器和战地就是：大众+先进+高端；而植物大战僵尸，就是普及+自研+大众。例如Milo之前所在的麻辣马的&疯子爱丽丝&，就可以算是”高端+先进+小众“。《斗战神》就是自研+优势+大众的组合（网游的普遍模式）。&br&&br&实际上，几乎每种组合，你都能找到相应的产品。下面来分析一下影响：&br&&br&1. 无论对大众市场，还是小众市场，因为授权成本的降低，先进+自研引擎将会收到深刻的冲击；&br&&br&2. 优势引擎因为要考虑照顾到极为多样和复杂的公众配置，这一块可以算作是UE和CE的短板。而且优势引擎的涵盖用户群是一个刚需，单纯的先进引擎（如CE）很难对这部分引擎用户产生吸引力。大部分的公司（尤其是网游），通常会是用自研和知名开源引擎来解决这个问题。Unity如果按照现有的目标来看，可以覆盖先进和优势两端。所以会凭借低成本和工具链成熟，&b&对未来的自研和中端引擎市场造成不小的冲击&/b&，但是对已经有成熟引擎和产品的公司来说，吸引力未必就很大了，这一类引擎可以借助UE4快速进化到一个比较高的水平。&br&&br&3. 普及引擎多数出现在休闲类作品中，这一类作品一般引擎都有很强烈的自我特质，很难被先进/优势引擎覆盖到，因此仍然相对固定。但是不排除因为Unity这一类工具链相当完整的引擎授权改编后，游戏的创作者会顺应改变游戏的性质，使其像优势引擎的方向发展（也就是3D化或者立体化）。但是我不认为这个是主流。&br&&br&4. UE4的代码的廉价开放，会使从业人员很轻松就能获得可靠权威的参考代码，本来在IT行业就有借鉴后自研的倾向，也可能会因为这个原因再度兴起。&br&&br&综合一下，&b&UE4的市场策略是双管齐下与Unity5对抗&/b&：先进引擎市场利用价格与之抗衡；优势引擎市场利用技术公开与之抗衡。&b&Unity5的市场策略则是一脉相承，简单粗暴，多点开花：&/b&降低价格，充分挤压中端引擎和自研引擎市场，释放优势引擎市场的潜能，并尽可能吸引普及引擎的用户加入其中，同时试图用新特性打入高端。&b&CE的策略则是：在充分先进的基础上，更便宜，更便宜，更便宜。&/b&&br&&br&&br&至于他们的市场策略能否奏效，未来发展如何，那得看腾讯会不会把三家全收购了。（逃）
以下仅代表个人观点，不喜请喷首先，我将引擎和市场进行分类（仅包括图形部分，下同）：1. 按照引擎特性，分为先进引擎，优势引擎和普及引擎；（以2D/DX9.3/DX11为分界线）2. 按照引擎的应用领域，分为高端（UE,CE,Unity），中端（鬼火，OGRE），自研引擎；…
时代在变化。&br&&br&当一项技术走向产业化并不断成熟时，角色的分化是不可避免的，就像操作系统的出现，就像高级语言的出现。技术发展的过程当中，我们总是在试图解决超越自己能力问题，于是当人们看透过去失败的教训时，他们便停下来思考，达成共识，构造抽象，搭建阶梯，制造一个巨人的肩膀来让后人站得更高，不必再担心脚下是否坚实可靠。如此循环往复，技术进步，时代变迁，我们的创造力也从中解放。这是人类进步的必然，游戏也不例外，不过游戏业发展到如今，早已是一个远离先驱的时代。&br&&br&然而分化仅仅是个开端。依稀记得当年Unreal和id的引擎大战，游戏引擎这一概念第一次在人们眼中变得鲜明起来。就像操作系统的出现改变了人们编程的方式一样，游戏引擎的出现也势必颠覆人们创造游戏的方式，于是各大技术实力深厚的公司纷纷开始打造自己的引擎来支援游戏开发。&br&&br&但分化还在继续，游戏引擎逐渐从游戏创作中剥离出来，就意味着它将不断专业化，为了克服复杂度，变得更加强大，引擎本身也将作为一个独立的个体继续分化下去，从开始的图形引擎，音效引擎，碰撞引擎，到后来的脚本引擎，物理引擎，动画引擎，再到更加细分的格斗引擎，动作捕捉，美术框架，场景设计，资源管理。而现今流行的体感，多平台，3D视觉在以后也将更加清晰和专业化，融入游戏引擎的大家族。&br&&br&引擎在不断复杂和细化，也在不断解放游戏创作人员的创造力，让他们摆脱繁杂的底层处理，把所有精力真正投入到那些有价值的异质的部分：设计，艺术与游戏性。然而时隔多年，游戏引擎早已从一组API变成了一整套庞大的创作环境，直到一家游戏公司再也承受不了引擎维护的巨大成本，一个崭新的市场和产业呼之欲出。&br&&br&这接下来的一切都正在发生。一些公司面临抉择，有的选择逐渐摒弃游戏业务，开始专心研发商业游戏引擎，想要成为这一新市场的先驱者；有的选择放弃引擎维护，把成本投入到更有价值的内容创作中；还有为数不少的技术型厂商依然沿着老路在走，或外包，或自己做。&br&&br&随着去年Unreal和CryEngine相继开放使用，越来越多的引擎加入到这一新市场的争夺上，「寒霜」、「Red Engine」，个个都有备而来，素质不凡。然而Unreal作为行业的先驱者，拥有庞大的社区和完善的开发者支持，优势是很明显的。随着下个家用机世代的到来和Unreal 4的发布，好戏才刚刚开始。未来5到10年，商业引擎产业的格局将会越来越清晰，更多的公司将会采用商业引擎，一些引擎的霸主地位也将逐步确立，为群雄割据的时代画上一个句号，整个游戏业也会完成它的进化。&br&&br&当商业引擎产业不断稳定和成熟，它将是难以进入的，这和任何一个其他产业的情况都是类似的。就像PC大潮结束时一样，一个发展成熟的操作系统是复杂而无所不及的，上面连带着大量的产品和服务，平台价值无法估量，此时它已经是不可替代的。一家公司可能能够创造一款独一无二的操作系统，但已经几乎没有机会去创造一个成功的生态系统了。所以国内即使有自己的操作系统，也只能是极其细分的小规模应用。&br&&br&成就「巨人肩膀」的是牛顿手中的苹果，而不是「巨人肩膀」本身，PC浪潮时中国已经错过了摘苹果的时机，而商业引擎时代中国厂商也正在错过。Unreal和CryEngine在做正确的事情，他们在开放平台。等到基于它们的构造不断被创造出来，平台价值开始井喷，没有人能阻止他们成为霸主。技不如人就只能在平台竞争中落败，也就只能不断地错过成为霸主的机会，直到有一天我们真正地作为一个民族超越了其他民族，我们才有机会站在浪潮之巅。&br&&br&如今的游戏业商业上的主战场在家用机平台，PC游戏平台几乎已经沦为了新技术的试验田。而游戏引擎作为技术力的代表是要靠单机游戏来竞争的，网络游戏天然的实时性不足让它难以成为技术竞争的主战场。这也是国内引擎行业尴尬之处所在，为数不多的国产引擎均以网络游戏为核心，最多画面引擎出彩一些，很难产生真正有核心竞争力的引擎产品，更别提开创一个生态系统。&br&&br&时代在变化。国产引擎正在错过成功的时机，购买引擎已经像购买SDK一样自然，未来也将更加普遍。现在开发引擎已经颇难，随着大型引擎的开放化，这将越来越变成一件不可能，也不值得去完成的事情。
时代在变化。当一项技术走向产业化并不断成熟时，角色的分化是不可避免的，就像操作系统的出现，就像高级语言的出现。技术发展的过程当中，我们总是在试图解决超越自己能力问题，于是当人们看透过去失败的教训时，他们便停下来思考，达成共识，构造抽象，搭…
来自子话题：
我是王哲，cocos2d-x创始人。正面回答楼主的问题&br&&br&1. cocos2d-x是中国人自己搞的?
YES。不仅如此，我们已经雇佣了cocos2d-iphone作者Ricardo Quesada一起搞。在程序员的世界里面，没有中国人、美国人、阿根廷人的概念，只有C++程序员，Java程序员，Lua程序员的概念。技术无国界。&br&&br&2. 国外用得不多吗？可能是早期情况。截止2014年7月的情况是，日本的《怪物弹珠》基于 cocos2d-x, 问鼎过日本付费总榜第一，万代南梦宫的正版《梦想海贼王》《J
OJO奇妙大冒险》都是基于cocos2d-x开发。我们统计出来全球google play前1400名有17.5%是基于cocos2d-x引擎开发。AppStore美国付费总榜第前5名的Big Fish Casino也是基于cocos2d-x的。楼上说得对，野心不小。我的野心就做是一个世界级的产品，对社会和行业有价值。
我是王哲，cocos2d-x创始人。正面回答楼主的问题1. cocos2d-x是中国人自己搞的? YES。不仅如此，我们已经雇佣了cocos2d-iphone作者Ricardo Quesada一起搞。在程序员的世界里面，没有中国人、美国人、阿根廷人的概念，只有C++程序员，Java程序员，Lua程序员…