游戏数据包的补丁和更新
我们的游戏引擎是基于虚拟文件系统，可以通过网络把开发机上的目录映射到手机上。这对开发非常方便，开发者只需要在自己的开发机上修改资源，立刻就能反应到手机上。
但当游戏发行（也就是我们正在准备的工作），我们还是需要把所有资源打包，并当版本更新时，一次性的下载更新补丁更好。
之前一直没时间做这方面的工作，直到最近才考虑这个问题。我们到底应该设计一个怎样的补丁更新系统。
我们的游戏引擎是基于虚拟文件系统，可以通过网络把开发机上的目录映射到手机上。这对开发非常方便，开发者只需要在自己的开发机上修改资源，立刻就能反应到手机上。
但当游戏发行（也就是我们正在准备的工作），我们还是需要把所有资源打包，并当版本更新时，一次性的下载更新补丁更好。
之前一直没时间做这方面的工作，直到最近才考虑这个问题。我们到底应该设计一个怎样的补丁更新系统。
Lua 的数据类型非常有限，用 C 编写的 Lua 模块也没有统一的生态。在不同模块间传递内存块就是件很头疼的事情。
简单通用的方法就是用 Lua 内建的 string 类型表示内存块。比如 Lua 原生的 IO 库就是这么干的。读取文件接口返回的就是字符串。但这样做有额外的内存复制开销。如果你用 Lua 编写一个处理文件的程序，即使你的处理函数也是 C 编写的模块，也会复制大量的临时字符串。
我们的游戏引擎是基于 Lua 开发的，在文件 IO 上就封装了自己的库，就是为了减少这个不必要的字符串复制开销。比如读一个贴图、模型、材质等文件，最后把它们生成成渲染层用的 handle ，数据并不需要停留在 Lua 虚拟机里。但是，文件 IO 和资源组装（比如贴图构造）的部分是两个不同的 C 模块，这就需要有效的内存交换协议。
我们游戏引擎的 UI 使用的是类似网页的技术，是将 RmlUI fork 出来的自行维护的版本 。目前游戏中大量遇到的一个需求是：把 3d 模型作为 UI 组件使用。这个需求在我经历过的历史项目中都曾遇到过，在不同的游戏引擎中我见过各种解决方案。
最典型的是 RPG 类游戏的人物属性面板。通常需要在面板上显示 3D 人物模型。通常还可以旋转这些模型，让玩家 360 度观看。我们目前的游戏类似 Factorio ，没有 Avatar ，但点开建筑的信息面板时，也需要把建筑的 3D 模型动态展现出来。
最初，我们没去细想 3D 渲染怎么和已有的 RmlUI 结合在一起，直接把模型渲染在 UI 层之上。相当于在 UI 模块外开了个后门。UI 上只需要把位置空出来，等 UI 渲染完后，再叠加 3D 模型上去。但这样做的坏处是很明显的：3D 模型无法和 UI 窗口有一致的层次结构。
后来，我们额外构造了一个 render target ，改造了一点 RmlUI ，让它可以支持一个矩形区容纳这个 rendertarget 的画布 。这样，3D 模型渲染就比较好的和 UI 模块融合在一起。但是需要单独编写 UI 上 3d 元素的相关代码，尤其是管理它 ( rendertarget ）的生命期。
最近，我希望在 UI 上增加更多 3d 模型。它们仅仅是用来取代原来的 2D 图片。从 UI 角度看，这些就应该是图片，只不过这些图片并不是文件系统中的图片文件，而是运行时由 3d 渲染模块生成的。如果继续沿用目前的图片方案，我们就多出一些开发期处理这些预渲染图片的维护成本。但是，如果直接使用已有方法的话，那个看起来临时的解决方案又有点不堪重负。
上篇谈了一下我们游戏引擎的虚拟文件系统（vfs）。我觉得这个系统中，游戏资产的管理部分还是个满有意思的设计，值得写一下。
VFS 的设计动机是方便把开发机磁盘上的数据同步到运行设备（通常是手机）中。传统游戏引擎的做法通常是建一个叫做资产仓库的东西，在开发期间不断添加维护这个仓库。需要把游戏部署在运行设备时，再打包上传过去。因为传统游戏引擎在开发期间一般直接在开发机上运行，所以打包上传（从开发机转移游戏资产）并不频繁。
而我们的游戏引擎特别为手机游戏开发而设计，我们不可能直接在手机设备上开发，所以开发机一是和运行机分离的。为了提高开发效率，所以我们设计了 VFS 系统。可以通过网络同步资源仓库。
目前我们游戏用的引擎早在 2018 年就开始了。因为一开始，它就定位为一个主要用于手机平台的游戏引擎，要方便手机开发。因为我们不太可能直接在手机设备上编写代码、制作资源，所以开发机一定是和游戏运行环境分离的。从一开始，我们就设计了一个虚拟文件系统，它可以通过网络，把开发机上的文件系统映射到手机设备上，同时兼有版本管理的功能。这样，才可以做到在开发期间，开发机上所做的大多数修改，都能立刻反映到手机上。
我们的游戏引擎的大部分是用 Lua 开发的，这也意味着文件系统中不光有游戏用的资源素材，还包括了代码本身。甚至包括了虚拟文件系统自身的实现。这个东西比一开始想的要麻烦，我们这几年不断地修改它，直到最近。比如一开始认为最麻烦的自举部分 ，在去年就去掉了，为的就是减少系统的复杂度。
最近在手机上玩我们正在开发的游戏时间比较多（之前主要运行的是 Windows 版），发现有许多操作值得改进。这里列举两个值得一提的交互优化。
第一，触摸屏上点击特别小的物件时很难精确。去年我提过一个解决方案 ，我们的游戏一直是这样处理的：连续 tap 屏幕同一个位置，会轮询这个位置附近的物件。这样，一次点不准的话，可以多点几次选到想要的焦点。这不仅可以解决小物件密集的时候，tap 不好区分的问题，还可以选到重叠的物件。这个方法其实在鼠标游戏中已有这么使用的了，比如 rimworld 就是用类似方法处理同一个格子上有多个可选物件的。
这两天遇到一个任务调度算法引起的性能问题，花了颇多精力排查和解决。问题出在我写的 ltask 这个 lua 多任务库上。ltask 最初是对 skynet 的一些反思中开始的，最初只是想换一种思路实现 skynet ：做一个库而不是框架、更少的锁竞争、避免服务因为消息队列堆积而过载……
后来、我们游戏引擎开始尝试基于 ltask 利用手机设备上的多核，渐渐的便完善起来，也发展出和 skynet 不同的部分。它最近两年一直是围绕移动设备客户端程序优化，所以网络部分并非重点，也就不需要像 skynet 那样把网络模块做在框架底层，而是以一个独立服务存在。而网络 IO 、文件 IO 、客户端窗口这些部分又不适合于其它渲染相关的服务混在一起，因为它们需要和操作系统直接打交道，所以我在 ltask 中又分出了独占线程和共享工作线程两种不同的线程，可以把不同的服务绑在不同的线程上。甚至对于 iOS ，还必须让窗口线程运行在主线程上，而不得不在 ltask 里做特殊的支持。
最近发现的这个问题也是游戏客户端特有的，它很能说明用于游戏服务器的 skynet 和用于客户端的 ltask 在实现侧重点上的不同。
所有在桌面玩的游戏都算作桌面游戏。几乎所有的人都玩过，比如象棋、围棋、扑克。如果不计这些传统的抽象游戏，我玩现代桌面游戏已经有十多年了。过去，是和朋友一起玩，而最近几年，更多的是和家人（小孩）一起玩。和许多不玩现代桌游的人想象的不一样，虽然电子游戏脱胎于桌面游戏，但桌面游戏却并没有被淘汰，反而一直在推陈出新，每年都有许多新的佳作面世。
玩桌游这么些年，我发现桌游其实可以分出几个子类。像我这些各种桌游都玩的玩家很多，但有相当一部分人专注于特别一个子类，对其它类的桌游兴趣不大。有时，隐隐觉得不同子类之间还有一些鄙视链存在。
上次提到，经过数据分析发现，我们引擎（游戏）目前特效系统占了很大的 CPU 比例。虽然特效的计算已经放在独立线程，不影响帧率，但 CPU 的开销会导致电池消耗，最终会引起手机热量上升，最终让手机降频。所以，当时想了一些牺牲准确性的方案来做优化：即，不在镜头内的特效不运算。让视觉裁剪同时也裁剪掉特效粒子片的计算。
最近做了这方面的重构工作。其中的难点在于：特效模块是第三方的，并不完全贴合我们的引擎设计，而短期内又没有重新实现或改造的计划。
第一次感染 covid-19 是在去年底，距今已有 8 个月了。
最近似乎又中招过一次，特此记录一下。
上周四（ 8 月 10 日）午饭过后，感觉有点困，就靠在办公椅上打了个盹。我平常没有固定午休的习惯，觉得自己是头天没睡好的缘故。14 点多醒了，感觉依旧精神不好。起身去上厕所时发现有些头晕，不过没太在意。
18 点下班时，感觉头晕没有缓和，似乎更严重了。去食堂的路上走路有点飘。没什么胃口，快速吃完，觉得自己的体力不足以步行回家，就搭了个同事的顺风车赶紧回家睡觉。
我们的手机游戏引擎一直在跟随着游戏项目的进程不断优化。一开始是因为游戏引擎在手机上帧数达不到要求。得益于 ECS 框架，我们把初期用 Lua 快速开发出来的几个核心 system 用 C 重写后，得到了质的飞跃。
其实这些核心代码总量并不算大。例如在 profile 中表现出来的非常消耗 CPU 的一个场景树更新系统，用 C 重写了也才 200 行代码 ，但在优化前 Lua 版本会消耗超过 1ms 的时间，而用 C 重写后，时间已可以忽略不计。
另外，我们采用了类似 skynet 的 ltask 做多线程框架，把业务尽量拆分到多线程中并行处理，这也极大的减少了每帧的耗时。除了主业务逻辑外，UI 、粒子系统、IO 被分为几个并行线程。且渲染底层的 bgfx 也是按多线程渲染设计的。这些并行流程间只通过少量的消息通讯，所以，并行的总工作量并没有比单线程模型更多。ltask 也可以很方便的调节工作线程的个数，用来更好的适配手机的 CPU 。
从xcode 的调试信息看，在游戏场景丰富时，大约会占用 280% 的 cpu 。换句话说，如果我们采用的是单线程架构，在不删减特性的前提下，做到流畅是相当困难的。
在我们的 ecs 模块中，有一个重要的内部数据结构是 eid 的数组。它是 Component 结构的一部分，表示每个 Component 属于哪个 Entity 。目前，它是以一个有序的 id 数组实现的。
这个数据结构常见的操作分别是：遍历、随机访问、查找 id 所在的位置。一个有序数组可以很好的完成任务。O(1) 的随机访问时间，O(Log N) 的查找时间。
我们的 Entity ID 是 48bit 的，我觉得保存 48 或 64bit 的 id 数组有点浪费，且空间越大，实际操作效率也会相应降低。实际上，Entity 的个数不会太多，我觉得限制在 2^24 (一千六百万左右）足够了，所以用了一个间接索引，保存 24bit id ，再用它去索引真正的 entity id 。
我们的游戏引擎使用的是 stb 的 truetype 库 来处理 ttf 字体的。最近发现在使用公司提供的 阿里巴巴普惠体 时出了一点问题。
引擎渲染出来的汉字比标称的像素高度矮了不少，想渲染 100 像素高的汉字，结果只有 70+ 像素左右。我们之前测试使用的中文字体（ Windows 自带默认字体）没有这个问题。
在网上翻了一下，找到这么一个帖子：https://github.com/nothings/stb/issues/689 以及 imgui 也遇到过类似问题 。
游戏数据包的补丁和更新 (3)
Cloud :
为什么不直接用 git 的实现 ？
因为，我们只需要实现 git 一...
游戏数据包的补丁和更新 (3)
涛叔 :
git 也是相同的思路，每个文件对应一个 blob，名字是内容+固定结...
游戏数据包的补丁和更新 (3)
czyt :
感谢云风大佬分享。我感觉这种实现跟git差不多，那么为什么不用git这...
Lua 的 C 模块之间如何传递内存块 (1)
x :
理解的很深刻，一个lua应用的边界情况，也正在把lua的轻量加重。...
贴图管理模块及 UI 上的 3D 模型 (9)
怪物公司 :
如果每帧执行的输入参数不变，把执行请求注册到目标系统内部会不会更好？...
贴图管理模块及 UI 上的 3D 模型 (9)
Cloud :
id 到 handle 转换涉及到多线程都要做，用缓存反而复杂。
我...
贴图管理模块及 UI 上的 3D 模型 (9)
怪物公司 :
id到handle的转换只应该必要时才做。每帧都做同样的一件事，是不是...
贴图管理模块及 UI 上的 3D 模型 (9)
nothanks :
云风的设计思路有很多操作系统的影子...
贴图管理模块及 UI 上的 3D 模型 (9)
danggui1995 :
Dota2的Panorama中跟这个差不多：每个特效，模型都是额外的v...
贴图管理模块及 UI 上的 3D 模型 (9)
IronCrow :
茅塞顿开！这样处理得好干净啊！
非常感谢！...
