Posts Tagged The Saga


Wow, are we really at this stage already? In chronological terms, this post takes place just after Development Video #1. Ahhh, I was so young back then in the summer of 2011… [nostalgia]

… anyway, since I’m a cynical old fart now and clearly nothing like my half-a-year younger self, I’m free to criticise past-me for being a naive twit. And naive twit he was indeed when it came to speciation. He knew… wait… I knew? Gah, pronouns. This would be so much easier with a TARDIS, but I’m not a Time Lord. Past-me was but that was before the accident. Wait… after the accident? Goddamn time travel. Oh well, at least I stopped the Dec-2012 mayan-zombie-apocalypse. Suck it you undead sods, nobody gets to destroy this planet except me.

Back on topic, past-me I knew that seperate species, and thus speciation, was not going to be an easy thing to implement. We can’t even define it properly here in the real world! “Species” as a category usually means “unable to interbreed”, but what about ring species, where there is a continuous spectrum of creatures capable of breeding between two populations that can’t?

But they're still just birds! it's not like they've evolved into flying carnivorous fungi! Therefore evolution is false.

Image Source

This provides an interesting design challenge as well as a coding one. How do I define a species? How do I detect when two species have split?

(I say “detect” above because the existing simulation already includes speciation: what I’m describing here is a passive process that analyses the population, not an active process that forces a speciation under certain conditions)

As already stated, I knew that this was not going to be a simple problem to solve, but I was quite unprepared for the sort of problem it actually was. Coding it turned out to be difficult yes, but for all the wrong reasons. And as it turned out it was the design problems that required the most attention. This wasn’t a case of making it up as I went along (my usual method of coding): I was going to have to sketch out the problem in detail to find a realistic and sensible solution.

However, the game is called Species, so I couldn’t just chicken out on this one. It needs to be able to inform the player when speciation occurs, and allow them to track the progress of new and existing species in the ecosystem.

Initial attempts at defining this were sketchy in the extreme. Here’s something I wrote on the SMRT forum back when I was trying to work this out (because I’m too lazy to repeat myself when I can just copy/paste):

The biggest problem is defining species/populations. Just to give you an insight into the internals: I’ve set up a genetic comparison function which compares two creatures and returns their “Genetic Difference”, and I’m using this to determine mating compatibility (greater than 20 and two creatures can’t mate, and are thus different species). So, in the same generation, you have creatures A, B and C. If A’s genetic value is 10, B’s is 25 and C’s is 35, you can see the problem: A can mate with B can mate with C, but A cannot mate with C. Thus A and C are seperate species: but how do we define B?

This would be fairly simple to deal with if it weren’t for speciation. In a large population of many B’s and a few A’s (we’ll call them all “Species 1”), a C is born. What do we do? Do we mark the new C and all it’s descendants “Species 2”? Do we modify the existing populations label, making the B’s a mix of 1 and 2 depending on who’s closer? Or do we change the label and call all the B’s “Species 1.5”?

Despite the difficulties it causes, though, it’s kinda cool I’m dealing with the same issues taxologists have to deal with when trying to categorise animals…

My naivety shines through a little bit in those early comments, and later designs incorporated what I learned about ring-species and subspecies from the answers to my queries above. My second design had a system of ‘sub-species’ underneath ‘species’: a subspecies would be a group of creatures all of which were genetically compatable with one another, and a species would be the larger group that contains all subspecies, linked by those creatures that were genetically compatible with more than one subspecies. It took a few attempts at defining how this would work before I realised that my concept of a series of semi-mutually-exclusive subspecies simply wasn’t possible: the group of compatible mates is different for each creature, so any algorithm to determine this would end up with almost as many subspecies as creatures.

Eventually I dropped the concept of subspecies entirely and just stuck with a solid definition of “species”: a species is a group of living creatures from which a genetically-compatible path exists from any creature to any other creature within the Species. So despite the fact that the subspecies on either end of the ring species above cannot interbreed, the game would consider them all to be part of the same species

This solution brings up several more problems to solve: how do we tell if two creatures can interbreed? How and when do we work out if speciation has occured? And how much of a performance hit is this analysis of every creature going to be?

The first problem was, luckily, one I had already solved. While I was implementing mating, creatures had to check to see if they could mate in the first place. For reasons detailed in the previous post I couldn’t use the genetic string for this, so they instead compare their associated genetic values. Differences in floating point values increase their genetic distance proportionately to the difference, while differences in discreet values provide a constant (but dramatic) increase.

The end result is a floating point number representing the genetic distance of any two creatures. If it exceeds an arbitrary constant, creatures are no longer able to mate.

This system is an interesting one: it leads to a couple of interesting side-effects (for example, the genetic distance value is logarithmic. Immediate descendants can easily have a genetic distance as far as 10.0 units away simply by random mutation, but randomly generated creatures with no relation to one another have only 60.0-100.0 units distance). It’s also unmappable: afterall, how do you represent co-ordinates in 80-100 dimensional space? Because that’s what the genetic values usually amount to. Of course, just because something is unmappable doesn’t mean I’m not going to try…

Everyone loves graphs!

The graph is a bit misleading: the X position of a line represents the genetic-difference away from a “baseline-creature”. So if you imagine a circle, with the baseline-creature in the centre, the horisontal position of the line is the distance away from this creature. Two creatures can be on opposite sides of the circle, but appear at the same place on the graph and a species could be moving “around” the centre (instead of towards/away, as the yellow/orange-coloured species is clearly doing) and you’d never know. And since genetic difference includes a whole load of parameters, it’s less of a “circle” and more of a “50-dimensional sphere”.

Yeah, at that point it loses me too.

… [pause for thought]…

…actually, I just worked out a way to map it while I was typing that, by using the compatible connections rather than the co-ordinates and an elastic vector-web (ever played ‘world of goo’? If you have, you can probably sort-of imagine what I’m suggesting). Not only would that work, it would be absolutely fascinating to watch. Darn it, yet another thing to add to the feature creep list…

Moving on, the second problem then is “How and when do we work out if speciation has occured?”

The genetic comparison function isn’t too bad, but it does take time to run unless I can find a way to convert a Timecube into pure software (no luck so far). Back when I was only using it to help a creature determine if they could mate with another creature it’s effects were negligable, but calling it for every creature in a species, against every other creature in a species, every frame… well, you can see where that leads.

Thankfully, speciation can only happen under very specific conditions. It never happens unless the size of the species is changing, and never in response to a birth: adding a node to the web can’t create a new species (well okay, if the new creature is completely sterile it could create a species of 1, but that’s an exception to the rule).

Speciation is triggered by death: a population will speciate when the creature(s) linking it to the main population die off. So I only need to run the speciation checking routine in response to a death.

But we still need to work out how it works. I know I said working out the design for this system was the hardest thing about building it, but because I’m not an expert in searching algorithms, programming this algorithm was a close second.

The function starts by comparing the Species Average to all other creatures in the List, dumping any that are compatible into the “main population” bin. From there it compares every creature in the ‘main population’ bin to the remainder of the population, putting each compatible match into the bin before recursing to check the match against everything remaining.

By the time this function is finished, we have two bins of creatures: the main population and the remainder. 99% of the time there will be no remainder, which shows that the search function managed to find a way into every segment of the population. But if there is a remainder then it concludes that speciation has occured and splits it off into an entirely new species.

Huh… typing these posts forces my brain to rethink the processes I’m describing, and I think I’ve just stumbled on a few cases where this routine can be optimised. That’s good news: it means the game will be smoother and more efficient in the long run. Glad to see these blog posts serving a purpose beyond my own egotism!

Which isn’t to say egotism isn’t my primary incentive for writing this blog. That, the ability to tell rediculous lies in public. Oh, and also as cover for my time travel shenanigans. Nobody will ever suspect that I am really my evil time clone! Hahhahahahahah!

Now if you’ll excuse me, predestination demands I attack my past self with a toaster in a few minutes.

*Vwhooom vwhoooom vwhooommm…*
“Guys! I’m here from the future to warn you about- !”
“That’s quite enough of that.”

“Actually, predestination is a load of bull. I just told him he had to because it was hilarious the first time.”

, , , , , , ,


The Eyes! The Eyes!

At some point previously, I must have mentioned the EyeList. If not, just pretend I did. It’s a simple system: in the creatures Head object is a List of Eye objects. Every Eye object handles a number of things related to itself in much the same way that every Limb handles its own drawing and statistics: each Eye object contains an EyeType, and EyeTexture, a few Eye specific stats like size and location-on-head, and a routine to draw the Eye model in the right positions.

EyeList has served me well, but at a certain point I came to an important decision and took the ol’ fella out with me behind the shed. A few moments later, the loud sharp *BLAM* of a shotgun blast echoed around the farm. Immediately followed by a bunch of swearing and a second shotgun blast. Seriously, it was like 5cm away, how the hell did I miss?

Rest in Peace, EyeList.

Introducing its replacement, the FeatureList.

The theory is that FeatureList is a more generic and versatile system than EyeList, and that Features can do several things that Eyes could not. Contrary to logic, common sense, and indeed sanity, “being something other than eyes” is not one of those things: if I had wished I could have easily created Eye objects that were horns, ears, noses or shrunken voodoo heads: albeit horns, ears, noses or shrunken voodoo heads that either did nothing or inexplicably improved the creatures vision.

One thing that Features can do (well, okay: should be able to do, in the long run. This hasn’t been implemented yet…) is attach to body parts other than the head: primarily the torso and tail. Because the FeatureList is contained in the root Creature class rather than in the Head class inside the Neck class inside the Creature class (My Object Orientated Programming-fu was weak when I designed the Eyelist), I have a lot more freedom as to where I put them.

Another thing that Features do that Eyes didn’t is attach to procedurally generated locations on the head. The eyeList used a group of dummy objects (invisible objects that I manually put in in 3ds max), to specify the locations of the eyes. This worked, but it was slow and limiting to have to put these dummy objects on the model for every possible head model.

So now the program works out where to put the dummy objects by casting rays inwards towards the model and determining where they hit: I don’t even have to include them in the export anymore! This frees up time to spend on more important things, like modelling more head shapes.

An interesting side effect of this is that it allows me to orient the eyes so that, instead of pointing straight ahead, they look ‘out’ from the head surface. You can see the difference fairly easily if you compare early screenshots (or Development Video # 1) to later ones (or Development Video # 3): the eyes in later screenshots aren’t always pointing forwards.

This simple change drastically changes the visual style of the creatures. Where before they had ‘googly’ eyes and looked kind of cutesy, like cartoon characters, now they appear far more animalistic. And while I do kind of regret the loss of personality for many creatures, I’m of the opinion that this actually suits the game far better. This isn’t Spore or Viva Piñata, and cutesy isn’t the visual style I had in mind. Colourful and vibrant, sure: life is very colourful, after all! But not cutesy.

This change also opened up fascinating new possibility: orientation of eyes having an effect on the creatures eyesight, and thus survivability. Eyes pointed outwards will logically increase FOV, while eyes pointed forwards will improve Range.

Finally, and probably the most important thing that Features do, is change the appropriate stats for the creatures that own them, rather than being limited to vision. Horns will increase attack damage and scariness, plates will increase armour, eyes improve vision, voodoo heads will increase the power of arcane spells while sapping the power of divine spells, that sort of thing. This means that features are not just decoration: they’re functional and thus, like everything else in Species, influenced by natural selection.

Oh hey, it also means I can do away that that useless “TailTip” class and replace the Tail Tip with a feature attachment point. Please excuse me while I get the shotgun out again.


Umm... vampire mouse? Well, at least it's not sparkling...


“Oh wow. The blood just goes everywhere, doesn’t it? That’s horrible.

… Hang on don’t you faint at the sight of-“ *thwump* “… yeah. Yeah, that’s what I thought.”

, , ,


Behavioral Evolution

“FYI, the first third of this post consists of Qu just typing randomly with no coherent subject as he tries to come up with a subject for todays post. I have no idea why he decided to include it. Padding, probably. Feel free to skip to the stuff actually worth reading further down (assuming any of this dreck is “actually worth reading”).” -i

Welp. I have no idea what to write. I generally just write these posts by typing out whatever bullpoppy pops into myhead, and then going back and inserting some rediculous analogies, a bit of hyperbole, replacing the swear words with crap like “bullpoppy”, then clicking submit. And then re-opening the post and editing out all the spelling mistakes and adding in the links and images I meant to include in the original. Proofreading and preview buttons are for wimps!

But at this very moment my brain is giving me no prompts whatsoever, hense the above pointless and time-wasting sentence. What on earth am I going to write about?

Well, at this point in the saga, I have a working (albeit basic and rather buggy), simulation. Ummm…

Dammit writers block.

Dammit I just called myself a writer because I blog. Next thing you know I’ll be printing out business cards with this URL on them and adding “blogger” to my resume.

Okay, okay, let’s get serious. The first thing to do from this point in the games development was to expand and balance the selection pressures. But since this process is extensive, (so extensive it’s still ongoing, and shows no sign of letting up), and since I did a fairly pretentious post on it last time, let’s move on. I’ll be coming back to that topic sooner or later, there’s pretty much no way to avoid it, so no point in rushing it. Let’s talk about something else.


Hmm… I could do a post on performance and optimisation, but it’d come out all technical and I doubt too many people are interested. We’ll save it for later too.

Redundancy? I’ve touched upon the things that changed from the original design in other posts… but that’s pretty broad subject, maybe something more specific…

Oh, I know! Behavioral evolution.


“Stuff possibly worth reading starts here.” -i

The original design called for an unbelievably complex and mutable behavioral system, that could theoretically evolve to handle any situation. I’ll try to give a summary of it, but when I say “complex” I don’t mean “Pythagoras’ Theorum” complex, I mean “7th dimensional trigonomcalculus in a rotating reference-frame” complex, and I’m pretty sure that doesn’t even make sense.

The basic idea was that every creature could have a list of Perception Categories, based on visable data like “size” and “number of teeth”, so they could distinguish between predators and prey. Each perception category would also include an action (flee, approach, attack, mate), which based on the theory would, over time, evolve to become appropriate to it’s category.

Using this system, any action could be combined with any object. So Attack!Creature and Eat!Vegetation were possible, but so was Flee!Vegetation and Eat!Creature. (Note: creatures can only be eaten after they’re killed, so this did nothing except maybe annoying the creature being chewed on).

I actually implemented a placeholder version of this system, and discovered it’s flaw: it made creatures stupid. The earliest creatures picked actions at random, and would spend a good 90% of their time doing nonsensical things. The ones that survived were the lucky but random few who managed to realise they were supposed to eat their food, not copulate with it (not that there’s anything wrong with that (sorry, couldn’t help myself)).

At first I thought this was okay: creatures would naturally evolve to be smarter. But it quickly became apparent that the randomness cause by their own stupidity was the only selection pressure worth talking about in the game: it was overwhelming all the visible effects.

In addition, it was impossible to monitor. Getting statistics out of this system was like milking a tiger snake: not as hard as it sounds, but all you’ll get is poison. And there’s also the possiblity of being bitten by a pissed-off, venemous reptile, though I’m not certain the analogy streches that far. But it was very, very hard to tell the difference between “intelligent” and “brain-damaged algae” simply by looking at the perception categories. It was definately impossible to glean any useful information at a glance, which was the way I wanted to set the statistical elements of the game up.

And if that wasn’t enough, it evolved slowly. Increasing the behavioural mutation rate didn’t make it evolve faster, it just meant that the immediate descendants of an intelligent creature might well be back to running away from the scary food and trying to mate with the giant toothy predator twice it’s size. And decreasing it meant you could wait for hours before seeing anything.

And yet… if the only thing I was going for was accuracy, I might well have hung onto this system. It’s not too bad at replicating the way behavioural evolution in reality works: we recognise patterns and have instinctual reactions to those patterns. But evolution in real life doesn’t happen over the course of minutes, like in Species. It takes era’s. So this system, which is actually quite fast compared to real-world physiological evolution, is extremely inefficient compared with the simplified version found in Species.

What I had unrealisingly done was put a real-world system into a simplified simulation.

But I’m not “only” going for accuracy: the dual design goals for the simulation in Species are accuracy and intuitive… err… ness? Okay that word sounds ridiculous and probably isn’t an actual word, but you know what I mean. I want to be able to see evolution happening in Species, which is difficult to do with complex behaviors.

So that lead to the current, much-simplified system. It’s not quite as versatile as the ridiculously complex system detailed above, but it’s versatile enough to allow mutable behaviour while still allowing the user to see at a glance how the creature’s instincts govern it’s decisions. It makes the creatures understandable and (relatively) predictable, which is a good thing…

The system consists of four main genetic variables:

Curiosity/Cowardice: Determines a creatures reaction to other creatures in its line of sight. A high curiosity will cause this creature to approach, while a low one will cause this creature to flee.

Aggression/Sociability: Determines a creatures reaction to reaching another creature. An Aggressive creature will attack: a Social creature will either “Play” (an action which still has no real effect, but I’m planning on adding one. Sooner or later. When I can think of an effect it should have) or Mate. Which of those it does is determined by…

Amorosity/Asexuality: Amorous creatures will attempt to *ahem* “share genetic material” when approached by other creatures of the same species, while asexual creatures don’t. Since creatures are perfectly capable of reproducing by Parthenogenesis (cloning), it will be interesting to see whether sexual or asexual behaviour is the most viable within Species, or even if it changes depending on environment.

Interest In Tree’s/Lack Thereof: a behavioural variable that I may end up simply combining with the “diet” variable, because a) it’s redundant (Carnivores have no reason to approach trees), and b) it sounds silly. Interest In Tree’s causes creatures to prioritise vegetation over creatures (or vice versa for low values).

A few other variables, like “Scariness” and “Decoration”, provide modifiers to these: (scariness makes other creatures less curious, decoration makes them more amorous, etc).

And that’s it. This behavioural system theoretically provides support for predator and prey relationships, herding behaviour, and sexual selection, while being simple enough to understand at a glance and to not overwhelm the more interesting (debatably), visible selection pressures.

It’s not perfect though, and I’m always open to suggestions. E-mail me, or drop a line in the comments section below, if you’ve got an idea for this or any other system in the game. 🙂


Yeah, I’ve totally given up on making the random screenshots at all relevant.


, , , , , ,


Cue the Dramatic Music

Here we go: statistics that affect a creature directly.

I’d very much like to preface this by saying I thought out the various Selection Pressures thoroughly and with much aplomb prior to implementing them. I’d like to, but I won’t, because that would be lying, and I’m fairly honest except to heroes who ask me where the doomsday device is hidden.

It’s not that I didn’t give this any thought: I did. But by the time I came to code it, I’d corrected so much in the way of redundancies and stats that were unintuitive, impossible to visualise or ridiculously trivial that the final result bore little resemblance to the original design.

I’m letting you know this to provide context for the mess of massy stats connected by weird, overlong algorithms that I’m about to attempt to describe. All of what I’m about to say is an oversimplification or a metaphor or possibly an unintentional lie, because even I barely understand some of this. I don’t intend to rework it entirely, but making it simpler and more intuitive while hanging onto the quirks that make it interesting while also eliminating nonsensical outcomes is an ongoing and unwieldy process, much like this sentence.

Stats can be broken down into three varieties: moment-to-moment, genetic, and derived/lifetime stats.

– Moment-to-moment stats are things like Energy and Health. Actually, come to think of it, I’m pretty sure Energy and Health are the only moment-to-moment stats, unless you count things like their position and current behaviour. Oh, and metabolism now too! But I’ve already gone into detail about those things.

– Genetic stats are self-explanatory: anything a creature passes on to it’s descendants. This consists of discreet values like headType and floating point values like shoulderWidth. But I’ve already blathered on about that too. So let’s move on to the variety of stat I want to talk about here:

– Derived stats. These are statistics that are affected by genetic variables, or that exist as a combination of them, but aren’t genetic in-and-of themselves. They are generally derived when the creature is born, so the calculations for them are only done once (to save CPU).

As an example, EnergyMax directly limits the amount of energy a creature can store at any moment: the creatures’ fat-stores, if you will. It is determined from StomachWidth multiplied by StomachHeight (among other things).

There are lots of derived variables: often they exist to combine genetic variables into a usable value. For example, BicepWidth can’t directly be used to determine anything, but it can act as a modifier on the AttackDamage derived variable, along with a whole variety of other things. Here’s a few of the most obvious variables:

Health Max – Determined from creature size and torso width, mainly. Chunky or wide body parts like thick limbs will increase this value.
Energy Max – Fat stores. Height is a larger factor than width for this variable, but otherwise the two maximums are often similar.
Attack Damage – One of the more complex variables in the list: the damage of each arm, leg and head is calculated separately, and added together to give the creature an ultimate damage per second value, with additional modifiers for things like horns and fangs and, of course, size.
Movement Speed – The type, number, size and thickness of legs and feet will determine this. There’s also a ‘streamlining’ value that makes thinner, sleeker creatures faster.
Stamina – Uses many of the same modifiers as speed, but often in different ways. Many things good for speed are terrible for stamina. (Note: Currently stamina is deactivated and moving has no cost. This will be fixed as soon as I work out how the move-cost should compare to the likes of the metabolism and growth costs)
Growth Cost – A cumulative value from the energy cost of every body part on the creature; this is the amount of energy that must be spent to grow the creature from childhood to adulthood. Generally this is the balance variable: if a part has abnormally high stats, it will often cost a lot to grow.
Metabolism – an interesting value that establishes a lifespan for creatures, Metabolism is the energy required to keep a creature alive at any particular moment. It increases over time, costing very little when the creature is young but spiralling out of control as they age, eventually overcoming their ability to feed and causing death… which is rather horrible if you think too hard about it.

These are just a few of the derived variables. Some things, like arm-range, have only subtle effects on creature behaviour and are the result of one-or-two variables multiplied out. Other things, like Scariness, affect how other creatures react to this creature and are the result of a massive algorithm. Still other things, like the per-limb damage values, are only used as intermediate stages to calculate other derived values. Some genetic values affect behaviour directly, like the 4 psychological values I still haven’t told you about.

The goal for all of this unexpected complexity is to make it intuitive: the effects of any particular change should be predictable, even if you know nothing about the game. If a creature looks dangerous, with horns and fangs and claws, it should be dangerous; if it looks fast it should be fast; etc.

But I’m also planning to have the UI explicitly state the effect of each variable: hover over Attack Damage and you’ll see all the positive and negative modifiers contributing to it, hover over Bicep Width and you’ll see everything it affects, and how it affects them. The long and short of it is that if I’m seeing a certain trend in the way the creatures are evolving, I want to be able to dig down and quickly find out why they’d doing that with the minimum of work.

That sort of thing, convincing the player to wonder “why” of their own free will, is where the potential educational value in Species lies. I have no intention of shoving facts in peoples faces: that’s edutainment, which is… well… um… *shudder*. But the underlying mechanic of Species is the underlying mechanic of biology itself: it’s going to be hard to avoid learning under those circumstances. But that is an entirely different topic entirely, and this post is already redundant enough as it is.

At this point, all the fundamentals of the simulation are done. We have reproduction, mutation and selection pressures. If left on their own, the creatures evolve. Admittedly they don’t do it very well: at this point there were still plenty of energy leaks I hadn’t gotten around to dealing with, the AI was still fairly broken, and several aspects of their physiology didn’t actually do anything (heck, they still don’t), and in truth it would still be several months before it would be working well enough to actually observe non-random, selective changes over the course of time. At this stage, thanks to the aforementioned energy leaks, creatures would either go extinct in 5 minutes or completely overpopulate the world and crash the computer.

But that’s all polish. What was important at the time was that all the vital elements were in place. They’re evolving. Cue the pretentious choir music, the simulation is live.

More random screenshots! (because context relevance is for wimps)

Signing off,

“Bored now. Next week we rag on antievolutionists again, okay?”

1 Comment

Heads and Hands and Feets and Eyes Oh My!

With the basic body-plans implemented, the next job was detailed bits: things like hands and feet. In truth, this is probably one of very few aspects of the game that were changed very little from the original design: I take this as proof that the many long hours I spent labouring tirelessly over design documentation prior to beginning the game were well spent, because my fragile psyche is more comfortable with that idea than the alternative.

Individual body features like this are simple, pre-built parts, imported and attached to the end of the much more complex limbs. In general though not always, their only mutable statistics are scale and ‘type’, type being a discreet integer: the ultra stat that determines all the other stats. One stat to rule them all, and other such unoriginal movie references.

The complexity of these parts will come in the form of versatility via quantity. I intend to add a ridiculously large number of different types of feet and hands, all with different stats and connected through a web of allowable mutations.

Interestingly (well, to me: my sense of interest runs on Insane Troll Logic), this sort of feature requires a very different approach when it comes to generating content. With a feature that relies on procedurally manipulating geometry, like the torso or to a less extent the limbs, content generation is exponential: I do a bit of modelling work and then spend a lot of time programming, but I don’t actually see any content until the very end at which point there is suddenly ridiculous amounts of variety spewing messily all over the place: thin torsos, thick torsos, wide torsos, fin-shaped torso’s and symbolically phallic torso’s.


In general, I like this approach. Sure it takes a load of work before you see any result, but the ultimate result is awesome. Oh god, did I really just say that right after that screenshot?

With features like limb-tips, on the other hand, content is very much linear. I do a little programming, and from that point onwards the amount of content in the game is directly proportional to the amount of modelling work I put in. And quite frankly, I’d rather be improving the game mechanics than building crappy placeholder models for it until I can get an artist to look at it, so this sort of content is sorely lacking.

I do have a rather interesting idea to combat this lack of content, but I’m not certain how easily it can be done… stay tuned on that front. 🙂

Moving on, with hands and feet modelled and in place at the ends of limbs, it was time to move onto heads. Heads are more complicated than hands and feet, because they’re not just an attachment: they also do something. I’m not talking about influencing diet, or bite damage, I mean something technical… okay okay, feet raise the body by a certain amount which is “doing something technical”, but if you’ll just disregard my inability to be internally consistent for a moment and let me make my bloody point… What Heads Do is serve as an attachment point for Eyes.

Eyes are the most complicated type of feature, because in addition to having an independent texture and model (both of which influence their stats), there can also be any number of them, and they can be situated anywhere on the head (spoiler: later they’ll be able to be situated anywhere period. For the moment, just the head).

My initial solution to this conundrum left a lot to be desired. I instituted the EyeList, a system for tracking and mutating a variable number of eyes, and when I was modelling the head-shapes I added several rows of dummy objects. Each dummy object was a potential eye position, and by using them the eyes knew where to appear on each of the differently shaped heads.

I’ll go over the many horrobad problems inherent in this system later, when I reach the point in the saga where I fixed them. Suffice it to say, my fixing involved a method roughly analogous to the method veterinarians use to fix pets.

In the meantime, Eyes! And Heads! And Feetses! That is totally a real word!

/tangent I’d like to quickly expound on one other difference between procedural content and handmade content. Handmade content is specific, which means it can be tailored. So if I want a head shaped like a donut, or a skull, or a paperclip, I can model and import a head shaped like a donut, or a skull, or paperclip. But with procedural content, I can never reach that level of freedom: I might be able to get a spectrum of infinite variations on torso width and height, but I’ll never have a skeletal torso, or a torso with a great big hole through it, unless I add a discreet aspect to the Torso genetics (hmmm… idea…). This sort of melding of discreet and floating point variables can produce an astounding amount of potential variety amongst the creatures: certainly more than I expected when I started designing the game.

Our universe is purely procedural, but then again it can afford to be. It doesn’t require considerations like CPU usage and memory footprint: where I’m forced to simulate a creature using maybe a hundred distinct numbers, our universe simulates a creature using trillions of physical molecules all working at cross-purposes. The limitations I run into are ultimately the result of discreet variables representing macroscopic structures: the various 3d meshes that make up body parts. The universe has no such discreet variables: everything in it is floating point, to a Planck level of accuracy.

Ultimately, it comes down to the fact that Species is a simulation of a universe, not a universe in and of itself. But I’m certain the creatures in Species don’t care. They struggle to survive and reproduce in their own universe just as much as real-life creatures do, so maybe… just maybe… that qualifies them as alive…


* * * * * *

PS: I’m going on holiday for a bit (New Zealand! I’m gonna join the sheep races and be the fastest sheep jockey that ever lived, and then I’ll feed my hire car to the birds that eat cars, and then I’ll hang around Mount Doom heckling the midgets with rings!), so it’s improbable there’ll be anything to see here for the next two weeks. But I’ll definitely be back come Christmas.

* * * * * *

“I haven’t the heart to tell him there’s no such thing as sheep races…”

, , , ,

1 Comment

Energy Cycle

Okay, to finish off this trifecta of unhealthily co-dependent posts, here we approach one of the most central systems in the entire game: Energy.

“Energy” is everything in Species. Every dynamic in the game uses a type of energy, and every type can be converted into another type. 1 unit of plant-food can become 1 hit point, 1 unit of walking distance (sort of), 1 unit of meat for other creatures to eat, etc. If a creature loses all its energy it will starve. If it loses all its hit points, the energy will be converted to meat. And so on.

There’s nutrient energy in the ground, which is converted into plant energy. Creatures convert that into chemical energy by eating it, which can be used for all sorts of things: it can be used to grow into adulthood, it can be converted to hit points to heal themselves, it can be used to give birth (in which case it is handed directly to the child creature. Childbirth is a somewhat less messy process in Species), or just consumed by their metabolism and exertion (walking about). When they die, spare chemical energy is converted into meat-energy, which can be eaten by other creatures or, to complete the cycle, decay slowly into nutrient energy in the ground.

This system makes the decision of whether to implement a closed or open energy cycle a big deal.

A closed cycle would have the same amount of energy in the global ecosystem at all times according to conservation of energy. Growth, metabolism and exertion convert chemical energy to ‘biomass’, which is returned to the ground as meat when the creatures die. There is no external energy source.

An open cycle doesn’t convert metabolism and exertion energy into biomass: it just vanishes into the ether. In addition, some energy losses are acquired during conversions, such as eating. This requires an external energy source to sustains the losses and allow the cycle to continue.

Given these choices, I decided to build an open system. It’s less controllable, but I don’t want to control the ecosystem in Species: I want it to evolve, to adapt and change, on its own. It’s also more realistic: the earth has an external energy source, a ridiculously massive one that renders anti-evolutionist arguments involving the second law of thermodynamics (yeah, we’ve all heard that one, guys) utterly moot: the sun. It’s only fitting that sunlight in Species should serve the same purpose: feeding the trees that feed everything else.

This doesn’t stop me from closing off the energy cycle, however. It just requires me to add energy gains (the sun) and roughly equivalent energy losses (metabolism, movement) to it.

But it also makes problems harder to debug.

The problems I refer to are “energy leaks.” Under particular atypical confluences of unexpected variables, or more often simply because the programmer can be kindly described as a complete dingbat, energy can be gained without being lost. This particular type of bug absolutely plagued the early iterations of Species. Populations of creatures would often discover these leaks long before I did, and would explode massively as a result. And making it harder for them to survive in an attempt to control the population would simply result in them dying out before they found the exploit.

Some of these were easy to track down: for instance, an observation that the exploding population were all carnivores…

(“I thought you hadn’t yet implemented a carnivorous diet at this stage?” Shuddup. Time can be re-written.)

… led to me rewriting the energy transfer for eating meat. I have to admit, there’s something inherently awesome about the creatures helping me debug their own game without me having to prompt them to do so. 🙂

Other leaks were more subtle, and an inability to track them down would eventually, after much frustration, lead to some drastic action: I closed off the energy cycle entirely, built an “entire ecosystem” energy counter that added every type of energy in the game up, and watched to see when and why it changed. You can still see the “Entire Ecosystem” counter in both of the Development Video’s.

Only once I’d completely debugged the energy cycle, and ensured that it stayed closed and stable under all conditions, did I slowly reopen it. That was only a few months ago.

(“You’ve completely given up on a sensible chronology, haven’t you?” I am a Time Lord. Chronology has never laid a hand on me. “It hasn’t laid much of a hand on this blog, either.” Damn right it hasn’t!)

Of course, at the time of making this whole system I had no idea what lay ahead: I was just obliviously coding, and seeing populations of creatures change and move about as their constituents lived and died was more than enough for me to be happy I was getting somewhere.

The next step would be implementing variable statistics: tying leg size to speed, size to metabolism, not-yet-implemented head-type to not-yet-implemented diet, and so on. From that combination would emerge one of the most vital points of this entire project: natural selection.

But perhaps, before even doing that, I should implement the still-remaining body parts: head, eyes, hands and feet. Yeah, that’s probably a plan. Assuming I don’t get distracted and go off on some sort of a rant about something shiny.

Huh. That’s pretty much the most planning ahead I’ve ever done in my life. Err… for the blog. Not the game. I planned the game out completely from start to finish, like a professional– oh, who am I kidding? I’m winging every aspect of this thing.

See you next week!

“For the record, I’m… uh… pretty sure he’s not really a Time Lord. Like, 95% sure.”