经典的游戏引擎设计思路有哪些？
经典的游戏引擎设计思路有哪些？ 单机及网游基本类似：1、基本框架（渲染、逻辑、物理 等等各部分如何组装）
2、资源管理
3、渲染
4、基本逻辑（网游还要解决逻辑的同步问题）
5、物理（有时候和逻辑合并）
-----------分割线，以下是重要但较为独立的部分-------------
6、UI
7、音乐音效
8、网络
9、脚本（有些类型的游戏引擎需要脚本和逻辑的关联性非常强，有些脚本则比较独立）
社交游戏的引擎应该只是一个子集，主要需要解决资源管理和UI的问题，其他的相对并不重要，或根据具体游戏内容的需要再进行添加。 好问题，不过有点庞大且复杂，我尝试抛砖引玉回答一下。
以目前市面上非常成熟且成功的商业引擎——虚幻引擎举例，他的很多设计无疑是非常优秀的。我接触虚幻有三年多的时间，这里从自己的角度，来谈一谈其中的一些设计思路。
一、组件式设计
怎么理解呢？就是把某一种特定的功能封装到一个叫做“组件Component“的对象里面，通过添加与卸载组件达到灵活的复用与组合效果。包括unity在内，里面的基础对象和很多功能都是分开的。一个普通的对象可以什么功能都没有，放到场景里面既不会移动也不会显示，需要给他添加特定的组件才行，包括移动能力，显示模型能力，碰撞能力等。那举一个Unreal中的例子，比如说我们有一个角色character，也就是我们经常在网上见到的下面这个家伙。
他身上有几个默认的组件，包括一个胶囊体碰撞组件，一个模型显示的组件，一个摄像机组件以及一个移动组件。正因为有了这些组件，你的角色才可以自由的在场景内移动，与地面有碰撞交互甚至是执行网络同步。如果没有他们的话，你连看到他在哪都做不到。
从代码的角度来看，就是大概下面这个样子，一个Character下面有几个成员变量，
当然，最近ECS比较火，Unity已经提供相关的模块，Unreal也在尝试，但是好像还没有加入到引擎里面。
二、模块式设计
对于虚幻这样复杂的项目，管理与维护起来是相当困难的，为了尽可能降低各个模块之间的耦合，肯定是要将各个模块尽可能的拆分成独立的模块，不会相互影响。看一下虚幻引擎的目录结构以及其dll的文件夹，
基本上都是最小粒度的将一个模块封装成一个dll，每个dll的生成以及与其他dll的相互引用等内容要在模块.build.cs文件里配置。
三、插件设计
一个引擎想要成为商业引擎，只靠官方自己造轮子肯定是不行的。所以，一定要提供给大家足够灵活的方式去添加或者发布自己的轮子，简单来说就是插件功能。其实这一条与上面第二条是紧密结合的，我们如果一开始就能做到将各个模块都拆分成不同的库，那么插件也可以用类似的方式形成一个独特的模块，除了路径以及一些引用内容不同外，他基本上与其他模块式差不多的。
另外，第三方库肯定也是要支持的，不过这个可以由开发团队自己去搞。
四、抽象分层设计
这个比较宽泛，是我自己起的名。大概意思就是说，如果一个功能很复杂，就要想办法给其抽象一个出概念。接触虚幻引擎的朋友可能知道，虚幻引擎的代码之所以复杂，就是因为做了很多抽象和封装，你即使有过其他引擎的基础，看虚幻代码还是有很多新的概念要去理解。当然，我个人觉得如果不做抽象和封装，这个引擎就你就更别想看懂了。
这里拿UE4内置的网络模块做描述，正常我们写一个普通的网络通信逻辑一般也就是Client、Servedr、Socket、TCP/UDP这些概念，但是在虚幻引擎里面，为了考虑哪些包要可靠传输、哪些不要、粒度是如何的、同步的基本单位是什么等等就会引出来一系列复杂的概念，比如bunch、Channel、Connection等等，其实这些都是其多年的引擎设计经验不断完善的结果。我猜想一开始肯定也都是非常简单，随着不断的完善与添加新功能逐步做了多层的封装与设计。至于在设计时要封装到什么程度，取决于当前模块的复杂程度与目前的规划。如果对虚幻的网络模块有兴趣，可以参考我的文章《Exploring in UE4》网络同步原理深入，这里我不展开讲解。
五、更新逻辑
我们知道，其实游戏就是不断Tick的一个死循环，那么在一帧的时间里，哪些东西先更新，哪些东西后更新就是一个不小的学问。比如，网络收包在角色Tick之前还是之后？摄像机的位置在什么时机去更新？
虚幻里面，逻辑大概是这样。 网络收包—》物理执行前相关ACtor执行Tick—》物理执行中的相关ACtor执行Tick—》物理执行后的相关ACtor执行Tick—》摄像机更新—》网络发包—》渲染
六、引擎功能设计的取舍
这里是指我们对引擎的设计有哪些预期，比如如何处理内存泄漏问题、是否要有垃圾回收（C#就省心很多），是否要有反射与类型系统（我认为对于引擎来说必须要有），是否要内置序列化功能等。这其实都是些很朴素的问题，你有没有足够的时间去做？这个东西是不是可有可无？你是否可以用别人的轮子？（这些问题大钊的专栏InsideUE4里面有很多思考，建议大家看看）
为什么当前很多公司都放弃做游戏引擎？就是因为市面上的东西已经很优秀且丰富了，你再造一个轮子既费时间又并不见得有意义甚至可能还没有人家的好。
游戏引擎是一个相当复杂的软件系统，不仅仅限制于渲染、物理、AI、网络等模块的实现，如何组织他们以及如何提供给玩家一个舒适的编辑器环境都是非常重要的内容。 Design for Interactive Media，是我们在 USC 游戏设计专业的第一课，它是我们设计思维的基础，说它基础，因为它是底层的思路，而不是表层的经验总结。不是当你设计某类型游戏的时候才要这样做，而是设计任何类型的游戏都可以用，并在这个基础上发展变化。这门课包括两部分：系统设计和迭代开发流程——熟悉迭代的流程，并在这个过程中加深对游戏系统的理解。
由 Tracy Fullerton 教授撰写《游戏设计梦工厂》是这门课的教科书。如果有兴趣学习美国的游戏设计，尤其针对独立游戏开发者和想申请美国游戏设计专业的人来说，我认为这是最好的一本书。
一、系统设计
我们所讲的系统设计，与国内游戏行业讲的系统设计，最大的区别在于：我们把游戏总体作为一个系统，思考游戏中各部分设计之间如何互相影响，比如规则 1 和规则 2 交互，创造什么样的体验；国内由于主流是 MMORPG 之类的大型游戏，讲系统设计往往是讲游戏中的一个系统，比如装备系统、宠物系统等，思考的是这个系统本身的设计，而这个系统怎样和游戏中其他部分耦合，涉及的相对少。
我们这里讲的系统设计关注的是规则、目标、资源、冲突等系统元素，这些在《游戏设计梦工厂》的前五章中做了详细的阐述。举个例子：
玩家，作为游戏系统的一部分，在多数游戏设计中都是不被考虑的，因为有「默认值」：所有的游戏都面向玩家，所以相关环节一定被其他游戏设计过了。
而在《游戏设计梦工厂》一书中，将玩家的交互模式分成了以下七种：
1.单个玩家对抗游戏系统；
2.多个独立玩家对抗游戏系统：比如老虎机，或者单机刷排行的游戏；
3.玩家对抗玩家；
4.单边对抗：玩家有两个阵营；
5.多边对抗：玩家有多个不同阵营，互相对抗，比如大富翁等桌游，魔兽争霸 3 的 FFA 模式；
6.合作游戏；
7.团队对抗：比如 2V2, 3V3。
也许这里的很多模式你都设计过，但是把这些模式罗列清楚，思考它们有怎样的设计，为每一种模式列出尽可能多的游戏，会帮助你更好地理解这种模式的基础逻辑。有这样的基础，才能更好地去思考「一个设计为什么是这样的」，而不是趋向于「默认值」。
《Journey》（中译：风之旅人）的设计中，由于他们思考过玩家交互到底应该是什么样的，所以这个游戏中玩家无法打字，无法语音，没有用户名，不能邀请好友，不能和好友一起进行游戏，因为这些设计都会破坏这个游戏的系统完整性。
我们花了这么大力气把玩家置身于一个魔法世界。而这些名字，这些文本，瞬间把他们推回了现实。要让玩家们合作和产生情感连结，他们必须忘记这些现实的东西。
——《Journey》的设计者陈星汉说。并不是学过了这些系统元素就可以做出系统完善的游戏，而是在做游戏的时候提供一种思考的方向，从而帮助设计师在做项目的过程中建立系统式的思维方式。这也正是接下来各个步骤的目的。
二、系统分析
这门课的第一个作业是分析一个玩具的系统设计，包括其视觉设计、数学模型、历史、文化背景等等。我抽到的是魔方。
魔方，也称鲁比克方块，是由匈牙利布达佩斯建筑学院厄尔诺·鲁比克教授于 1974 年发明的。三阶魔方系由富有弹性的硬塑料制成的 6 面正方体，共有 26 块小立方体。
在国内的时候，我看过一些 MMORPG 的系统反推分析，基本上都是把一个游戏的各部分系统罗列出来，画几个箭头连起来而已。按照这样的思路，魔方的分析可能只能写一行字了。
魔方有很深的数学模型，但是我们是游戏设计师，不是数学家，所以这里分析的重点并不在它的数学模型上。我的分析有两个切入点：
1.魔方的视觉触觉设计，上手体验
魔方的视觉和触觉设计，使得它有非常好的上手体验。任何从来没接触过魔方的人，只要摸到一个魔方，就自然会扭动几下；不需要提示，就很容易理解这个玩法的目标，即让各面变成统一颜色；同时，一个拼好的魔方，人们看到就会想要扭开，让各面变成不同颜色。
2.不友好的难度曲线
由于魔方极佳的上手设计，它成为了一个非常流行的玩具。然而，魔方有一条非常不友好、非直觉的学习曲线。
每个人拿到魔方都会扭动两下，其中一部分人，经过自己思考，会拼出一片同色的魔方。然而极少人可以不看攻略就拼出整个魔方，这极大地限制了魔方的乐趣深度。
比如一架钢琴，任何不会弹钢琴的人去按几下按键，都会觉得有乐趣，但是这种乐趣只会持续几分钟；花上一段时间学习，人们就可以弹出一段旋律，达到这个水平的人，或许可以在钢琴上享受几十分钟甚至几个小时的乐趣，但是不会更长了；花了几年或几十年的时间学习，能够熟练演奏乐曲的人，也许可以沉醉于弹琴中，时间多久都不厌倦。
使用 App 查看完整内容目前，该付费内容的完整版仅支持在 App 中查看
App 内查看 消息循环->更新数据->绘制各节点 这是绘制的基本结构基本不会有大的改变。 各种引擎的变种很大部分是在游戏逻辑上的封装。脚本也好，直接写代码也好。比如较为古老的数据与函数分离，以C语言为代表 。大行其道的类结构。以c++为代表。以及现在光环日耀的CBSE，基于组件的架构。 补充一点，现代引擎对并行/多任务处理的原生支持也非常重要。
另外，如果想对游戏引擎有一个系统的了解，建议搞本《Game Engine Architecture》，第一章里就会给你一个鸟瞰，一定会让你过瘾的。 viv烦烦烦
→_→→_→→_→
好像当年不会用客户端的铁证啊
页:
[1]