End of April Update - Optimizations

Hello everyone,

As stated last month, our work this month has largely been limited to trying to further optimize the game, as many of the more recent graphical features (such as lights and some of the added particle effects) have put more strain on the game's performance. One of the big ways we plan on doing this is replacing the existing graphics API (OpenGL, a graphics platform that dates back to the 90's) with Vulkan, a far more modern system. Gustas explains:

"At the start of the month, still taking it slow and working with game packaging, finishing it up.  Doing some upstream work, testing various RTS's. Then I went more with optimizing work. I tried instance rendering, learning about the extent of OpenGL 3.3 spec. Later transitioning to investigating how easily we could transition to Vulkan. Then getting it running in a week, with ongoing work now. Past two days I've being absorbing as much insight about Vulkan and the current state of real time rendering from industry leading engineers, getting to know which practices are standard, which are outdated, what's often ignored, as well as learning GPU hardware and investigating platform support."

"Currently I'm thinking of going with Vulkan 1.2. it has basically everything we need. The newest version is 1.4 (from last year) and our hardware currently supports it, but we don't really need the newer features. Blender seems to be going with 1.2. This will probably be good till we get close to finishing. For final stretches we'll probably need to add support for older API's. Vulkan is over 10 years old, and there are a lot of older hardware that also supports it, though, granted 1.1 version wasn't that good."

"It seems standard for engines to use like 4 graphics API's."

Tommy has also spent some time finishing up the physics projectile system and deprecating the old, more primitive projectile system. He has also begun work on improving the weapons blocking system. While we debated about how exactly projectile blocking should work - with there being some cases for making it so projectiles always pass through friendly units, as they do in most RTS games - we decided it would be better to use a system that BAR uses, where unit gunnery can be blocked by friendly units in the way, and blocked units will simply not open fire. This sounds like it could be annoying if done incorrectly, but given D.O.R.F's greater emphasis on unit positioning in combat, it feels more appropriate to handle blocking this way. This will also help with avoiding the common RTS problem of deathball strategies, since chaotic masses of units will just be fodder for well-positioned enemy units. Of course, to avoid the frustration of dealing ordering units into exact firing angles, this system will be supplemented with a basic, Total War-esque unit formations/positioning system, so that units can be quickly ordered to form a firing line to attack from certain positions and angles.


As well as work related to unit attacking logic, guns can now be designed as using indirect fire, and so the gun barrels will actually elevate to account for firing in a parabolic arc. Obviously, this will be quite useful in depicting artillery units, as demonstrated with the hull howitzer on the Heavy Tank below.

I also spent some time finalizing a lot of civilian artwork and getting it ingame. A lot of these models were made ages ago, but were never textured, given damaged variants, shadow meshes and were never actually implemented ingame, so it was still quite a lot of work.

These include not just larger vehicles like busses and semi trucks, but also trailers, such as fuel tankers, freight trailers and mobile homes. They also actually function in that purpose, too.

These aren't just for added map detail, but will also serve a practical game purpose, as civilian vehicles - like the existing scrap piles in the game - can be absconded with by resource units and pulled back to your base to turn into resources. Some trailers will also contain supplies and fuel that can actually be utilized.

I've also begun some reworks on updating the UI to the game, since much of it used placeholder art (some even used placeholders from Tiberian Sun, such as repair and powered down icons from that game). 
 

There's also a few others that have not been implemented yet, though here is a preview of their meshes in Maya:

Outside of the game itself, we are pretty sure we already have our programmer lined up, and are just looking to get the actual legal contractual things sorted out before we formally bring him on, so hopefully development progress should speed up when we get all that in order.

That's all for this month. Next month we'll be continuing working on optimization, finishing up more of the attack logic, and I'll be spending a lot of time replacing a lot of the placeholder art and updating a lot of the outdated unit and building sprites, and of course, getting the new developer up to speed with the game's engine and its ins and outs. We also hope to have a huge overhaul of the game's terrain system fairly soonish, including adding proper cliffs, roads, dynamic water and some of the planned stretch goals like the snow and Megacity terrain, though that most likely won't start until around early Summer.

As always, thank you for all your support.

- John