复古即时战略游戏 - D.O.R.F. - 2022.11.02 - 开发日志
大家好，由于各种原因，上个月对我来说有点失败，我没能像我希望的那样完成这个项目。
人们投票希望看到对当前的基地建设系统进行更多改进，尽管这最终有点问题，因为我想到，由于许多必要的系统尚未到位（即物流系统）和渲染引擎大修），将工作重点放在抛光结构上会有点毫无意义，因为这些即将推出的系统将极大地影响建筑物（和一般精灵）的艺术作品的设计方式。
相反，我决定尝试着手添加新结构。我将从您可能已经在我的一些每周预览视频中看到的内容开始，这些内容是战团派系的一些额外防御选项：
显然游击队的城墙和防御哨不会特别坚固，但可以作为对敌方单位的低级威慑，而火焰喷射塔将作为廉价的反步兵和轻型车辆防御。
在更艰难的一面，我正在为“帝国”派系设计一些额外的防御和支持结构；这些将包括简单的掩体，它们最初的基本功能是增加你的总单位人口上限，并提供一种防御选择，让一些单位驻守在里面，通过窗户向敌方单位开火，但这些建筑物将能够单独升级包括更大的驻军存储空间、增加的人口上限大小，甚至还有一个巨大的通用防御炮塔。
如果你想知道为什么我为这些结构添加了两个角度，那是因为大多数结构在放置时都可以翻转；因为在某些情况下，朝向很重要，例如建筑物的入口/出口面向一个方向，或者对于只能以有限角度射击的固定枪支武器。另外，我喜欢对建筑布局有更多控制的想法；一些较旧的 RTS 有时会遇到这样的问题，即起始位置有利于工厂或资源结构面向特定方向的玩家（例如面向起始资源领域的资源精炼厂）。也正因为我是一个喜欢复杂基地布局的人，这些掩体的某些饰面将“插入”到这个派系的可建造混凝土墙中，以增加基地美学感。
至于其他正在进行的项目，Tovl 继续进行重新设计引擎资源系统的第一阶段工作，该工作应该会在 11 月底之前完成。之后，该项目将转向一个更紧迫的问题；你可能已经注意到了，但我目前展示的大部分预览视频的地形布局都非常乏味。坦率地说，这在很大程度上部分是由于 OpenRA 当前的关卡编辑器很糟糕。或者更确切地说，虽然它适用于真正的 2D RTS 游戏，例如原始的命令与征服，但它对于构建伪 3D/2.5D 游戏（例如 DORF）却很糟糕
2.5D是什么意思？嗯，尽管使用了 sprite，这个 RTS 在技术上支持 3 维运动。悬崖壁或向上和向下的斜坡不仅仅是视觉上的欺骗，它们实际上确实说明了 3 维运动；向斜坡上移动的单位实际上会上升，而向悬崖顶上的单位开火的单位必须举起武器才能准确开火。虽然这个系统有点工作，但地图编辑器并不真正支持放置诸如悬崖和斜坡之类的东西，而且通常使用起来很痛苦（请参阅下面的 GIF，了解在撰写本文时放置地形图块的乐趣）
因此，不仅支持需要 Z 深度因素的地形编辑，还需要其他便利，例如自动 LAT 系统，借用更多命令与征服术语（对于那些好奇的人，LAT 代表L ookup A djacent T ile ).这将通过使地图编辑器包含一个“画家”工具来实现，该工具使您可以简单地将新地形类型绘制到地面上，其中包含一个自动化系统，可以在放置的任何新地形上创建自然过渡地形图块。这变得很复杂，因为会有一些地形资产的大小是多个图块（例如海岸线），所以每块地形都需要分配给它其他地形块的字典，这些地形块将自动围绕任何新的地形放置这个“画家”工具。换句话说，以一种真正方便且不费力的方式放置新的地形类型。
还需要一些其他便利，例如“油漆桶工具”，用于使用相同类型的地形快速填充大面积地形，以及一个可以分配多个资产的工具，选择后会随机掉落每次放置对象时，都会从这个用户生成的字典中获取资产。那有什么用？好吧，目前，如果我想创建一个森林，我需要手动选择并放置每一棵树。这显然不理想，但是使用随机化工具，我可以将这些树分配给一个字典，然后只需在随机化工具中选择该字典，每次我使用该工具放置一个对象时，它都会从该字典中随机选择一棵树在地形上（为了更加方便，可以保存字典并在每次使用地图编辑器时简单地加载）。
另一个要提出的问题：您可能已经注意到Twitter 和 Youtube 上最新的预览视频中存在大量视觉错误。举一些例子，看看这些阴影：
阴影目前是引擎中的一个巨大而丑陋的问题，因为它们经常被切断，奇怪地遮挡在它们下方的物体上，相互重叠，并且总体上看起来很丑陋。虽然我正在为以后的开发博客保存更详细的如何解决这个问题的细目，但简而言之，OpenRA 的渲染引擎需要大量修改以包括动态照明和阴影。考虑到艺术资产的 2D 性质，这听起来像是无稽之谈，但这可以通过给定所有精灵伴随深度精灵（或者法线精灵）来实现，这将允许物体被附近的光源（例如灯柱、枪声）照亮, 普通火等), 并将阴影真实地投射到地形和其他物体上。这将是一项艰巨的任务，但会大大改善游戏的外观并修复大部分这些错误。（顺便说一句，如果你想看看这样一个系统在运行中是什么样子，请查看 Brigador 的镜头，它同样使用 2D 精灵，但添加了深度精灵来确定每个对象的光照和阴影）
另一个不那么复杂（但仍然非常难看）的问题是半透明精灵。长话短说，该引擎也不能很好地处理深度排序和精灵不透明度，并且经常会遮挡半透明像素后面的像素，通常会给一些对象带来讨厌的轮廓效果。
也在这里看到：更恶心的阴影错误。
解决方案更简单；停止在单位上使用半透明像素。虽然半透明像素仍然在烟雾和火焰效果或飞机上的螺旋桨等资产上占有一席之地，但在这种情况下，由于引擎覆盖简化了深度排序并且（简单地说）使这些对象可以正确显示它看起来不错。问题在于，以这种方式打乱深度排序会导致单位和结构（或您可能认为是“实体”的任何对象）的错误，并产生新的问题，例如精灵似乎相互剪裁或被切断以奇怪的方式。所以简而言之，我现有的大部分精灵都必须重新设计，以简单地去除半透明精灵并移除那些丑陋的轮廓（虽然这比听起来容易，但它仍然意味着很多繁琐的工作）。
至此，所有更新到此结束（除了您可能在每周上传到 Youtube 或 Twitter 上看到的内容之外）。我应该补充一点，我将继续研究一些额外的结构（并尝试在游戏中获得现有的新结构），但我将在一周内进行另一次投票，提供更多关于你们接下来可能希望看到的内容的选项。
原文内容
Hello all,
Last month was a bit of a bust for me, for a variety of reasons, and I wasn't able to get as much done on this project as I would have liked.
People voted to want to see more polish put towards the current basebuilding system, though this ended up being a little bit problematic, since it occurred to me that, due to the fact that many necessary systems are not already in place (namely the logistics system and render engine overhaul), focusing work on polishing structures would be a bit pointless, since those upcoming systems will greatly affect how the artwork for the buildings (and sprites in general) are designed.
Instead I decided to try and get to work on adding new structures. I'll start with what you may have already seen in some of my weekly preview videos, which are some additional defensive options for the Warband faction:
Obviously the guerilla faction's walls and defensive posts aren't going to be especially strong, but will work as a low-level deterrent for enemy units, and the flamethrower towers will work as cheap anti-infantry and light vehicle defense.
On the tougher side, I'm working on some additional defensive and support structures for the "Empire" faction; these will include simple bunkers, which initially have a basic function of increasing your total unit population cap and providing a defensive option for garrisoning a few units inside to fire out through the windows at enemy units, but these buildings will be able to be upgraded individually to include things such as a larger garrison storage size, increased population cap size, and even a huge general purpose defensive gun tower.
If you are wondering why I included two angles for these structures, that is because most structures will be able to be flipped when placed; since in some cases, the facing is important, such as the entrance/exit to the building facing in one direction, or for fixed gun weapons that can only fire in a limited angle. Plus I just like the idea of having a bit more control over building placement; some older RTS's would sometimes run into problems where starting positions would favor players whose factories or resource structures face a certain direction (such as a resource refinery facing the starting resource field). Also just because I'm a guy who loves intricate base layouts, certain facings of these bunkers are going to "plug" into the buildable concrete walls for this faction, to give that added sense of base aesthetics.
As for other ongoing projects, Tovl continues work on the first phase of redesigning the engine's resource system, which should be finished before the end of November. After that, the project will shift gears into a more pressing issue; you may have noticed it already, but most of the preview videos I've shown so far have very boring terrain layout. This is largely due in part to the fact that OpenRA's current level editor, quite frankly, sucks. Or rather, while it works fine for true 2D RTS games such as the original Command & Conquer, it sucks for building psuedo-3D/2.5D games such as D.O.R.F.
What does 2.5D mean? Well, despite using sprites, this RTS technically supports 3-dimensional movement. A cliff wall or upward and downward slopes aren't just visual trickery, they actually do in fact account for 3-dimensional movement; a unit moving up a slope will actually ascend, and a unit firing at a unit on top of a cliff will have to elevate its weapon to fire accurately. While this system sort of works, the map editor does not really support placing things such as cliffs and slopes, and in general is a pain to use (see the below GIF for how fun placing terrain tiles is as of this writing)
So not only will support for terrain editing that factors in Z-depth be required, but also other conveniences such as an auto-LAT system, to borrow more Command & Conquer terminology (for those curious, LAT stands for Lookup Adjacent Tile). This would function by making the map editor include a "painter" tool that lets you simply paint new terrain types onto the ground, with an automated system included that creates natural transitionary terrain tiles on any new terrain placed. This gets complicated, since there will be some terrain assets that are multiple tiles in size (such as shorelines), so each piece of terrain would need to have assigned to it dictionary of other terrain pieces that will automatically surround any new terrain placed with this "painter" tool. In other words, placing new terrain types in a way that is actually convenient and not excruciating.
Some other conveniences will be required as well, such as a "paint bucket tool" for rapidly filling in large areas of terrain with the same type of terrain, and a tool that you can assign multiple assets to, that when selected will drop in random assets from this user-generated dictionary every time an object is placed. What is that useful for? Well, currently, if I want to create, say, a forest, I need to select and place every single tree manually. This is not ideal obviously, but with a randomizer tool, I could assign those trees to a dictionary, then just select that dictionary in the randomizer tool, and it will pick a random tree from that dictionary every time I place an object with the tool on the terrain (for added convenience, the dictionary could be saved and simply loaded every time the map editor is used). This has other uses as well, such as placing other types of map doodads, like road signs, rocks, civilian vehicles, etc.
Another issue to bring up: you may have noticed a ton of visual errors in the latest preview video on Twitter and Youtube. To give some examples, check out these shadows:
Shadows are currently a huge, ugly problem in the engine, since they often cut off, shadow the objects beneath them weirdly, double over eachother, and just look hideous in general. While I am saving a more detailed breakdown of how this can be fixed for a later development blog, the short of it is OpenRA's render engine would need to be massively revised to include dynamic lighting and shadowing. While this sounds like nonsense given the 2D nature of the art assets, this could be achieved through given all sprites accompanying depth sprites (or alternatively, normals sprites), which would allow objects to be lit be nearby light sources (such as lampposts, gunfire, regular fire, etc), and cast shadows onto the terrain and onto other objects realistically. This would be a massive undertaking, but would drastically improve the look of the game and fix most of these errors. (as an aside, if you want to see what such a system looks like in action, look up footage of Brigador, which similarly uses 2D sprites but with the addition of depth sprites to determine lighting and shading for each object)
Another less complicated (but still very much ugly) issue is semi-opaque sprites. To make a long story short, the engine also does not handle depth sorting and sprite opacity very well and will often occlude pixels behind semi-opaque pixels, often given some objects a nasty outline effect.
Also seen here: more disgusting shadow errors.
The solution for this is more simple; stop using semi-opaque pixels on units. While semi-opaque pixels still have their place on assets such as smoke and fire effects, or the propellers on a plane, in that case those objects can display properly due to an engine override that simplifies depth sorting and (to put it simply) makes it look good. The issue is that messing with the depth sorting in this way results in errors for units and structures (or any object that you might conceive of as "solid") and creates new problems, such as sprites appearing to clip through eachother or be cut off in strange ways. So the short of it is, most of my existing sprites will have to be reworked to simply shave off the semi-opaque sprites and remove those ugly outlines (though this is easier than it sounds, but it still means a lot of busywork).
So, that concludes any updates so far (outside of what you may have seen on the weekly uploads to Youtube or Twitter). I should add that I will continue working on some additional structures (and trying to get the existing new ones ingame), but I will run another poll in a week with some more options on what you guys might want to see next.
