Archive for category XNA

Species 0.6.1 Released

Welp, here we are. Species 0.6.1 can now be downloaded from the download page.

Get the latest release of Species here!

This release was all about cleaning up the back-end code for future features and making visual improvements.

Be warned, this release is likely to be amusingly buggy for a week or three. Whether or not that’s a good thing depends on how much you enjoy watching me scramble about like a lemur on fire trying to keep up with the necessary hotfixes. And let’s face it, of course you do, that’s hilarious. You bastards.


Stability Improvements

- several fatal crashes have been fixed (‘System.OutOfMemoryException’, ‘CladeDiagram.CollideBranches’, ‘UIManager.Paused_Export_Update’),
- the method for addressing problems when the game is minimised or graphics card is lost has been improved,
- built-in troubleshooting for some start-up problems (running from the zip file, running from Program Files, running on computer with unsupported graphics card) has been added

Aesthetic Adjustments

- Procedural texturing: creatures now have different top, side and underbelly textures, giving them a more distinct appearance and more recognisable body covers.
- Custom textures: beaks, claws, teeth and mouths now have their own (appropriately horrifying) textures, blended into the triplanar texturing.
- Fur: Fuzzy wuzzy was a bear, fuzzy wuzzy had no hair, but the creature’s in Species do now. And they find bear meat tasty.
- Water reflections: They only reflect the skybox, but they significantly improve the appearance of the game nonetheless.
- A new Species ALRE logo. Now with infinity% more cladeogram and cycad leaf.
- Adjusted Tree Shaders make better use of dark greys and oranges, meaning trees have more colour variety and look more natural.
- An improved wasteland texture.
- Fixed that weird blue shading on trees when you pause the game (it still happens on grass).

Content Additions

- Body coverings: fur, feathers, scales and skins. Also squid skin, toad warts, echidna spines and human forearms (ewwww…).
- Leg shapes: from 6 in 0.6.0 to 20, meaning a much greater variety of knee shapes.
- Heads: a number of additions (and of course, the existing heads had to be adjusted to provide beak and mouth textures and fur polygons).
- A selection of the Body Part Voting Competition head types.


- Added an "Indirect" rover drive mode to the game options. Seriously, try it out. It's hilariously broken.

, , , , ,


Species 0.6.0 Released!

Species 0.6.0 is out!

This update introduces a decent number of gameplay and environment options, and marks the end of the “gameplay” development for a while. The next few updates will be more heavily focused on the foundation of the game: the creature simulation…

New Features

– Exaggerated physics (it’s more fun if they’re virtually uncontrollable!)
– Multiple rovers can be spawned by the player.
– Programmable to apply artificial selection pressures, by feeding or killing.
– Drivable. (there’s no particular reason to include this, it’s just for fun)

Clade Diagram
– Found in the Ecosystem details page
– Shows the speciation history of the world, even after loading a game.
– Includes a fossil record. (periodic snapshots of each species average)
– Individual clades are hoverable, so you can see the phenotype of each lineage.
– Zoomable and pannable.

Satellite Map
– Also found in the Ecosystem details page.
– Displays the entire map in real time, including biomes, food sources, camera FOV and rovers.
– Creature icons are hoverable, so you can see what’s evolving where without going to that location.
– Can be colour coded to make it even easier to find creatures with outlying statistics.

Web Of Life
– Yet again, found in the Ecosystem details page.
– Attempts to display the genetic relationships of the entire population in real time, as a way to visualise the mechanism of speciation.
– Kinda buggy and laggy: this infographic proved difficult to achieve, since the Speciation algorithm does not provide genetic relationships for every creature.

World Types
– Multiple “World type” styles.
– An alternative biome map for the saltwater “Ocean” world type.
– The ability to use alternative temperature/fertility maps, and change the fertility variation and average.
– Dry maps.
– Inverted “valley” heightmaps.

– Creatures now make use of procedural texturing. (goodbye stretching and scaling texture artefacts)
– Creatures now use a Hue/Sat/Lum colour palette, giving them a more toned-down, natural appearance when compared to the ‘circus-y’ colours of the R/G/B palette.

Bug Fixes

– Fixed the weirdness with Temperature/Fertility/Water-Level changes being given strange irregular increment sizes.
– Newborn creatures are no longer possessed by the souls of their previous lives and forced to attempt to complete the dead creatures final action. (even though it was awesome)
– Creatures in a loaded world are no longer unable to turn left or right.
– Loaded worlds now no longer include a ‘phantom ecosystem’ of invisible, inedible tree’s that for could nevertheless affect fertility and crowd out the regular, visible sort. (yes, that was a thing. And you never even noticed…)
– The game no longer crashes if you try to export a creature while in ecosystem mode. (This should also prevent it from creating corrupted creature files, which cause a crash when you go to the import screen)
– Reduced the once-a-second lag spikes caused by the Speciation routine by about 60-70%. (The game should now be a little more playable at high population levels)
– Temperature/Fertility across the map no longer slowly changes after you start the game.
– And a whole bunch of others…


Multi-texturing and Biomes

One of the priorities for 0.5.0 (the environmental update) has been to overhaul the multi-texturing system.

In 0.4.1 the best the engine could do was 4 textures (desert, grass, forests and cliffs), and those textures were placed at world-start, never changing. The end result was a very static map, very boring environment: basic tree loss/growth was the entire extent of environmental dynamics.

All this changes in 0.5.0. The design plan calls for a dynamic, responsive environment, and by crikey that’s what we’re going to have. (Crikey is Australian for… something. I dunno. Honestly I don’t even know what the word means, but it’s a stipulation of citizenship that we all say it at least once a week)

The first thing to add is more biomes. Desert/grass/forest works well as a basic, semi-tropical biome set, but what about colder biomes? Or warmer ones? Or wetter ones or drier ones? My current biome map concept has more than 20 different biomes drawn on a temperature/fertility map, including some hilariously extreme ones

If you can’t survive in a lava lake you’re simply not trying hard enough.

But that many biomes means a whole different approach to multi-texturing… or at least, I thought it did. This was when development started to go bad…

In 0.4.1 I used a multitexturing method called ‘texture splatting’. Imagine you’re painting the ground texture on a blank canvas. What texture splatting does is gives you a ‘stencil’ for each texture: so you can paint forest through the red stencil, grass through the green stencil and desert through the blue one, and by the time you’ve used all the stencils you’ve painted the entire terrain. All these stencils are nicely wrapped up into a single texture, called the blend texture.

Unfortunately, this only works for a limited number of textures per draw call: you can’t load more than a set limit of textures onto the GPU without it having a fit. So in order to render an unlimited number of textures, I’d need to change how I was approaching it.

My first attempt at a replacement system was sort of like an extremely complicated colouring book, where each grid square is numbered 1,2,3,4,etc and our hypothetical artist fills in the grid with grass/desert/forest from a colour key. Since we can include as many numbers as we like in the key, we can have as many biomes as we want.

Quick! Chop down a tree with your fists!

Once that’s done, our artist is faced with a problem: (s)he has to blur these colours together smoothly without pixilation or sharp edges. And since it’s going to be animated, a simple linear interpolation just isn’t going to cut it.

As it turns out, this is HARD. My own approach was to sample the biome-legend multiple times to give each pixel *four* biomes, each with a weighting value, which I then folded into the same channel as the key
(effectively, I designated the first digit of the channel as the key, and the remaining digits as the weight).

Honestly, the most surprising thing about this ridiculously complicated strategy is that it worked… mostly.

The grid is meant to be there.

But “works in general”, doesn’t mean “works well enough to use”. On closer inspection, the system produced artifacts all over the terrain. (not a typo: graphical glitches are “artefacts”, ancient relics are “artifacts”. I read that somewhere and internalised it, so it must be true) I actually got it working perfectly wherever 2 biomes met, but that was the limit: at any intersection with more than 2 it produced hard edges and odd colours, and the moment it was animated these artefacts started jumping about and generally making themselves easy to spot.

How many artefacts can you count?

So I ended up scrapping the idea entirely, and starting over with a new strategy, one requiring less math and more art.

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

This method turned out to have it’s own set of pitfalls, chief among them, alpha-blending and redrawing the entire terrain multiple times, with different textures each time. For an item which takes up as much of the screen as the terrain, this is a large graphics cost, and in a GPU-bound game probably would have spelled the end of this strategy. But Species is CPU-bound: it has GPU cycles to spare. So full-steam ahead.

“Everlasting pure darkness” will not be a biome in the full game. (Unless someone mods it in).

The artefacts of this method also turned out to be quite different to the ones I faced with the other method. The other method loved to produce singular, localised artefacts: hard edges and biome colours where they shouldn’t be. This method’s artefacts usually affected the entire terrain. I’d say two in particular are worthy of noting here, mainly because I haven’t actually managed to fix them: double rendered polygons and biome-set edges.

Biome-set edges were where one transparent layer tried to fade out into another. I never had any trouble with the inter-set blending, but proper alpha blending is a temperamental thing. In this case, because the biome colour fades out at the same time as the opacity does, the end result was a faded-but-noticeable black ‘border’ between different blend-sets.

Oh so that’s what wars are fought over.

I managed to ‘fill-in’ the majority of these borders by extending the colour to the very edge, but there is still a faint one around the first draw pass. Thankfully it’s subtle, and dealing with it had some odd side effects, so I’m going to leave that one alone. It’s not hugely noticeable.

Double-rendered polygons, on the other hand, are a problem.

It’s zombie-triangle apocalypse! Only trigonometry geeks will survive.

This isn’t actually a problem with the rendering method: it’s a problem with the QuadTerrain itself, which I didn’t know about until the rendering method made it visible. See, when the terrain is completely opaque, rendering a polygon twice has no effect. The colour from both renderings is the same, so it’s an invisible artefact. But when you render a *transparent* object, like, say… one of the 4-biome passes of the terrain… *then* it becomes quite visible, as you can see above.

But fixing it means re-familiarising myself with the QuadTerrain class, which I haven’t touched in quite some time. I’ve already made a little progress, eliminating about half of the artefacts above with one fix. Hopefully the next fix will get the rest, but I doubt it: bugs like this are often inversely exponential. You might be able to fix the majority of them easily, but there are always one or two subtle, extremely well hidden ones that you have next-to-no chance of ever finding.

Oh well, best I can do is to make sure I get most of them.

Currently, I have 23 biomes defined as rough shapes on a temperature/fertility axis. This includes ‘extreme’ biomes, like lava and salt-plains, and a number of underwater biomes that will only be found… err, underwater. (Fertility will at least partly be determined by height: everything below the water plain will be water).

So far everything is coming together as planned. Biomes are done, 3d trees are done (I’ll do a proper post on them later), I’m midway through tying the two together, and soon the nanozombies will be unleashed on the unsuspecting… oh wait wrong blog. You didn’t hear that.


“Other stipulations of Australian citizenship include:

– Must defend vegemite no matter personal opinion of taste. (sticky salty gunk)
– Must be willing to throw foreign tourists in front of a croc to save yourself. (Or was that the other way around?)
– Must know how to defend against drop-bears (trick question: there is no way to defend against drop bears)”

, , , , , , , , ,


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


Plans for the Next Version

Alright I’m back.

It’s been a fairly small launch, but that was expected: it’s not like I advertised the game much beforehand. I’m kind of relieved: I can go back to working on it without worrying too much. I think I’m more comfortable with the idea of slow progressive growth than with rapid expansion.

And going back to working on it is exactly what I’m doing. I think I have a better grasp now of the games failings, and I’m looking into rectifying them, starting with the most obvious: the static vegetation.

The 0.5.0 release will contain an extensive vegetation overhaul: very little of the current system will survive into it’s next incarnation. This will provide three things that (in my opinion) the game needs: an gentler survival curve, an evolving environment, and a prettier world.

The gentler survival curve will be achieved by a new behavior: grazing. Rather than having to find a tree in order to get enough energy to reproduce, a creature will be able to gain energy by grazing from the ground. This comes at a cost, of course: it’s slow and won’t provide much energy, and will also reduce the local fertility. But it will mean that even creatures that don’t find a food source will still have a chance, and the deaths of most creatures will become a bit more interesting than the current average of “too stupid to look for food”.

Speaking of which, I’m well aware that the AI needs a lot of work. Unlike the other planned overhauls, I’m planning on slowly improving the AI bit-by-bit, since it touches upon all the other features I’m looking at and working on. The creatures will get smarter and more responsive, but to what extent I don’t yet know…

The evolving environment will be a load of fun to program. I should probably clarify: by “evolving enviroment” I don’t mean “evolving plants”. Sadly, with CPU usage what it is, I can’t spare the extra CPU cycles to include completely mutable plants. It’s on the wishlist, and anything I can make mutable I will, but there a hundred-fold more plants than there are creatures, so plant evolution will have to be limited to simple things like size and colour.

But even though the individual plants will be mostly static, the forests most definately won’t be. As temperature and humidity across the map changes (being influenced by creatures, rainfall, climate change, and even the player), the various biomes will drift about, and the plants native to each biome will colonise the newly exposed area’s, allowing (and/or forcing) the creatures to migrate and adapt.

With luck, this won’t be the only large upgrade to make it into the next version either. I’d like to get a top-down map in place so you can watch the simulation in a more symbolic/iconic format, and make a number of changes to the gene system so we can start Playing God ala. Jurrasic Park. I’d also like an ‘export’/’import’ creature function as soon as possible, so you can save your favorite creatures and bring them in as introduced species to devastate the local ecosystem.

Also, I’ve been playing Dwarf Fortress. It’s not exactly a bastion of good game design (in many cases it’s a perfect example of what not to do), but it has a terrifying amount of depth and complexity, and has given me a load of new idea’s for how I can improve Species (those familiar with Dwarf Fortress are either cheering or weeping right now).

I realise Species in it’s current alpha state is a very shallow game: interesting, but not for long, and with no actual gameplay behind it. All of that is coming: an idea I’ve had to start with is to allow you to highlight creatures by specific statistics, which could be used to tell you which creatures to kill and which to aid in order to promote certain forms of artifical development.

I won’t set a date for the next update just yet, but I won’t go more than 3 months between updates. I’ll also try to implement anything suggested in the forums or the wiki.

“For anyone trying to apply artificial selection in the current version, the best way is to bottle-neck the population around a mutant creature (ie. kill everything except that creature), then feed the population up again until you find another creature you like the looks of…”



Well, here we are.

One year ago today I started this blog with a simple post with the most inspiring and unique title ever, unofficially unleashing the concept of Species on an unsuspecting world.

Now I officially release the Proof of Concept Demo: Alpha 0.4.0. You poor sods.

I’ll try to keep the maniacal laughter to a minimum, but no promises.

How to install

First, download and install the XNA redistributable from the Microsoft website.

Then, download Species: Artificial Life, Real Evolution (0.4.0). I’ve uploaded it to MediaFire as a stopgap solution until I’ve got an official website set up. That should only be a week or so, so check back! With any luck I’ll have forums and a wiki on it too.

To play the game, just extract the zip file and run “Species.exe”. I recommend you go into the options and set your resolution. 🙂

Note: some graphics cards will give you a Texture Width error when you try to run Species. If that happens, try copying this file into the “Mods” folder. It should fix that particular error.

Note 2: some other graphics cards don’t play well with the Terrain Shader. If your terrain appears blue or invisible, try copying this file into the “Mods” folder. Obviously I’ll try to build these modifications into later versions so you don’t have to install them manually.

If anyone has any problems running the game, send me an e-mail at qu.quasar{at}gmail{dot}com! I’ll do my best to get back to you as soon as I can, and I should be on consistantly for the next few days (except for sleep).

Massive thanks goes to Jade, our Friendly Neighbourhood Graphic Artist, without whom the game wouldn’t look anywhere near as polished as it does. Check out that deviantart account to see some of Jades other stuff!

The game comes bundled with the Mod Maker. I’ll post a tutorial for that later, or you can try to work it out through trial and error. You know, the same method I used to make the game. Okay, mostly error.

It’s just a proof of concept at this stage: I’ll discuss what needs implementing and improving in next weeks post. The game still has a long path ahead of it: this is only the first step!


(EDIT) Controls!

To move the Camera: Use W, A, S and D.
To toggle camera Gravity: Press Space.
To Move Faster: Hold Shift.
To change the Time Accelleration rate: Press ~, 1, 2, 3 (or use the mouse buttons)
To view individual Creature Statistics, including DNA: click the Select Creature button twice.
To view individual Species Statistics: click the Species button twice (you can even see the Species Average morph over time!).
To see the Tree Of Life: click the World button twice.
To Move creatures: click the move button, then click the creature you want to move to pick them up. Click again to place them.
To Feed creatures: click the feed button, then click the creature you want to feed.
To Kill creatures: click the murder button, then click the creature you want to murrrrder.

Bonus Controls! (mildly buggy)

Orbit camera: Press C (good for keeping track of individuals)

“Have fun.”

, , , , , ,


T-minus 4 days…


, , ,

1 Comment

Future Development

This’ll be fun post to write: I’ll outline the things that are ready for the alpha release (ie. bragging), and then I’ll start talking about what needs to be fixed, and then go on to where we’re heading after that. And then… well, we’re now officially in testing-and-bug-fixing mode for the alpha, so I guess it’s time to announce the release date. Ahem.

Where we’re at.

Species 0.4.0 is a functional and apparently stable evolution-from-first-principles simulator. It’s possible to spot natural selection in action with the Species Average statistics, and I’ve seen things like convergent evolution (creatures consistently become more amorous, for example) and punctuated equilibrium (evolution starts off quite rapidly, but slows down after a number of generations). There’s plenty of neutral, beneficial, and harmful mutations, and a variable mutation rate (you can set it when you start a new map).

We’ve also implemented genetic recombination (mating) and the possibility of predator/prey relationships (attacking and eating dead creatures).

We also have a small variety of observational functions. It’s possible to analyse most of the creatures statistics, watch the progress of their energy and health bars over the course of their lifetime, and read their genetic code (which, admittedly, is somewhat indecipherable).

We’ve got a built-in speciation detector, that works out which populations can and cannot interbreed, and allows for the retrieval of stats and averages. We also have a real-time population history, which doubles as a tree of life.

Oh, and we’ve got a variable map generator, that you can use to customise the map before you enter the game, as well as entry-level save/load functionality.

And moddable body parts, too. 🙂

What we’re missing

Playing the game at the moment reveals a few… not so much ‘bugs’ as ‘things that aren’t much fun’. They’re things I’m aware of, but haven’t had time to fix and/or expect to fix with a planned, later feature.

Constant environment. The environment at the moment is a fairly constant variable: tree’s always regrow in the same area’s and the temperature never changes. This means that creatures have a tendency to adapt to their environment and stagnate.

Highly variable survival rate. A less-than-fertile map has a good chance of killing off the starting creatures, while a fertile one will cause a ridiculous population explosion once they adapt to be more efficient.

Lack of carnivorous incentive. Creatures rarely become predators because vegetation is plentiful and easy to find in comparison to meat.

Unmapped Mutations. I still need to add a mutation map for feature, limb-tip and body covering mutations. At the moment they find an ‘ideal’ far too rapidly.

Not enough Homogenizing. Species currently don’t visually distinguish themselves very well: you end up with a large crowd of highly variable creatures. Reducing the mutation rate helps, but I’d like to amplify homogenising forces like mating to make individual species more visually distinct from each other, as well as implement some sort of herding behaviour to make them congregate into discreet area’s.

Stupid creatures. They’re really pretty dumb sometimes. I expect their AI to improve slowly, a little bit with each release.

Incomplete Statistic Mapping. The UI allows you to track which statistics affect which other statistics, but the mapping is incomplete and doesn’t take into account all the effects (it’s a big list, and I’m tweaking it all the time. Nevertheless, I’ve managed to include all the major effects).

Performance. Is absolutely terrible on less-than-modern machines. My development laptop struggles to keep it going at better than 10fps once the simulation reaches more than 500 creatures.

Where we’re heading

Here’s the fun one! (Note that everything I say from here on out is tentative. I can’t make any promises, this is just what I’m planning)

The Big Feature for Species 0.5.0 will be a complete and massive overhaul of the vegetation system. It will use dynamic biomes based on a temperature/humidity map (which will change over time based on the actions of the creatures), instanced models, and a rewritten terrain shader.

It will also separate vegetative energy into two sources: fruit tree’s (point energy-sources, similar to the tree’s in the current system but rarer and more valuable), and grazing (idle, herbivorous creatures will graze, very slowly and inefficiently gaining energy but reducing the local fertility).

This system will solve the first two problems I have with the alpha release (mentioned above), and will have an as yet unknown effect on the third. But it’ll probably make the performance issues worse, so I may have to shrink the default world-size and creature-cap to compensate.

0.5.0 will probably also feature a top-down map view, with coloured icons for creatures and food sources, and another real-time phylogenetic tree of life. Unlike the current population history graph, though, this tree will encompass the entire history of the simulation, and will record morphological data about extinct species. It will form the basis for an extensive ‘fossil record’ in later versions.

One apparently minor inclusion to the vegetation system will be a ‘height’ value for fruit tree’s: creatures will need to hold their head (or hands) at a particular height to eat from particular tree types. While this might not seem like much, it sets the stage for a creatures vertical position to influence their actions and survival. And that sets the stage for another Big Feature: flight and swimming.

And of course, I’ve already mentioned a third Big Feature in a previous post: multithreading to improve performance. Not to mention my extensive plans for player interaction in the Beta… I may or may not be too ambitious for my own good.

But pulling right back from my deranged ramblings about the future, the figure you suffered through that entire post for is here. Without further ado:

Species 0.4.0 (alpha) will be publically released on the 27th May, 2012

(one way or another)


“… assuming the Old Ones don’t return before then and consume us all. You know, the usual disclaimer.”

, , ,


Optimisation, Performance, and *shudder* Multithreading…

Yeah, it’s time for another technical post. Sorry guys, I just can’t help myself. If you understand what I’m talking about, you’re probably doing better than I.

CPU Performance in Species is probably the single most restrictive factor of programming the game. It limits the number of creatures, it limits the methods I can use to change their variety, it limits the complexity of their behaviour, it limits everything sooner or later. But with very, very careful programming and optimisation, that ‘later’ can be pushed pretty far back.

Firstly, a little background: Species is ‘CPU Bound’ as opposed to ‘GPU Bound’. A CPU (Central Processing Unit) limited program spends more time computing what it has to draw than it does actually drawing it, meaning the GPU (Graphics Processing Unit) sits idle until the CPU is finished. I could dump a whole load of extra information onto the GPU and it simply wouldn’t care, because it’s hardly working as it is. The GPU is awesome like that.

Shawn Hargreaves can probably explain all this better than I, if you’re looking to read up on it:

An Elf In A Box
How to tell if you are CPU Bound or GPU Bound

I’m loathe to admit it, but I secretly suspect the Terrain LOD system I spent so long programming may be slowing the game down, because it takes work away from the GPU at the cost of a little bit of work on the CPU’s part, and I’m so heavily CPU bound there’s a chance just brute-force-rendering the terrain would be better at this point (I could be wrong, though, and taking it out at this point would be rather silly since there’s so much more yet to implement, on the GPU and CPU)

That’s why some of my systems, like the Billboard Vegetation, are reliant on offloading information from the CPU to the GPU. The GPU can handle it. The GPU can handle anything. (Advertised product may not in fact be able to handle anything)

So that’s fairly simple, right? Drawing takes no time at all, so all our time must be spent updating the simulation.


In reality, I’m only spending maybe a quarter of my CPU time in the update call. The reason for this is the bottleneck between the CPU and the GPU. Before the GPU can draw anything, the CPU need to tell it what to draw, in excruciating detail.

So even though I can’t save time by saving the GPU work, I can save time, lots of it, by stopping the CPU from telling the GPU it has work to do. There are a variety of ways I’m doing this…

I’m sure I’ve mentioned before that creatures are made up of a whole bunch of separate ‘part’ meshes. A high detail creature would have a torso, tail, 6 limbs, 6 limb tips, a neck, a head, and a currently unlimited number of Features attached to the head (open to later revision). Multiply this by whatever our creature cap is and we’re calling the draw routine far too many times for good performance.

But it doesn’t have to be called for every creature. Creatures off-screen don’t need to be drawn at all, and we can get away with drawing less detail on distant creatures.

We can also speed this up with State Batching. (Note for technical readers: Model Instancing would have been my preferred approach, but the parameters for each creature are unique. It’s not easy to instance meshes under those conditions). See, in order to tell the GPU what to draw, the CPU has to feed it with the model, texture, and parameters things like animated bone positions, sizes, colours, etc). The easiest method would be just to feed in these three things for every model, every time, and this is exactly what repeatedly calling Draw() in XNA does.

But you don’t actually have to. The GPU remembers: if you just change the parameters, but leave the model and texture as is, you can draw a second copy of it without resending the model. So by carefully rearranging the order of drawing to (for example) draw all creature torso’s one after the other, you only need to set the torso model on the GPU once. You can do the same thing with textures and parameters too, if you’re changing models all over the place but repeatedly using the same texture.

Obviously there are other, more subtle and game-specific ways to improve general CPU performance as well. Moving calculations out of loops wherever possible is a generic one: more than once I’ve caught myself doing a calculation multiple times when it could be done only once. A more specific example was carefully controlling matrix operators: streamlining the modifications I’d made to the skinning animation system cost me some programming time, but resulted in a noticeable performance increase.

But even with all these ongoing optimisations, I’m still not happy with the games performance. I’ve been treating my 4 year old, dual-core laptop as a baseline minimum (not least because that laptop is my development machine), but it struggles keeping the game running at a decent frame rate once the simulation gets going properly. There’s still room to optimise (there’s always room to optimise), but I don’t think I can get it to
the performance levels I’m hoping for with after-the-fact methods and reprogramming individual methods. This leaves one other option…

… multithreading. *dramatic thunder*

(Note: this rest of this post will likely be one long whine. I hate multithreading even more than I hate render targets. I still plan to tame it one day, because it really is a powerful way to improve CPU performance, but not for the alpha release)

Most machines have more than one CPU these days, and many people assume as a result that that means the computer must be faster. 4 cores? FAST. 8 cores? ULTRAFAST. 128 cores? OMG WHY YOU STEAL NASA SUPERCOMPUTER. In reality though, most programs are not designed to take advantage of this. The vast majority of programs do all their actions on a single core, because Multithreading Is Hard.

Multithreading is the process of taking part of what you have to calculate and giving it to a separate process (thread), which can run in parallel on a separate core: in short, it’s telling the computer to do multiple things at once. So for a game, you might tell the main core to render the screen while the second core works on updating the simulation for the next frame.

Of course, describing the process so clinically doesn’t quite summarize the emotional response I have to multithreading. So for that side of things, here’s an alternative explanation: multithreading is the process of juggling 3 plates, 2 watermelons, a chainsaw and a rabid wolverine while walking a tightrope over a pit of giant acid-spitting ants while cyborg trapeze artists take pot-shots at you with AK-47’s and grenade launchers.

I’ve actually attempted multithreading in the past. The results were unpleasant, unpredictable, and impossible to debug, mainly because I didn’t know what I was doing but also partly because that’s just the way multithreading is.

To give you an idea, suppose the first thread retrieves something from the second before the second thread is finished with it. The program might fail (which is what we want, so we can work out why the first thread is retrieving stuff from the second), but it will usually try to keep going. The simulation will start acting strangely, using false values, but not actually telling you it’s doing so. If it fails, it will fail somewhere else in the code that has nothing to do with the multithreading, and you will then spend hours investigating in the wrong place.

The usual approach to multithreading is to implement a lock, so that one thread waits for the other to finish before using any of the same resources. But the draw call needs to use a lot of the same resources that the update call uses, so it would likely spend much of it’s time waiting, and wouldn’t be much of an improvement over single threading.

(There are, obviously, ways around this, and when I do implement multithreading properly I will have to study them in detail)

In addition, for some reason, Multithreading plays havoc with Visual Studio’s debug mode: a multithreaded game seems to run much slower than an equivalent single threaded game in debug mode: so slow that, during my ill-fated attempt, I had run the game outside of debug mode on in order to test it. Less than ideal, and it makes tracing bugs and errors much, much harder.

For the alpha release, and probably for the second alpha release too, we will have to settle for less-than-optimal performance. When I do implement Multithreading I will have to set aside a lot of time to rework a large amount of the code, and to deal with the inevitable problems. With luck, though, I will be able to significantly improve frame rates, which will allow for bigger worlds and more creatures.


“You know, there’s probably potential for a misogynistic nerd-joke about multithreading in there somewhere.”

, , , , ,

Leave a comment

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

, , , ,