Unturned II 开发日志#033

更新的重点是保存和加载游戏状态。

持久性概述

虽然仍然潜伏着一些bug，但在beta版中，保存和加载的基础相对来说是有功能的：

与原始游戏相比，持久化状态要多得多。例如，手动放置在级别编辑器中的项只生成一次，并且删除的项(最后)在加载之间是安全的。

有三种类型的本地储蓄：

• 每个级别都有一个快速保存槽。按F5键快速保存，按F9键快速加载。
• 在此之上，每个级别都有一个自动保存槽。在加载映射、定期保存和退出时，这通常是默认的。
• 可以创建和删除手动保存槽以保留时间点。

专用服务器通过INI文件配置保存数据，并具有诸如定时自动存盘之类的关键功能。

造型机

多年来，我可怜的笔记本电脑一直在忙着编译和构建未打开和未打开的II更新程序。在社区成员HoldBaker的新年部落模式活动中，我无法修补他们遇到的一个bug，因为构建起来可能需要太长时间。谢天谢地，一台合适的专用构建机已经组装好，笔记本电脑就可以休息了。这台新机器的更新速度快了13倍！

持久性实现

在过去的几周里，大量的计划和重构进入了这个节省系统。虽然有几个方面我还不完全满意，但下面是一些有趣的关键决定：

• 默认情况下，存储的数据为专用服务器以JSON格式保存，单机则以二进制/json混合格式保存。为XML或其他格式编写数据格式化程序的插件实现很简单。我的计划是JSON格式对于WebAPI后端很有用，并且易于与第三方工具集成。
• 从游戏代码的角度看，读写是只向前的，支持键值映射和数组。基本格式并不重要。
• 蓝图完全控制自己的保存/加载处理。这一点很重要，并对这一做法产生了重大影响。他们接收一个带有包装器的“SaveContext”或“LoadContext”来处理本机c++代码。
• 虽然自动属性序列化很好，并且可能会在某个时候被自动地用于保存标记的属性，但是在加载端通常比在保存端需要更多的游戏逻辑。特别是对于支持版本控制的蓝图，因为它们没有像UE4Version或LicenseVersion这样的简单数字。由于这个原因，所有的读取函数都可能失败，例如TryReadInteger。
• 游戏逻辑控制存储和加载的内容，但是数据的存储方式是可配置的。今后，我预计配置文件中将有一个[持久性]实现键，用于将专用服务器存储指向本地文件系统、远程API或其他什么地方。

原文

4.20.5.0 update focused on saving and loading game state.

Persistence Overview

While there are definitely bugs still lurking, the foundations for saving and loading are relatively functional in the beta now:

Much more level state is persisted than in the original game. For example items manually placed in the level editor are only spawned once, and dropped items are (finally) safe between loads.

There are three types of local saves:

• Each level has a quicksave slot. Press F5 to quicksave and F9 to quickload.
• On top of that each level has an autosave slot. This is usually the default when loading a map, and saved to periodically and when exiting.
• Manual save slots can be created and deleted to preserve a point in time.

Dedicated servers configure savedata through an ini file, and have key features like timed autosaves.

Build Machine

My poor laptop has been chugging away for years compiling and building updates to Unturned and Unturned II. During community member HoldBaker's New Year Horde Mode event I could not patch a bug they ran into because it would take too long to build. Thankfully a proper dedicated build machine has been assembled, and the laptop can rest. This new machine blazes through updates 13x faster!

Persistence Implementation

Lots of planning and refactoring went into this save system the past few weeks. While there are a few aspects I am not completely happy with yet, here are the key interesting decisions:

• Stored data is kept in JSON format for dedicated servers by default, and a binary/json hybrid for singleplayer. It would be straightforward to write a plugin implementation of the data formatter for XML or another format. My plan is that the JSON format will be useful for the web API backends, and easy to integrate with 3rd-party tools.
• From a game code perspective the reading and writing is forwards-only, supports key-value maps, and supports arrays. The underlying format does not matter.
• Blueprints have full control over their own save/load handling. This was important and significantly impacted the approach. They receive a "SaveContext" or "LoadContext" with wrappers to handle the native c++ code.
• While automatic property serialization is nice, and might be automated for savegame-tagged properties at some point, there is often significantly more game logic required on the loading side than on the saving side. In particular for blueprints to support versioning because they do not have a simple number like the UE4Version or LicenseeVersion. For this reason all of the read functions can fail e.g. TryReadInteger.
• Game logic controls what is saved and loaded, but how the data is stored is configurable. In the future I expect there will be a [Persistence] Implementation key in the config file to point the dedicated server storage at the local file system, a remote API, or something else.