The tree system has kept me occupied for a while now.
Here are the problems I have with the existing system:
- 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.
- 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.
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.
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).
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.
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.