Vegetation System – Trees

 

The tree system has kept me occupied for a while now.

 

131365048499164085

 

Here are the problems I have with the existing system:

 

  1. Periodic updates – Size.

 

Updating tree’s only once in a while keeps them from destroying your CPU, but it also looks awful. It works fine when they’re just growing at 1x speed, but any time the tree’s try to update faster than that (such as during time accelleration, or when they are dying), it’s obvious that their animation is running at less than 1fps.

 

In order to fix this, I’ve had to completely re-think their growth mechanism. Previously, if a creature ate from it while it was growing, the tree would have to pause it’s growth while it regrew it’s foliage.

 

This isn’t a bad system in and of itself, but it made the size of the tree’s. A tree born at a specific time could grow uninterrupted to full size, or it could have leaves bitten off repeatedly and have to pause each time. So to define it’s scale we need to keep sending it from CPU to GPU.

 

This meant the periodic updates, in order to prevent the sheer number of tree’s from melting your computer (just kidding, I can’t melt your computer. It would explode well before that point).

 

But if it *wasn’t* unpredictable, if we could determine in the shader what scale a tree would be at that moment in time, that would open up different options…

 

So for the new system, instead of a single “scale” value, we’re sending two values to the shader: “TimeOfBirth” and “TimeOfFullGrowth”. Unlike scale, however, these values will never change: a tree will always reach full size at TimeOfFullGrowth.

 

These values are passed to the shader along with a parameter every frame called “currentTime”. Using the tree of them, the shader can smoothly interpolate the tree between it’s minimum and maximum size. Bam! No more periodic updates… well, for size, anyway.

 

  1. Periodic Updates – Consumption.

 

The other big piece of information I kept sending to the trees was their consumption level. This value determines how much foliage they display, and is why you can see tree’s ‘retract’ their leaves as they are consumed.

 

Tree’s will no longer do that in 0.10.0. Instead, tree’s will have exactly 4 consumption states: inedible, edible fiolage, edible fruit, and fallen fruit.

 

treeExamples

 

Tree’s will simply pop between states when their energy level gets high enough. To communicate the contained energy in a tree, then, they will have a set of bars when you hover over them, similar to the ones that appear over a creature when you hover over it.

 

131371100780464801 - Copy

 

The green bar is foliage, the cyan bar is fruit and the yellow bar is fallen fruit.

A bar has to fill up completely before becoming edible (and causing the tree to change states), and empty completely before becoming inedible (and, again, causing the tree to change states).

131371100184058716

Naturally, these states will also have varying attributes. For now, the main difference is that fallen fruit can be reached by any creature regardless of size, allowing even Primum specium to feed off of large trees.

 

Further down the track, foliage will have less carbohydrate and more fibre, and fallen fruit may have some sort of rot or decay associated with it.

 

  1. Growth-rate.

131369714598405604.jpg

Back when I was designing the biome system, I didn’t quite understand the definition of the word “biome”. A biome includes not just the ground cover, but the vegetation and fauna that inhabits it.

 

Obviously the fauna in species can take care of itself: doing any defining of my own on that front would defeat the purpose of the game. But you may have noticed that the ‘biomes’ in Species do a poor job of defining the flora on them. A large area designated “woodland” or “tropical rainforest” by it’s fertility and temperature can be completely devoid of non-grass vegetation.

 

This is because, in Species 0.9.0, tree’s don’t just appear out of nowhere unless the “square” it’s in has no vegetation of the appropriate type. A world-size 1 map is broken up into a 20×20 grid, so a “square” is around 25 pixels wide. You can see the pixel size in the previous post.

 

If the square already has vegetation, the game expects it to reproduce on it’s own. Tree’s reproduce once they reach full size, spawning new tree’s of the same type in a radius around them. Only children that spawn (or ‘seeds that land’) on a viable biome will actually start to grow: a cycad tree won’t grow if it spawns on a savanna biome.

 

This system allows trees to have hereditable and mutable stats: if a blue-tinged tree reproduces, it’s children will also be a close shade of blue. It also allows flora to expand into inhospitable biomes: as they stabilise the ground around them towards their preferred fertility, that provides space for their children to grow.

 

But it has it’s downsides. Suppose you increase the in-game fertility. Massive swaths of desert instantly become ‘woodland’, but it takes a long time for tree’s to start expanding into the region and as they do they are eaten by hungry herbivores. Especially late-game, herbivores can completely strip a map of tree growth.

 

Ideally, trees should be a feature of biomes. If an area is designated ‘woodland’ it should meet a specific density of woodland trees. Inversely, if an area has no trees, it should be desert or grassland.

 

But I also want to keep all the good features of the current system, especially the hereditability side of things (which has a lot of potential for the future). Some idea’s, like a soil seed bank, would potentially put those features at risk.

 

I haven’t come up with any big design-change to address these issues: instead, I’m simply optimising the values of the existing system. Faster regrowth is the obvious one: with the new smooth growth animation, I can afford to amp up growth rates. I’ve lowered the energy content of tree’s to compensate. I’m also attempting to optimize the biome stabilisation with faster fertility decay rates and stronger tree-stabilisation effects, but which only kick in when a tree is dropping fruit.

 

Speaking of the tree stabilisation effects: I got rid of the odd ‘pulsing’ effect by transferring them from shader parameters to sprites, which allows me to handle a lot more of them every frame. This has had some… odd… side effects on the temperature map. Tree’s now stabilise temperature, which can cause things such as tree’s pushing ice away in a large radius, but it’s worth it for the background benefits.

 

And speaking of temperature: large tree’s now have shadows beneath them (like all the shadows in the game, they’re fake: just textured planes overlaid on the ground), and lower the temperature for area’s close to their trunk. This allows creatures to cool down by basking in the shade. The amount of cooldown shade can provide is capped at a few degrees, and does not stack with nearby trees, but I haven’t been able to replicate that for the shadow’s visual appearance. It can get a bit excessive in particularly dense forests.

131369715101530832.jpg

Cheers,

Qu

 

Advertisements
  1. #1 by anon on June 14, 2017 - 1:01 am

    It’s always interesting and entertaining to read this blog. Thanks for the interesting posts here from time-to-time.

  2. #2 by Zulu on June 24, 2017 - 4:32 am

    Very interesting update. I’m glad to see the project improving.

  3. #3 by Charles Jr. Pike on June 27, 2017 - 7:00 am

    I thunk that the best possible solution to the biome problem would be to have inorganic values across the map, and have plants evolve a variety of morphologies to meet the environment just as creatures do– but that would probably be an arse to program within itself.

  4. #4 by White parrot on August 13, 2017 - 10:12 am

    Completely artificial suggestion: since the matter is having fertile areas get seeded quickly, what if the realistic system of waiting for seeds to find their way to the tiles was REVERSED, with empty tiles occasionally (at a semi-randomized rate depending on fertility) “sucking” seeds from trees in range (with various weights, such as distance, to determine which has the best probability to occupy the spot)?

    While it does sound process-consuming at first glance, since it only applies to empty tiles, it would get less and less intensive as the woods get filled.

    Nothing can be done to alleviate the ridiculousness of the premise, however.

    What do you think of this kind of out-of-the-box (to put it lightly) thinking?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: