I’ve been working on applying torques to the creatures in a meaningful and well thought out manner (read: banging my head against the keyboard whilst trying to fix all the horrible signage errors). The original intention was to simply pass the torques on to the energy system and let natural selection weed out the unbalanced and physically impossible specimens. But I realised I have the perfect opportunity to overhaul a system that has bothered me since its inception: the quadruped system.
Logically, if a creature has slightly smaller front limbs than back limbs, it should lean forward in order to walk on them (unless it’s a pangolin, but they’re too awesome to be swayed by our petty logic).
Without something to enforce this, every creature in Species ALRE would be a biped, because every creature has at least a *slightly* different leg size.
The quadruped system governs how this is implemented. A hideously simplified description would be “if the torso rotation is less than 45 degrees, and it has fore or back legs, the creature will fall forward onto its front legs or chest. If it’s higher than 45 degrees, or it has mid-legs, it will remain bipedal.”
That “45 degrees” is completely arbitrary. It’s just a value I picked.
This system is why ‘head-down butt-up’ creatures, whose bodies hang forward from their back legs are so common: Any creature with large back legs and a small torso rotation will end up with this body plan.
That’s the old system. The new one is much more sophisticated.
It starts by completely eliminating the quadruped system: creatures will initially be created *exactly* as their genes would have them (ie. with only one pair of their legs reaching the ground). It then calculates the skeleton and torques as normal.
Once that’s done, it passes control to the droop system. This applies “droops” to every body part attached to the torso: limbs, neck and tail. Legs are bent upwards by the reaction force on their legs, neck and tail are bent downwards, and the torso droops based on the creature’s balance, all in direct proportion to the torque applied on the joints.
If a body part droops into the ground, it stops drooping and adds a ground contact point, which will take some of the creatures weight in the next step.
Then pass 2 starts, the body-plan is completely reinitialised: bones are regenerated, torques and forces are recalculated. The results of pass 2 are what the creature will ultimately use for most of it’s energy calculations, so as to take advantage of the creature new quadrupedal body plan. (physical droops will affect energy, but proportionally to how much they rotate rather than as a function of torque. Small drops onto legs will be a negligible cost)
This also has a noticeable effect on creature appearances. I haven’t adjusted the rotation genes at all in the following screenshot: these variations are entirely the result of torso, neck and tail thickness changes causing different torques in the creature’s body plan.
One particularly noticeable change is that the creatures tail now has an effect: increasing its mass is the only way to counter the torque produced by the head and neck in the second body plan. For bipeds with centrally situated legs (raptor-like creatures), a sizable tail will be the only way to maintain balance (other than having an upright torso rotation gene and incurring a large energy cost in droop).
I’m hoping this system will be realistic enough to promote life-like body plans in place of a real-time physics system, which would be far too CPU intensive to implement across thousands of creatures. More likely, it will be exploited ruthlessly in ways I can’t yet imagine. But hey, that’s what makes it fun!
“Anime references. There goes the neigbourhood”
I played with the Rover UI while I working out exactly how I was going to apply the (now completed and working) torques to the creatures in a realistic fashion. This led to the following thought processes, presented in conversational format for readability and not because I pay heed to the voices in my head. Because I don’t. I am sane.
“I promised to do thing X with the rover AI for 0.7.0, but with the upgrades to the code it should be possible to make it do interesting things Y and Z as well. But there are a variety of sensible, practical reasons to leave those for a later version so I can get 0.7.0 out earlier. I would have to be completely insane to distract myself with additional feature creep at this point in time.”
“I make a very sensible point. Does the opposition wish to provide a counter argument?”
“Yes! Now! THIS IS A PERFECTLY RATIONAL AND SANE DECISION!”
So, umm… this (click for full size if you can’t read it):
In addition to the promised “creatures with genetic distance to” option, we’ve now got “trees with high/low stat”, (this should be helpful for encouraging reforestation), “Species” will be good for cladogram pruning (I’d also like to add a “plus descendants” option, since it’s hardly a proper genocide if the Rovers ignore branches of the species), and most importantly, “Population when total creature count is higher/lower than” will be great for controlling population explosions and preventing mass extinctions.
It’s already mostly implemented, so this hasn’t set me back too far.
You’ll also notice that the Rovers now have randomly-chosen names. This was another small, unplanned feature. It has absolutely no effect on gameplay, and some of the names are a bit silly, but overall I’m quite happy with the addition. It gives the game as a whole a tiny bit more personality than before.
- – - – -
“It gets harder to not talk to yourself when there’s so many of you.”
Hello my totally-not-expedible minions!
Finally feel like I’m getting somewhere with these torques, so I thought I’d share a bit of the
pain and frustration fun times!
I gave in and repurposed the debug text routine to draw the actual values of torques to the screen so I could debug them. I wasn’t sure whether the actual calculated values were wrong, or just the display arrows.
Turns out, both were: the calculated values were wrong, and the display arrows were not even reflecting them accurately. So I’ve stopped looking for a quick fix and am stepping through the code as best I can, fixing things as I go.
I think I’ve found the first major problem: it’s a bit hard to explain, so I’ll diagram it:
The short version is that in order to calculate torque I need to calculate both distance and magnitude perpendicular to the bone. If they were parallel, then there would be no torque and the bone would face compressive forces instead.
The problem is that by crossing the Force’s Normalised Magnitude Vector with the Bone Rotation, we introduce it’s *direction* into the equation. Then later on we calculate the Dot Product of that and the Forces full magnitude vector, multiplying it’s direction a second time and resulting in a torque going the wrong way.
If you’re by some miracle still following, then a) you have a better attention span than me and b) I’ll probably fix this by removing the final Dot product: just multiply cross2 by the force length and call it a day.
And then I can finally get to work on why the display arrows are crap.
* * * * *
PS: The Orbital EMP Cannon is down again. We sent an investigation party, and they reported that the living quarters are for some reason highly radioactive and not fit for human habitation. They also said something about millions of spiders before descending into incoherent and extremely uninformative screaming.
I’m sure they’re fine.
We’re now taking volunteers for the cleanup party. Biohazard suits and flamethrowers will be provided.
Some of the things of which I have been the doing… (that’s totally a sentence and anyone who says otherwise will be EMP’d)
Rather than just adding an option to allow rovers to prioritise differently, I completely overhauled their AI. It does the same stuff as before, but in a much more versatile, object-oriented manner which will allow:
- Task queue. Allows for sequential tasks, waypoints, and 2-part actions like move and gene splice.
- Arbitrary targets. Rovers can now target anything with the “Entity” base class, which includes trees, fence posts, devices, other rovers…
- Arbitrary actions. They can now call any method in the game when they reach their target, rather than just picking through a predefined library (feed/kill in 0.6.0))
- Arbitrary prioritiser. The system for choosing which entity next merits their attention is now versatile enough to support any prioritisation method, rather than just picking highest/lowest statistics.
To test the system I added a routine that appends a “DoNothing” task tied to the camera entity. The rover finishes murdering whatever they were murdering, then comes to the camera, says hi, then runs off again on its eternal killing spree. It’s adorable.
I then implemented the UI for Targeted Rover Programming (would it be tacky to shorten that to ‘Rogramming’?).
It’s not quite as user-friendly as it was, but it’s capable of a lot more. And it was really easy to hook into the aforementioned AI system! Configuring the UI itself, on the other hand… let’s just say the UI code rather desperately needs a cleanup.
The end result? I targeted Primum Specium and let 4 rovers get to work on a randomly generated species…
This “forced devolution” sequence took about 2 in-game hours, (12 minutes at 10x). I had to switch them from killing to feeding a few times to keep them from driving the creatures to extinction, and I learned something in the attempt: it seems that selectively killing a large, thriving population is a much more effective way to apply selection pressure than selectively feeding a small, struggling one. There was a different population that caught the attention of the feeders, but ultimately they were incapable of surviving even with assistance.
There will be a major change to the game as a result of this feature: the Creature Editor which has been an unofficial part of the game since 0.4.1 will enter the game officially as a means of creating your own selection targets for your rovers. You won’t be able to use it as a creature generator: designed creatures will appear in the export list as “Genome Only”.
Finally, another potential major change: this rover AI system marks the beginning of the end for the godhand tools. The goal has always been indirect gameplay, and replacing the direct “Feed” button with a way to give the rovers that command is a step in that direction (plus it steers the game away from god games like Black and White).
It should also work well with a few planned changes to the UI (not for this update, but later): rather than “Select Mode”/“Select Tool”/”Click Target”, I’m thinking of a more context sensitive “Select Target/”Click Tool”, where the mode is determined by the target. So you’ll get different tools if you’ve got a creature selected than if you’ve got a rover or a tree selected. Such a system should be more extensible for things like group selections, as well as easier to use.
Placeholder models, but they work! They look a bit odd in 10x speed though: the optimisation that causes the biomes around forests to ‘pulse’ causes the same effect from the climate devices, except even more noticeable. I may have to work out a solution for that problem, but initial results are promising: it should now be possible to keep creatures alive on a glacial map without simply changing the global temperature.
They’ll need a UI too, though: at the moment I’m just generating them with the “G” key. Once more unto the breach!
I’ve got all the forces in play, including reaction forces, but the 3d torque calculations are still giving me trouble. Can’t work out why the tail torque is backwards. Heck, I can’t work out whether the tail torque is backwards: it’s possible that my display arrows are the things that are backwards. I’ll get there eventually.
Overall progress report!
• Mutation Map Editor: 100% done. Just need to get around to actually using it for new content.
• Fences: 90% done. A few bugs to fix, mostly AI related: creature’s need to ignore objects on the other side, and rovers need to path around.
• Targeted Rovergramming: 90% done. Some minor cleanup and bugfixes.
• Skeletal Analysis. 75% done. Slowly getting there, but the aformentioned torques are still giving me Fun.
• Physical Values: 70% done. Volume is defined, and Mass is calculated from a placeholder value for density. Should be easy to hook in the material system, which is being developed off to the side, when it’s ready (no idea when, but not for 0.7.0).
• Metric Units. 70% done. Same as “Physical Values” because they’re effectively the same thing Comes with volume and density. Not in genes, so conversion is performed in BodyPlan and fed through to the boneses.
• Climate Devices. 40% done. Mainly I just need to make a UI for them.
• Animation. Not started. If anything, my forays into step-size adjustment have just introduced more problems.
Overall? Hard to say: some of these jobs are ginormous (Skeletal analysis is taking a lot of time) while others are tiny (Climate Devices were surprisingly easy to tie into the existing system), plus I keep coming up with new things to add or overhaul.
We’re definately past the halfway point, though.
- Darker, linear arrows are Bones.
- Brighter, circular arrows are torques.
- Torque display arrows scale with torque magnitude.
- Torque Colour matches Bone colour (the orange torque goes with the dark-orange bone, which is the neck)
- Compressive and tensile forces are not displayed (though they *are* calculated).
- The creature was animating when this screenshot was taken, which is why the bones don’t match the leg.
- Torques are only calculated with Mass: reaction forces are not yet accounted for. Imagine the creature hanging from a string wound around it’s torso: those are the forces you see here.
- I’m not doing all this visualisation just for debugging: I intend to include the skeletal view (cleaned up, of course) in the final release.
I got sidetracked.
I was working on tying volumes to bones in order to calculate mass from volume and density, when I suddenly realised I was going to have to get density from somewhere. I was this close to following the original plan and adding a simple constant “creature density” value to the game… but…
Well, quite frankly, I’m tired of making placeholders and putting the interesting stuff off until I’ve finished the boring stuff. So I decided not to, and dived headfirst into the new material system. I wonder how many of these I can fit in? Any preferences?
My initial thought was to take a leaf out of Dwarf Fortress’ book, and define materials generically, to amplify the possibility of weird, interesting and utterly horrific combinations. The problem with this, though, is that they need to texture differently depending on how they’re applied, especially for things like fur and claws. So it’s more likely we’ll need to split them up based on how they’re applied…
- The furry/feathery/skinny/slimy surface covering. Has a strong influence on friction and insulation. Mass determined by Surface Area * Thickness * Density. Immediately visually apparent by virtue of body texture, obviously.
- The goo and meat and muscle inside the creatures body. Influences the creatures strength and flexibility, as well as their optimal operating temperature and how endothermic they are. Mass determined by Volume * Density. Visual markers are mouth-textures and corpse meat textures.
• Hard Tissue
- Skeleton and weapons (I’ll probably split these into two seperate items, so a creature can have different claw and bone material). Density and compressive/shear strength will be the most influential settings for the skeleton, while density and sharpness will be important for weapons and chewing. Visible on hands and feet, teeth and in corpse bone textures.
These three categories will make up the outer covering (fur, feathers, skin), inner covering/organs (fibrous, porous, fatty) and skeleton/claws/teeth (keratin, chitin, osseous tissue, enamel), respectively. Each item will have its own texture/spritesheet, and a position in the mutation map.
I will likely have to have duplicates so as to allow, for example, chitin to be used as either endoskeleton or exoskeleton. One idea I’m leaning towards is storing materials as three texture objects in the same asset folder, so chitin could be a single Material asset but still be applied as Skin, Flesh or Hard Tissue. I imagine making your internal organs and muscles out of chitin wouldn’t end well, but why should we stop creatures from trying?
And as a bonus, this means creatures can have body coverings and flesh made entirely out of materials I hadn’t considered before now, like fibrous muscle, or bone tissue, or eyeball fluid or retina cords!
Wow. I am a horrible person.
This material system will likely become one of the sources of tangential learning for Species. Much the same as how playing Dwarf Fortress is an extremely effective way to drill into you what Magnetite, Hematite and Limonite are, Species will happily throw a bunch of terms I’ve stolen from Wikipedia at you until you bloody well remember what Osseous Tissue is, damn it.
The system will also have a few additional per-material values. Most of these will be placeholders until their appropriate systems are in place, but it doesn’t hurt in the long run to define them early. So far ‘m thinking these ones look good:
Compressive, Tensile and Shear Strength,
YieldRatio (a simpler way to represent Compressive, Tensile and Shear Yield Strength),
Coefficient Of Friction,
IgnitionTemperature, BurningEmission (that is, the amount of heat this material will emit while burning),
Melting and Boiling Point,
Thermal Capacity and Conductivity,
OperatingTemperature (flesh and muscle specific: determines the optimal body temperature for this creature),
HeatOutput (per unit of mass. This will be what establishes Endotherminess!),
Of course, finding values some of these numbers is gonna be all sorts of fun. “What’s the compression strength of fibrous muscle? What’s the melting point of eyeball fluid?” It won’t be easy, but there’s plenty of dogs and cats in the area.
Or, y’know, I could just ask The Google. But where’s the fun in that?
(Edit) Oh wow. I think I promised to let somebody kick me if I did exactly what I’m doing right now.
Yep. Yep I did. Who wants to do the honours?
I had a curious idea this morning. It’s turning out to be a rather interesting can o’ worms.
I hadn’t really considered sideways torques before now: because the bones are static (by necessity: we can’t go recalculating them every frame, for the same reason we can’t animate every limb on the map) I’d been mainly considering creatures as “balanced or not” based on how they stand still. But what about gait? A slow biped with large, wide-spread legs *should* be incapable of using them effectively, but the game would fail to take that into account by always treating them as if they were standing on both legs.
So what if we apply a very rough “gait” calculation, basically just a sin curve, based on their limb size? This applies positive torque when they’re on their left leg, and negative torque on their right.
So far so good, but the creatures need to be able to adapt to this. At the moment, the only gait-influencing attribute is leg size, and it just affects how fast the legs animate. In order to optimise their gait, they need to be able to sync their legs to each other, which can only be done if they have *exactly* the same sized legs.
Here’s where the can o’ worms comes in. How do we allow for gait-sync in creatures who could have any size or number of legs, but whose legs must move at the right speed so as not to slide strangely across the ground?
My initial thought is this: we’re going to need to procedurally modify the animation, specifically the step size. If the aforementioned slow biped with large, wide-spread limbs took small fast steps instead of wide slow ones, it could concievably walk without losing balance. In addition, it could sync up those small steps with smaller limbs that take wider steps, and these smaller limbs could take the weight while the large limbs step forward.
But we still hit a similar problem to before: if the speed is even slightly off, then 10-, 50-, 1000- steps down the road, the legs will no longer be alternating and the benefits of syncronisation are lost.
My current idea is to have a binary flag gene, which stores which limb indices are synchronised. So if limbs 1 and 3 are synchonised, it would store 13. (no, that’s not “1,3″ it’s “101″. Afterall, there are only 10 kinds of people in the world…* :D). These limbs would ignore their actual step size in favor of one which allows them to stay in sync.
Well, regardless of whether we manage step sync and sideways torques, I’m sold on the idea of a variable step size: it’s the only way we’ll have decently animated sauropod- and elephantoids. I had originally intended to implement it via additional limb-types, but if I can find a way to do it procedurally I can get infinite more variation! Am hyped! Am very hyped right now!
And I won’t even start on the idea of using the torques to rotate the torso bones so as to make the energy expenditure visible and the walk animation more realistic, because if I do that I’ll never be able to clean the drool off the keyboard.
* * * * * *
*footnote: <i>”… those who find nerd jokes about binary formatting funny, and those who aren’t pretentious nobs with the social skills of parthinogenically-reproducing lizards.”</i>**
**footnote: <i>”Self-depricatory humour. Binary jokes are hilarious and parthinogenically-reproducing lizards are badass.”</i>
* * * * * *
(Edit) So I tried to implement variable step size! And got… um… this…
Success! Although it might need a little bit of tweaking. Just a bit.