I am not Qu. I am merely borrowing his name. My true name would drive you all mad and usher in the end of times.
Posted in Uncategorized on June 8, 2017
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.
Posted in Uncategorized on May 25, 2017
The ground cover/grazing system in Species 0.9.0 is a mess, but an interesting mess. It has a lot of strange little redundancies and quirks simply to remain functional. Much like myself, them. I feel a sense of kinship with it.
And so it must die. But let’s talk about it first.
In 0.9.0, when a creature decides to graze, they will always target a point either 200cm or 400cm away from themselves. This completely arbitrary distance makes up for a quirk of the cost-benefit analysis that creatures perform when deciding what to eat: a food source they are already standing on has no cost associated with walking to it. By making them move a distance before grazing, we increase the chances of browsing trees and scavenging corpses, as well as making grazing a slightly more interesting a behaviour.
The point they pick will be the highest ‘value’ point at that distance from them, which prevents them from grazing on desert grass if there’s green grass behind them.
They will then move to that location and begin the graze routine. While grazing, they gradually gain food while emitting a negative fertility aura around themselves. In theory, the negative aura should eventually exhaust the area and force them to seek out new food, preventing them from becoming a completely sessile organism.
This generally works, but the fertility-effect provided by fresh-water in 0.9.0 is extremely strong. In the right place on a ‘lake’ or ‘oasis’ map, a grazer can theoretically remain sessile their entire life.
This quirk, incidentally, is because of the way the underwater biomes work. The water in 0.9.0 is a transparent, blue plane, but the terrain below it isn’t actually tinted blue by water fog or lighting effects. The textures themselves are blue for underwater biomes in order to give the impression of depth. Unfortunately, those textures look really strange if they are uncovered, so a strong fertility-effect forces them to only appear underwater and to rapidly recede when the water does.
Obviously, 0.10.0’s water fog and lighting effects completely negate this need: I’ve changed the underwater biome textures to more generic rock/sand textures, so they won’t be unsightly when uncovered. That in turn free’s us to use a much less powerful fertility effect, which means groundcover re-growth rates on watery maps will be much more in line with what you see on landlocked ones.
Back to sessile grazers.
In order to prevent sessility and to keep creatures moving about, I implemented a time limit to grazing. After a certain number of seconds have passed, a grazer will automatically reconsider their options. If they’re still hungry, they’ll reactivate the grazing routine… and pick a location 200cm or 400cm away from their current one to graze from.
This utterly arbitrary system works… okay, I guess? Better than it has any right to. But frankly, it’s a hack job, a Frankenstein monster of code, and I’ve never been happy with it.
The energy from grazing is extremely inconsistent: a savanna area might provide X calories before being exhausted, or it might never be exhausted due to regrowth if it’s near water or being stabilised by trees. The scale of the aura further increases the inconsistency and general wishy-washyness of grazing. It’s all-but impossible to tell how much grazing ‘energy’ a creature will be able to extract from an area.
So for 0.10.0, this has been completely reworked. Both the arbitrary distance and arbitrary time limit have been removed, and instead of an aura, creatures treat the individual pixels of the ground cover map as food sources.
Each pixel is effectively an extremely low-yield tree.
When a creature eats a pixel, the ground cover instantly reverts to 0 fertility, converting it into the ‘wasteland’ biome. Grazers will need to stay on the move in order to get enough energy from grass, and will leave a trail of consumed ground cover behind them. Large numbers of grazers will still have the ability to turn an area into a wasteland, but it will be the result of lots of small, sharp bites out of the ground cover rather than the large, gentle ‘aura’ bites they were taking before.
For the moment, the ‘scanning’ behaviour prevents super-fast creatures from abusing this mechanic and scything their way across the landscape, absorbing every square of grass along the way. After eating a pixel, creatures re-analyse their needs and environment in order to decide what to do next, and I put them in idle for a second and make them look left and right when they do that. For the moment that’s okay, but I’m thinking of changing it from “scanning” to “chewing” and giving it a variable duration based on head type.
The end result of all is that the energy a creature gains from grazing a pixel is a measurable, quantifiable amount, based on the biome of that pixel, and open to the same optimality calculations as trees and corpses.
It’s also an acknowledgement of the simulations artificiality. You probably noticed the grid overlay in the above screenshots: we’ll be keeping that in 0.10.0. When your mouse is over a ground pixel, (as opposed to a creature or tree), you will be able to see it, as well as it’s energy content (either as a green mini-bar or as a number somewhere on the screen).
In real life, of course, grass isn’t broken up into tiles like this. The system we’ve got in 0.9.0 actually goes to great lengths to blur the grid and hide it’s existence from the user.
But Species isn’t real life, and I’ve come to the conclusion that acknowledging the artificiality of it’s world isn’t a bad thing, especially if it allows me to improve the mechanics upon which the simulation is based.
Besides which, it’s in the tagline. “Artificial Life, Real Evolution.”
Don’t worry though, I’m not about to go all abstract and matrixy on you. Within the context of the game, the game world is the real world, not a simulation. Ground pixels notwithstanding.
Posted in Uncategorized on April 11, 2017
I had the site restored from backup and was just delighted to discover the restored version was a copy of the empty, deleted site. Apparently it took godaddy more than 48 hours to get to my restore request, by which time their system had re-run and overwritten the backup of my site.
So… it’s gone for good. The database is still there, so the most important stuff (community posts) remains safe, and of course I have local copies of the game itself. But there are no copies of the site files left online.
I’m going search my old desktop to see if there are any old backups from when I originally set everything up, but I’m not hopeful. Most likely I’ll have to re-build the site from scratch.
… on the bright side, though, I haven’t lost too much momentum on the development side of things. I’m continuing to overhaul the vegetation system and am making some good progress there. Even if I can’t get the site back for a while yet, I should be able to at least put up some blog posts.
And thusly the forums return to us, like a pheonix rises from the ashes!
Or a zombie arises from the grave!
Or cancer returns after you think you’re- okay I think we’re done with this simile. The forums are back!
Still working on the main site, which is going to take a lot more effort to get back.
The theme I was using, bluemasters, hasn’t been updated to Drupal 8.x, and the alternative themes I was looking at just straight up don’t work for some obscure reason I haven’t been able to work out and that google isn’t giving me the answers to. The css doesn’t seem to be being applied somehow, so you end up with Times New Roman on a white background.
For the record, game development? Nowhere near as painful as website development. So yeah, mad props and/or condolences to the masochistic bastards who do this for a living!
Posted in Uncategorized on April 8, 2017
So how has your Saturday been? I spent all of mine on the phone trying to work out what the hell happened to my goddamn website. This is exactly how I wanted to spend my weekend. So much fun!
Sigh… long story short, malware infected the website. This is part of a pattern of automated attacks we’ve been experiencing this last month, which is doing wonders for my newfound motivation to work on and discuss my plans for the game. /s
As usual, the security system I pay for on the site disabled the problem-code before I even knew about it, and I started the process of getting the site manually cleaned and restored. I’m getting quite familiar with the process, since this is the 4th time it’s happened in the last month.
And then the site files were deleted. Just… gone. FFFFFFFFFFFFFFF-
The database is still there, so don’t panic just yet: your forum posts are safe. And I store donation records separately, so those were never in any danger. What’s gone is the site theme, images, and download files.
I still have no idea why or how: malware doesn’t usually delete shit. What I do know is that my hosting company, godaddy, is making me pay through the nose to restore the site from backup, as well as charging me extra for automated backups in the future, which I thought I already had.
They said the restore could take up to 48 hours, and even then it’ll still be infected and require a clean, so my apologies to all my community members: the site will likely be down for a few days.
Rest assured I will get the site back, but for now I need to go scream into a pillow.
Posted in Uncategorized on April 5, 2017
I’m returning to goal-driven development. Experimenting with an aimless, careening development path provided some benefits: I’ve made tweaks and implemented systems I might not have done otherwise. But, predictably, having a goal and driving towards it is a more productive strategy.
So with that in mind, these are the goals I’ve identified and intend to complete (or already have completed) prior to releasing Species 0.10.0.
Temperature System Overhaul
Check. I still have some balance work and polishing to do (P. specium can’t actually survive to reproduce in the current development build, which is a slight problem) but the foundation is solid.
Also, I was reminded that water feels colder than air because it has a higher thermal conductivity, and not because the water is actually colder. You can thank Klei’s Oxygen Not Included for that. So… I need to make some adjustments to water’s effect on temperature, and to a creatures ability to ‘read’ temperatures in places they want to go, in order to take that difference into account.
There’s still a few edge cases, and they are perhaps going to need a bit more in the way of foresight. “Ooh, there’s food in the water! I’ll just go and- OH GOD THE WATERS FREEZING GETMEOUT GETMEOUT GETMEOU- Ooh, there’s food in the water!”
Although the aforementioned water thermal conductivity change may have an impact on this, so I should look at changing that first.
First things first, I need to crush your hopes and dreams. This isn’t the “evolving plants” overhaul I have planned: that’s still on the backburner for now and considered a low priority.
But some changes are necessary to the current placeholder system, including changes to the way grazing the ground cover works (already implemented and I’m quite happy with them, will discuss in the next blog post), as well as extensive improvements to the mechanisms vegetation uses to grow and re-grow.
The goal is to make vegetation a more consistent feature of the biomes it appears in. This will mean faster growing tree’s, and we’ll be taking away a creatures ability to kill a tree by exhausting it: it will instead enter an inedible state until it regrows.
Additionally, I’m looking at the possibility of foliage/fruit/nuts that fall to the ground, to ensure the larger ‘feature tree’s’ (palm tree’s and pines) are still a relevant part of the environment for creatures that cannot reach their crown.
Oh, and I’m also looking to kill the ‘tree lag’ that comes as a result of only updating vegetation objects once every few seconds. I have a much smoother system in mind.
Mutiselect & God Tool improvements
I spent a fair bit of time implementing a system that allows the game to display multiple selection circles (it uses the same rendering technique as the fake shadows).
Should probably put that to use! What I have planned is…
1. The ability to drag a box around a group of organisms to select them. Or you can click on a single organism and then click a “species” button to select every organism in it’s species. Or you can select trees. The dialog in the bottom right will display relevant information about the current selection, whether that be a creature, group, species, tree or group of tree’s. This should all be far more user friendly than the ‘modes’ we have currently.
2. The ability to heal, feed, move and irradiate entire groups at once. I’ve never been particularly fond of these functions (in the long term I feel like they should be done indirectly, by giving orders to nearby rovers), but while the game remains the sandboxiest of sandboxes I consider them a necessary evil, so I might as well at least make them easy and fun to use.
3. “Suggestion”. The ability to right-click on an object and draw the attention of all your selected creatures to it. So if you right-click on a plant, they will approach it and may start eating it. Similarly, if you right-click on a fellow creature, they might attack it, mate with it, or simply examine it. And if you right-click on the ground, they’ll go there if they don’t have anything better to do.
The is idea is that this isn’t a means of controlling the creatures: you are simply directing their attention. Further, any creature that is distracted by other needs might well ignore your suggestions, or interpret them in a way you’re not expecting. A species you bred in the nursary will be significantly more obedient than a wild one.
Finally, I’ll be implementing a new “Initialise” option to generate a number of Primum litatio and Primum praedator, instead of Primum specium. Together, these two species will form a functional, if basic, predator-prey relationship from the very start of the game.
In addition to simply being a great starting point for a simulation, this option should allow me to rapidly iterate on and balance the game to make predatory behaviour a viable survival strategy. This should in turn make it easier for P. specium‘s descendants to start preying on their cousins.
Posted in Uncategorized on March 14, 2017
A unexpectedly influential addition in 0.10.0 is the addition of a Stamina meter.
I’ll explain why we need it after I explain what it is.
The stamina meter has some basic, functional similarities to the stamina meter you might find in other games: it’s a meter that is used up when creatures do something exhausting, like sprinting or attacking. But it is quite a bit more complex under the hood. Here’s how it works:
Obviously, creatures will use up their stamina when they engage in any ‘exhausting’ action: walking and running, attacking, those sort of things. Less obviously, both the strength/speed of these actions and their stamina cost will be linearly proportional to the creature’s stamina at the time. An exhausted creature will run slower and be weaker than their fully rested counterpart.
This will have several interesting results. A creature which triggers the ‘flee’ response will begin by sprinting as fast as it is able. As it runs it’s stamina will drop, so it will slow down, but also use less stamina. At a certain point, it’s stamina regeneration (metabolism) will reach equilibrium with its run speed: this will be the fastest run speed it is capable of maintaining. A high speed stat won’t necessarily make a creature faster if their stamina regeneration (directly proportional to metabolism) can’t keep up.
Similarly by virtue of how the system works, a creature’s initial attack will be its strongest. This should be a boon to predators, allowing them to kill weaker prey with one blow. I’m also considering add a stamina cost to getting hit, to further advantage the creature that lands the first blow.
Tangent: Speaking of boons to predators, one change I’ve made recently is to significantly reduce all creatures total hitpoints (/10) and increase their damage resistance (x10) to compensate. This will make it less costly for the survivor of a fight to heal damage, making hunting more rewarding.
So, why did I think a stamina bar was necessary? Because of the temperature overhaul mentioned in the last post.
I was thinking about the effects of cold and heat on creatures. None if they’re operating at optimal temperature, damage if they’re exposed to hot or cold extremes… but what about moderate temperatures? Real-life creature’s don’t get hurt from moderate changes in temperature, but they don’t enjoy it either. Besides, the game has far too many causes of damage already: gradual health loss has been my go-to source of selection pressure since 0.4.1, and I really need an alternative.
So I wanted a ‘stage 2’ state for creatures that were hot or cold, but not too hot or cold. In real life, creatures sweat, pant and shiver… all of which are thermoregulation adaptations and have nothing to do with their internal temperature being non-optimal. How do creatures without these adaptations, reptiles and amphibions, respond to non-optimal temperatures?
They sleep. And there’s my answer: mild non-optimal temperatures should make creatures lethargic, and slow them down without actually hurting them or costing them energy.
That realisation lead to the implementation of Stamina as a means to control their speed and cause them fatigue without hurting their health. Their maximum stamina (the orange bar) at any one moment is directly proportional to how close their temperature is to optimal at that moment, so creatures who maintain an optimal temperature will be able to move and attack with far more strength and speed. Additionally, if their temperature is bad enough (freezing/burning to death), they will not be able to move, which is a death sentence even before temperature damage kicks in.
This gets really cool in it’s interactions with other systems: one thing that’s been bothering me is endothermism’s ties to a higher metabolism and more active lifestyle. Originally I assumed I’d need to implement something manually: factoring metabolic heat production into the speed calculations. But with this stamina implementation I don’t need to because those ties are likely to emerge as symptoms of this system. Creatures capable of thermal regulation will naturally be faster and more active by virtue of always operating at their optimal temperature, while their ectothermic counterparts will slow down or speed up based on the current temperature, just like their biological counterparts.
Posted in Uncategorized on March 7, 2017
Every time I feel a bit enthused to come back to write a new blog post I feel obligated to discuss my absence and motivational issues. After all, I can’t just come back and pretend everything is fine. Everything is not fine, I’m having motivational issues. Motivational issues are not fine.
But then I start writing about it and get all introspective and offer solutions and then get self-conscious and realise I’ve made promises in it I may not be able to keep and scrap it all and then the brief period of motivation has passed and so I don’t post anything to the blog. Blargh! I must have written my “comeback” post six times by now. I’ll be honest, I’m sick of writing this post over and over.
So… screw it. I’m not talking about it. This is me not talking about it. I know it might look like I’m talking about it but I’m not. It’s actually just Venus reflected by swamp gas. These are not the droids you are looking for. Have some conveniently distracting pictures:
This is the new (read: months old but I haven’t shown it to anyone yet so that makes it new) underwater shaders in action. Before this the underwater visuals didn’t actually work: going underwater would make the water plane disappear, there was no fog, and the ground was lit the same as abovewater. This was why we had to clamp the camera above the water plane and make creatures swim on the surface.
Of course, this was all implemented when I thought underwater creatures were going to be the major feature of 0.10.0. That’s fallen by the wayside, but the visual improvements are still there and they do improve the general appearance of the game quite a bit.
Aside from the visual improvements, I’ve also implemented a significant upgrade to the temperature system.
In 0.9.0, a creatures energy loss due to temperature was determined simply by comparing the external temperature to their optimal. This works fine for passive temperature adaptations (for example, evolving fur coverings), but it doesn’t allow for them to *respond* to temperature changes. Since they have no thermal inertia, dedicated thermoregulatory behaviors like basking in the sun, splashing in the water or huddling together for warmth are useless. Behaviours like that might temporarily reduce how rapidly they lost energy, but wouldn’t stop other forms of energy loss entirely and would prevent them from seeking food. Ultimately, with the thermal system as simplified as it was, these behaviors would be a complete waste of time and energy for the creatures engaging in them.
So I added thermal inertia to the system, followed rapidly by a metabolic heat production gene, which for now I’m calling “endothermism” even though that’s actually a misnomer. Endothermism also ties in with optimal metabolic temperature: as a placeholder, I’ve set it to 38 degrees (human operating temperature) for 1.0 endotherms’s, and 28 degree’s (arbitrarily chosen) for 0.0 ectotherms’s.
(I’ll note that the things I’m writing here are driving biothermal regulation experts into a frothing rage, but they kinda deserve it for making their field needlessly opaque with polysyllabic words. I DON’T BELIEVE “POIKILOTHERMIC” IS A REAL WORD)
Insulation was sort of already there in the game, so naturally I completely removed it and started over. Although I did use it’s values to help work out some of the new insulation values for the various furs and skins.
All of this is extra complexity, but it’s for a good cause: with it, we can implement the thermal regulation behaviours I mentioned before. So for example, an endothermic creature can “huddle”. Huddling decreases surface area, which increases insulation, which can be an effective way to increase the body temperature of endotherms. Joining an existing huddle is even more effective.
Other implemented behaviours are “Basking in sun” and “Basking in shade”. The “bask” action increases their surface area, meaning they reach equilibrium with the outside temperature sooner. Swimming also provides cooling, simply due to the cooler temperatures of the water: I haven’t gotten to the point of implementing it as a seperate behaviour yet (and suspect I may not need to, since creatures naturally understand to move towards cold area’s like water when they’re hot).
Speaking of water temperatures, I’ve been trying to work out what temperature the water should be in relation to the atmosphere. I initially implemented it as a constant “AirTemperature – 10”, but that’s not good enough. The deep sea supports homeothermic creatures precisely because it is always a constant temperature, so depth needs to be factored in. But depth doesn’t acutally matter unless the creatures can movement up and down on the Y axis, and I haven’t even decided yet whether I want P. specium to float or crawl along the seabed.
In short, progress may be slow but it is still being made! More info to come soon.