Z's Blog

Welcome to my blog. This is a technical site focused on game development. My open-source projects on GitHub: github.com/hxhb and Open-Source projects.
The articles in the blog include a C++ series, Hot Update for UnrealEngine, Plugins and tools development, Game Resource Management series, and thoughts series, etc.

In my spare time, I research and develop technical solutions and preview the results: Showcase. If you are interested in any of the projects, feel free to email me at imzlp@foxmail.com.

UE as Lib

Dictionary-based Shader Compression

Remake PAK at Runtime

Multi-stage Resource Inspection

Splitting Game Resource

Human Pose Tracking in UE

In addition to this site, I also created a community-driven Chinese knowledge base site for Unreal Engine https://ue5wiki.com/, hosted on GitHub Pages. Contributions of technical content are welcome to help build the Chinese Unreal Engine technology community! Please see the submission rules: Wiki Content Writing Format and Rules .

随着游戏规模和资产精度的提升，以及Nanite等技术的应用，项目工程规模急剧膨胀，达到数百G乃至上T的量级，完整拉取的耗时可能数小时。
而每个人在实际开发中，能够用到的资源只占其中的一小部分，所以怎么样减少工程拉取量级，使工程轻量化是需要优化的问题。
在UE5中，官方推出了虚拟资产(VirtualAssets)机制，与P4结合能够做到这一点。

本篇文章会介绍UE5中虚拟资产的配置流程、资产的虚拟化过程与加载代码分析，以及断网可用性的测试。

In game development, hot update is a crucial capability, allowing us to update features and fix bugs without replacing the entire package. However, which elements can be hot-updated, which cannot, and which carry risks, are topics not extensively covered in current articles.

In this article, I will share my thoughts on hot update capabilities and safety, derived from my development of HotPatcher and practical experience with project hot updates. This ensures that when the project goes live, the hot update capability and stability are guaranteed. During the hot update iteration phase, it also provides clarity on what can be hot-updated, allowing for accurate assessment of update risks. Furthermore, by building peripheral capabilities, risks can be identified in advance, and the hot update process can be automated, requiring only the version PM to control patch building and release timing, with no programmer involvement needed in the hot update process.

When developing UE plugins, we often provide a large number of configurable parameters for flexible control, used to manage the specific execution logic and behavior of the plugins.

This article is the eighth in my UE Plugin Development Series, and will introduce my thoughts and implementations regarding the configurability of plugins during the development process, along with practices in project configuration, task configuration, dynamic parameter replacement, etc., to make the plugin configuration process as flexible and easy to use as possible.

In game projects, when we package for various platforms, we always hope that the package for each platform can be minimized for easier distribution, and there are specific size requirements for some platforms.

For UE, it contains massive code and numerous plugins, and during the Build phase, it generates a lot of reflection glue code, resulting in a significant increase in code segments during compilation. Taking the Android platform as an example, this leads to a sharp increase in the size of libUE4.so, putting pressure on both the package size and runtime memory.

Moreover, some necessary and additional resources brought in by the engine can take up hundreds of MB, making the size of an empty APK easily reach several hundred MB! Not only to meet the platform’s requirements, but it is also necessary to trim down the size of the UE package from the perspective of package size and memory optimization.

This article will take Android as an example and introduce optimization ideas and practices for the cuttable parts in the UE package from various aspects, optimizing both the APK size and the runtime memory usage of native libraries. The strategies can also be reused on other platforms.

Recently, I encountered an extremely bizarre bug involving two maps. One map, A, can be accessed with its PAK placed in the engine’s automatic mount directory, but it cannot be accessed from the hot update directory. The other map, B, behaves completely oppositely: it is abnormal in the automatic mount directory but works normally in the hot update directory.

At first glance, the issue appears entirely elusive, with two mutually exclusive behaviors occurring within the same logical framework. Moreover, the hot update mount and the automatic mount only differ in timing and priority, so this problem shouldn’t theoretically exist.

While the issue can ultimately be resolved on the business logic side, this behavior involves another very obscure path within the engine. Understanding why and how it works is crucial. Therefore, I analyzed the engine’s code based on this behavior, came to a reasonable conclusion, and devised a method to detect and mitigate this issue.

This article assumes that readers have some basic knowledge of UE hot updates; if in doubt, please refer to other articles in this blog’s hot update series for more information.

For personal knowledge management, I am very keen on creating my own local-first and open source self-hosted services. This way, I can avoid relying on any platform, have complete autonomy over my data, and be able to migrate services at any time. Options like Obsidian, Hexo blog, and the memos introduced in this article all meet these criteria.

The protagonist of this article, memos, is an open-source lightweight note-taking service that allows you to take notes in a way similar to posting on Weibo, supporting TAG marking and citations. It features an account system and permission management, allowing web access at any time, and notes can be public or private, offering great flexibility. I chose it because it complements Obsidian; Obsidian is still too heavy for my needs—it works well on PC but has a poor mobile experience. Thus, I need a lightweight, always-available note-taking service.

This article will introduce how to deploy a Memos service on a VPS using Docker, along with Nginx to bind the domain name, Certbot to issue and automatically update SSL certificates, and regular backups of the memos database, as well as some optimization configurations I made for the service.

In previous articles, I primarily introduced how HotPatcher can be applied in the hot update process. However, HotPatcher is not just capable of fulfilling the needs for hot updates; it is also a flexible resource packaging framework.

As the project development reaches a certain stage, a massive amount of resources needs to be packaged, and waiting for a complete package to be built can take a long time. If a real device encounters issues, the serial process of repair -> package -> verify can become exceedingly lengthy. There are often cases of script, data, or other resource errors that lead to package abnormalities.

In such cases, waiting hours to generate a complete package prevents smoke testing from proceeding. Even if you rebuild the package, there’s no guarantee that there won’t be other overlooked issues; otherwise, you have to start over again.

Based on this pain point, we urgently need a method to quickly fix resource issues within packages and validate them during the development phase. HotPatcher provides this functionality, allowing you to utilize it fully without waiting for a complete package.

This article will introduce how to utilize the editor features provided by HotPatcher to quickly package preset configurations and specific resources, accelerating the validation process of resources on real devices and significantly improving testing efficiency.