End of June Update

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