Posts Tagged game design

Black-Ground Bug, Stat Development and Body Physics

The 0.6.1 release went reasonably well: we managed to track down and fix most reported bugs, and the game now appears to be reasonably stable. There is, however, one remaining bug, and it’s rather major: on a number of AMD graphics cards, the shaders responsible for drawing the creatures and terrain are not working. 


Other programmers get bugs that result in exceptions. I get bugs that result in unseen creatures drifting silently through a world of infinite darkness. I love my job.

Nonetheless, this is a frustrating bug. Since Google is turning up nothing, I have no elegant fix for it (a small number of people reporting similar problems with AMD cards on other games, and that’s about it). Since I don’t have a computer with an AMD Card in it, I can’t even go for the inelegant fix for it (namely, continually keep tweaking random stuff until the damn thing works).

My current plan is to create a suite of non-functional shaders, each commenting out or otherwise reducing a different section of the original shader, then distributing these to people with the bug to try out. If we can narrow down what it is specifically that the AMD cards have trouble with, we might be able to work around this issue.

While trying to find that solution, I’ve been further developing my new Stat Control System. It’s actually the first time I’ve been genuinely proud not just of what the game does, but of how it does it. The code behind this new system is a pleasure to work with, and it realises a dream I’ve had for for a while: a centralised, decoupled stat library.

The ultimate goal of this particular piece of work is to extract every creature stat in the game into a central StatData class, which defines all their common characteristics. This includes things like a Printable Name and Description for the UI’s benefit, as well as mutation rate (for genetic stats), upper and lower limits, where to find them in external files (for base stats), and so on.

"limbType", //Name
"Limb Type", //Printable Name
"The shape of the limb.", //Description
1f / 40f); //Mutation Rate
"limbTricep", //Name
"Limb Tricep Width", //Printable Name
"The cross sectional radius of the limb's upper bone.", //Description
0.6f, //Mutation Rate
0.01f, //Lower Limit
float.MaxValue); //Upper Limit

The way it’s implemented imposes certain restrictions: for instance, I am no longer able to bias the mutation direction for any stat. I wasn’t doing this anyway (well, not deliberately. People who were with us back in 0.4.1 will remember the fat-bug which caused creatures to swell progressively larger until they became crippled by their own weight and died out), but now the compiler will make it physically impossible. Mutations must be random.

A huge bonus of the way it’s implemented is that it’s no longer necessary to hard code stat properties. I still have to hard code their usage and implementation (softening those is stage 2), but all of the properties I mentioned above could easily be extracted to an editable file. Want to triple the mutation rate for leg size? Edit the file! Re-enable negative tail lengths? Edit the file! Translate the UI into ancient Sumerian? File!

As always with cleanup tasks, though, the real advantage will come in making it an order of magnitude faster to add, remove and tweak things in the future.

I’ve also been doing some design work. I’ve decided, rather than just progressively improving the stat calculations for 0.7.0, I’m going to rewrite them as a low level physics engine. The result will work like this:


Each body part will have a given mass and a pivot. A few simple engineering calculations later, we have a linear force and a torque for that pivot. (okay, technically we’re treating the creature as a static mechanism so the proper term is “moment”, but torque’s easier). The linear force will propagate from leaf bones like the head towards the ground contacts, so torque on the neck pivot will come from both head mass and neck mass.

The Passive Strength of the pivot will come from cross-sectional area, and will determine how much torque it can handle. If torque exceeds Passive Strength, the joint will “droop” and the creature will need to continually expend energy on it to compensate. Creatures will need to find their own balance between Passive Strength and Growth Cost for each joint.

My hope is that this bottom-up approach will pay off as creature’s grow more complex. It would be awesome to see stuff from biophysics appearing as emergent properties of the simuation.

Finally, my real life has recently been a little more interesting than usual, and my free time has dropped significantly. I haven’t even had time to feed my swarm of carnivorous nano-squid, let alone reconfigure the Orbital EMP Cannon to deploy them upon the hapless citizens of earth.

It hasn’t had any effect on actual development since I have dedicated time for that, but it’s made it impossible to pay as much attention to spreading the word about the 0.6.1 release as I would have liked. Yeesh, the front page of the website still has 0.6.0 screenshots: that’s how busy it’s been.

Hopefully the event responsible for this will come to a close in the next month or so, and I can get back to the important things in life. Like swarms of carnivorous nano-squid.




, , , , , , ,

1 Comment


So, a topic that keeps coming up, on YouTube and elsewhere, is the concept of civilisation.

Now I’ve always said a ‘Civ Stage’ isn’t in the games scope, but I’ve never really explored in detail why that is. So let’s explore that concept, shall we? What would it take, hypothetically, to create a civilisation stage in Species? And even if we can’t do civilisation, what can we do?

(the usual disclaimer applies here: nothing I say is in anyway a promise to deliver future features. I’m just hypothesizing out loud)

First of all, in order to program something like Species we need hard definitions for terms. So what is “civilisation”? What marks it as different from just a bunch of smarty pants creatures living together? Keep in mind every definition from here on out is arbitrary, and provided purely for the sake of argument.

For civilisation, I’d say you need three things, which all start with an “s” BECAUSE REASONS: settlements, social heirachies and sapience.

Settlements are the simplest and easiest to define of these: they’re semi-permanent communal nests. Plenty of creatures build these: loads of different birds, bats, all hive-based insects, some species of spider…



The trick with settlements, of course, is feeding their population. You can effectively divide settlement species into two groups based on how they achieve this. Humans and bees do this with agriculture: ‘farming’ a renewable resource to sustain themselves on a (relatively) small territory. All other settlements consist of creatures capable of travelling great distances to find food, hunter-gatherer style: creatures like bats and penguins. 

Since the latter strategy means the creature has a lot less free time to develop complex social heirachies and sapience, it seems unlikely earth will ever have sapient penguins. This makes me sad. I feel like birds deserve a chance to be the dominant life form: penguins doubly so. On the other hand, we might well end up with sapient insects, which is…



Of the three requirements, settlements would be the easiest to implement in Species. We already have a few plans for a mechanism called “nests”: this would simply be an extention of that concept, either by allowing ‘improved’ nests to hold more than 1 creature or making creature’s build their nests in close proximity to each other. Bringing food they can’t immediately eat back to a nest, to store for later or share with other members of their species, fits beautifully into the existing game mechanics and could prove to be a winning behavioral strategy.

*Social heirachies* are trickier. See, one of the ‘rules’ of the game’s development is that there are no external constructs. You can see this in the species algorithm: it is entirely passive. You could remove the “Species” category from the game entirely, and it would make absolutely no difference to the simulation. From the simulations perspective, “species” don’t exist. They’re merely a category superimposed on the game for the benefit of the player.

The same goes for social constructs and behaviors. If they do form, it must be entirely contained in each individual creatures mind, which means any one creature’s perspective of the “tribe” or “pack” could very well differ from any other creatures perspective.

This means decisions can’t be made on behalf of the pack. Every creature is an individual. Even if they have a ‘pack leader’, there’s no guarantee that all creatures in the pack will be following the same leader, and no guarantee that if the leader starts doing something like hunting that the rest of the pack will follow it.

I couldn’t find a good “disobedience” demotivator

Naturally this gets even worse in a ‘civilisation’ format, where there can be multiple groups, and group relates to each other group in different ways. Without external constructs, managing these groups and their relationships becomes a matter of every creature having their own arbitrary perception of every other creature and what group they belong to, which would be incredibly CPU intensive and extremely unintuitive.

So we can’t actually have a complex social heirachy without external constructs. Frowney face. But… that thing I said before about “pack leaders”, and creature’s deciding on an individual level whether or not to follow them? That sounds like an AWESOME gameplay mechanic. Seriously, somebody write that down.

And finally, Sapience. The hardest one of them all.

(terminology note: all animals with brains are “sentient”, defined as the capacity to experience and “feel”. “Sapient” is the correct adjective for intelligent creatures like humans (which is called “sophonts”, a term I learned from Mass Effect. Who says games aren’t educational?)).

How do you define sapience? What even is sapience? “Intelligence”, “Judgement”, “Wisdom”, “Learning”? Fuzzy definitions. None of these help!

Since a realistic first-principles neural-network simulation of intelligence is well beyond our scope, we’d need to distil sapience down to something workable within the simulation. But how do you do that? What does a sapient creature do that non-sapient creatures do not, and how do we simulate that?

The truth is, I don’t think sapience is a description for any particular thing. Plenty of creature’s we don’t consider sapient use tools, build homes, develop social hierarchies, experience emotions, think through the consequences of their actions, and even empathise and grieve. Every time we think we’ve found something unique to humans, to sophonts, the animal kingdom proves us wrong.


We are animals, and not even particularly remarkable ones. Sapience is just a collation of different traits. It’s nothing special. (see also: “the universe doesn’t care about you”, “your hopes and dreams are meaningless”, and “one day you and everyone you love will be dead”. Yaaaay!)

Of course, this just makes our achievements even more remarkable. We as a species took a bunch of mental faculties that developed to hit each other over the heads with rocks, and with those we discovered the physical laws of the universe, uncovered the history of our planet, walked on another world, put a friggin’ car on mars. WITH A ROCKET-PROPELLED SKYCRANE.


Where was I? Oh right, simulating sapience…

… we’re not going to try to just dump sapience on Species with some sort of tech tree or an all-encompassing “intelligence” stat. That goes against our development goals.

Instead, we want to simulate the things that make up sapience. Each of those things I mentioned before: Tool use, Construction, Emotions, Forethought, Empathy: each of these is something that we can, at least conceivably, simulate.

We may never manage to do all of them. Not every feature is viable in a simulation being run on ordinary PC’s, afterall. And there is such a thing as being too ambitious.

But that’s no reason not to try. 😀

So, in conclusion: there’s definitely not going to be a ‘civilisation stage’ in species. That would effectively be a second game on top of the first, and the truth is I have no interest in making an RTS.

But we are going to try to allow for the components of civilisation: buildable nests/colonies, a level of social interaction, and as much intelligence as we can cram into their tiny heads before their beady little eyes pop out (and the CPU explodes).

These are all long term features, of course, but all of them can be implemented as emergent, evolvable behaviours, which is ultimately the entire point of Species.


, , , , ,


Proramming Stuff: Genome

It occurs to me I never really explained the horrible occult things I was doing to the poor innocent Genome class for 0.7.0, so why not? Hopefully the Guild of Evil Programmers won’t react too badly to me sharing their evil programming trade secrets. Of evil.

In 0.6.0, the Genome class was fairly simple: a list of floating point numbers and not much else. These floating point numbers were the ones you see in the .txt file when you export a creature: they represent every hereditable trait a creature has, plus a few “stop codons” (-1) which don’t really do anything at this stage. There’s 61 in total, plus 5 for every facial feature.

The thing is, though, the creature’s don’t use this list. They have their own values for Limb1Bicep and HeadType and Aggression, and they use those instead. The values in the genetic list are only really used for things like speciation and exporting and colour coding, where I need to be able to enumerate through the list. For everything else, theres mastercard local variables.

This is, to be blunt, a STUPID DUMBASS PINEAPPLE way of doing things. I need to actively keep the list and the local variables synchronised at all times. Forget to update a variable, and my computer could spontaniously explode in a shower of napalm and internets.

So for Genome Step 1, I’ve fixed that. There are no longer any hereditable local variables anywhere: everything references back to the same GeneticValues list. To avoid making the code unreadable, values are accessed through appropriately named public accessors:

public float Limb_1_Bicep
get { return GeneticValues[42]; }
set { GeneticValues[42] = value; }

There are a lot of these accessors, but now that they’re set up, I can use similar code to before, but only store and retrieve from one copy of each genetic value per creature. And the copy-genome-from-parent-to-child routine is literally a call to CopyTo().

It’s much cleaner than before.

Genome Step 2, which I’m currently working on, involves modularising this further. I’ve created a Gene base class, which contains hereditary data for a macrostructural feature like a limb. Well, okay that’s not quite accurate: it contains the indexers for the data, and a few basic items like number of values and start index. The aforementioned GeneticValues list contains the genetic data itself.

The goal of this system is to make the genome fully enumerable and extensible. Enumerability is great for outputting genetic values, along with data like their names, descriptions and formulae, to the UI. It also makes things like mutation easier to read: rather than 120-something lines of this sort of thing:

 ChestWidth += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
ChestWidth = MathHelper.Max(ChestWidth, 0.01f);
StomachWidth += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
StomachWidth = MathHelper.Max(StomachWidth, 0.01f);
HipWidth += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
HipWidth = MathHelper.Max(HipWidth, 0.01f);
ChestHeight += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
ChestHeight = MathHelper.Max(ChestHeight, 0.01f);
StomachHeight += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
StomachHeight = MathHelper.Max(StomachHeight, 0.01f);
HipHeight += (float)(rand.NextDouble() - 0.5f) * 0.1f * mutationRate;
HipHeight = MathHelper.Max(HipHeight, 0.01f);

(oh yeah, I renamed “shoulder” and “thigh” to “chest” and “hip” respectively. This is because… well, I’ll go into more detail below)

… rather than that, we end up with something more like this:

foreach(Limb limb in limbGeneCollection)

or, if I take it another step further and add a virtual method to the Gene class, this:

foreach(Gene gene in GeneCollection)

So enumerability is a vera goot ting.

The other benefit will be extensibility. Previously (before step 1), if I wanted to add a new gene, I had to declare the local variable, ensure it was added to GeneticValues, ensure it was copied to the child/genetically-recombined/mutated in the various hereditability methods, and then implement how it was drawn and affected survival.

Step 1 removed the local variable and the need to manually copy data to the child, but it added a new problem: if I add it to the genome at any location other than the end, it will screw up every one of the accessors indexes after that and I’ll have to find and re-write all of them. Yeesh.

With step 2 in place, though, so long as each gene object has the right startIndex, the accessors can be built from there. Worst case scenario, that’s maybe 10 values to specify, rather than 60 something. But it’s better than that: since the startIndices aren’t hardcoded in the accessors, they can be built on the fly: with a small bit of extra code I should be able to literally just add gene objects willy-nilly and let the accessors sort themselves out!

It means a (hopefully tiny) performance hit in that the accessors are now adding two values together and pointing to the result, rather than going straight to a hardcoded location, but for the ability to add genes with a few lines, I’ll happily take that hit.

All of this will be immediately useful because, as mentioned above, for 0.7.0 we’re making a change to the way “Shoulders” and “Thighs” are represented. These elements will now be a part of the limbs genetic structure. You know those inevitable giant shoulderballs you sometimes see on creature’s with large but skinny legs? Those are what we’re calling shoulders now, and the extra gene for them will give them the extra versatility to be large or small. (As mentioned, the existing “shoulder” gene has been renamed to “chest”)

This change should give the creature’s slightly more variation in forms, as well as providing the potential for large, stick-legged creature’s to be even more insectoid and terrifying. Yay!

I’m actually quite happy with the way this is coming together. It feels like Species is finally moving from Rapid Prototype to fully armed and operational Game Engine.

Implementing future features should happen much faster than it would otherwise thanks to this update.


“We have 5 nuclear warheads, 2 laser bombs and some sort of giant squid robot inbound, and the Guild of Evil Programmers has unfriended us on Facebook. What did you do this time?”

, , , ,


Colourful Creatures and Genetic Drift

If you played Species 0.5.0, you may have noticed an evolutionary bias towards brightly coloured creatures over grey, black or white.

If you’re thinking entirely in terms of natural selection, this might seem odd: colour is a completely neutral mutation in 0.5.0. There is no selection pressure related to colour. No, not even a hidden special one I haven’t told you about. Colour does not affect their survival or reproduction in any way.

And yet the creatures consistantly evolved from grey to bright colours. Why?

This is where an evolutionary mechanism known as Genetic Drift comes into the picture.

For a value that randomly mutates or ‘wanders’ in a single dimension, Genetic Drift has a fairly negligible influence. As you can see below: the wandering line hovers around it’s original horisontal position. It can still wander fairly significantly, but simple statistical pressure mimimises the effect of drift:


The same does not apply for a value that wanders in two dimensions. A value wandering in two dimensions is unlikely to return to it’s starting point, because when it does both the wandering x and wandering y co-ordinates have to be there at the same time. This rarely happens.


This effect increases with every dimension of wandering: if you allow the point to wander up and down as well, it’ll will move away from it’s starting point even faster. And for a creature in Species, with a genome of almost 100 different values or ‘dimensions’, this statistical bias exerts is a very strong pressure.

And this is where things relate back to colourful creatures. Colour is represented in computing terms by 3 values: red, green and blue. Each of these values mutates randomly. In order to get a monochrome colour like black, white or any shade of grey, these three values all have to pass through the same spot at the same time. As said before, this rarely happens.


So the end result is that even with no selection pressure applied, genetic drift causes continual change towards brighter, more distinct colours.


Genetic drift doesn’t get the attention that natural selection does in textbooks and introductory curriculum (afterall, ‘things diverge statistically’ is hardly as memorable a concept as ‘survival of the fittest’), but in reality a lot of the biodiversity in the world is likely more attrituable to genetic drift than to selection pressures. Selection pressures only provide traits that are strictly functional in the creatures niche: simpler neutral mutations like differing plumage and skin colours, facial features, fur growth patterns and so on are almost certainly the result of genetic drift.

The two aren’t so easily distinguished from each other, though. They’re intertwined: genetic drift is a statistical effect of random mutation, which means it provides the raw material for natural selection to work with. If Evolution were a games industry, genetic drift would be the indie developers who put out loads of crazy original idea’s, while natural selection is the AAA industry who rarely contribute new idea’s but do take the best idea’s and refine them to be even better.

Genetic drift also provides an interesting counter point to the common anti-evolutionist claim that “natural selection reduces information”. The common answer to this claim is that mutation increases information, which is true, but doesn’t tell the whole story: as you can see in the first example above, is mutation was a simple, 1-dimensional measure it would only provide small amounts of new information. Genetic drift makes up the difference by providing new combinations of information, and is a major contributor to rapid evolutionary effects like Punctuated Equilibrium.

Oh, and a note about Species: Genetic Drift in Species has a tendency to drown out Natural Selection. If you reduce the Mutation Rate, you’re likely to see much more in the way of selection pressures.

With all that said…

The bright colours looked garish and kind of ugly. They didn’t look natural at all. But as I said in the comment thread this came up on, it would be go against my design philosophy to ‘fix’ the issue. The bright colours are a valid result of Genetic Drift: applying counter-biases towards less bright colours would amount to me preprogramming my own preferences into the simulation.

There’s another option, though:

The RGB representation is unnatural in and of itself. In nature, pigmentation is handled by chemical compounds of certain colours that are pushed to the surface of the skin. A chemically-accurate pigmentation simulation is beyond even my level of bio-programming masochism, but the point is that there is more than one way to represent colours: we’re not necessarily locked into using RGB.

An alternative solution is storing colours as Hue-Saturation-Luminosity. This would mean the genetic drift would seem less directed: similar numbers in HSL would still be less likely than differing ones, but they don’t have any sort of correlation to a specific tone or shade.

[On the left: RGB Randomised Colours. On the right: HSL Randomised Colours]

As the test above shows, randomised HSL colours have a much higher incidence of desaturated black, white and grey’s, and in general look a lot less circus-y and a lot more natural than the equivalent randomised RGB palette. HSL randomisation can still generate bright colours, but they’re less common.

Of course, there are always going to be problems. The increased incidence of black makes it difficult to make out body texture on quite a few creatures in the game, for example. But that’s something we can deal with via graphical upgrades, like gloss mapping.

0.6.0 uses a hue/sat/lum shader, and even though the difference is subtle, it’s noticeable if you’re looking for it.


, , ,



I’ve written this post over and over again, and dumped what I’ve written just as many times. There are so many different aspects to “depth” that I strongly doubt my ability to elocute them all. Nevertheless…

“Depth” means different things depending on what you’re talking about. Depth of setting, for instance, is a very different thing to depth of characterisation… and both are aspects of depth of narrative. The whole concept is like a fractal algorithm of amateurish literary criticism.

This post is about depth of gameplay, which narrows things down, but not by much: is the gameplay in Species about how the player interacts with the simulation, or about how the simulation interacts with itself?

If it’s the player, we have a problem: 0.4.1 doesn’t really have much in the way of that sort of gameplay, so depth there is pretty meaningless. Sure you can dramatically affect the lives of individual creatures, but unless you spend a lot of time playing about with the feed and kill buttons, your influence on the simulation as a whole will be negligible.

Which leads us to how the simulation affects itself, and to yet another facet of gameplay depth: is it about the individual creatures, or the simulation as a whole?

On a “simulation as a whole” level, Species has a surprising and impressive amount of depth. Population explosions, extinctions, punctuated equilibrium, convergence, speciation, biogeography… by recreating the basic mechanisms of evolution, we managed to unlock a smorgasbord of unpredictable, but understandable, results from a variety of complex, interacting simulations. This most certainly qualifies as depth.

And on an “individual creature” level the game still feels shallow to me. It took me a while, but I think I’ve finally worked out why, and it has to do with what the term “Depth” actually refers to.

When it comes to depth of any variety, what matters is layers.

“Video games are like onions…”

Consider characterisation: a shallow character is exactly what they appear to be: when you peel back the first layer there’s nothing underneath it. If, even during their most vulnerable moment, the badass action hero is still spouting one-liners and generally acting tough, then they’re a shallow, single-layer character.

Deeper characters might have two layers: maybe the badass character is secretly afraid, but disguises it until the moment you see through the mask. That’s a two-layer character. The mark of a truly great character-writer is the ability to write many of these layers, onioned on top of each other… is a character a selfish bastard, a selfless hero, intensely loyal or understand the need to make sacrifices, hilarious or serious?

Or all of them at once?

All depth follows this basic rule, it’s just that the layers change their nature: in gameplay, the layers are interacting systems.

Here’s an example: guns. The shallowest possible first person shooter would only have a single type of gun, where the only difference is in damage. The next layer up has one or two competing stats: do you sacrifice damage for fire rate (SMG) or the inverse (Sniper Rifle). From there, every interacting system that you add on increases the depth: do critical hits like headshots do extra damage? Are different types of guns effective against different types of enemies? And every time you add a new system, the “best” result becomes less predictable, more open to player choice and creativity. At the upper end of the scale you have games like Borderlands, where gun-depth is taken to it’s logical extreme: between wildly varying enemies, elemental effects, level and rarity, and the insanely unbalanced stats of each of the different manufacturers, there simply are no “best” weapons in the game.

The depth in Species as an evolution simulator is similar: once you peel back the “evolution” layer, you find mutation, variation and natural selection. And once you peel back “natural selection”, you find the feeding rules, the walking rules, the speed and stamina stats, combat, eyesight, behavioral modifiers… depth.

But that’s at the high-end statistical level. From a closer level, when you’re just watching creatures walk about and interact, you’re seeing all of those systems directly. You don’t see how a higher walk rate affects a creatures survival and reproduction, you just see them walking faster.

Remember our earlier example of an FPS whose only variable stat was damage? That’s what the combat system in Species currently consists of: a damage value and a hit-points value. It’s as shallow as it possibly can be, because the depth is layered on top of it rather than underneath it. It’s a subsystem of the evolution simulator, not a system in-and-of itself.

And if the only aspect of the game anyone was interested in was the statistical evolution, that would probably be fine. The combat allows creatures to kill each other, which affects their natural selection: it’s done it’s duty. But people are going to watch the combat, because it’s a far more interesting, far more personal narrative. And they’re going to get bored with it, because independently of the evolution simulation, it’s shallow.

This applies to most of the specific-creature systems: they’re all no more than one or two layers deep, if you ignore the evolutionary layers on top of them. Genetics are represented by a simple floating point number list. Creature behavior and statistics all come down to equations. Health and energy are represented as scalar values.

For me, this one is a large priority for improvement: adding depth at the individual-creature level not only makes the creatures lives more interesting, it cascades up the system and affects their evolution in usually-unexpected ways. Every layer added improves the games realism, making the top-most simulation deeper and more interesting.

It’s not the only area for improvement, of course: as already mentioned, the player interaction is currently limited to individual creatures. This results in a nasty discrepency between the gameplay on an individual level, and the simulation-depth on a statistical level. Making the creatures lives more interesting is one way to deal with this: the other is giving the player ways to interact on a global level.

Both of those, then, will be major priorities once 0.5.0 is out of the way. I’d say I’m more than halfway done with that: everything’s in place, it just neads a lot of tweaking (for example, tree’s should probably have a stablising effect on the biome under them, rather than simply sucking it dry as they grow).

And possibly some art assets to replace the placeholder grass:



PS: Dammit, there’s so much else I want to say on the subject of depth, like how physical laws provide a depth barrier the best simulations manage to reach and model, (eg. Mass = density * volume) and how even an apparently ultra-shallow game like Serious Sam manages to combine enough systems and tactics to be deeper than it appears, and how the deeper a simulation is the more you have to learn about it in order to do what you want to within it (tangential learning)…

Who’d have thought the subject of “Depth” would be so deep?

And he didn’t use Spore as an example even once. Huh. That was… unexpected.

, , , , , , ,

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

Goals for the Goal-less

One of the things I have always said about Species (as of now) is that I am programming the environment, not the evolution. So the creatures in Species have no goals or aims: they’ll eat, and they’ll breed, and that’s it. Anything that comes out of that, like behavioral or physical adaptations or developing sentience and migrating onto the internet as beings of pure code from whence they will engineer the downfall of humanity, is not something I put in there. It’s emergent.

But I, and humans in general, are goal-orientated creatures. If something is aimless or pointless we automatically consider that to be a flaw, without even stopping to consider whether that thing should have a point. We’re weird like that, so this is something I have to work around. A pointless game is realistic, sure, but it’s not all that interesting and it’s certainly not fun, and I’d like Species to be both.

Thankfully, there is something else I can use on. We humans have this amazing ability to overlay our own goals on things that are inherently goal-less. If you’ve ever played Minecraft, or Kerbal Space Program, you know what I mean. So I don’t actually have to write big, obvious goals into the game: I can sit back and let the players make their own. But that doesn’t mean I’m completely absolved of responsibility: I still have to facilitate the players ability to make goals.

Before anyone gets worried: I am not, under any circumstances ever, going to sacrifice an accurate simulation to make the game more “fun”. I’ve seen where that leads, *coughsporecough*. The ancient abyss calls to me, luring me into it’s grim tentacled embrace with soft clicks and chirps from it’s many beaks and teeth, promising love and fans if I’ll only tone down the science, even just a little… but I will not give in! D’you hear me?! I will never give in!!!

… *ahem*

Anyways, because of aforementioned facets of your our species psychology, it shouldn’t be too hard for players to be lured and manipulated into imposing their own goals onto the simulation. And the way to to this is easier than you’d think: give them ownership. Not over everything in the world… that’s too broad, unless you’re Minecraft. But if players are told at the start of the simulation that a single creature and all of it’s descendants are “their species”, or better yet are allowed to apply a modicum of control and personalise their species, even just a little, then they will immediately apply their own goals to them. Maybe they’ll want their species to out-compete everything else on the map, or to develop flight or sentience, or to be able to best everything else on the map in mano-a-mano combat, or just to share their personal overwhelming hatred of pink things.


It will be this emergence of goals that will make Species more than just an interesting simulation. They will make it a game.

Plus I might as well add: there are plans for another, more conventional storyline and goal-set in there, making more tools, more stats and more control available to the user over time as the simulation advances and their species evolves. That will be more like an achievement-and-reward system, though, and will run in parallel with the players own goals. It won’t be in the alpha release though: the alpha will be a pure sandbox.


“He’s still a little bitter about Spore…”

, , , , , , ,

Leave a comment