摘要
本文是为那些缺乏Unity使用经验的读者设立的，会对Unity游戏开发的大致流程以及一些属于进行说明
Unity的游戏开发，大体可以分为三个步骤
- 将美术素材和各种逻辑功能整合在一起，创建出角色
- 摆放好各个角色，创建出场景
- 创建好所有需要的场景
根据我们的经验可以知道，在游戏中，玩家操作的角色以及敌方角色，还有作为游戏舞台的背景等都会显示在画面上。游戏中的那些角色可以通过鼠标或者触屏来操作，也可以根据自己的一追来回移动。另外，背景还会成为组织物体移动的障碍物。
3D模型和2D图片这些美术素材自身是不能称为"游戏角色"的，只有能够响应玩家操作，以及具备能和其他素材之间进行碰撞检测等功能，才算初步具备角色雏形。
准备好角色和北京之后，就可以开始制作游戏的场景了。
游戏画面行会显示各种各样的东西，譬如有时现实游戏的主题，有时显示玩家得分这类游戏结果的信息。即使在同一款游戏中，画面上显示的内容也是频繁更换的。
综上述，开发游戏时的这些必备要素，用Unity的术语来表达大概是下列几条
- GameObject/游戏对象
- Component/组件
- Asset/资源
- Scene/场景
- Prefab/预设
游戏对象是指角色。组件是角色的功能，代表了角色"能做的事"。资源指美术资源和音频等数据。场景则用于放置各个角色，在游戏中负责展现画面。和绘图软件中的"场景"意义大致相同，因此Unity中也采用了相同的名称
最后的预设，在Unity之外的环境中可能很少听过。然而这并不是什么复杂的概念，只是一种利用复制来创建大量同类角色的手段。
下面我们对这些概念逐个详细说明
游戏对象
所谓游戏对象，就是指游戏中出现的各个"东西"。包括可看到的和不可看到的。
玩家角色和敌方角色、背景模型、特效、得分等等，甚至可以说，画面上出现的所有东西都是游戏对象
除此之外，游戏对象还包括很多没有显示在画面上的物体，摄像机和灯光就是两个典型代表。
摄像机的功能是决定"场景的显示范围以及显示的角度"。摄像机本身并没有出现在画面上，就好比在电影和电视剧中，摄影师本人不用出现在屏幕上一样。
灯光的概念好比现实中的照明，用于决定3D模型的色泽。
游戏中还有一些游戏对象会根据关卡登记数据来生成敌方角色，这类游戏对象也是不可见的。虽然作为角色生成点的美术素材，如"魔法阵"，"敌穴"，有时会显示在画面上，但本质上来说他们属于管理对象。这类对象"探测到敌人一个个被打败后，会生成新的敌人"，或者"如果玩家越来越熟练，则逐渐让出现的敌人变强"。简单来说，它们决定哪种敌人将在何时、何地出现，类似"指挥官"的角色。
假如一款游戏中，敌人都在画面之外生成后进入，那么画面上就没有必要设置生成点的美术素材。但是即使在这种情况下，仍然会有一种游戏对象用来控制敌人登场的时机。
组件
组件是附在游戏对象上的各种"功能"。正因为附加了各种组件，游戏对象才得以具备各种各样的功能
如果只是单纯把3D模型个2D图片摆放好，虽然也能创建出"类似游戏中的画面"，但光靠这些美术素材是无法组成"角色"的。要成为"角色"，还要求素材能够按玩家的操控运动，展示特效和音效，以及对玩家操作产生某种反应。
所谓的组件，就是用来将这类"响应玩家的操作""播放动画"等功能和美术素材相结合的载体
现在我们不妨来看看最原始的游戏对象。前面提到过，Unity通过向游戏对象添加各种组件来创建角色。那么，一个没有添加过任何组件的游戏对象会是什么样的呢？打个比方，就像一个"什么也做不了的小幽灵"
事实上，最原始的游戏对象确实不具备任何功能。即使将它放置在场景中，也不会有任何视觉上的表现，更不会对游戏产生什么影响。
游戏角色这类游戏对象，是通过将组件添加到美术素材上创建的。事实上，能够吧"把美术素材内容展现在画面上"也是组件的功劳，而非游戏对象与生俱来的功能。如果游戏对象没有添加"显示素材到画面"的组件，就无法在画面上显示什么。只有添加了对应的组件，才会具备相应的能力。
游戏对象能不能被看见，仅仅取决于是否添加了用于显示的组件。
角色以及背景这类可见的对象，都是添加过"显示素材"的组件的游戏对象，而摄像机和灯光这类没有必要显示的对象，则有最原始的游戏对象创建而来。它们都秉持着需要什么功能才添加什么组件这一共同原则
需要注意的是，一个游戏对象上允许添加多个组件
现在我们来分析一下玩家角色需要哪些功能
玩家要操控角色，因此"显示"功能是必备的，同样，动画功能也需要。
读取鼠标和键盘的操作并使角色一哦那个，这属于"玩家操作"功能。接下来，还需要添加防止和敌方角色或背景对象发生重叠嵌套的"碰撞检测"功能。此外，诸如在移动或跳跃时发出"音效"以及产生烟雾等""特效的功能对于增强游戏的趣味性也是十分重要的。
通过这样简单的梳理我们就已经发现，需要在一个角色上添加大量"功能"。
下面再来看一个关于组件的例子。
"开始按钮"可以被认为是2D图片添加"对鼠标垫集合触屏产生反应"的开关组件后的游戏对象
和玩家角色对象不同，开关按钮这类UI（User Interfac，用户界面）不会在"游戏世界"中登场。即便如此，他仍是通过给美术素材添加组件创建出来的游戏对象。
如果说"在游戏中来回穿梭的角色，和这些读取用户操作的UI按钮本事上是相同的"，可能很多人会感到不可思议。但是，允许通过相同的方法创建出二者正是Unity的优点之一。简单地说，它们的创建方法都是""给美术素材添加功能组件。开发游戏时，从功能入手进行分析是很有帮助的。
C#脚本也是一种组件。甚至可以说，游戏中用到的大部分钻都是自己编写的C#脚本。
敌方角色不受鼠标控制，行为是由自主行动的AI组件决定的。通过实现不同的AI逻辑，我们可以创建出"只会单纯地追赶玩家"的麻瓜角色，或者聪明的"会预先埋伏在玩家前方"的角色，甚至是"遇到玩家会主动逃开的"怯懦型角色，如原神中的小动物就是怯懦型角色
对于AI来说，在行动中体现角色性格固然重要，但更重要的是角色的行为必须符合游戏规则。
资源
资源指的是3D模型和2D图片这些"数据"。当然，BGM和音效等"音频数据"也属于资源
下面我们将详细说明组件和资源各自的功能以及二者之间的关系。
3D模型在游戏中无处不在，将这些模型显示到画面上，并非3D模型自身持有的功能。说到底，还是网格渲染器组件的功劳
但是话说回来，如果仅有网格渲染器，也是无法显示出3D模型的
为了让网格渲染器正常工作，必须指定待显示的数据。打个比方，网格渲染器相当于工具，3D模型资源的"fbx文件"相当于设计图。添加网格渲染器组件后的游戏对象的职责，就是最照着设计图组装出模型。
单纯的游戏对象什么也做不了，组件也不过是也各个工具。工具毫无规章地使用，是做不出什么东西来的。只有将作为设计图的"资源"和作为工具的"组件"以及使用工具的"游戏对象"这三者搭配在一起，才能将3D模型显示在画面上。
处理资源是一定会用到相应的组件，所以它们总是成对使用的。
流程
在对"场景"进行讲解之前，我们先对流程这个概念做简单说明。
一个游戏中会存在多个"画面"，比如用于表现游戏主题并允许玩家通过开始按钮计入游戏的"主题画面"、游戏过程中的"游戏画面"以及最后的"结果画面"。
这种以"玩家会在这个画面做什么"以及"这个画面能用来做什么"为基准将游戏过程切分出来的"环节"就叫"流程"
在后面的内容中，我们把"游戏画面"，"结果画面"这些切分流程的"**画面"都称为"段落"。接下来要说明的是Unity场景也是一种以段落为单位来开发游戏的结构。
一般来说，流程中的这些段落也叫"场景"或者"画面"。不过为了避免因其描述上的混乱，我们按下列规则区分
- 各个流程单元=段落
- Unitu的场景功能=场景
场景
下面我们来讨论Unity的场景功能。场景是游戏中的一个个场面或者段落的组成单元
我们可以回忆一下电影拍摄中的布景过程。"主题画面"的布景只不过需要树立起一块写有游戏主题以及插画的大块画板即可。而"游戏画面"的布景中，就包含了玩家角色和敌方角色以及背景等。电影播放时投影在荧幕上的内容，也就是布景时摆放的内容。对照电影过电视剧的拍摄过程会很容易理解这个概念。这个"拍摄时的布景"体现在Unity中就是场景
所有的游戏对象都会存在于某个场景中。当场景发生切换时，将删除其包含的所有游戏对象，并在下一个场景中生成新的对象。因此也可以把场景看作是一个可以容纳游戏对象的箱子。
使用Unity开发游戏的理论在于，当"必要的游戏对象"发生变化时，场景也跟着切换。先将无用的游戏对象全部删除，再到新段落中生成所有必要的游戏对象......这样做未免太麻烦了。借助于场景，我们可以批量地删除、生成游戏对象，同时还可以防范常见的bug----忘记删除已经无用的游戏对象。
严格来说，场景并不一定非要对应某个特定流程段落。即使和流程无关也可以创建场景，甚至还可以合并所有的流程段落做成一个场景。只不过场景经常用来创建流程，所以非常方便。在最初的阶段可以理解成场景时用于创建流程的某个段落
预设
预设用于复制游戏对象
当我们需要一次性创建大量相同的角色，或者希望角色在其他场景中也出现时，经常会产生复制游戏对象的需求。如果提前把游戏对象制作成预设，就可以很方便地实现复制。
而且，借助预设，可以在游戏运行是通过脚本来创建游戏对象。用专业一点的话来说，它支持运行时生成。
例如，在卷轴游戏中，随着玩家角色的移动，画面的显示范围也在不停的变化。一些刚开始看不见的敌方角色会陆续进入显示区域出现在画面上。即使是画面固定的游戏，也经常会有随着时间的推移不停出现新角色和新道具的情况。这些出场的角色都不是在游戏启动之初就配置在场景中的，相反，它们只有在必要的时候才会被生成。这是出于加快处理速度和节约内存的考虑这种"在脚本中创建游戏对象"的情况就需要使用到预设。
和普通复制相比，预设有以下两点优势
- 复制后的修改非常简单
- 可以简单地复制到任意场景
下面我们逐条解释，先来看看"复制后修改"的特点
预设具有"源对象的修改可以直接反映到复制生成的对象上"的特性
通过"普通的复制功能"批量生成游戏对象时，复制的源对象上发生的任何变动，都无法直接反映到那些复制生成的游戏对象上，因此不得不执行下面三个步骤
- 修改源对象
- 将复制生成的游戏对象全部删除
- 再次复制修改过的游戏对象
但是，由于预设具有"源对象的修改可以直接反映到复制生成的游戏对象上"因此通过使用预设，上述步骤2和3就可以省略了
使用预设的好处不仅与你，在"复制生成的游戏对象"上发生的修改，也能直接反映到"源对象"中。当然，这种修改也会传递到其他的游戏对象中。结果，所有的游戏对象都会产生相同的变化（就像类里面的static 类型数据一样）。
此外，预设还具备可以简单地复制到任意场景的特性
我们曾提到"场景相当于容纳游戏对象的箱子"，反过来则意味着"游戏对象必定存放在某个场景中"。
如果想复制并在医用某个已经创建完成的游戏对象，首先必须找到该游戏对象的存放位置。当然，如果提前讲那些经常用到的对象专门放在某个特定位置，这样我们找起来会方便很多，一旦需要进行复制，直接到这个位置取出即可。
事实上，预设就相当于这个"常用对象的存放位置"。严谨地说，"位于常用对象的存放位置"的对象就是预设。"常用对象的存放位置"也就是"预设的存放位置。被作为预设的游戏对象将会被移动到"预设存放的位置"，以后就可以简单地复制到任意场景中。
