人的心理状态很奇怪，你的理想追求是最为高尚的事物，在那一刻你是纯净的，而现实是你的心理状态会对自己造成羁绊。人的这一生首先得拿深度来定义自己，然后再让自己更为广泛。追求者们做的都很对。去追寻理想坚持自己所爱。
gameplay foudation system.
我们知道一个游戏引擎是为了构建游戏服务的，而引擎会做一些基准让游戏性运行于这个基础之上，例如虚幻给你提供了AI路径系统，而你仅仅是使用它，AI的基础部分不同游戏的依赖情况是不同的，所以这本是一个非常模糊的地带。
但有几个基础系统在业界已经达成了共识，这是一个基础游戏引擎应该给开发者提供的地方：
1.运行时对象模型：例如Actor class让你可以在编辑器中使用
2.关卡加载：例如LevelStream的管理。
3.更新实时对象模型：如果不会更新将不会产生变化
4.消息事件：例如controller类要告知pawn做一个事件相应。
5.脚本：unrealscript和kismet之于unreal C#和JavaScript之于unity
6.目标管理流程：游戏的规则，怎么算是完成任务
7.Spawn和Destroy
8.还要能联系底层引擎
9.游戏是一种实时模拟应用，例如Actor类中的tick
10.能定义新的对象类型
11.udid
12.可以foreach
13.找到对象引用
14.状态机制：unrealscript中就有state
15.网络复制：网络游戏的基本原理是这样的，多个机器通过服务器或者局域网连接在一起，一个对象状态通常有一台机器管理，如果这个对象有更新就得通过网络将其复制到其他参与者的机器上，这样大家才能看到一致的内容。例如Titanfall一个敌人被打死了，服务器应该将这种状态从死亡机器上复制并传递给别的玩家。
16.存档呗：记着我最崇拜的制作人三上真司参与过最早的游戏是《阿拉丁神灯》这款FC上的游戏在你通关之后给你一个序列密码，这个密码在关头输入便可以跳转到那一关，这算是我最早的见到的人脑存档法吧。现今的游戏当然不会再使用这种愚蠢的存档法了。玩家们都会享受于系统自存档的方法。
运行时对象模型：游戏运行时就是这些对象模型的实时模拟，他们的行为和属性会不断变化。例如敌人会寻路，受伤会掉血和死亡。游戏性基础系统必须对这些东西进行具体实现。而我们平时使用的脚本语言仅仅是使用API告知怎么响应，而引擎去执行底层实现。
大部分游戏对象模型的实现结构是一个树形，从根部GameObject定义基类，然后是动态类MoveableObject,接着在这个根支上进行渲染，RenderObject，然后演化出不同的类型分支，后边的分支意味着功能越多。
例如虚幻引擎 从Actor继承而来的类就有Brush，controller,Pawn,info等，另一侧有light,HUD，inventory，PickUp.
随着类的不断扩充健硕，就得想办法对其维护理解和修改，这些会增加复杂度，怎么解决这个问题呢？我们经常会看不懂自己写的代码。在子类中修改了一个看似无害的虚函数，就可能违背基类中的某个基类的假设，让Bug难以调试。
那么我们要找一个标准来进行分类，你可以把人类按照肤色分类，也可以按照地域，也可以按照头发颜色whatever，那么使用什么选择对游戏性对象进行分类最为科学？
我们对一些敌人进行分类，做成了近战和远战敌人，在这基础上你扩充了1.矛手，父手 2.机枪兵，榴弹枪。这时候策划说给我再做一种能投手榴弹的重斧手《刺客信条4》。
这时候你自然而然的想到了多重继承，他的样子就像一个迷人的钻石，维护起来会要你的小命。
冒泡效应是一种非常奇妙的现象，我直接饮用Jason的例子，你写了一个可以在水上漂浮的箱子，感觉很酷，然后就想给所有的人类，载具和纸张等都判定可不可浮。可不可浮这本身不是原来的分类标准，由于不想使用多重继承，就将这个功能在父类中上移。但许多派生类本不需要该功能。虚幻的Actor类就包含了渲染，动画，物理，世界交互，生效，多人的例子。这也让类维护起来比较困难。
