Game engine ?

[Ciriak]

Hello team, very hyped about the project !

What Engine / tools are you using ?

[D353RT_H4WK]

OpenRA

[DORFdev]

The game uses a heavily modified version of OpenRA. Most graphics are created by creating 3D models and then rendering them from an isometric perspective in Maya Autodesk.

[E Pluribus Unum]

It's cool how sourceports are being used as a jumping-off point for original retro-style games. First GZDoom, now RA2, I wonder what's next, OpenMW?

[cdcool]

Originally posted by DORFdev:

The game uses a heavily modified version of OpenRA. Most graphics are created by creating 3D models and then rendering them from an isometric perspective in Maya Autodesk.

I would like to get on the Beta if possible, look good!
Cedric
Chief Admin
https://www.facebook.com/groups/computer.war.exploration.games

[Bounty Hunter]

Originally posted by DORFdev:

The game uses a heavily modified version of OpenRA. Most graphics are created by creating 3D models and then rendering them from an isometric perspective in Maya Autodesk.

OpenRA? Then I hope that your game will officially support Linux.
OpenRA works great on Linux.
https://www.openra.net/download/
I see Linux's logo.

[Exar kun]

To add to the question about the game engine, won't the updates for OPENRA be retroactive for D.O.R.F. or has heavy modding made that impossible? Another thing is loading a save in OPENRA starts as a replay from the very beginning until the replay is "finished" in the background when it reaches the save point but its pretty slow and clunky for long games, have you optimized it so thats no longer the case?

[DORFdev]

Originally posted by Exar kun:

To add to the question about the game engine, won't the updates for OPENRA be retroactive for D.O.R.F. or has heavy modding made that impossible? Another thing is loading a save in OPENRA starts as a replay from the very beginning until the replay is "finished" in the background when it reaches the save point but its pretty slow and clunky for long games, have you optimized it so thats no longer the case?

D.O.R.F. was forked from OpenRA over a year ago, so many of the updates to the engine will most likely not be applied to D.O.R.F. Of course there are still many efficiency and optimization updates we will still add to D.O.R.F, so do not assume a lot of the issues with pathing and performance will remain in the final product.

[Sunday Driver]

I love the idea of Boomer Strategy blossoming like Boomer Shooters have.

[zeMantras]

Finally after more than a decade, a actual full game made with Open RA. goodluck

[Hochleistungschiller]

I don't know much about the details / limitations of the engine, but are you limited in color depth by using OpenRA by chance? Just curious, since screenshots (and especially unit portraits) look 8-bit, I don't know if that was intentional for artistic reasons, or if it was due to engine limitation. Does that also affect the ongoing work with 2.5D shader?

[DORFdev]

Originally posted by Hochleistungschiller:

I don't know much about the details / limitations of the engine, but are you limited in color depth by using OpenRA by chance? Just curious, since screenshots (and especially unit portraits) look 8-bit, I don't know if that was intentional for artistic reasons, or if it was due to engine limitation. Does that also affect the ongoing work with 2.5D shader?

Both engines actually allow for 8-bit PNG, although in D.O.R.F.'s case, some assets (basically all useable units and buildings) are limited to 256 colors so as to be recolored at runtime to display the team's color. Some of these may need to be revised though, as some assets made a pretty inefficient use of color palettes.

As for the ongoing work with adding lighting/shading in real time, this affects sprites insofar as this system doesn't fully support anti-aliased sprites/semi-opaque pixels, so all assets now (save for effects like dust and explosions) need to be redone to be fully aliased. This is fine anyway, since the previous quasi-anti-aliased look was terrible and just resulted in sprites having an ugly outline that was always either too light or too dark.

Also as you may have guessed, this now means every sprite now needs an accompanying sprite to support the psuedo-3D effects of dynamic lighting. Thankfully our programmers recently devised a clever system that can successfully merge all the XY normal data, Z depth data, and specularity data into a single RGBA image, meaning that all units will only require a diffuse sprite and a secondary auxiliary sprite that contains all the lighting and depth data, rather than keep the latter as 3 separate sprite types, which would absolutely hog VRAM.