【程序员的游戏开发之路】游戏架构-CSDN博客

本文链接：https://blog.csdn.net/qq_32418469/article/details/81369544

啊啊啊啊今天去面了鹅厂，结果在实习公司Unity用得太多了，好多基础都忘得差不多了，看起来要捡起来好好再学习一下O(∩_∩)O莫要放弃，就从游戏架构开始学起哈。
参考的书是《 游戏编程权威指南 》

游戏整体架构

总体来说，游戏中的所有子系统属于以下的3个主要类别之一：
1.应用层
应用层关注的是游戏运行的机器，如果将游戏移植到别的平台，则需要重新写很多应用层的代码，但不需要修改其他的部分。这个模块中包含处理硬件设备的代码、操作体统服务（网络通信或线程）和操作（如游戏的初始化和关闭）

2.游戏逻辑
游戏逻辑层就是游戏，他与游戏运行的机器和显示方式完全无关。在理想情况下，修改游戏逻辑相关代码，它依然可以在所有之前支持的平台或操作系统中运行。在这个模块中，你会发现管理游戏状态的子系统，将状态变化传送给其他系统的子系统和从其他系统中接受输入命令的子系统。还包括执行游戏世界规则的系统。其中一个示例是物理系统，它用于管理游戏对象互动和交互的过程。

3.游戏视图
该系统负责显示游戏的状态，并将输入转换为可以发送给游戏逻辑的游戏命令。它可以拥有不同的实现，连接到游戏中的视图数可能与电脑处理的视图数相同。有多种游戏试图①针对玩家的，它会绘制屏幕上的游戏状态，将音频发送到声音输出设备 ②针对人工智能代理的 ③针对网络中的远程玩家。
（其实我看到游戏视图这里没懂，看后面的吧）

举例：
假设我们需要做一个赛车游戏：
对于游戏逻辑来说：①输入就是转向、加速度、制动、紧急制动等 ②输出则是状态变化和事件，包括车的位置和方向等等。事件和状态将被发送到游戏视图。

游戏视图则要做很多工作来传递给玩家很多信息，比如说图像、声音、粒子效果等。同时它还要读取游戏控制器的状态，并将其转换为逻辑命令，然后发送给游戏逻辑。

应用层见下面

应用层

1.读取输入

多种用户输入设备，例如键盘、鼠标、游戏手柄等，读取这些设备基本完全依赖于对操作系统和设备驱动的调用。总是将这些设备的状态转化为游戏命令，其中一些会发给游戏逻辑，而另一些会给游戏视图。在读取用户输入时，最好不要直接修改游戏数据，这样系统的可维护性是很差的，会成为系统的负担。

2.文件系统和资源缓存

文件系统是从存储系统中读取数据，并将数据写入存储系统中。该之系统常常负责管理游戏源文件、加载和保存游戏状态。
资源缓存是以某种方式管理素材，让游戏误以为它们一直存在于内存中，如果一切顺利的话，游戏永远无需等待，因为资源缓存能足够聪明能预测出将使用哪些素材并提前加载他们。但是它时常会算错，导致缓存未命中，可能会导致游戏的卡顿等。