These past two weeks we focused on terrain generation and visuals; we produced 4 versions ending up in v0.28.2. Get it now if you haven't!
Procedural Vegetation Placement
Spent quite a bit of time improving the “plains” biome, placing grass and rock objects on them. That may sound simple, but it required a lot of trial and error tweaking the number of objects (to obtain an adequate performance) and their placement (to look organic and nice).
While it already looks much better, we still need to do some work in the terrain texturing; we did some tweaks already in the strength of the normals, and changing the textures we were using, but it is still too random and patchy. We need to have it match more with the placed vegetation and the surrounding features.
Looking for a way to place the new vegetation, as well as to cover the forest biomes with trees (something that was left in a weird state after previous weeks’ changes on the biome placement), led me to make a big refactor on how the vegetation was placed in the map. There were two different algorithms being used; the first one (“brute-force”) seeded the map randomly with trees and then “grew” in almost random directions from the seeded trees, and required a control structure to prevent placing too many trees clumped together (these collisions were expected due to the lack of control on the growth). It provided good, organic results, but there was too little control which caused issues when trying to match it with another feature (like the biomes map), and overall I hate brute-force approaches personally.
The other, more recent algorithm, used cellular automata to simulate the growth. It had more control but its performance was far too slow because of the overall size of the map and the resolution of the vegetation grid. I could have made it work by subdividing the map but that would probably have brought additional complexities in the intersections.
So, I decided to replicate an algorithm I was already using for the height map generation, making it a bit more generic. It’s a mix of the two previously described, with objects being seeded into the vegetation grid, but instead of having a C.A. run thru all the matrix (expensive!), the seeded objects are added to a queue, which is processed checking each object for growth into the adjacent cells (with a % chance). When a cell grows, it gets added to a new queue, repeating the process a number of times. This, together with making the final location of the objects a bit fuzzy so that they don’t look like they are aligned in a grid, seemed to bring the best of both worlds together.
I used this not only for vegetation but also for rock objects; I’m not completely happy with how they currently look though… we still need to do some work in their visuals for them to blend together with the terrain.
Yet another third big refactor was needed to make it easier to add new types of vegetation to the generator without having to duplicate boilerplate code to load the new prefabs correctly; all these refactors also allowed fixing these cases where a single tree stood in the middle of the map and acted as if it was a forest since now the check is made versus the map of biomes.
Terrain Visuals – Vegetation
In addition to the placement of the objects in the map, a lot of time was invested to make these objects look nice in our overhead perspective and dynamic lighting conditions. This involved a lot of experimentation with the different assets our artist had created, selecting which ones worked, and tweaking the shaders to be used and their parameters (balancing their level of detail with our camera distance).
Another small but important change that was made, was tweaking the material of the existing forest trees, for them to be much less reflective and thus appear darker and greener for most situations. We probably changed them as part of the many iterations of visual tweaks and didn’t notice how bright they looked. So now they make the entire landscape look closer to the are we are referencing (the high Andes)
New Enemy Unit! Conquistador Cavalry
The Conquistador Cavalry is a quick unit with a high attack that shows up in the later stages of the invasion and will test the skills of the player. In their current shape, they are already formidable enemies, but we will be adding a special attack for it in upcoming versions, making it even more dangerous as it charges thru your ranks giving you little chance to strike back.
Performance improvements
While wrestling with the addition of more objects for the plains, I noticed a small tiny thing that was causing a tremendous performance overhead; the clipping plane of our camera was set way too deep, much more than we needed! just by changing it a little bit we are culling the rendered objects by about 80%. We still need to do a lot to improve the performance (including optimizing the shadow casters, but this should help a lot already especially in lower spec machines.
Also, since the addition of the detailed grass means more objects are being rendered, I restricted it to the High and Ultra graphic levels.
Unit portraits
We are experimenting with adding weapons to the portraits of the units; this may allow the player to more quickly differentiate them when seeing them on a list, and also increases variety, however, I’m still evaluating how clumped they may make the lists look versus just having an item for the unit type.
Finally, I changed the portrait composer so that Guecha Warriors are generated with short or shaved hair, based on historical resources.
Upcoming mysteries!
We continue working on an additional unit, still being designed and conceptualized, hopefully, we’ll be able to reveal more in the next update.
We are also already ideating the next scenario on the NovaMundi series and are pretty excited about it. We will release more info about it when it starts taking shape.