复古即时战略游戏 - D.O.R.F. - 2023.06.24 - 六月底更新

大家好，

首先，感谢本月初 PC 游戏展活动之后所有额外的支持者。这肯定会有助于资助 DORF 的开发。我们还看到 Steam 页面上的愿望清单数量大幅增加，因此这也非常令人兴奋。

现在开始更新：本月我们无法完成我们希望的那么多额外的民用/环境功能，因此更新的这一部分会有点简短。

首先，我们添加了一些平民和中立生物，只是为了给你已经见过的城镇增添一点额外的味道。这些家伙不会在地图上做太多事情，但就像《命令与征服》中的平民，或者原版《星际争霸》中奇怪的外星生物一样，他们只是在那里为某些地图添加更多气氛。他们大多只是漫无目的地闲逛。

如果你感觉特别虐待狂，他们也可能被枪杀。

我们还对地形动画进行了一些实验，尽管这对使这些动画无缝且令人信服提出了重大挑战。

这些海岸图块实际上是两个图块，尽管我们可能会将它们的大小更改为单个图块，因为难以制作无缝动画的多图块地形块。虽然这些实际上并不像我最初想象的那么难创建（我们没有在 Maya 中进行实际的流体模拟，它们只是在 Sony Vegas 中创建的一系列相互重叠的动画纹理），将所有这些大型动画缝合在一起正确的将是一个巨大的痛苦，因此我们可能会放弃这些更现实的波浪，转而选择更易于创建的东西。

另外，如果您想知道为什么沙子会硬切入草中，那是因为由于有关地形调色板的未解决的错误而尚未创建纯沙瓦片。这将在即将到来的地图编辑器/地形变形大修中得到修复。

现在来谈谈我们本月正在进行的大项目：我之前多次提到过的巨大的动态照明检修。

为了比之前的文章更具技术性，照明将通过几种方式发挥作用。使用延迟着色系统（您可以在这里阅读这意味着什么： https: //en.wikipedia.org/wiki/Deferred_shading），每个 2D 精灵将具有伴随的法线、深度以及我们所说的“微深度精灵” 。

例如，这是您之前见过的动力装置，但有一些变化：

该精灵实际上与您之前看到的精灵不同，因为它使用全局照明设置，因此不会从任何一个方向照亮（这一点在其烟囱上尤其明显），以适应动态照明系统。该精灵（最接近您在实际游戏中看到的精灵）将被称为漫反射精灵。

接下来我们有（有点令人困惑的名称）普通精灵：

如果您熟悉 3D 图形，这应该看起来很熟悉。几乎所有 3D 游戏引擎都使用这些，尽管是纹理形式（您可以在这里获得广泛的概述： https: //en.wikipedia.org/wiki/Normal_mapping），创建 3D 凹痕、突出物和其他小细节的错觉，这些细节实际上并不是它们所附着的 3D 模型的一部分。然而，它们在 DORF 中的使用有点不传统，因为不是将纹理应用于 UV 展开的对象，而是用于创建漫反射精灵的 3D 模型也用于生成普通精灵。本质上，不同的颜色决定了不同的朝向（或者更准确地说，它们用于决定不同的法线，因此是法线精灵），洋红色代表东南面，深蓝色代表西南，青色代表向上，等等。 

正如您可能已经猜到的，这就是它用来确定 2D 精灵的 3 维性的方法，并且允许灯光以 3 维方式照亮它。因此，如果汽车将车头灯对准这个结构，车头灯的形状就会真实地照亮它，而不是像大多数具有动态照明的 2D 游戏那样以体积的形式倒在它上面。

接下来是深度精灵：

与其他两个精灵一样，它来自相同的 3D 模型，其中亮值代表距离相机较近的物体，较暗的值代表距离较远的物体。这将用于帮助确定深度排序。什么是深度排序？好吧，由于游戏资产最终都只是平面上的 2D 剪切图，因此需要某种方法对它们进行排序，以便（例如）步兵从桥下经过，而不是看起来在桥上渲染，或者坦克的炮塔出现在坦克的顶部，而不是在坦克的下方或后面。虽然目前这是使用钝整数值作为偏移量来完成的，但这有其局限性，设置起来很繁琐，并且通常只会导致 Z 战斗（https://en.wikipedia.org/wiki/Z-fighting）或物体在距离另一个单元一定距离时突然与另一个单元的错误部分重叠。

深度精灵稍后还将具有一些附加功能，作为在旋转或上坡时帮助平滑单位的手段，尽管该特定用途超出了当前项目的范围。

最后，我们有“微深度精灵”，或者“微 Z 精灵”或“阴影精灵”。

顾名思义，这些精灵（单独）比上述精灵小得多。它们也是深度精灵，尽管是从不同的角度渲染的，并且以不同的方式使用。本质上，游戏将采用这些精灵，并使用微深度图数据作为对象形状的基础创建一个简单的 3D 网格（可以想象游戏引擎使用这些精灵来确定对象的形状）。这个简单的 3D 网格将用于生成动态阴影。这些阴影也将在某种程度上进行抗锯齿处理，以使它们看起来更柔和，因为网格的粗略形状可能不完全准确于实际的精灵。

这是此更新中最具实验性的部分，如果其性能不佳或导致不寻常或难看的阴影，则可能需要进行更改或限制。该系统也可能不兼容，或者问题太多，无法与动画对象（例如步兵或机甲）一起使用。

最后，也许这是不言而喻的，但该系统也将在每个地图的上下文中使用，允许多个光源，这些光源都可以产生动态阴影。每张地图都会有一个太阳，其强度和颜色可在地图数据中调整，而某些结构（玩家和平民/中立）将有自己的投射灯。尽管如此，由于性能问题，建筑物上很少会连接多个光源，而且大多数建筑物都没有它们。

而且，对于任何询问的人来说，是的，这些功能将能够在游戏设置中单独禁用，因为它们可能会导致较旧、较弱的系统出现性能问题。

目前就这些，但再次感谢大家一直以来的支持。

- 汉斯克

【原文内容】

Hello all,

First off, thanks to all the additional backers that came in after the PC Gaming Show event earlier this month. That will certainly help with financing the development of D.O.R.F. We also saw a pretty significant spike in wishlisting on our Steam page, so that was also pretty exciting to see.

Now onto updates: we weren't able to complete as much of the additional civilian/environmental features as we would have liked this month, so that part of the update will be a little bit brief.

First, we added a few civilians and neutral critters, just to give the towns you've already seen a bit of extra flavor. These guys won't really do much on the map, but like civilians in C&C, or the weird alien critters in the original Starcraft, they're just there to add a bit more atmosphere to certain maps. They mostly just wander around aimlessly.

They can also be shot at and killed, if you are feeling particularly sadistic.

We also got a little bit of work done experimenting with terrain animations, although these pose a significant challenge in making these animations seamless yet also convincing.

These shore tiles are actually two tiles, though we may alter them to be a single tile in size due to the difficulty in making seamlessly animated multi-tile terrain pieces. While these are actually not as difficult to create as I initially thought (we aren't doing actual fluid sims in Maya, they are just a series of animated textures created in Sony Vegas overlaid over eachother), getting all these big animations to seam together correctly is going to be a huge pain, and so we may ditch these more realistic waves in favor of something more manageable to create.

Also, if you are wondering why the sand just hard-cuts into grass, that is due to pure sand tiles not being created yet due to an unresolved bug regarding terrain color palettes. This is something that will be fixed in the upcoming map editor/terrain deformation overhaul.

Now onto the big project we've been taking on this month: the giant dynamic lighting overhaul I've mentioned a few times before.

To get a bit more technical than in previous posts, the lighting will work in a few ways. Using a deferred shading system ( you can read about what that means here: https://en.wikipedia.org/wiki/Deferred_shading ), each 2D sprite will have accompanying normals, depth, and what we are calling "micro depth sprites".

For instance, here is the powerplant you've seen before, though with a few changes:

This sprite actually differs from the one you've seen before, in that it uses an global lighting setup, and so is not being lit from any one direction (this is especially noticeable on its smokestack), in order to accommodate the dynamic lighting system. This sprite (the one that closest resembles what you will see in the actual game) will be referred to as the diffuse sprite.

Next we have the (somewhat confusingly named) normal sprite:

If you are familiar with 3D graphics, this should look familiar. Almost any 3D game engine uses these, albeit in a texture form (you can get a broad overview here: https://en.wikipedia.org/wiki/Normal_mapping ), to create the illusion of 3D indentations, protrusions, and other small details that aren't actually part of the 3D model they are attached to. However, their use in DORF is a little bit unconventional, as rather than a texture applied to a UV-unwrapped object, instead the 3D model used to create the diffuse sprite is also used to generate a normal sprite. Essentially, the different colors determine different facings (or more accurately, they are used to determine different normals, hence normal sprite), with magenta designating a southeastern facing, deep blue designating southwest, cyan designating up, etc. 

As you may have guessed, this is what it used to determine the 3-dimensionality of the 2D sprite, and will allow lighting to illuminate it in a 3-dimensional manner. So if a car points its headlights at this structure, the shape of the headlights will brighten it realistically, rather than falling over it as a volume in the way most 2D games with dynamic lighting do.

Next up is the depth sprite:

As with the other two sprites, this comes from the same 3D model, where light values represent objects closer to the camera, and darker values further away.  This will be used to help determine depth sorting. What is depth-sorting? Well, as the game assets are all ultimately just 2D cutouts on a flat plane, there needs to be some way to sort them, so that (for example) an infantry passes underneath a bridge rather than appearing to render over it, or that a tank's turret appears on top of the tank rather than beneath or behind it. While this is currently done with blunt integer values as an offset, this has its limitations, is tedious to set up, and often just results in Z fighting ( https://en.wikipedia.org/wiki/Z-fighting ) or objects suddenly overlapping the wrong part of another unit when in a certain proximity of it.

The depth sprites will also have some additional functionality later on as a means to help smooth out units when they rotate or move up slopes, though that particular use is out of the scope of the current project.

Lastly, we have "micro depth sprites", alternatively "micro Z sprites" or "shadow sprites".

As the name implies, these sprites are (individually) much smaller than the above sprites. They are also depth sprites, albeit rendered from different angles, and used in a different manner. Essentially, the game will take these sprites, and create a simply 3D mesh using the micro depth map data as a basis for the shape of the object (think of the game engine using these as you would blueprints, to determine the shape of the object). This simple 3D mesh will be used to generate a dynamic shadow. These shadows will also be anti-aliased somewhat to make them appear softer, as the crude shape of the mesh may not be fully accurate to the actual sprite.

This is the most experimental part of this update, and may have to be altered or limited in the event it isn't performant, or results in unusual or bad looking shadows. It's also possible this system will not be compatible, or simply too buggy, to be of use with animated objects, such as infantry or mechs.

Lastly, and maybe this goes without saying, but this system will also be used in the context of each map allowing for multiple light sources that can all case dynamic shadows. Each map will have a sun, with its own intensity and color adjustable in the map data, while some structures, (both player and civilian/neutral) will have their own casting lights. Although, due to performance issues, it's likely that there will rarely be more than a single light source attached to a building, and most buildings will not have them.

And, for anyone asking, yes, these features will be able to be individually disabled in the game settings, as they may cause performance issues on older, weaker systems.

That's all for now, but again, thank you all for your continued support.

- Henske