今年下半年打算正式撸一撸小游戏，正好这些天整理一下有关游戏的一些知识，当然了，目前还是打算使用浏览器网页进行游戏开发。
网页游戏开发的优势与未来
如果使用其他语言开发游戏，无论游戏本身大小与否，我们都需要游戏引擎来帮助我们构建开发，而对于浏览器来说，我们在开发小游戏时候，利用浏览器本身提供的组件和 api 就可以直接进行业务处理，我们也可以更加高效的学习与实践游戏逻辑。同时网页游戏的构建与发布也非常简单。
例如像 Js13kGames (Js13kGames是一个针对 HTML5游戏开发者的 JavaScript 编码竞赛,该竞赛的有趣之处在于将文件大小限制设置为13 kb ) 这样的限制代码量的游戏开发竞赛。对于非网页游戏开发来说，这基本上是不可能完成的，因为它们不具备有像浏览器这种量级的通用型的工具。
随着时间的发展，浏览器的功能，性能也在不断提升。通过 WebGL, WebAssembly 各种层出不穷的技术。让很多之前想都不敢想的功能在浏览器上实现。同时,伴随着 5G 到来，网速的提升，在浏览器上开发游戏充满了无限的可能。
当然了，事实上，不同的游戏需要不同的组件，其中包括数学库，随机算法，碰撞及物理引擎，音频，资源管理，AI机制等等等等，不过在浏览器环境下，这些组件都可以做到按需引用。
游戏循环架构与风格
游戏本身是基于动画的。不知道大家在小学的时候有没有买果或者玩过翻纸动画？如果你没有了解过，也可以看一看bilibili 中的视频 高中生自制的翻纸动画短片。视频中通过快速翻动纸张来实现两个火彩人打架的精彩动画。事实上，我们的电脑，手机设备能够展示动画都是基于此原理。
所谓动画，就是不间断，基于时间和逻辑不断更新数据以及重绘界面。其核心一定会有至少一个循环。这里我介绍几种常见架构。
视窗消息泵
在 Windows 平台中，游戏除了需要对自身进行服务外，还需要处理来自于 Windows 系统本身的消息，因此，Windows中有游戏都会有一段被称为消息泵的代码。其原理是先处理 Windows 的消息，之后再处理游戏循环逻辑。
// 不断循环处理
while (true) {
MSG msg;
// 如果当前消息队列中有消息，取出消息
while(PeekMessage(&msg, NULL, 0, 0) > 0) {
TranslateMessage(&msg);
DispatchMessage(&msg)
}
// 执行游戏循环，类似于更新与重绘
RunGame()
}
以上代码的副作用在于默认设置了游戏处理消息的的优先级，循环中先处理了 Windows 内部消息。如果游戏在调整界面或者移动视窗时候，游戏就会卡住不动。
回调与事件驱动
很多游戏框架(包括浏览器)已经在内部实现了主游戏循环，我们无法直接介入内部循环机制，我们只能够填充框架中空缺的自定义部分。通过编写回调函数或者覆盖框架预设行为来实行。
例如一些游戏渲染引擎是这样实现的:
while(true) {
// 渲染前执行（游戏子系统逻辑）
for(each frameListener) {
// 回调函数
frameListener.frameStarted()
}
// 渲染
renderCurrentScene()
// 场景渲染后执行
for(each frameListener) {
// 回调函数
frameListener.frameEnded()
}
// 结束场景与交换缓冲区
finalizeSceneAndSwapBuffers()
}
而另一种回调是基于事件驱动，实现方式为：事件系统会将事件置于不同的队列之中，然后在合适的时机从队列中取出事件进行处理。这种方式也就是浏览器的处理方式，利用消息队列和事件循环来让网页动起来。
while(true) {
// 从任务队列中取出任务
Task task = task_queue.takeTask();
// 执行任务
ProcessTask(task);
// 执行各种其他任务 Process...
}
而浏览器提供的回调就包括 setTimeout(延迟执行) 与 **setInterval **(间隔执行) requestAnimationFrame(动画渲染) **requestIdleCallback **(低优先级任务)。前两者执行时机由用户指定时机执行，后两者是由浏览器控制执行。
setTimeout 是一个定时器，用来指定某个函数在多少毫秒之后执行。他会返回一个编号，表示当前定时器的编号，同时你也可通过 clearTimeout 加入编号来取消定时器的执行。
// 注册 10 ms 后打印 hello world
const id = setTimeout(() => {
console.log('hello world')
}, 10)
clearTimeout(id)
结合上面的事件驱动模型，可以看出该回调函数就是在循环中不断执行任务,当发现延迟任务队列中的某个任务超过了当前的时间节点(通过发起时间和设定的延迟时间来计算)，就直接取出任务执行调用。等到期的任务都执行完成后，在进行下一个循环过程，通过这样的方式，一个完整的定时器就实现了。浏览器取消定时器则是通过 id 查找到对应的任务，直接将任务从队列中删除。
我们也可以通过 setTimout 回调函数内再次执行 setTimout 来实现 setInterval 函数的功能，看起来也类似于间隔执行，其实还是会有一定的区别。
// 在回调函数完成后才去设置定时器，时间会超过 16 ms
setTimeout(function render(){
// 执行需要 6 ms
// 定时 16ms 后
console.log(+ new Date())
setTimeout(render, 500);
}, 500)
// 尝试每 16 ms 执行一次，不管内部回调函数耗时
setInterval(function render(){
console.log(+ new Date())
}, 16)
重点在于，JavaScript 本身是单线程的，同时基于上面的事件驱动代码，我们只能依赖任务加入顺序依次处理任务，无法切断当前任务的执行，我们只能够控制定时器任务何时能够加入队列，却无法控制何时执行，如果其他任务执行的时间过久的话，定时器任务就必须延后执行，开发者没有任何办法。 当然了，社区的力量也是无穷的，facebook 的 React Fiber 就是实现了在渲染更新过程中断当前任务，执行优先级更高的任务的功能。
不过像使用浏览器的系统(包括游戏等)都是软实时系统。所谓软实时系统，就是即使错过限定期限也不会造成灾难性后果——错过了当前帧数，现实世界不会因此造成灾难性后果，与此相比，航空电子，核能发电等系统都属于是硬实时系统，错过期限会有严重的后果。不过就算如此，谁会喜欢一个经常卡顿的系统呢？所以实际业务开发中的性能优化还是重中之重。
当然了， requestAnimationFrame 本身也是回调函数，那么这个函数究竟有什么过人之处可以提升动画性能呢?在此之前，我们先介绍一下屏幕刷新率与 Fps 的区别。
屏幕刷新率与 FPS
屏幕刷新率即图像在屏幕上更新的速度，也即屏幕上的图像每秒钟出现的次数，它的单位是赫兹(Hz)。 对于一般笔记本电脑，这个频率大概是 60Hz，在 Window 10 上 可以通过桌面上右键->显示设置->高级显示设置 中查看和设置。屏幕刷新率表示显示器的物理刷新速度。
对于我的电脑来说，无论我目前是在浏览网页还是在挂机状态，当前显示器都以 1 秒刷新 165 次当前界面，该数值取决于显示器。我们也可以通过修改适配器属性->监视器来调整屏幕刷新率,一般来说，我们只要调整到眼睛舒适即可。
事实上，仅仅靠显示屏的刷新率是没有用的，就像上面的循环机制,如果 GPU 处理当前任务的耗时大于当前屏幕刷新的间隔时段。就无法按时提供图像。该特性也就是我们所说的 FPS 每秒传输帧数(Frames Per Second)。而对帧数起到决定性的是电脑中的显卡，显卡性能越强，帧数也就越高。
即 FPS 帧数是由显卡决定，刷新率是由显示器决定。如果显卡输出 FPS 低于显示屏的刷新率，则在显示屏刷新中将会复用同一张画面。反过来，显示器也会丢弃提供过多的图像。
requestAnimationFrame (Raf) 使用与机制
下面我们就谈一谈 raf 函数对比其他定时器回调的优点。
首先，raf 函数本身并不是一个新特性，就连 IE 10 都提供了支持，所以这里不再介绍兼容。设置这个 API 的目的是为了让各种网页动画效果（DOM动画、Canvas动画、SVG动画、WebGL动画）能够有一个统一的刷新机制，从而节省系统资源，提高系统性能，改善视觉效果。使用方式如下:
let start = null;
let element = document.getElementById('SomeElementYouWantToAnimate');
element.style.position = 'absolute';
function step(timestamp) {
if (!start) start = timestamp;
var progress = timestamp - start;
element.style.left = Math.min(progress / 10, 200) + 'px';
if (progress < 2000) {
window.requestAnimationFrame(step);
}
}
window.requestAnimationFrame(step);
可以看到，其实函数使用方式和 setTimeout 基本一致，只不过不需要提供第二个参数。
那么在没有第二个参数的情况下，函数究竟多久执行一次呢？raf 充分利用显示器的刷新机制，执行频率和显示屏的刷新频率保持同步，利用这个刷新频率进行页面重绘。也就是说在我的电脑上，raf 函数每秒执行 165 次。也就是 6 ms 执行一次，如果其他任务执行事件过长的话，该函数顺延到合适的时机。也就是其他任务执行时间大于 6 ms，函数就会在 12 ms 时候第二次执行，如果大于 12 ms,则会在 18 ms 时候第二次执行。
当看到 raf 函数和屏幕刷新率一致时候，大家也能大致的猜测出，浏览器为什么要提供 raf 函数了。因为显示器和 GPU 属于两个不同的系统，两者很难协调的运行，即使两者周期一致，也是很难同步起来。
所以当显示器将一帧画面绘制完成后，并在准备读取下一帧之前，显示器会发出一个垂直同步信号（vertical synchronization）给 GPU，简称 VSync。这时候浏览器就会利用 VSync 信号来对 raf 进行调用。
CSS 动画是由浏览器渲染进程自动处理的，所以浏览器直接让 css 动画于 VSync 的时钟保持一致。但是 js 中 setTimout 和 setInterval 由开发者控制，调用时机基本不可能和 VSync 保持一致。所以浏览器为 js 提供了raf 函数，用来和 VSync 的时钟周期同步执行。
针对于 VSync，大家可以参考 理解 VSync 这篇文章。
扩展
注意: 浏览器为了优化后台页面的加载损耗以及降低耗电量，会让没有激活的浏览器标签 setTimeout 执行间隔大于 1s。requestAnimationFrame 执行速率会不断下降，同理 requestIdleCallback 也是如此。
同时，相信浏览器后面也会函数调度提供更加方便的支持，大家感兴趣也可以了解一下 isInputPending，不过该提案还处于起草阶段，工作组尚未批准，更不用说投入生产中了。
鼓励一下
如果你觉得这篇文章不错，希望可以给与我一些鼓励，在我的 github 博客下帮忙 star 一下。
博客地址
