1.7 从0开始学习Unity游戏开发--物体的组成

前篇我们简单的入门了对于一个游戏场景（Scene）如何使用编辑器进行编辑，这是我们进行游戏内容创作的重要工作流程，但是目前为止，我们能操作的最小单位也只是物体，并没有深入到物体本身，本篇我们将借助Inspector面板和代码来讲解组成游戏世界的物体，到底是什么，以及我们如何进行操纵。

Inspector面板

上篇文章我们也简单提了这个面板，这里我们详细了解一下。

在选中任何编辑器上的物体时，不论是从Hierarchy选中还是直接从Scene窗口里面选中的，都会显示其内容，而物体内容显示的面板则是Inspector面板。

对于一个内建的3D立方体Cube，则是这样的，我点击了左侧的箭头，收起了每个部分的细节，这样能够有一个直观的感受。

从代码层面构建游戏物体

假设我们需要自己用代码来设计游戏物体这样一个泛用的概念，学过面向对象编程的应该都会第一时间想起那个经典的例子：

// 基类是Person，代表所有子类都是人类
class Person {};
// Student继承自Person，可以带有Person的能力，又能有自己的特殊功能
class Student : public Person {};
// Doctor也是类似
class Doctor : public Person {};

这样设计的好处就是复用了子类可以复用父类的能力，还能利用多态对相同接口做出不同的响应，从而实现一些统一的封装逻辑。

对于一些方向，确实很好用，例如UI框架就是非常典型的可以一层一层继承下去的场景。

但是对于游戏，我们可以这样设想一下：

// 基类是GameObject，代表所有物体都是GameObject
class GameObject{};
// 立方体Cube继承自GameObject
class Cube : public GameObject {};
// 球形Sphere继承自GameObject
class Sphere : public GameObject {};

这样设计看起来好像也没啥问题，但是如果有这样的情况呢：

• 所有物体都需要支持物理碰撞，那是不是得中间加个PhysicalGameObject来作为抽象？
• 新增一个物体玩家，到底应该继承自Cube还是Sphere还是单独再写一个继承自GameObject？如果是重新从GameObject继承，那Cube，Sphere和玩家都需要的渲染功能是不是只能放在GameObject里面？

等等。

这些问题其实就反应出了游戏世界其实是非常灵活的，一开始设计的基类，可能因为子类共同所需的功能越来越多而急剧膨胀，最后的结果就会出现一个非常大的GameObject类而导致无法维护或者效率低下。