Biomes and 3D.

Week 30 is over. This week was dedicated to biomifying Dominance map – everything from tweaking the biome generator to displaying the new combined map in the client in some form that’s easy to comprehend.

The Map

Let’s start here. The current map, ignoring placeholder graphics for biomes, should look like this:

You can see two relatively important features – the higher the hex is, the whiter its biome image becomes, and now we have a terrace system for displaying higher elevations.

Yes, the biomes are ugly, this is deliberate. Let’s see a larger picture.

There are about 15 different biomes, granting modifiers as much as you’d expect. A tropical rain forest will penalize terrain lore, but grant bonuses to defense. Being stuck in the snow might affect offensive power as well as terrain lore. These modifiers are not game-changing, deliberately, since you cannot choose where you spawn, and modify off, def, lea and terrain lore with -15 up to +15, no more. Biomes were always a flavor thing.

All of these biomes are now fully coded in and apply each tick onto all avatars. Static installations and the slow-moving caravans gain no bonuses or penalties from biomes underneath them.

Terraces

The terraces were a necessary step towards general map comprehension which added some unexpected challenges to general UI processing.

Say, a player clicks on some pixel. What’s beneath it? Well, so far we always could calculate which hex was beneath since I knew exactly at what coordinates each hex was drawn. But now hexes have offsets – 5 pixels per height level to the “north” and 3 pixels height level to the “west”. So, which hex is beneath the mouse?

I attempted several methods (remember, each has to be blazingly fast) – first was to take the original hex, say “You clicked here”, then take all surrounding hexes, calculate if each of their centers was closer to the mouse than the selected hex’ center and then return the closest one.

This was a disaster. Not all neighbors HAVE height levels. Calculating all of this for every single pixel of mouse movement made the client scrape the CPU and lag horribly.

Then I remembered one cute  intrinsic feature of the dominance map – it slopes very slowly. Sure, it may be possible to find 3 hexes sloping downwards next to each other, but this is rare. So, now the process is much simpler:

  • Player hovers over a pixel.
  • I take the hex that would be there if we didn’t have offsets, then add that hex’ offset to the mouse position – effectively either eliminating the offset completely or in worst case eliminating all except -3, -5 pixels of the offset.
  • Then I look again which hex is beneath and unless the player hovered over those few border pixels the resulting hex will be the correct one.

The terraces generally have issues we’re not even aware of ATM. Targeting an avatar to move blindly into the fog of war might send the avatar to a wrong hex (but the error will never be larger than 1 hex). The client simply lacks the topology to correctly calculate the positions of hexes in the fog, and assumes their height levels are 0. We’ll see if this causes major issues.

New atlases

I’ve dumped the entire idea of pregenerating settlement (and later other) images and because I value my sanity have decided to use the bit slower but much more manageable method of drawing settlements via base image + masks.

For example:

This is an actual atlas of the hamlet. It has the base picture which also serves as the Men variant, and has additional versions in there (a few pixels of difference) for Erol/Haad/Wud. A few masks that define ownership – and two masks that get thrown beneath the sett for hover/select. At most we need to draw 3 of these per 1 map object. It’s small (under 40k) and easy to manage.

That’s it for this week, next week I’m looking into many other “minor” tasks that are yet unresolved.