大家好，由于各種原因，上個(gè)月對我來說有點(diǎn)失敗，我沒能像我希望的那樣完成這個(gè)項(xiàng)目。

人們投票希望看到對當(dāng)前的基地建設(shè)系統(tǒng)進(jìn)行更多改進(jìn)，盡管這最終有點(diǎn)問題，因?yàn)槲蚁氲?，由于許多必要的系統(tǒng)尚未到位（即物流系統(tǒng)）和渲染引擎大修），將工作重點(diǎn)放在拋光結(jié)構(gòu)上會有點(diǎn)毫無意義，因?yàn)檫@些即將推出的系統(tǒng)將極大地影響建筑物（和一般精靈）的藝術(shù)作品的設(shè)計(jì)方式。

相反，我決定嘗試著手添加新結(jié)構(gòu)。我將從您可能已經(jīng)在我的一些每周預(yù)覽視頻中看到的內(nèi)容開始，這些內(nèi)容是戰(zhàn)團(tuán)派系的一些額外防御選項(xiàng)：

顯然游擊隊(duì)的城墻和防御哨不會特別堅(jiān)固，但可以作為對敵方單位的低級威懾，而火焰噴射塔將作為廉價(jià)的反步兵和輕型車輛防御。

在更艱難的一面，我正在為“帝國”派系設(shè)計(jì)一些額外的防御和支持結(jié)構(gòu)；這些將包括簡單的掩體，它們最初的基本功能是增加你的總單位人口上限，并提供一種防御選擇，讓一些單位駐守在里面，通過窗戶向敵方單位開火，但這些建筑物將能夠單獨(dú)升級包括更大的駐軍存儲空間、增加的人口上限大小，甚至還有一個(gè)巨大的通用防御炮塔。

如果你想知道為什么我為這些結(jié)構(gòu)添加了兩個(gè)角度，那是因?yàn)榇蠖鄶?shù)結(jié)構(gòu)在放置時(shí)都可以翻轉(zhuǎn)；因?yàn)樵谀承┣闆r下，朝向很重要，例如建筑物的入口/出口面向一個(gè)方向，或者對于只能以有限角度射擊的固定槍支武器。另外，我喜歡對建筑布局有更多控制的想法；一些較舊的 RTS 有時(shí)會遇到這樣的問題，即起始位置有利于工廠或資源結(jié)構(gòu)面向特定方向的玩家（例如面向起始資源領(lǐng)域的資源精煉廠）。也正因?yàn)槲沂且粋€(gè)喜歡復(fù)雜基地布局的人，這些掩體的某些飾面將“插入”到這個(gè)派系的可建造混凝土墻中，以增加基地美學(xué)感。


至于其他正在進(jìn)行的項(xiàng)目，Tovl 繼續(xù)進(jìn)行重新設(shè)計(jì)引擎資源系統(tǒng)的第一階段工作，該工作應(yīng)該會在 11 月底之前完成。之后，該項(xiàng)目將轉(zhuǎn)向一個(gè)更緊迫的問題；你可能已經(jīng)注意到了，但我目前展示的大部分預(yù)覽視頻的地形布局都非常乏味。坦率地說，這在很大程度上部分是由于 OpenRA 當(dāng)前的關(guān)卡編輯器很糟糕?；蛘吒_切地說，雖然它適用于真正的 2D RTS 游戲，例如原始的命令與征服，但它對于構(gòu)建偽 3D/2.5D 游戲（例如 DORF）卻很糟糕

2.5D是什么意思？嗯，盡管使用了 sprite，這個(gè) RTS 在技術(shù)上支持 3 維運(yùn)動。懸崖壁或向上和向下的斜坡不僅僅是視覺上的欺騙，它們實(shí)際上確實(shí)說明了 3 維運(yùn)動；向斜坡上移動的單位實(shí)際上會上升，而向懸崖頂上的單位開火的單位必須舉起武器才能準(zhǔn)確開火。雖然這個(gè)系統(tǒng)有點(diǎn)工作，但地圖編輯器并不真正支持放置諸如懸崖和斜坡之類的東西，而且通常使用起來很痛苦（請參閱下面的 GIF，了解在撰寫本文時(shí)放置地形圖塊的樂趣）

因此，不僅支持需要 Z 深度因素的地形編輯，還需要其他便利，例如自動 LAT 系統(tǒng)，借用更多命令與征服術(shù)語（對于那些好奇的人，LAT 代表L ookup A djacent T ile ).這將通過使地圖編輯器包含一個(gè)“畫家”工具來實(shí)現(xiàn)，該工具使您可以簡單地將新地形類型繪制到地面上，其中包含一個(gè)自動化系統(tǒng)，可以在放置的任何新地形上創(chuàng)建自然過渡地形圖塊。這變得很復(fù)雜，因?yàn)闀幸恍┑匦钨Y產(chǎn)的大小是多個(gè)圖塊（例如海岸線），所以每塊地形都需要分配給它其他地形塊的字典，這些地形塊將自動圍繞任何新的地形放置這個(gè)“畫家”工具。換句話說，以一種真正方便且不費(fèi)力的方式放置新的地形類型。

還需要一些其他便利，例如“油漆桶工具”，用于使用相同類型的地形快速填充大面積地形，以及一個(gè)可以分配多個(gè)資產(chǎn)的工具，選擇后會隨機(jī)掉落每次放置對象時(shí)，都會從這個(gè)用戶生成的字典中獲取資產(chǎn)。那有什么用？好吧，目前，如果我想創(chuàng)建一個(gè)森林，我需要手動選擇并放置每一棵樹。這顯然不理想，但是使用隨機(jī)化工具，我可以將這些樹分配給一個(gè)字典，然后只需在隨機(jī)化工具中選擇該字典，每次我使用該工具放置一個(gè)對象時(shí)，它都會從該字典中隨機(jī)選擇一棵樹在地形上（為了更加方便，可以保存字典并在每次使用地圖編輯器時(shí)簡單地加載）。

另一個(gè)要提出的問題：您可能已經(jīng)注意到Twitter 和 Youtube 上最新的預(yù)覽視頻中存在大量視覺錯(cuò)誤。舉一些例子，看看這些陰影：

陰影目前是引擎中的一個(gè)巨大而丑陋的問題，因?yàn)樗鼈兘?jīng)常被切斷，奇怪地遮擋在它們下方的物體上，相互重疊，并且總體上看起來很丑陋。雖然我正在為以后的開發(fā)博客保存更詳細(xì)的如何解決這個(gè)問題的細(xì)目，但簡而言之，OpenRA 的渲染引擎需要大量修改以包括動態(tài)照明和陰影?？紤]到藝術(shù)資產(chǎn)的 2D 性質(zhì)，這聽起來像是無稽之談，但這可以通過給定所有精靈伴隨深度精靈（或者法線精靈）來實(shí)現(xiàn)，這將允許物體被附近的光源（例如燈柱、槍聲）照亮, 普通火等), 并將陰影真實(shí)地投射到地形和其他物體上。這將是一項(xiàng)艱巨的任務(wù)，但會大大改善游戲的外觀并修復(fù)大部分這些錯(cuò)誤。（順便說一句，如果你想看看這樣一個(gè)系統(tǒng)在運(yùn)行中是什么樣子，請查看 Brigador 的鏡頭，它同樣使用 2D 精靈，但添加了深度精靈來確定每個(gè)對象的光照和陰影）

另一個(gè)不那么復(fù)雜（但仍然非常難看）的問題是半透明精靈。長話短說，該引擎也不能很好地處理深度排序和精靈不透明度，并且經(jīng)常會遮擋半透明像素后面的像素，通常會給一些對象帶來討厭的輪廓效果。

也在這里看到：更惡心的陰影錯(cuò)誤。

解決方案更簡單；停止在單位上使用半透明像素。雖然半透明像素仍然在煙霧和火焰效果或飛機(jī)上的螺旋槳等資產(chǎn)上占有一席之地，但在這種情況下，由于引擎覆蓋簡化了深度排序并且（簡單地說）使這些對象可以正確顯示它看起來不錯(cuò)。問題在于，以這種方式打亂深度排序會導(dǎo)致單位和結(jié)構(gòu)（或您可能認(rèn)為是“實(shí)體”的任何對象）的錯(cuò)誤，并產(chǎn)生新的問題，例如精靈似乎相互剪裁或被切斷以奇怪的方式。所以簡而言之，我現(xiàn)有的大部分精靈都必須重新設(shè)計(jì)，以簡單地去除半透明精靈并移除那些丑陋的輪廓（雖然這比聽起來容易，但它仍然意味著很多繁瑣的工作）。

至此，所有更新到此結(jié)束（除了您可能在每周上傳到 Youtube 或 Twitter 上看到的內(nèi)容之外）。我應(yīng)該補(bǔ)充一點(diǎn)，我將繼續(xù)研究一些額外的結(jié)構(gòu)（并嘗試在游戲中獲得現(xiàn)有的新結(jié)構(gòu)），但我將在一周內(nèi)進(jìn)行另一次投票，提供更多關(guān)于你們接下來可能希望看到的內(nèi)容的選項(xiàng)。

原文內(nèi)容

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.