Games104-P1-3 基础架构
Lecture2 游戏引擎的分层架构
引擎分层
工具层
构成完整游戏生态体系
- 引擎内：⬆️
- 引擎外：DCC
- Asset conditioning pipeline：各种import&output
- 数据间互导需要统一格式
功能层
- Gametick
- 游戏里的“普朗克时间”，1/30s
- tickLogic：逻辑帧，对于世界tick内的物理模拟
- tickRender：渲染帧，tick内进行渲染
- 区分引擎&游戏的功能代码：功能层提供引擎功能，部分功能隶属游戏而非游戏引擎
- 多线程架构：如将tickLogic、tickRender、Render放入三个线程
- 未来引擎使用多核架构，JOB System更先进，但Dependency的管理困难
资源层
资源层管理游戏运行时，生态资源池的分配；管理资产生命周期
数据引擎化
原因：DCC生成的文件包含大量无效信息
做法：Importing时，将Sources转为Assets，使用引擎高效数据
GUID
- 资产的唯一识别号，资产的ID
- 通过XML文件，完成数据间关联
- 运行时资源管理——游戏优化
- handle系统：和GUID一起负责资产的生命周期。类比GC（垃圾回收）系统。例如切换关卡时，部分资产失效，需要加载新的资产
- 延迟加载：指的是希望人走到哪，这些资源再加载。例如，玩虚幻引擎做的游戏的时候经常有个细节（不知道最新版本有没有修改）：一个角色出现在你的面前，一开始看到那个贴图很模糊，然后一点点变得更清晰
核心层
游戏引擎的基础
- 引擎数学库：更适用于引擎，提升效率
- 内存管理
- 尽可能将数据放到一起
- 数据按顺序排列
- 数据修改时，一次修改一批而非一个
平台层
平台无关性
- 去除平台间差异（系统路径和API）
Render Hardware Interface (RHI)
- 重新定义API，将SDK封装使用以消除差异
为什么引擎要分层
- 降低复杂度
- 下层提供基础服务，每一层各司其职
- 层层封装
- 底层尽量不改动
- 底层稳定，上层灵活
- 上层调用下层功能，下层禁止调用上层功能
Piccolo逻辑
总结
- 游戏引擎架构分层
- 底层稳定，上层灵活
- tick驱动
Lecture3 如何构建游戏世界
组成
- Game Object
- Dynamic 可交互
- Static
环境
- Sky
- Vegetation
- Terrain
Other
Game Object
属性：Property
行为：Behavior
继承
组件化
适用于，游戏自定义
解决继承中，谁是爷爷（？）的问题
将对象拆分为不同组建
组件化后：
商业引擎中的Component
如何让世界动起来
Object-based Tick
按照GO，对GO中Component依此进行tick
Component-based Tick
按照Component，针对一个系统tick
tick对比
高效的做法——流水线
事件机制
eg：如何实现爆炸
早期：Hardcode；无法解决复杂游戏世界中问题
衍生出事件机制；解耦合
发出Event给到对应的GO，由GO进一步处理
现代游戏引擎设有自定义机制的接口（add custom event
场景管理
每一个GO都有一个ID，用于被标识和定位
对于非均匀场景，根据GO分布，进行八叉树（空间）划分
总结
其他需要解决的难题
绑定：运动联动
- 父节点先于子节点tick
时序问题
- eventTick和posTick解决
- 消息分发，引擎优化
循环依赖（图片左下角
- 物理和动画互相影响，通过插值处理