Unturned II 开发日志 #040-041 第二集

我没想到会写这个！

Unturned II

自上一篇文章以来，我已经取得了一些进展，例如增加了在单手和双手武器姿态之间切换的能力，但是我将把这些细节留给下一个下载日志。在过去的一个月里，我几乎所有的时间都花在了“Devlog#040-041”帖子中未提到的“潜在UI重写”上。

由于这使得我花了两个月的时间在未打开的II上而不是未打开的II上，我的计划是在11月和12月尽可能多的投入到未打开的II上，并希望在年底之前完成一个“令人兴奋的”特性，比如开放世界的敌人。

Glazier

“glazier”是从事玻璃工作的商人。我认为这是Unturned的UI重构的一个好名字，因为系统需要学习一种新技术：uGUI

这里的目标是几乎无缝地将整个游戏UI从遗留的IMGUI转换为uGUI，并考虑到将来对UIElements的转换。每个uGUI替换应该看起来与它们的IMGUI完全相同或“更好”。

谢天谢地，游戏并没有直接使用IMGUI调用，而是将它们封装在“光滑”的类中。“SleekButton”在某些地方，它们有着相当深的层次结构，例如，SleekLabel>SleekButton>SleekButtonIcon>SleekButtonIconcon&SleekButtonIcon难，其中许多层次结构都是不合逻辑的。

现在，基类是一个名为“ISleekElement”的接口，它具有像“ISleekButton”这样的子接口。每个Glazizier实现这些接口，例如SleekBase>GlazierBase_uGUI>GlazierButton_uGUI实现ISleekButton。所有的构建块元素现在只有三层深。

一个问题是由其他元素组成的光滑子类，如“SleekWorkshop SubscriptionButton”和“SleekColPicker”。它们不能再是直接子类了，因为基必须支持uGUI和IMGUI之间的切换。我对这里的最终设计很满意：他们继承了一个实现ISleekElement的“SleekProxy”类，并将接口转发给了一个每釉器实现。

有很多一次性的问题需要解决，比如在整个代码库中使用硬编码的IMGUI，或者依赖于全局GUI状态，Molt设法找到了大量的bug，但我认为它现在已经准备好了。如果你想尝试一下，蒸汽上的“琉璃”贝塔分支今天就公布于众了！

原文

Well, I did not expect to be writing this!

Unturned II

I have made some progress since the last post, for example adding the ability to switch between one-handed and two-handed weapon stances, but I will save those details for the next devlog. Almost all of my time this past month has been spent on the "Potential UI Rewrite" for Unturned mentioned in the "In-between Devlogs #040-041" post.

Since this has resulted in spending two months on Unturned rather than Unturned II, my plan is to commit as much of November and December to Unturned II as possible, and hopefully finish one of the "exciting" features like open-world enemies by the end of the year.

Glazier

A "glazier" is a tradesperson who does glasswork. I decided this was a good name for the Unturned UI refactor, as the system would need to learn a new technique: uGUI

The goal here was to almost seamlessly convert the entire game UI from legacy IMGUI to uGUI, with a future conversion to UIElements in mind. Each uGUI replacement should look identical to or "better" than their IMGUI counterpart.

Thankfully the game was not directly using IMGUI calls for the most part, instead wrapping them in "Sleek" classes e.g. "SleekButton". These had a pretty deep hierarchy in some places, for example Sleek > SleekLabel > SleekButton > SleekButtonIcon > SleekButtonIconConfirm, and a lot of this hierarchy was illogical.

Now the base Sleek class is an interface, "ISleekElement", with sub-interfaces like "ISleekButton". Each glazier implements these interfaces, e.g. SleekBase > GlazierBase_uGUI > GlazierButton_uGUI implements ISleekButton. All the building-block elements are now only three layers deep.

One problem was sleek subclasses composed of other elements like "SleekWorkshopSubscriptionButton" and "SleekColorPicker". They could not be direct subclasses anymore because the base had to support switching between uGUI and IMGUI. I am happy with the end design here: they instead inherit from a "SleekProxy" class which implements ISleekElement, and forwards the interface to a per-glazier implementation.

There were a ton of one-off issues to resolve, like hardcoded IMGUI usage throughout the codebase or dependence on the global GUI state, and Molt managed to find plenty of bugs, but I think it is almost ready to go now. If you would like to try it out the "glazier" beta branch on Steam was made public today!