大家好，

首先，感謝本月初 PC 游戲展活動(dòng)之后所有額外的支持者。這肯定會(huì)有助于資助 DORF 的開發(fā)。我們還看到 Steam 頁(yè)面上的愿望清單數(shù)量大幅增加，因此這也非常令人興奮。

現(xiàn)在開始更新：本月我們無(wú)法完成我們希望的那么多額外的民用/環(huán)境功能，因此更新的這一部分會(huì)有點(diǎn)簡(jiǎn)短。

首先，我們添加了一些平民和中立生物，只是為了給你已經(jīng)見(jiàn)過(guò)的城鎮(zhèn)增添一點(diǎn)額外的味道。這些家伙不會(huì)在地圖上做太多事情，但就像《命令與征服》中的平民，或者原版《星際爭(zhēng)霸》中奇怪的外星生物一樣，他們只是在那里為某些地圖添加更多氣氛。他們大多只是漫無(wú)目的地閑逛。

如果你感覺(jué)特別虐待狂，他們也可能被槍殺。

我們還對(duì)地形動(dòng)畫進(jìn)行了一些實(shí)驗(yàn)，盡管這對(duì)使這些動(dòng)畫無(wú)縫且令人信服提出了重大挑戰(zhàn)。

這些海岸圖塊實(shí)際上是兩個(gè)圖塊，盡管我們可能會(huì)將它們的大小更改為單個(gè)圖塊，因?yàn)殡y以制作無(wú)縫動(dòng)畫的多圖塊地形塊。雖然這些實(shí)際上并不像我最初想象的那么難創(chuàng)建（我們沒(méi)有在 Maya 中進(jìn)行實(shí)際的流體模擬，它們只是在 Sony Vegas 中創(chuàng)建的一系列相互重疊的動(dòng)畫紋理），將所有這些大型動(dòng)畫縫合在一起正確的將是一個(gè)巨大的痛苦，因此我們可能會(huì)放棄這些更現(xiàn)實(shí)的波浪，轉(zhuǎn)而選擇更易于創(chuàng)建的東西。

另外，如果您想知道為什么沙子會(huì)硬切入草中，那是因?yàn)橛捎谟嘘P(guān)地形調(diào)色板的未解決的錯(cuò)誤而尚未創(chuàng)建純沙瓦片。這將在即將到來(lái)的地圖編輯器/地形變形大修中得到修復(fù)。

現(xiàn)在來(lái)談?wù)勎覀儽驹抡谶M(jìn)行的大項(xiàng)目：我之前多次提到過(guò)的巨大的動(dòng)態(tài)照明檢修。

為了比之前的文章更具技術(shù)性，照明將通過(guò)幾種方式發(fā)揮作用。使用延遲著色系統(tǒng)（您可以在這里閱讀這意味著什么： https: //en.wikipedia.org/wiki/Deferred_shading），每個(gè) 2D 精靈將具有伴隨的法線、深度以及我們所說(shuō)的“微深度精靈” 。

例如，這是您之前見(jiàn)過(guò)的動(dòng)力裝置，但有一些變化：

該精靈實(shí)際上與您之前看到的精靈不同，因?yàn)樗褂萌终彰髟O(shè)置，因此不會(huì)從任何一個(gè)方向照亮（這一點(diǎn)在其煙囪上尤其明顯），以適應(yīng)動(dòng)態(tài)照明系統(tǒng)。該精靈（最接近您在實(shí)際游戲中看到的精靈）將被稱為漫反射精靈。

接下來(lái)我們有（有點(diǎn)令人困惑的名稱）普通精靈：

如果您熟悉 3D 圖形，這應(yīng)該看起來(lái)很熟悉。幾乎所有 3D 游戲引擎都使用這些，盡管是紋理形式（您可以在這里獲得廣泛的概述： https: //en.wikipedia.org/wiki/Normal_mapping），創(chuàng)建 3D 凹痕、突出物和其他小細(xì)節(jié)的錯(cuò)覺(jué)，這些細(xì)節(jié)實(shí)際上并不是它們所附著的 3D 模型的一部分。然而，它們?cè)?DORF 中的使用有點(diǎn)不傳統(tǒng)，因?yàn)椴皇菍⒓y理應(yīng)用于 UV 展開的對(duì)象，而是用于創(chuàng)建漫反射精靈的 3D 模型也用于生成普通精靈。本質(zhì)上，不同的顏色決定了不同的朝向（或者更準(zhǔn)確地說(shuō)，它們用于決定不同的法線，因此是法線精靈），洋紅色代表東南面，深藍(lán)色代表西南，青色代表向上，等等。?

正如您可能已經(jīng)猜到的，這就是它用來(lái)確定 2D 精靈的 3 維性的方法，并且允許燈光以 3 維方式照亮它。因此，如果汽車將車頭燈對(duì)準(zhǔn)這個(gè)結(jié)構(gòu)，車頭燈的形狀就會(huì)真實(shí)地照亮它，而不是像大多數(shù)具有動(dòng)態(tài)照明的 2D 游戲那樣以體積的形式倒在它上面。

接下來(lái)是深度精靈：

與其他兩個(gè)精靈一樣，它來(lái)自相同的 3D 模型，其中亮值代表距離相機(jī)較近的物體，較暗的值代表距離較遠(yuǎn)的物體。這將用于幫助確定深度排序。什么是深度排序？好吧，由于游戲資產(chǎn)最終都只是平面上的 2D 剪切圖，因此需要某種方法對(duì)它們進(jìn)行排序，以便（例如）步兵從橋下經(jīng)過(guò)，而不是看起來(lái)在橋上渲染，或者坦克的炮塔出現(xiàn)在坦克的頂部，而不是在坦克的下方或后面。雖然目前這是使用鈍整數(shù)值作為偏移量來(lái)完成的，但這有其局限性，設(shè)置起來(lái)很繁瑣，并且通常只會(huì)導(dǎo)致 Z 戰(zhàn)斗（https://en.wikipedia.org/wiki/Z-fighting）或物體在距離另一個(gè)單元一定距離時(shí)突然與另一個(gè)單元的錯(cuò)誤部分重疊。

深度精靈稍后還將具有一些附加功能，作為在旋轉(zhuǎn)或上坡時(shí)幫助平滑單位的手段，盡管該特定用途超出了當(dāng)前項(xiàng)目的范圍。

最后，我們有“微深度精靈”，或者“微 Z 精靈”或“陰影精靈”。

顧名思義，這些精靈（單獨(dú)）比上述精靈小得多。它們也是深度精靈，盡管是從不同的角度渲染的，并且以不同的方式使用。本質(zhì)上，游戲?qū)⒉捎眠@些精靈，并使用微深度圖數(shù)據(jù)作為對(duì)象形狀的基礎(chǔ)創(chuàng)建一個(gè)簡(jiǎn)單的 3D 網(wǎng)格（可以想象游戲引擎使用這些精靈來(lái)確定對(duì)象的形狀）。這個(gè)簡(jiǎn)單的 3D 網(wǎng)格將用于生成動(dòng)態(tài)陰影。這些陰影也將在某種程度上進(jìn)行抗鋸齒處理，以使它們看起來(lái)更柔和，因?yàn)榫W(wǎng)格的粗略形狀可能不完全準(zhǔn)確于實(shí)際的精靈。

這是此更新中最具實(shí)驗(yàn)性的部分，如果其性能不佳或?qū)е虏粚こ；螂y看的陰影，則可能需要進(jìn)行更改或限制。該系統(tǒng)也可能不兼容，或者問(wèn)題太多，無(wú)法與動(dòng)畫對(duì)象（例如步兵或機(jī)甲）一起使用。

最后，也許這是不言而喻的，但該系統(tǒng)也將在每個(gè)地圖的上下文中使用，允許多個(gè)光源，這些光源都可以產(chǎn)生動(dòng)態(tài)陰影。每張地圖都會(huì)有一個(gè)太陽(yáng)，其強(qiáng)度和顏色可在地圖數(shù)據(jù)中調(diào)整，而某些結(jié)構(gòu)（玩家和平民/中立）將有自己的投射燈。盡管如此，由于性能問(wèn)題，建筑物上很少會(huì)連接多個(gè)光源，而且大多數(shù)建筑物都沒(méi)有它們。

而且，對(duì)于任何詢問(wèn)的人來(lái)說(shuō)，是的，這些功能將能夠在游戲設(shè)置中單獨(dú)禁用，因?yàn)樗鼈兛赡軙?huì)導(dǎo)致較舊、較弱的系統(tǒng)出現(xiàn)性能問(wèn)題。

目前就這些，但再次感謝大家一直以來(lái)的支持。

- 漢斯克

【原文內(nèi)容】

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