啊啊啊啊今天去面了鹅厂,结果在实习公司Unity用得太多了,好多基础都忘得差不多了,看起来要捡起来好好再学习一下O(∩_∩)O莫要放弃,就从游戏架构开始学起哈。
参考的书是《 游戏编程权威指南 》
游戏整体架构
总体来说,游戏中的所有子系统属于以下的3个主要类别之一:
1.应用层
应用层关注的是游戏运行的机器,如果将游戏移植到别的平台,则需要重新写很多应用层的代码,但不需要修改其他的部分。这个模块中包含处理硬件设备的代码、操作体统服务(网络通信或线程)和操作(如游戏的初始化和关闭)
2.游戏逻辑
游戏逻辑层就是游戏,他与游戏运行的机器和显示方式完全无关。在理想情况下,修改游戏逻辑相关代码,它依然可以在所有之前支持的平台或操作系统中运行。在这个模块中,你会发现管理游戏状态的子系统,将状态变化传送给其他系统的子系统和从其他系统中接受输入命令的子系统。还包括执行游戏世界规则的系统。其中一个示例是物理系统,它用于管理游戏对象互动和交互的过程。
3.游戏视图
该系统负责显示游戏的状态,并将输入转换为可以发送给游戏逻辑的游戏命令。它可以拥有不同的实现,连接到游戏中的视图数可能与电脑处理的视图数相同。有多种游戏试图①针对玩家的,它会绘制屏幕上的游戏状态,将音频发送到声音输出设备 ②针对人工智能代理的 ③针对网络中的远程玩家。
(其实我看到游戏视图这里没懂,看后面的吧)
举例:
假设我们需要做一个赛车游戏:
对于游戏逻辑来说:①输入就是转向、加速度、制动、紧急制动等 ②输出则是状态变化和事件,包括车的位置和方向等等。 事件和状态将被发送到游戏视图。
游戏视图则要做很多工作来传递给玩家很多信息,比如说图像、声音、粒子效果等。同时它还要读取游戏控制器的状态,并将其转换为逻辑命令,然后发送给游戏逻辑。
应用层见下面
应用层
1.读取输入
多种用户输入设备,例如键盘、鼠标、游戏手柄等,读取这些设备基本完全依赖于对操作系统和设备驱动的调用。总是将这些设备的状态转化为游戏命令,其中一些会发给游戏逻辑,而另一些会给游戏视图。在读取用户输入时,最好不要直接修改游戏数据,这样系统的可维护性是很差的,会成为系统的负担。
2.文件系统和资源缓存
文件系统是从存储系统中读取数据,并将数据写入存储系统中。该之系统常常负责管理游戏源文件、加载和保存游戏状态。
资源缓存是以某种方式管理素材,让游戏误以为它们一直存在于内存中,如果一切顺利的话,游戏永远无需等待,因为资源缓存能足够聪明能预测出将使用哪些素材并提前加载他们。但是它时常会算错,导致缓存未命中,可能会导致游戏的卡顿等。
3.内存管理
内存管理是游戏中很重要的系统。游戏中的很多数据结构都是相对较小的内容,并且他们属于不同的区域,例如RAM或显存。所以要尽量使内存管理器面面俱到,让你知道游戏需要和使用的内存的所有细节。
4.初始化、主循环和关闭
主循环基本是用来控制系统的主体行为,主要由三个部分组成:①获取并对玩家输入排序 ②标记游戏逻辑 ③在所有游戏视图中显示逻辑状态(渲染图像、播放声音、或者通过互联网传送游戏状态的变化)。
游戏逻辑
游戏逻辑是游戏的核心。它定义了游戏世界、其内容和其交互方式。包络游戏状态和数据结构、物理层、事件、进程管理器、命令解释器这机种组件:
1.游戏状态&数据结构
每个容器对象都具有容器,并且需要合理的数据结构来存储它
2.物理学和碰撞
3.事件
当游戏逻辑让游戏状态发生变化时,游戏系统就会作出响应
4.进程管理器
保存进程列表
5.命令解释器
游戏逻辑需要对外部命令做出响应。
其实我也不知道这是不是现在流行的架构了,看了很多资料,各有不同,仅供参考吧