Archive for category Game Design


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).

Throw logic out and do the impossible, that’s the way pangolin’s roll

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”

, , , , , ,


0.7.0 Voting Competition

I’ve come up with an idea…

Here’s the deal: every two weeks, you (yes, you) can vote for a new body part to see in the game. We’ll put up a choice of 4 new body parts each fortnight.

The winning body part of each round will be modelled by our artist Jade and added to the mutation map in 0.7.0…. if, and only if, gets enough unique visitors that fortnight. (“Unique visitors” includes returning visits, so coming back the next day to check the forms or wiki counts!) Last fortnight we had 5322 unique visitors: for the first round, we’ll aim to roughly match that. To keep things interesting, we’ll adjust the target after every round.

So, without further ado, your choices for the first 0.7.0 Body-Part Voting Spread-The-Word Competition Thingy (working title) are:

* Crocodile Longjaw *
* Housefly Probiscus *
* Zoidberg Tentacles *
* Halo Elite Split Jaw *

Vote here: (you’ll need to register to the forums to vote)

So go forth! Spread the word, join in on the forums, and remember to vote. The winning head type will make it into Species 0.7.0 if we get 5000 unique visitors before the 15th of September.

(Edit) Suggestions to help make sure we get enough visitors!

Visit the site, post on the forums, even try updating the wiki (it hasn’t been updated since 0.4.1!)
Like/Share our Youtube Gameplay Trailer (and subscribe to the channel if you want to see more of the same!)
Like/Share our facebook page
Link to us on twitter (though my twitter account is basically just a blog feed, so best just to skip it and link straight to
Mention us on your blog/in the comments on relevant blogs/on tumbler/on reddit… anywhere you think people might be interested! 😀
\/ Or just use the buttons below to like and share this post around \/

, ,


Species 0.7.0 Dev Plan

So. We’ve updated the Environmental systems in 0.5.0, and the Gameplay options in 0.6.0: it’s time to go back to basics. 0.7.0 will be the Utilitarian Update, focusing primarily on the backend systems behind simulating and displaying creatures.

As the name suggests, this will not be a big fancy update. We’ll be upgrading the elements that have been left behind in quality as everything else has improved, so there won’t be any brand new features: just improvements on old systems. But that doesn’t mean there’s not going to be loads of awesome stuff! Our goals for this update are:

Code Cleanup And Modularisation

Okay, boring stuff out of the way first. This update will serve as the foundation for more impressive updates in the future, so the code needs extensive cleaning, with a focus on object orientation and modularisation. This part of the update is about turning what is essentially a glorified prototype into a solid, extendable game engine.

This step will probably contribute more to the long term development of the game than anything I’ve done on it so far, so for all it’s boringness it’s worth the investment.

Creature Simulation

A few simulation-centric elements to address, mostly centered around the gameworlds physics:

– physical values. Switching the underlying stat formulae from generic, relative values like “size” and “stamina” to deeper, more realistic values like “volume”, “mass” and “surface area” will improve the simulation’s accuracy and ultimately result in more accurate and emergent evolutionary pressures. It will also allow us to make use of real-world relationships between variables (for example, the laws of thermodynamics, or newtons laws of motion) rather than trying to make our own rules via trial and error.

– metric units. Tying in with the previous point, metriking the game will make it more scientific and easier to program based on actual, physical laws. For all those who would rather we use imperial units… pfffHAAAAAAAHAHAHAHAHaHaHaHaHahahahahaaah.

– the vertical axis. At the moment, Y position has very little influence on the game: Species is basically a 2d game playing out in a 3d environment. This will change that, by introducing gravity and bouyancy as actual forces on the creatures, applying modifiers to eyesight based on head height, introducing a neck range which affects what plants a creature can and cannot eat, keeping them from hovering, preventing needle legs and necks, and so on. And I’m sure you can imagine one or two planned future elements which will rely on vertical physics to work…

– LOD. The level of detail system is a mess, combining two or three seperate systems for creature animation, detail and the far-distance sprite imposters. Replacing and optimising it should be worthwhile from a performance and visual standpoint. (this point ties in with both Cleanup and Aesthetics as well)

Creature Aesthetics

You didn’t think I’d stop with Procedural Texturing, did you? Improving the creature aesthetics will involve three more steps this update:

– Under/Over textures. Tri-planar texturing should allow us to apply a different texture to the creatures back and underbelly, giving them more definition and a better appearance overall.

– Manually applied textures. Some textures, such as those for claws, teeth and mouthes, should be tailored to the body part they’re applied to. This will give creatures face and limbs more definition and allow us to give the creatures even more hideous faces than ever before.

– Fur. Not High Level Shader Fur: that’s too much of a performance impact, but fur polygons, like what Skyrim has. You can see it best around the edges of this image:

I have no idea how well this will turn out, but I desperately want to try it out and (in theory at least) it’s performance impact should by limited to the GPU. We’re just trying this as an experiment, so no promises it’ll make it into the game. This is not really an essential feature so much as developers prerogative, and that’s me so I get all the prerogratives. ALL OF THEM.

(You may have noticed that I haven’t mentioned Normal Mapping or Gloss Mapping here. The reason for this is simple: we’re prioritising Aesthetics over Graphics. Mapping techniques are fascinating and valuable tools in their own right, but ultimately they’re varnish. If the creatures look terrible without them, they’ll look shinybumpyterrible with them, and shinybumpyterrible is still terrible.)

– We also want to add basic procedural animations for eating tree’s, corpses and grass. This won’t be anything complex, just moving their heads into the appropriate position, but it should provide a bit more context to the creatures behavior.

Creature Content

Saving the best for last: we’ll be bringing all the stage 1 placeholder assets up to at least stage 2 placeholder assets. That’s a technical way of saying we’re going to be deleting many of the current assets and adding wider variety, more gradual evolutionary stages, and better-looking textures and models for:

– Body Coverings. Since we have to remake the body textures anyway for the aesthetic upgrades, we might as well start over, giving them a detailed mutation map as well.

– Legs. We will be including a whole bunch of new animated limb shapes, which will mean even *more* hideously surreal creature forms. Yay!

– Facial Features. More variety in eye and horn styles and textures, and couple of new general categories of features.

– Heads. We won’t be completely overhauling the head models (they’re already a stage 2 placeholder), but we will be redoing the existing ones to work with the new graphical system and adding a number of new ones.

And that’s the plan for the next update. Let us know what you think below, or leave us suggestions over in the Suggestion Forums.





There’s not too much to say about the obvious mechanisms of the 0.5.0 in-game grass: it uses the billboard system which I explained a while back. I could mention the other technical details: it only draws a few, nearby, vegetation nodes, grazing affects the length of the entire node, it fades out at a distance because there’s way too much of it to draw it across the entire map… okay, done that, now what?

Well, seeing as how talking about implementation is boring, I guess we might as well talk about the design aspects.

The moment I decided on grazing as a feature for 0.5.0, I knew I’d have to represent it somehow. The grass itself, though, wasn’t originally meant to be that representation. Indeed, I’m still not entirely convinced that grass is the best representation for it: rendering grass has limitations that make it less than ideal.




Okay, I’m in the middle of typing up this post and I’m beginning to realise that the height of the billboard grass really isn’t the best way to represent grazable material. That’s what I get for blogging about a feature I’m in the middle of coding. Oh the joys of an evolving project.

Okay, new approach: I’m going to use this post as an opportunity to get my thoughts in order before I go off and play with the code a bit more.

The plan (prior to about about 30 seconds ago) was to include a grazables container or bucket within each square of terrain. This container would contain all the energy that creatures could graze from, and how ‘full’ it was would determine how long the grass in that square was. Fertility loss due to grazing would occur when the bucket was empty and had to ‘buy’ more energy to regrow.

Documenting my design decisions. I am a professional and I act like a professional.

The big pro to this approach is that grass height shows you at a glance how much grazable energy the local area has. Unfortunately, there’s also a lot of cons:

– all grazable scatter-material grows like grass and is edible, regardless of what it actually looks like. This includes pebbles on rocky terrain, shells on the beach, salt in a salt plain, and lava rocks in lava.
– grass in an area is all the same height. Since an ‘area’ is an exact square of roughly 10m x 10m, this would be especially noticable at borders where grass on one side is short and grass on the other is long.
– fertility loss is applied on an area-scale, not on a local one. A creature eating at the very corner of an area will affect the fertility of ground 14.1421m away (+/- 10m, anyway. Oh who am I kidding, I have no idea how big the vegetation squares are), while not affecting the ground just behind it.
– Grass is invisible at a distance, so you can’t see the direct effects of grazing from far away.

Yes, the rocks are edible. Why wouldn’t the rocks be edible? Stop being so carbon-based in your thinking.

Now, all of these are things that can be dealt with to eliminate or reduce their effect: scattering a squares vegetation a bit beyond it’s border would blur the straight line between squares, by applying fertility loss on a macro level makes it less apparent that it’s related to overall area and not to the actions of individual creatures.

But what if we could deal with all of these problems just by changing the way ‘grazable energy’ is stored? This is the idea I’ve just had:

Eliminate the energy buckets in terrain squares, and effectively remove all terrain-based control over grazable energy. Grass no longer has any limit: creatures can just keep grazing and grazing within their biome… until the biome changes.


With this system, a creature emits a ‘death aura’ while grazing, gradually reducing the fertility in a small area directly underneath themselves. Eventually, the biome under them degrades. This introduces a direct correlation between fertility and energy: a creature absorbs fertility from the ground and gains energy in exchange.

Do vegetarians usually suck dry the very soul of the planet? Oh no wait that’s vegans. Ba-dum tchch! (teasing vegans. I’m so original)

Since grazables are no longer dependant on area but on biome, we’ll be able to introduce a variety of biome dependant statistics (starting with a simple isGrazable boolean) as a central function of the simulation, rather than as something tacked on afterwards as was originally planned.

A conventient bonus is the fact that the ‘death aura’ code already exists, in the form of biome stabilisation from trees. The only difference is that where tree’s stabilise the habitat they’re best suited for (with the exception of some unbalanced pioneering species which make the simulation more dynamic by stabilising towards biomes they can’t survive in), grazing creatures stabilise the habitat towards arid, desert biomes, and then have to move on to find more grass.

Of course, I’ll have to rework some of the code for this: the ‘buckets’ system already exists in the development version. But that’s the nature of prototyping.

[The following day]

Welp, that’s done. This actually makes the environment feel a lot more ‘directed’, since you can now pinpoint the source of every fertility change: it’s either grazing creatures, trees or water. I might have to add a few more fertility-change sources, just to make it less predictable.

Ultimately, this change leaves the grass itself as little more than an aesthetic item. Oh well: the system’s in place now, it’s useful in defining the presence and quantity of grazable material in each biome, and when even the placeholder art looks good, you know you’re doing something right..



He doesn’t mean it about the vegans. We actually think vegans are pretty awesome: it must take a lot of willpower and strength of conviction.

Please don’t kill us with your psychic vegan powers.

, , , , , , , , , , , , , ,



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

Genetic Programming and Limb Physics

Note: I realise my blog update schedule hasn’t exactly been regular recently. Truth is, I’ve been at a bit of a loss for things to write about. I could use some ideas. (The fact that I’ve been posting loads of potential blog material over on the forums instead of here probably doesn’t help).

I’ll try to get back to a every-Tuesday posting schedule in coming weeks, assuming I can think of something worthwhile to write about. In the meantime, here’s some disjointed thoughts.

* * * * * * * * * *

Species is a Genetic Algorithm, but it is not Genetic Programming.

Genetic Algorithms use mutation and selection to find the optimal solution to a problem. The problem to which Species looks for a solution is simply “survival”, in the context of the games environment, which adds some complexity and depth to the “problem” side of things, but the “solution” isn’t actually hugely complicated.

Creature Genetics in Species are simply a bunch of one dimensional numbers. There are exceptions, but most of the genetic values in Species can be represented as a simple slider. So the evolution in the game is simply pushing these sliders up and down on their axes. The interactions and dynamics between the ecosytem and the statistics add quite a bit of depth but ultimately it’s not a particularly deep solution.

The concepts of genetic programming are quite a bit deeper. Genetic Programs use a noded ‘tree’ structure: rather than pushing numbers up and down, mutations in a genetic program add and move branches of the tree around. These branches might refer to packets of code, if()then conditionals, or loops. Or, if we take the analogy a bit more literally, they might refer to branches.

This is actually closer to the way real-life evolution works, and I would quite like to implement some of these concepts into Species. GP concepts are much, much better at producing unexpectedly novel structures and behaviors.

Unfortionately, GP structures don’t evolve very fast, and Species is about *seeing* evolution in action. That video above encompasses 7 hours of evolution. This was exactly the problem I had with the original behavioral system, which used some similar idea’s: it was too complex and didn’t evolve fast enough to be relevant to the simulation. When I replaced it with the simpler aggression and social sliders, it became much more responsive to selection pressures.

But like I said, though I don’t have GP, I want it. I want it a lot.

* * * * * * * * * *

I am jealous right now, as I often am when looking at other evolution sims.

I cannot *begin* to describe how much I would *love* to build something like this into Species.

Unfortionately the only way to achieve that is to work out a way to fake it: physics like this is deadly to the framerate when you’re simulating more than one creature. Simulating 1500 is well and truly too much.

So… faking limb physics. My initial thoughts are that there are two ways to do this: top-down, or bottom-up.

The former involves Inverse Kinematics. The genes give us an indeterminate limb-shape, and at birth an IK algorithm takes that limb shape and makes it walk as best it can, similar to the way creatures in Spore could walk no matter the shape of the legs. We then reverse-engineer stamina and speed stats from the step motion.

The disadvantage to this is that even though the legs might look different, they will all be animated the same way. There won’t be any novelty to the motion. On the bright side, that motion will probably be (relatively) crisp and clean: the feet will reach the ground and will provide a good appearance of ‘pushing’ walking creatures along.

The second method is bottom-up: we give every joint in a creatures leg a ‘motor’ to run it, a few paramters to determine step size and speed, and we try to somehow analyse the result to give us a constant speed, or even better, a variable one. This is a painfully difficult method: it will cost a lot in terms of performance, and the physics probably won’t look great, but if it works it could have a lot of potential. The trick is in working out exactly how to *make* it work.

One possiblity is that ‘step size’ could be limited to fractions of a particular value. So step sizes could be 1.0, 0.5, 0.25, 0.2, 0.1… but not 0.8 or 0.3 or 0.15.

This would make the limb-movement cyclical, and we could simulate a single cycle of motion at birth to determine how fast the creature can move. This is an expensive operation, however, and might result in noticable lag-spikes during births if poorly implemented. It also has a limitation: if the creature moves forward in jerks and bounds, a constant movement speed would not register that and the creature would look like it was gliding (although there might be ways around that, maybe, I hope).

Don’t get your hopes up just yet, though. This is all very much long-term stuff, which I probably shouldn’t even be discussing publically, but hey: I had to post something. And this is the sort of stuff I consider for Species. 🙂



Defining Species

One thing about Species that I keep stressing, but which is easy to forget even for me, is that the simulation is random. It’s easy to say that a species “decides” to splinter from the main population and speciate, or to say that they’re “trying” to develop eyes and legs. But all of that is pure personification on our part: it’s like saying the ocean “decides” to have tides, or the clouds are “trying” to rain.

The ‘species’ category is a perfect example of this. I was showing a friend the game and caught myself saying that “once it comes back down from the population explosion, the simulation will make them speciate”. But that’s not how it works at all: the simulation doesn’t make them do anything. They don’t have to speciate any more than a million proverbial monkeys bashing on typewriters have to produce the Twilight series. The simulation simply detects speciation/vampire-romance after it occurs.

I could have adopted the top down approach, and made speciation something that the game makes happen after a certain amount of time or in response to certain events. That would probably have been much lighter on performance, and easier to code to boot.

But it would also have been cheating. Real life approaches things from the bottom up.*

So the speciation routine has no influence on the simulation. It’s completely passive, an exercise in analysis and display: computer-generated taxonomy. The creatures don’t know or care what species the game thinks they belong to, and the simulation would play out exactly the same with or without speciation detection. Whether or not creatures can mate is determined on an individual basis, not based on species.

This has allowed for some fascinating and unexpected effects. Quite often, a ‘speciation’ of a single creature will happen, appearing as a pixel-wide line on the population history. This is the result of a creature being born sterile (ie. mutated heavily enough that it is unable to mate with anyone else in the population). Since the creatures can reproduce without mating this creature can still have descendants, and may well become a stable species in it’s own right.

(Worth noting: a creature cannot be born into a new species, because a speciation test isn’t done for births: a newborn is simply given it’s parents species. If it is born sterile, it will speciate when the parent dies and breaks it’s link to the main population)

This system also makes for an interesting design challenge. See, two things that would make the simulation more interesting are an increased mating frequency (increasing the gene sharing and making things like sexual selection more apparent) and more speciation (making lots of small species rather than one large one). But in the current system, these two features are diametrically opposed: expanding the genetic compatibility range and allowing the creatures a wider variety of mates means populations have to distinguish themselves more before the game will detect a speciation.

One solution to this, suggested here by Icefire, is a ‘soft’ definition of species, not reliant on breeding compatibility. My problem with this is that it makes the ‘species’ category less well defined: rather than being “a collection of creatures capable of interbreeding” it becomes “a collection of creatures with an arbitrary amount of genetic similarity”.

But after some thought I decided I’m okay with exposing it for a future version. I think the default should always be the “Hard” definition of species (the game is called Species, after all) but using the softer options will allow you to make interspecies breeding possible.


*footnote: this top-down bottom-up discrepancy is an interesting spanner in the works of the Intelligent Design crowd. Design is an inherently top-down process: a designer starts with a goal and works out the simplest, most efficient method to achieve it. So designed objects tend to be mathematical and precise: straight lines and square corners. Natural objects, on the other hand, take a bottom-up approach: this molecule on that molecule, this rock on that rock, this gene on that gene, all clumping together to make up an object.

A designed room can be represented abstractly as a set of numbers: width, height and breadth for a simple rectangular prism. 3 numbers. A natural cave, on the other hand, can never be represented in full detail, because you’ll never have enough numbers. The unecessary complexity is evidence that it’s natural, not that it’s designed.

Which only makes it more jarring when denialists argue that the incomprehensible complexity of life is evidence of design. It seems like quite the opposite, from my perspective at least.

“Twilight Jokes. Statistically inaccurate Twilight Jokes. Wow, I didn’t think we could sink any lower.

The chances of pure randomness producing a particular work of fiction the length of one of Stephanie Meyer’s novels are quite significant**, and more importantly, are completely incomparible to a force like evolution, which is cumulatively influenced by forces like survival, gene-sharing and reproduction.


115362 words in Twilight * (5.10 (average number of characters per word) + 1.5 (rough guess for spaces and punctuation)) = ~761,000 characters.
1 in 49 = Odds of random key on typewriter being correct.
Odds of producing novel of this length in a single trial: 1 in 49^761000

Size of the universe = 3.1e84 (cm^3) / 4.22e-99 (planck cube volume) = 7.3e+182
Age of the universe in Plank time: 3.3 x 10^60
If trials could be condensed to the size of a cube 1 planck length on the side, and run once every plank time frame, a computer the size of the current observable universe would have performed 2.4 x 10^243 trials.

2.4*10^243 < 49^761000.

Ergo, if you want monkeys typing vampire romance novels, you're better off going into neuroscience or biology than mathematics. They've got better odds in the long run."


Potential Gameplay

For anyone not following the Development Thread:

The planned 1.4.1 release is growing: what started out as a simple polish/hotfix release has become a pretty serious extension to the game. I’m not messing with anything particularly fundamental, so it still plays much the same, but the changes make an impressive difference to the general feel of the game. Everything is a lot more ‘alive’ now.

In addition, being able to import and export creatures will give the player some much-needed interaction capabilities, and the new “UltraTime” capability (currently mapped to the “U” key) will allow the player to turn off the graphics rendering and run the simulation at the maximum speed their computer can handle.

Oh, and the creatures are somewhat less idiotic.

I’ve been trying to work out what this next post should be about. I’m already recording my progress in the aforementioned Development Thread, so that’s out (curse me for stealing blog material and posting it on the forums!). I’ve got a bunch of fragmented thoughts about depth and complexity, thanks to Dwarf Fortress, but I’m still trying to work out how to package them: “depth” in particular is a hard concept to define, and I think I’m still using the word to refer to at least five different concepts at the same time. I’m also out of idea’s for denialist rebuttals and evidential arguments: I always try to take those posts in a unique direction, giving the denalists credit for a decent sub point or using it as a springboard to explore a valid criticism, but right now I think I’d just end up ranting about how they have a lower density of brain cells than the inside of the LHC tube.

So I’m going to talk about the back-story of Species. Because clearly a game like Species needs a back-story.

Okay, that was mildly facetious. What Species really needs, and where the back-story naturally comes from, is a player avatar.

I’ve given this quite a significant amount of thought, but note that this is all speculative at the moment. The current system, where the player is just an camera with a few unexplained abilities, is not much fun. I rather suspect it won’t matter how many tools I give the player: it’ll help, of course, but it won’t solve the problem. The player needs something to call ‘me’.

But what should this entity be? There are a number of choices…

Native Creature. The player could be a creature in the game. There are a variety of reasons I don’t like this idea (‘controlling’, rather than ‘aiding’ the creatures, the fact that the player creature would be capable of things the others aren’t, etc), but I do like the idea of ‘seeing things through their eyes’, so that might have to be something you should be able to do in-game.
Human. Similar to Minecraft: the player could simply be an unexplained, unnamed human wandering around, doing whatever they want. This is the simplest choice, but it doesn’t offer much in the way of explanation: why is there an immortal human capable of time acceleration capability walking about in the middle of nowhere?
God. Something like Black and White: the player could be a deity, capable of interacting with the environment via unexplained means. I don’t mind the idea, but the unfortunate implications put this one well outside the realm of possibility.
Alien. Similar problems to ‘human’, although it adds a bit more interest to the player avatar.
Alien base/ship. Now we’re getting somewhere. Making the player avatar a ‘base’ gives it a few capabilities, including the ability to deploy/control multiple entities (aliens or robots) which return to the ship after some time. But making it alien implies Panspermia. Panspermia is an interesting concept, but it’s not quite the feel I want for the game.
Human base/ship. Getting close. A NASA-style lander, with a series of rovers, captures the feel of scientific discovery and most of the game play elements that I want. We’re close, but I still don’t think it’s just right. I also need a way to define a nursery area.

… which leads us to the option I’ve decided on:

Derelict Artificial Intelligence Building Complex.

“Created by a (probably-long-extinct) native species (maybe human, maybe not, I don’t intend to clarify any time soon), the genetic AI was originally designed to study, protect and preserve the ecosystem, and had a suite of facilities and vehicles to use to that end. Eons later, the derelict structure is accidentally activated again. It sets about the task of repairing itself and studying it’s new environment.”

This idea is my favourite: it solves the ‘nursery area’ problem quite elegantly (the area inside the complex’s walls becomes the nursery), provides me with a variety of potential vehicles, tools and structures (the design I have in mind is an unholy mix of Jurassic Park and NASA), and also provides a motivation which makes sense: the AI itself is as undirected as the player, so even nonsensical attempts to artificially select the biggest head and smallest body are logically consistent with the character.

Back on the ‘vehicles, tools and structures’ front, I’d like to make them semi-autonomous and customisable. So outfit a rover with a health/energy scanner and a food bag and you can send it out to automatically (ie. without input) feed the starving. Likewise, give a rover an a ‘creature-head-size’ scanner and a pair of chainsaws, and you can send it out to “enhance the selection pressure” in favour of large heads. (both of these behaviours would probably require some sort of AI upgrade)

This system allows the player to exercise significant power and artificial selection pressure over the ecosystem without ever actually controlling it directly: the smaller-headed creatures don’t magically die because they had smaller heads, they die because a homicidal chainsaw-wielding rover attacked them. I also want to keep the vehicle cap small: this isn’t supposed to be an RTS, so there will probably never be more than 4 or 5 in your fleet. You’ll need to upgrade those rather than making more if you want them to be more efficient. If you want to make an army, that’s what genetically engineered superpredators are for.

As for structures, at bare minimum we’ll need a garage (vehicles), incubator (genetic manipulation and cloning), nursery (members of your personal species) and storage (food, possibly other resources).

That’s where all this is heading and I’m extremely excited about it: so excited that I need to keep pulling the reins tighter to keep myself from running off and programming them now. The simulation is the most important thing right now: these sort of game play aspects will only be fun while the simulation stay’s interesting.

Doesn’t make me any less excited, though!

“Not that that means much. He’s also been known to get dangerously excited about robot cartoons, fake text games, stick figures and pennies.”


Modding and Mutation Maps

As it turns out, modding is pretty hard to do in XNA. So, the first part of this post will serve as a bit of a ‘how to’ for XNA developers building for PC (it might help for XBox, maybe, but I make no promises). After that I’ll skip to the more species-specific discussion: feel free to skip ahead.

The reason XNA has trouble with modding is its content pipeline, which serves to pre-serialize the game content into an easily readable binary format (*.xnb). This is actually a very smart system: rather than spending loads of time compiling models and textures every time you open the game, it compiles them once on the developers end, saves the result as a part of the game data, and can quickly load it again on the players end without having to do anything complex with it.

But it’s a nightmare for modding, because it means modded parts either need to be pre-compiled to be brought into the game, or the game needs to be shown how to compile the modded parts itself.

Of course, the XNA team are awesome, so they provided the WinFormsContentLoading sample. This sample shows us how to make a program that compiles and renders a model, and can easily be extended to work with Textures and other files, too (well, ‘easily assuming you don’t find one of the pitfalls‘). Perfect! Add that to the game and it can compile modded parts, right?

Not right. You see, for a variety of reasons that I’m certain make sense to someone somewhere, Microsoft have decided in their infinite wisdom that the content pipeline assemblies shall not be included in the XNA redistributable, and XNA developers are forbidden from distributing it themselves. This means that, were I to include mod compilation capabilities in the game, it would not run for anyone who had not installed the full version of XNA. The full version of XNA is free, but installing an entire development environment just to run the game is a bit much to ask.

Interestingly though, restricting compilation does not restrict use. Once compiled, modded parts can be distributed all we like. So, with or without XNA, everyone will be able to use modded parts. They’ll only need to install XNA if they want to make modded parts.

This leads to the strategy I have in place for Species, which could be easily applied to any game. Mod users won’t have to do anything more than download modded parts and copy them into the appropriate subfolder. The Load Content routine, rather than loading a hardcoded number of items, reads the number of *.xnb files in the subfolders and loads them in one by one (it’s not necessary to have them in the Content Project, so long as it can read their filename).

Mod making, on the other hand will be a bit more involved. It won’t actually require the mod developer to use XNA: I’ve created a utilitarian (read: ugly) ‘mod maker’ application out of the WinFormsContentLoading sample, that compiles and copies the *.xnb files. But even so, the mod developer will have to install XNA and Visual C# to use the mod maker in the first place.

We prefer the term "Aesthetically Challenged"

I hope that this will be acceptable for people making modded parts, as it’s the easiest I can make the process at this stage. Thank goodness Visual C# and XNA are free, or it probably wouldn’t even be worth implementing, which would be a great loss in a game like this. Community modding has huge potential to expand this game beyond what any development team could make it, and I’m incredibly excited to release it into the wild and see what people come up with.


If you’re skipping ahead, start reading here.

So, what will be moddable in Species specifically?

In the Alpha release, just body parts. It will be possible to model your own head types, eyes, ears, horns, feet, etc, or to draw your own new body coverings like scales or fur. Add the required stats, copy the files in, and new body parts will appear in the game. Also, technically, you can replace any texture or model in the game using just the mod maker, but that’s just a side effect.

This is only the start though. It takes time to open up a section of the game to modding (without just handing out the source code, which I’m reluctant to do) which is why I didn’t bother opening the vegetation system up. The billboard vegetation will be replaced in the second alpha release with a much more complex and dynamic vegetation-and-environment system, and that will be open to modding. In the long term, I’d even like to open the statistic map to modding: allow the players to add their own selection pressures and stats. That’s an ambitious one, though. At the moment, just making it visible through the UI has been quite a time consuming job.

Subtly pulling the conversation back to body parts (the ultimate conversational topic!), there’s one aspect of that I’ve not yet discussed. It’s one of the last things I implemented, which is ironic because this subject is one of the very first things I started to sketch out when I began designing this game. I’ve even got proof, one of the very first digital sketches I made, a long long time ago:

I'm pretty sure I drew this before I even started using XNA.

Mutation mapping is something I have to be careful with, because I know some people are going to look at these diagrams and say “he’s guiding the evolution”. That is not and never will be the purpose of this system: every mutation goes in both directions, and no mutations are more or less likely to occur than any others.

What the Mutation Map system is doing is not guiding the simulation, it is restricting it. Without this system, if we were to just use a random number generator, it would be entirely possible for a fin to spontaneously become a wing, a duck bill to become a crocodile mouth, a reproductive organ to become a politician, etc. Since such a thing doesn’t happen in real life and is impossible (or at least, extremely unlikely) according to the theory of evolution, this restriction is an important element of the simulation.

It also allows for progressive development amongst otherwise discreet variables. It’s easy to imagine a Species slowly getting larger and larger in the game, because floating point variables work perfectly for evolution, but with discreet variables such as eyes, features will suddenly appear on a mutant creature and then spread through the population. This isn’t gradual at all.

A mutation map doesn’t actually stop this, but it allows it to be a lot less sudden, by including (for example) a light-sensing patch of skin, followed by a better, shaped patch, followed by a very basic lens, followed by a complex eye. It’s also possible to include offshoots at every stage (and recommended: I’m going to try to include as much content as possible in the vanilla game, before we even get to modding). Of course, the light sensing patch will still appear just as suddenly as the eye did earlier (in real life, it’s likely a patch of skin would grow more and more capable of sensing light rather than just appearing), but that’s still a lot more gradual than a fully formed eye appearing out of nowhere.

An interesting point about the mutation mapping in general is a fact I realised some time between realising it was going to be necessary and implementing it: I shouldn’t actually be designing it as a ‘web’. The above diagram shows the problem with the way I was originally designing it: I was using features idea’s I knew existed in real life, and connecting them based on similarities. I was doing it completely backwards: what I should have been doing instead was starting from a simple design and branching out, letting the part design reflect it’s statistics rather than working out the statistics based on the part design.

Here’s a more recent sketch. As you can see, rather than the convoluted web we had in the body covering sketch, designing this way forms a sensible nested heirachy:

Apparently, in my spare time, I sketch pictures of feet. You now know more about me than you ever wanted to.

It’s also scarily exponential. Four generations with three statistics and I already have 40 different feet types. Not to mention the fact that designing stuff like this is surprisingly easy: it wouldn’t be hard to extend the design to a fifth generation. Modelling and importing 121 feet types, on the other hand… not so easy. As a friend mentioned to me recently, the feature creep potential for Species is rediculous!

Which is part of why modding holds so much appeal for me. Even with the help of a proper graphic artist, there’s no way an indie studio like us can do that much content on our own. Community modding frees us to work on new engine functionality, things like flight and swimming and an improved vegetation system, while a lot of the actual potential for biodiversity can be unlocked and appended by the community themselves.

Don’t worry, though: I’m not going to rely entirely on the modding community The vanilla game will have as much content as I can build and pack into it. Nevertheless, I’m superexcited to see what people do with it once the game hits the public, in a month and a half or so… 🙂

“He’s only excited because he feeds off the wordpress blog stats the way demons feed off of the souls of D&D players.”

, , , ,


Management in Gaming

Slight change of tone today: I’m going to share a few thoughts about (video) game theory, because it’s been on my mind lately and also because I’ve been re-watching lots of Extra Credits episodes.

In order to understand a few things about the design I’m planning on implementing Species, it might be necessary to understand my personal preferences when it comes to games themselves. Role Playing Games which focus heavily on stats and levels and inventory management? Not keen on them. I dislike Real Time Strategy games as a rule (alright, I have some nostalgia surrounding Age Of Empires 1 and 2, and even I had to admit that Warcraft III was fun at times, but otherwise I can’t stand them). Turn-based strategy? Doesn’t interest me. MMORPG’s? *hiss*

What all these have in common is micro-management. The more I have to manage, the less fun I’m having. I’d much rather pilot a single fighter in Freelancer than a fleet in Eve Online, and I’d rather play as a soldier in Battlefield Vietnam (I’m not keen on the more popular battlefield games, but I had loads of fun mastering the impossible-to-fly helicopters in BF:Vietnam) than as a general in Command and Conquer.

I prefer to focus on and control a single entity directly in my games, not try to manage multiple groups of entities.

With that in mind, it might be surprising that it’s me building a game like Species. It has all the classic elements of a Real Time Strategy game: large groups of units controlled by their own AI. Indeed, I’ve had to adopt several RTS-conventions in the programming and design, like health-bars and selection circles. And then, underneath that, it has a statistic tree that puts most RPG’s to shame, and it has a unique series of stats for every single unit (disregarding clones).

The difference lies in what I’m going to offer the player. The simulation is sacrosanct: the player will be able to interact with it, but they won’t be able to control it. So they won’t be able to select a large group of creatures and tell them to migrate to a specific location. The creatures need to decide to do that on their own.

But that doesn’t necessarily leave the player helpless. They might, for example, be able to plant a lure that will attract those creatures to it, or perform an action that causes the creatures to follow them. This is macro-management, which is a whole different animal.

A good example of this sort of macro-management can be found in From Dust, an interesting but also fairly short game with a similar premise to Species: a game built on top of a simulation. In this case, the simulation is geography: the landscape changes and morphs on its own, with earth eroding, water picking up silt and depositing it when it reaches the sea, rivers changing course when they are blocked, lava flowing and creating rock as it cools, and so on. In From Dust, you don’t select tribe members and tell them where to go and what route to take: you simply tell them what you want them to do (‘colonise this’, ‘retrieve that’) and they work out the rest themselves. You aid, but never control, your tribes.

That’s a good description of the gameplay I have in mind for Species.

Of course, I’m releasing Species to the public pretty early, even by the standards of alpha releases. Kerbal Space Program (I’m sure I’ve mentioned that KSP is awesome at some stage, haven’t I?) was originally released at 0.7.0: Species will be released as a 0.4.0, with no player avatar and only the essentials of the simulation set up. There will be a bit of placeholder functionality: things like feed, kill, clone… but it’s a bit early in the piece to get too excited about the gameplay, because as far as I’m concerned there is no gameplay in the Alpha. At this stage it’s being released as a simulation: an interesting experiment… but not a game.

I can guarantee that will change significantly in later versions, however. Current long term plans for gameplay include artificial selection pressures and genetic manipulation techniques, environmental manipulation, discovery and collection (for example, the ability to slowly unveil the in-game tree of life by taking DNA samples and finding the fossils that creatures occasionally drop when they die), and a variety of (optional) achievements and challenges. I may have to set up a wiki or something to keep track of all my idea’s and how they are progressing.

But these are long term goals. As excited as I am about some of them, and as much as I think they have potential to broaden the appeal of the game, I’ll hold off while we’re in the alpha stage and work on polishing the simulation (I’ve got so many idea’s for that too! Squeeeee! *ahem*).

Right now though the priority is on less interesting (but necessary for release) features, like adding a Menu system, improving the UI, and opening up to the player functions of the game that I had previously been hard coding within the development environment (things like save/load functions, terrain generation, and whether the code generates ‘blank slate’ creatures, like in Dev Vid 2, or ‘random’ creatures, like in Dev Vid 3).

So the alpha won’t be as exciting as all that, but it will hopefully be a pretty big first step.


* * * * * *

“Huh. Not many jokes today either. Truth be told, I’m starting to think he’s kinda freaked out by the idea of actually releasing something in a semi-official capac- oh crap he’s curled up into a fetal position and is hyperventilating again. Gotta go!”

, , , , , ,