介绍

本文旨在解释《Half-Life: Alyx》游戏引擎和开发工具背后的一些基本概念。使用过《SteamVR Home》创意工坊工具的用户会有一定优势，因为这些工具采用的框架与《Dota 2》等其他游戏所提供的框架相同。不同的是：光照系统得到了极大的改善，其中ModelDoc是模型编辑器的全面改进版，标准着色器有所不同，并且还有更多的实体和内容可供使用。尽管并非全部都能直接适用，但本Wiki上的SteamVR Home创意工坊工具文档仍然可以为制作《Half-Life: Alyx》插件的人们提供一些有用的信息。且已经被汉化的文章相对Half-Life: Alyx要更多。

启动《Half-Life:Alyx》创意工坊工具

请查看创建插件

插件, 以及content和game文件夹

插件是一组文件，这些文件依靠于基础游戏上，其概念与Source 1的mod相似，但允许在运行时更改插件。 您的文件将分为两种类型-源文件（原始文件）和成品文件（处理或编译后的文件）。

源文件位置

• \Steam\steamapps\common\Half-Life Alyx\content\hlvr_addons\your_addon_name

成品文件位置:

• \Steam\steamapps\common\Half-Life Alyx\game\hlvr_addons\your_addon_name

当您将插件上传到创意工坊时，内容文件夹将不会重新分发，而游戏文件夹中的数据将打包到VPK文件中。

资产编译

Source引擎的资产通常以不太适合重新分发或快速加载和呈现的格式保存。例如，纹理可以是一个Photoshop文档，其中包含数十个图层，这些图层包含数百兆字节，它们将被编译成针对引擎优化的格式，以尽可能快地进行渲染。它会丢弃所有不需要的数据（例如，图层或标记数据），并将其压缩为渲染系统的着色器所要求的形式（在显卡上运行的小程序，负责处理屏幕上所看到的像素）使它适合于尽可能快速高效地加载和显示。

content文件夹中的所有文件都是对用户友好的格式，有的是被用户放在这里，有的则是在《Half-Life: Alyx》工具中创建，而game文件夹中的文件通常由content文件夹中的文件产生，并且都能被引擎直接使用。

通常，当磁盘上的内容发生更改时，引擎将自动重新编译，从而允许用户在Photoshop中保存文件，并使所有内容都在材质编辑器和地图编辑器中进行更新。如果引擎没能发现变更，也可以强制重新编译。

基本的文件 - 纹理, 材质, 模型和地图

• 纹理 – 例如一张墙壁上砖块的图像,或者一张法线贴图 (准确地描述了表面的位置，用来模拟额外的细节),或者很多其他的可能性之一。纹理通常在类似于Photoshop之类的软件中制作,GIMP或类似的每当内容更新时就会自动重新编译。但是，要在游戏中渲染需要材质引用它们。

• 材质 – 描述了所有纹理如何协同工作。对于砖墙，材质也许会指向一张色彩图，一张法线贴图,一张粗糙度图等等来明确在游戏中砖墙看起来会是什么样子。您可能会有一种可供替代的砖墙版本，虽然有不同的色彩图，但是有相同的法线贴图和粗糙度图。材质会整理所有这些内容，并允许对所有着色器输入进行简单配置。
  • 材质通过 Material Editor 来创建.

• 模型 – 在例如Maya,Modo或者Blender等3D建模程序中生成。这些是由三角形组成的3D形体，例如家具、树木、在建筑物上的细节以及人物或怪物。在Half-life:Alyx中您会看到有很多东西是基于这些模型的。这些模型所用的面分配了特定材质，这些材质依次分配了要使用的适当纹理。 虽然底层模型文件通常使用外部软件构建，他们在引擎中的用途可被在 ModelDoc 里设置。
  • 更改来源内容时自动重新编译 – 生成的编译过的模型的规格可以由它使用的材质定义。例如，有简单的未照明材质的模型可以被自动编译为没有顶点法线的模型以节省空间 – 但是，如果后续要更改材质以使用适当的照明，就要强制重新编译模型。类似的是，如果更改材质以开始对某些对象使用次要UV，就可能需要重新编译模型以使其正确渲染。

• 地图 – 把它想象成您正在世界上创造的所有物品的容器。地图包含照明数据、放置道具的位置、何时何地播放声音，甚至是将对象行为链接在一起的基本脚本。您在Half-life:Alyx中看到的一切最终都会被放到地图上 – 那是将会发生所有游戏内事件的电影布景或舞台。
  • Half-Life: Alyx创意工坊工具集包含了 Hammer 来作为它的地图编辑器。
  • 地图不会自动重新编译，并且总是需要编译才能查看游戏内的变化。这个过程包括例如计算lighting 和可见性。

其他文件包括声音、粒子系统等 – 这些都在插件的内容文件夹中有来源版本，并在插件的游戏文件夹中编译成精简、高效的版本。

文件分布规则的例外情况

有一些文件类型，例如引擎直接使用的各种脚本文件。这些文本文件放在游戏文件夹中的某个地方，并不会被编译。这些包括声音景观定义、本地化文件等。

实体, 几何结构, 实体逻辑与更多

在Half-Life:Alyx里，Hammer内的一张空的地图是一段VR体验的空白画布。这是几乎所有东西都被放置的地方，除非您把一些物品添加到地图上，否则世界将完全是空的。

• 实体 – 每一个都事实上是自定义代码位，用于执行一组特定的指令，当用户与其他实体结合，互动时，这些指令允许用户在游戏中创建各种体验。他们在世界上几乎总是有一个可见（和/或可听见）的表象，并以特定的方式对事物做出反应。一件物理道具是实体的一个示例，用户可以在其中指定哪个模型应渲染为物理道具，它应如何响应玩家投掷道具的动作等。其中一些数据包含在Hammer中，可以编辑，而模型文件中包含特定于该模型的其他数据。另一个例子是NPC（猎头蟹，联合军士兵），光源，或一个不可见的触发体，当一个特定实体进入它时，它告诉另一个实体执行某事。

• 几何结构 – map geometry built in Hammer 主要像固定的体系结构一样使用，所有事件都发生在它上面。您还可以将地图几何图形的特定部分绑定到特定实体–这会告诉实体（如滑动门或旋转平台）使用该地图几何结构作为其可视化表现。

• 实体逻辑 – 这是将地图中实体的行为粘在一起的基本粘合剂。根据实体的输入和输出定义，一个实体可能会经历一个特定的事件发生（例如玩家将一只手放入指定的区域中），这会导致它触发OnTrigger而输出。它连接到另一个实体上的输入，该实体告诉它执行其他操作，例如打开灯。有一篇关于 Inputs and Outputs 的文章，请注意，这是一个Source 1的教程，因此链接和细节经常会偏离到不适用于Half-Life:Alyx的主题，但核心理念是相同的。

光照

游戏引擎使用一种模拟光线在现实世界中的反应的方式来渲染物体以使物体表面对光线的反应更加真实。物体的阴影不止可以投射到其他物体上，同样也可投射到其自身表面上。光照是地图的一个重要组成部分，而且恰当地布置光源也是一种艺术。有一篇页面是对光照系统的总览性介绍，你可以阅读光照系统来对它的能力和限制进行了解。

命令控制台

Referred to simply as "the console" it is a command line interface that relays logs and messages back to the user and also accepts many text-based commands for controlling features deep inside the engine. It takes the form of a separate program and with the tools running you can bring it up by pressing the tilde key (~) just below the escape key to the top left of your keyboard, or from the Tools menu in the top right corner of most tool windows.

性能

VR is extremely taxing on system requirements and as such various trade offs must be made when building content inside of Half-Life: Alyx. One of the largest computational costs is rendering a scene, and in this case, two binocular views in high definition at 90 frames per second. Any time the framerate drops, much more so than with games on a flat monitor, missed frames in VR can be pretty obvious and unpleasant. This may cause shimmering at best or painful juddering at worst. The rendering system and shaders in Half-Life: Alyx are specifically engineered to be as efficient as possible but it’s still very possible to overload it.

The adaptive fidelity system used in Half-Life: Alyx will dynamically enable and disable render size and features to get the best possible quality from your hardware but to prevent excessive blurriness it won’t go below a certain level. When running in Tools mode this will be disabled. It will be only enabled in game mode. Proper performance testing of your addon should be done in the game mode (as opposed to running the game with tools loaded in the background).

Here are some potential high cost areas:

• Too much geometry The world can be too detailed and building too detailed of geometry in Hammer or placing too many static props can start causing the framerate to drop. Use the example maps provided as a gauge.

• Expensive lighting – Having too many indexed (baked, precomputed lighting) light sources can all add to the rendering cost. While the lighting system in Half-Life: Alyx is remarkably efficient, misunderstandings and over-expectations can cause significant issues. A general rule of thumb is to not have too many indexed lights shining on any one surface. The hard limit is four, though the game will run more efficiently if there's only one or two indexed lights hitting a surface. Dynamic lights should be used conservatively, and are usually reserved for highly specialized use cases, such as the flashlight.
  提示:There are various visualization modes available in Hammer's 3D view - use the menu at the top right to set 'Tools Visualization Mode' to 'Baked Lighting Complexity'. Black corresponds to zero indexed lights on that surface, red one, orange two, yellow three, white four and cyan is four plus (this should always be avoided as it will cause lighting errors when baking the lighting). There's more information in the lighting overview.
  • If you can, find a user with an entry-level GPU (such as an Nvidia GeForce GTX 1060 or AMD Radeon RX 580 with 6GB VRAM) to test things with as a good baseline to evaluate your map.

For an up-to-date view of current rendering cost, bring up the frame timing window in SteamVR : Settings : Performance : Display Frame Timing. At a very simplistic level, the GPU graph at bottom should stay below 11ms for a 90Hz display, without any non-zero red line popping up at the bottom – if running in game mode, the adaptive fidelity should try to maximize GPU usage, but it should rarely if ever go above 11ms.

提示:Most performance discussions will revolve around milliseconds as opposed to frames per second. It takes marginally over 11ms a frame to maintain 90fps, so 'saving 2ms' is much more meaningful to say than 'saving five frames per second', as the latter gives no indication of the absolute rendering cost saved. Did you start at 10 or 1000 FPS?

If your CPU graph is frequently leaping above 11ms, then there are possibly some other performance costs going on. Here are some potential CPU costs:

• Too many entities – It’s much more likely to be some aspect of the specific entities you have in the map, rather than an overall count of all entities. If you have many more than usual of a certain thing, it may be worth investigating further. For example, a simple box map with a hundred Combine Soldiers may be challenging to render, but it's even more challenging to have all those AI calculate paths, targets, cover locations, and collision with the world.

• Complex rendering – Counter-intuitively, you can have a high rendering cost even if the GPU isn’t maxed out thanks to draw calls. If you have many separate models and/or materials, the CPU has to tell the GPU to render each one, which incurs a cost that goes up the more things you have.

• Complex physics – Having too many physically simulated objects in the scene at the same time can be a significant computational cost – and in particular, having one complex collision hull collide with another can be very expensive, causing severe frame drops. While the example maps may have hundreds of physics objects, not all of them are active at the same time. Keep this in mind when building your addons.

样例地图

一些样例地图被放在了 \Steam\steamapps\common\Half-Life Alyx\content\hlvr\maps。

• workshop_examples 放有一些带有注释的《Half-Life: Alyx》功能演示地图。
• release 放有最终游戏成品的全部地图源文件。

您不应该去自己重新编译游戏成品的地图。完整的音频和光照计算对于一般家用个人电脑来说会消耗大量的时间 - 但你可以通过地图扩展功能来对现有地图增加实体类内容。

文档

最后，欢迎来到Valve Developer Community Wiki！本文档一直都在编写中，并且是由像你一样的的人所建立 - 每个页面都有一个讨论区，而且如果你认为有需求，每个页面都可被编辑和扩写。如果你有任何疑问，请将其发在讨论区 - 如果你有答案，也请发出来！