浅谈游戏架构
一、游戏基本概念理解
1.大部分游戏的总体结构如下：
游戏制作层
游戏架构系统（游戏表现层）
引擎层
游戏系统的概念：任何的游戏玩法都要系统支持
所有的功能都应该属于某一个系统
系统：包含一组相关功能的集合
玩法：依赖于多个系统配合实现
功能：系统下面的某个具体行为
架构：将引擎层提供的接口或功能封装成适合我们游戏层的接口或功能
表现：粒子，动作，模型，界面
框架：游戏框架就是某类游戏的半成品，包含了部分的游戏架构系统
2.游戏阶段状态：
我们的游戏主要依靠外部的服务器，KBE插件给我们提供了3个登录状态（未连接，角色登录，账号登录）
而我们的游戏阶段状态管理系统将游戏阶段划分为8个阶段
为了让KBE插件提供的登录状态和游戏阶段一一对应，需要结合关卡管理系统来处理
用户处于某类关卡中，就处于某一游戏阶段
编码原则：完成一项功能所需要的东西越少，步骤越少， 逻辑越简单，出错几率就越低，也越可靠
不同的系统之间的关系越少，代码越健壮
游戏逻辑应依赖于游戏层中的系统定义的状态
尽量让架构层的系统少一点交流，将交流都定义到我们封装出的游戏层
3.UE4客户端崩溃原因总结：
a.Actor使用方面原因：
1.访问已经释放的指针
2.访问未初始化的元素
b.Entity使用方面：
1.DEF文件定义不正确
2.访问已经释放的指针
3.访问未初始化的元素
c.Uobject使用方面：
1.访问已经释放的指针
2.访问未初始化的元素
d.根集方面：
1.未加根集
2.增加和删除操作不对应
e.蓝图方面：
1.C++代码修改以后，对应的蓝图未进行重新连线
2.类型转换出错
4.游戏对象系统：
a.游戏对象识别：
1.概念：在游戏代码运行时，能识别一个对象是什么类型
2.举例：怪物，角色，陷阱，场景物件或者其他游戏可交互对象
3.实现：使用一个枚举类型来记录对象的类型
4.使用：交互的时候基于交互对象双方的类型来触发对应事件
比如当陷阱中进入一个怪物时会触发爆炸事件，当进入一个玩家时则不触发爆炸事件
b.为什么说方法都要在游戏元对象中定义？
任何对象之前的交互，都可能要在Game Object中定义方法
c.来自C++的RTTI（运行时对象识别）：
是反射机制和序列化等功能的基础
d.反射机制：
概念：编译器编译代码时，会生成几个表，有的表管理类的属性，有的表管理类的方法，
运行时可在代码中使用它们
e.序列化和反序列化：
概念：序列化就是将对象转换成特定标识符的字符串流，
反序列化就是将字符串流解析成对应的对象。
f.虚幻的Class.h/cpp就是处理对象识别系统，同时支持反射和序列化
g.多态：
概念：接口的多种不同实现方式即为多态
子类重写父类的方法，在同一情况下，不同子类执行不同行为
5.循环重复和迭代提高
a.伟大的程序员只花很少的时间去写代码
b.代码优化的步骤：
1.先让代码变得独立（去掉不必要的依赖）
2.去掉不必要的蓝图可调用
3.去掉一些不必要的公有方法
c.优化的效果：后续对该代码的修改，调整都比较容易掌控
6.编程范式
a.任何一个算法都有两个部分：Logic（逻辑）+Control（控制）
b.如果将Logic和Control有效分开，代码就会变得更容易改进和维护
c.MVC模式：M代表Logic代码，C代表Control代码，V代表界面
d.大部分框架都是MVC模式
e.Logic也叫业务逻辑，Control也叫应用程序逻辑
7.游戏主循环：
1.消息接收
2.消息分发
3.消息处理
4.子系统更新
5.设置Actor位置
6.渲染处理
7.残影现象：服务器设置Actor位置后在客户端角色变换位置后会出现残影
原因：Kbengine服务器设置Actor位置是在子系统更新以后，就会出现差一帧现象，
即子系统更新的还是上一针的数据
8.一个游戏由GameMode和GameState构成，加入游戏的玩家与PlayerController相关联，
这些PlayerController允许玩家在游戏中占用Pawn，以便它们在游戏中有物理展示，
PlayerController也为玩家提供了输入控制，HUD及处理相机视图的PlayerCameraManager