0.5.0 Development Thread

[Quasar]

The 0.5.0 release: Environmentalists Overhaul.

Aim: to make the environment of species much more dynamic and responsive, encouraging adaptability and making the game feel much less static and boring (also prettier).

Green is Implemented,
Black is Planned,
Blue is In-Progress.


Developments
Biome system (Everything from rainforests to tundra to coral-reefs to lava-plains)

• - - - - Dynamic temperature/humidity map
  - - - - Real-time terrain multi-texturing with more than 4 ground textures.
  - - - - Moddable Biomes, mapped to temperature/humidity in a format similar to the well known Whittaker Diagram
  - - - - Changeable over time: can animate.
  - - - - Responsiven to in-game factors, like grazing and tree-eating.

Individual Trees (3-Dimensional and Biome Dependant)

• - - - - Lots more variety (beyond the current 6 tree types)
  - - - - Moddable Tree Stats (beyond energy capacity and size), to allow for potential future features like perching, shade, different types of trees (fruit vs leaves), etc.
  - - - - Tree Placement, Type and Frequency dependant on what is specified in Biome Stats.
  - - - - Tree types on biomes that don't support them die out and regrow as valid types.
  - - - - Instanced 3D Models instead of Billboards.
  - - - - Alpha maps used to make their foliage and/or fruit disappear and reappear as they are eaten, rather than growing and shrinking as they currently do.

Grazing (New food source, completely changing the selection pressures)

• - - - - Visual - Grass billboards, dependant on biomes
  - - - - Replace the Idle behavior with a grazing behavior.
  - - - - Change from generic 'Trees' to 'Fruit Trees', making them more appealing to omnivores and even some carnivores.
  - - - - Refit the Herbivore/Carnivore range to make full-herbivores the only ones who can graze efficiently.
  - - - - Make grazing decrease the fertility (ie. Humidity) of the local area, meaning that excessive grazing will render the ground barren and force creatures to migrate.
  - - - - Tweak grazing efficiency and fertility loss to make it invariably inefficient, but still a potential survival strategy in the right climate

Water (oceans are cool)

• - - - - Little more than an impassable barrier for this update, but the water plane will be a great placeholder for later in-game developments.

Disasters

• - - - -A placeholder system allowing the player to trigger global temperature and fertility changes.

Other

• - - - - RTS Camera
  - - - - Music
  - - - - Better Tooltips

Fixes

• Everything in 0.4.1 (Hotfix 5)

[/b]

[Reprieve]

If you're introducing changing environment are there any plans for intraenvironment variability such as seasonality? Of course, such an implementation would probably be useless unless the creatures knew to behave differently at different times of the "year" (if {wet} prioritise {mating} etc.) so one wouldn't expect to see it in this release, but is such a thing on the far horizon?

Also, with this environmental update are there any plans to introduce weather systems such as rain? Whilst I wouldn't expect them to really do anything but look nice (to minimise processing power, if you think you could have them being functional with little impact on the simulation itself then I'd be all for rain boosting fertility or something) it would certainly be a cool indicator that "here is humid" or just to generally break up the frustratingly optimistic clear sky that exists permanently atm.

[Quasar]

If you're introducing changing environment are there any plans for intraenvironment variability such as seasonality?

For seasons... possibly. It's either that or large, permanent "Events" (eg. "Ice Age", "Global Warming", "Drought", "Radiation"). The biggest worry with any cyclic change is that they would mask the games natural selection, by providing selection pressures towards cold, then warm, then cold, then warm...

Probably worth noting is that the game already has a rudimentary selection pressure for temperature: different body coverings lose different amounts of energy to "climate" (you can see it happening on the Energy tab page). It's just that it's set to "Average" and never changes...

unless the creatures knew to behave differently at different times of the "year" (if {wet} prioritise {mating} etc.)

As much as I want to include Genetic Programming aspects like this (currently, the evolution is done by Genetic Algorithms, which is an entirely different field), they are definately a far horizon thing.

Also, with this environmental update are there any plans to introduce weather systems such as rain?

Yes, but it probably wouldn't be biome-based. The problem with biome-based rain would be that you'd end up with rain-storms 10 meters across, which would look rediculous. Instead, I'm thinking that rain and storms would probably be an Event, similar to climate change, increasing the entire maps humidity as the storm goes over.

I like the idea of capital-E Events because it lends itself well to a SimCity-style disaster function in the future. But if don't know if I'll be able to get it done for 0.5.0.

[Reprieve]

The biggest worry with any cyclic change is that they would mask the games natural selection, by providing selection pressures towards cold, then warm, then cold, then warm...

I suppose the trick would be to have any climate variation occur within the lifetime of an individual, although that seems like rigging the system somewhat and so have suddenly become thoroughly opposed to the idea.

(currently, the evolution is done by Genetic Algorithms, which is an entirely different field)

Whilst I have a feeling we're going to regret this question; what is the difference?

The problem with biome-based rain would be that you'd end up with rain-storms 10 meters across, which would look rediculous.

I dunno, I think it would lend itself nicely to the whole "world in a bottle" effect that's going on (if that is indeed what you're going for. This might just be the only habitable crater on an otherwise desolate moon for all I know).

[Quasar]

(currently, the evolution is done by Genetic Algorithms, which is an entirely different field)

Whilst I have a feeling we're going to regret this question; what is the difference?

You know the alarm noises dam floodgates make just before they open up and wash away the town below? Neither do I, but I'm totally making those noises.

Genetic Programming is a subset of Genetic Algorithms. In general, if you're using hereditable traits and mutation, you're using Genetic Algorithms. They're omnipresent in evolution simulators.

Genetic Programming is a type of Genetic Algorithm, but the difference is in what it evolves. The Weasel program evolves text, Primordial Life and Biogenesis evolve biots, Species evolves 'creatures': a Genetic Program evolves branching, heirachial computer programs. So where a gene in the Species algorithm might be 'leg width' or 'head size', a gene in a Genetic Programming algorithm would be an if() statement, or an assignation, or something else.

The obvious target for concepts like these is behavioral evolution, but as we've already seen it can be tricky to mess with those without getting silly results. There might be a place for them later, once I improve the depth of creature interaction (for instance, if(target size < 10) { attack } else { flee }, but until then they're too complex for the current sim.

A less obvious target for similar concepts would be something like limbs. The big appeal (for me at least) of GP is that it builds a 'structure', rather than just following a sliding scale. So what about a limb system where a limb was defined not by 'type', but by physical joints?

This idea is really really far off, you understand, but what about a limb system where joint 1 is the shoulder, and the joints after that serve as variable 'building blocks' to build a limb? Each joint would have various stats related to it: rotation range, rotation axis, width, height, etc. and would be proceedurally animated. The animation would then be analysed to work out how fast and efficiently the limb could propel a creature, and how well it could take their weight.

As much as I love this idea, it's limited by performance. Calculating all this stuff costs CPU, even if you only do it once when they're born. So we'll probably be stuck with pre-animated limbs for a while.

Whoa. I talk too much.

I dunno, I think it would lend itself nicely to the whole "world in a bottle" effect that's going on (if that is indeed what you're going for. This might just be the only habitable crater on an otherwise desolate moon for all I know).

Hmm... I think I see what you mean. I'd pictured the rain coming from the sky, which would make it look like a pillar of rain, which would be rediculous. But if it were minaturised in the z-axis (ie. make the rain come from ground-hugging clouds), it might be kinda cool.

As for 'what I was going for', I never even really considered it. The crater is Jade's work. My own attempt looked utterly terrible.

[Reprieve]

Well, I'm game for anything that makes evolution seem more organic. ATM stuff does seem to appear rather abruptly, with limbs and eyes suddenly forming. Where's my light sensitive pit (or am I just missing it?). Granted this doesn't sound like it would be completely like real evolution, with limb joints appearing suddenly, but it does seem to be a step in the right direction and removes "pre-programmed" limb type. It's always interesting to watch computers do something by themselves.

As a Star Trek fan I've become good at post-hoc rationalisations. For the crater I imagined an introductory scene explaining that this was a desolate moon/planet/asteroid, except for this one crater where the conditions for life to appear were there. So it did.

[Quasar]

ATM stuff does seem to appear rather abruptly, with limbs and eyes suddenly forming.

Eyes are still a problem yes: they still don't have a mutation map, so they can mutate from any eye type to any other in one hit. There *is* a light sensing patch in there, but it tends to blend in with the creatures skin and can be hard to spot even when it does appear.

(Hmm... I wonder if I can get the feature mutuation map in place for 0.4.1? It'll be a stretch, but I'll add it to the list)

Limbs at least have the advantage of starting off quite small and growing from there (though they *can* increase in size due to neutral mutation before they actually manifest...), but I definately need to start leveraging the mutation map system to make the discreet mutations a lot less sudden. This is written as a permanent item on my todo list, that reads simply: "MOAR CONTENT".

Finally: http://www.astro.lu.se/~dainis/Images/W ... _large.JPG

[Quasar]

And we're back on this stuff.

The biome multitexturing is still giving me gyp, but I'm ever so slowly wearing it down. Currently biomes merge smoothly, which is good, but only if there's two of them being merged in the local area: introduce a third and you end up with all sorts of squarish visual problems. Which is bad.

In addition, I don't have the slightest clue how I'm going to make this compatible with the older graphics cards some of you guys are using. I've got a few idea's, but I don't know how well they'll work... if all else fails, I may end up sacrificing the merge entirely on those older cards and just making it look like Minecraft.

[Quasar]

Urgh.

I'm starting to think I may have screwed up my biome renderer and wasted about 2 weeks of work.

The original idea was to transfer a set of 4 Biome ID's and 4 Weights for every grid square, then blend between them to break up the sharp edge. I've reached a point where it works, but it has a few problems:

It's quite expensive in the pixel shader (and given the amount of spare GPU cycles I had, that's saying a lot). Everyone who had the blue-terrain problem would be pretty much screwed: I can't see how I could make it any simpler.

Graphically, it still has problems with Biome ID's, resulting in squares which fade to unrelated biomes before ending in a sharp edge. This seems to happen whenever there are more than two biomes meeting (I was hoping to get away with three).

Also graphically, I'm finding I'm having floating point errors, which result in edges 'flickering' from biome to biome, even when the dynamic biome simulation is paused.

...

I'm pretty much at the stage of "dump everything I've done and start over with a different strategy". Thankfully, I've got just such a strategy in mind: rather than trying to do everything at once in a single draw call, I draw the terrain itself multiple times.

Maybe an analogy will help: what I have been doing in 0.4.1 is sort of like painting through a series of stencils, where I paint forest through the red stencil, then grass through the green one, then desert through the blue one. Unfortionately, because of I've only got the RGBA channels, I only get 4 stencils to work with (okay, I actually get 5, but only because I cheat).

The system I've been trying to replace it with is sort of like an extremely complicated colouring book, where each grid square is numbered 1,2,3,4,etc and the artist fills in the grid with the associated biome texture from a colour key. And then we do some really complicated crap to make it blend smoothly without pixellation or sharp edges between, for example, the edges of biomes 3,7 and 2. It's all that complicated crap I'm having trouble with.

My new strategy is much simpler: we go back to using the 'stencil painting' system, but this time once we're done painting with the first 4 stencils (biomes), we put a new, transparent canvas over the existing canvas and keep on painting on that with a new set of stencils. Rince and repeat.

...

On the bright side, the dynamic biome sim itself is working perfectly. I threw in a varient of the cloud shader as a placeholder animated temperature/humidity map, and it results in a mess of shifting, changing biomes across the map: you can see ice shrinking as the area heats up, desert growing as it becomes drier, and so on. So I'll be able to salvage that part at least.

[Icefire]

For the idea about 3d Models instead of imposters/billboards(I think that's what they are called) You could make it so they are 3d models up close, billboards at a distance. You wouldn't be able to tell (as easily) from a distance, and it's saving CPU.