Just Keep Swimming…

First things first: with Mike Stankiewicz’s help we’re starting our move to Steam, so I’ll be taking the Species 0.10.0 alpha down from speciesgame.com within the next week, along with the donation buttons. Please be aware that the Species alpha will not be downloadable for a while as we build up to the Steam launch.


With that out of the way, let’s get onto the important stuff: I taught Primum specium to swim!




Ultimately I decided to implement a realistic buoyancy model. I actually implemented the variable-buoyancy model I described previously, but decided it was not going to work for a couple reasons…


The first reason was the odd effects it caused when I was defining tissue density. I’d planned for the starting/average tissue density of creatures to be 0.913 (this being the density of body lipids. Primum specium is basically a blob of fat). But water has a density of 1.0, which meant it would have floated on the surface. I had to fudge the numbers to make P. specium able to dive.


That wasn’t a breaking problem though. What ultimately clinched it for me was implementing the oxygen system.


Oh, right! There’s also an oxygen system now! Here’s what I went with:





“Respiratory System” is a genetic value akin to “Diet”, ranging from -1 (water breathing) to +1 (air breathing). Creatures at the 0 mark (ie. P. specium) are roughly equivalent to anaerobic organisms: they absorb a small amount of oxygen regardless of the medium they’re in. The trade off for this is that they have to ‘gasp’ periodically to restore their oxygen meter, wasting time and energy.


Oxygen is a 7th emotion, somewhat akin to fatigue. When it becomes a problem, air breathing creatures will swim for the surface, water breathing organisms will move downhill hoping to reach water. Once they reach a breathable medium, they will ‘gasp’ to double their oxygen regeneration rate until it isn’t a problem anymore. (Anaerobic organisms can gasp anywhere, but restoring their oxygen bar will take a lot longer).




Back to the buoyancy model! I temporarily turned P. specium into +0.1 air breathers to test the need to swim for the surface for oxygen. This lead to a problem: P. specium was happy to make the attempt, but it didn’t have enough swim speed to reach the surface, and ended up continually swimming upwards against an invisible force until it gave up and was dragged back into it’s preferred plane to suffocate.


This cinched it for me: I still think the variable buoyancy model might have provided some interesting evolutionary results, but if those results are going to be odd and unintuitive, they’re simply not worth it.


So instead, I implemented a realistic buoyancy model: unless they’re perfectly balanced, creatures will slowly sink or slowly float upwards while in the water. This will give swimming creatures access to all levels of the water column, provided they have enough propulsion to resist their buoyancy.


This same buoyancy model will also apply to the air, which will open up some interesting options for the future. I can’t promise there won’t be any bugs…




… but they should be the fun sort of bug, rather than horrible game-crashy sort.



The end result of all this tinkering: when you put them in the shallows, my air-breathing P. specium have a dive-to-eat/surface-for-air cycle that is fascinating to watch, and really sells the idea that the world of Species (well, the oceans at least) is a 3 dimensional space and not simply a 2D plane. I’m really happy with the way it came out, and may actually end up leaving the +0.1 air breathing gene in.


I still need to implement a few extra bits of oxygen-seeking behavior (eg. walking uphill if you’re not a swimmer, swimming downwards if you’re a buoyant water-breather, treading water to prevent being re-submerged while gasping on the surface, etc), but I’m very happy with where this is going right now.




Oh, I also took some time to fix a problem that had been bothering me in the development version: Creatures eyes had stopped appearing. I hadn’t realized how much I missed their doofy faces until they were gone. Thankfully, that’s fixed now!




… yes, totally fixed.        


I also added a crown to the kelp!




I know it doesn’t look like much, but putting those floating leaves on top of the water took me far longer than it should have and convinced me never to try and do ‘special rendering modes’ for specific tree types ever again. Until such time as I completely rework the vegetation system from the ground up (which will be necessary when/if I implement evolving plants), I’ll stick to normal tree types.


Like coral, which is totally a tree.




One other thing I’ve been working on, but can’t really show via screenshot, is attaching limbs to the creatures body more firmly. Previously, the leg’s up/down animation was an estimation based on where the torso animation was at. I’ve overhauled that system to bind the legs directly to the torso bones, which should have them follow the animation of the torso much more closely.


This will also assist the legs in following the torso’s movement during the swimming animation, which differs in a number of significant ways from the walking animation.


It’s an incremental improvement and it won’t fix everything wrong with creature animation, but it’s a start.




There’s still a lot of work to do: I still dont have grass working in the Monogame version and I need to introduce swimming-specific body parts like flippers and variable tails, but we’re gradually inching closer and closer to having something worth releasing!





1 Comment

Underwater Plants

The first part of an underwater ecosystem: food. The game needs to have something growing in the underwater biomes for the herbivorous fish-analogues to eat.

This means I’ve been spending my time modelling up underwater plants and coral and watching a lot of Pixar movies. For research. Yes. Pixar binge for research. It’s not like I cry every time Dory finds her parents or anything.

Moving on, here’s the new trees so far:


Obviously, I’m using a loose definition of the word “tree” here, but they’ll be rendered by the tree system and they work the same as aboveground trees, so as far as the game is concerned, they’re trees.

The exception to the rule, of course, is the kelp. If it was rendered normally it would stick up well above the surface of the water, so I’m coding some new rules for it. Any geometry above the water won’t be rendered, and I’ll be trying to add a ‘crown’ model that floats on the surface, to hide the geometry cutoff.


Early results are promising.


The swim physics are also coming along, though P. specium look less like they’re swimming and more like they’re crawling along an invisible flat plane in the water. I’ll need to iterate over all their moments in order to make things look good in the water.

I’ve also been working on the limb animation. To save time, I’m not going to re-animate all the limb assets with swim motions. Instead, I’m going to try and procedurally modify them to make them look less like alternating ‘steps’ and more like a sort of breaststroke. Not sold yet on the idea, but we’re seeing progress, and that’s the important part.




Designing Swim Physics

0.11.0 will be the Underwater Update, on account of the addition of an underwater ecosystem to complement the aboveground one we currently have.

This system has three main parts:


1. Food. This is a pretty basic requirement: I need to break open the rusty lock and take down the warning signs on my 3d modelling skillz and model up some coral and underwater plants. This is straightforward content production: time consuming and not my favourite thing to work on, but none too difficult.

2. Oxygen. This is probably the most interesting mechanic, from an evolutionary standpoint. It will be a relatively straightforward mechanic to implement, combining features from the diet system (a linear spectrum from -1 to 1, with 0 being a ‘jack of all, master of none’ position) and the temperature system (insufficient oxygen will present itself in the same manner as hot or cold internal temperatures: by draining the creatures stamina and tiring them, doing damage if it passes a certain threshold). But it’s implementation will mean two (sort of) mutually exclusive environments, which will naturally mean more niches for the creatures to fill.

3. Physics. This is the big one…

The model I’ve mocked up for swim physics has two goals: it has to be capable of simulating a variety of movement types in water (from walking on the sea floor to swimming to dog paddling across the surface), and it has to be capable of, with only minor adjustments, capable of simulating flight in air (making life easier for me in later updates).

So for that reason, it’s primary mechanisms will be drag, propulsion and buoyancy. (powered lift will be added later).


The game already has a value called “streamlining”, which reflects how thin and long the torso is. This already has a very minor effect on walk speed, but it will probably need to be improved (the head and legs should also contribute) in order to serve a significantly more important role in determining swim speed.


A relatively straightforward stat: more and bigger flippers = more propulsion. Normal legs will provide some propulsion, so that legged creatures can doggy-paddle across the surface of the water. Propulsion will be replaced by walk speed for creatures that walk along the sea floor.


This will be determined by the creatures density, and may require me to model some additional stats. Certain parts of the body tend to be of a higher density than torso and tail, something that the game doesn’t currently keep track of.

I’ve thought about whether or not I want buoyancy to be modeled accurately. If it’s accurate, creatures will either sink (and ultimately end up on the sea floor) or float: there would be no ‘resting height’ for swimming creatures.

On the other hand, I could model it using the concept that Terry Pratchett describes in Going Postal (2009)

“The flotilla’s of the dead sailed around the world on underwater rivers.

Very nearly nobody knew about them. But the theory is easy to understand.

It runs: the sea is, after all, in many respects only a wetter form of air. And it is known that air is denser the lower you go and lighter the higher you fly. As a storm-tossed ship founders and sinks, therefore, it must reach a depth where the water below is just viscous enough to stop it’s fall.

In short, it stops sinking and ends up floating on an underwater surface, beyond the reach of the storms but far above the ocean floor.”

This would allow creatures to have a preferred resting height, at which they could swim without needing to propel themselves upward or downward. It would also serve well for future ‘gas bag’ style flying creatures, support for which has long been a part of the plan for Species.

I’ll probably test both models before settling on one: I dislike making breaks from reality when it comes to the physics of the game, but I can see an argument for it here.


1 Comment

Slow running’s (a fix)

I was gonna talk about design but I decided to talk about this.

The way Stamina works in 0.10.0 is a bit off. It made sense when I was implementing it: as you get exhausted, you get slower and weaker, right? And moving slower uses less energy. So a running creature should, essentially, sprint for a brief period as they use up their stamina bar, before slowing down to a sustainable jog as stamina use and stamina recharge balance each other out.

In practice… this works exactly as described. A creature attempting to run down prey will start running fast before slowing down to a sustainable pace.

Additionally, running costs more stamina per meter than walking: something else that looks good on paper. Of *course* it’s going to be more efficient to walk than to run.

It’s when these two equations meet that the problem becomes apparent: equilibrium for a running creature is slower than equilibrium for a walking creature. So a prey creature can casually walk about while an exhausted would-be predator stumbles along behind it, running slower than it’s prey walks, never able to catch up.

Amplifying this problem: A creature doesn’t give up unless another need exceeds the one it’s trying to deal with. Since the predator has reached stamina equilibrium, it’s stamina will never hit 0 and it will never go to sleep to recharge it’s stamina: it will just keep burning through stored energy trying to reach the prey until it keels over and dies.

The solution, which you’ll see in 0.11.0, was a cruel one: rather than automatically pacing themselves, running creatures will now continue to burn stamina at the maximum rate until they collapse from fatigue. Falling asleep will serve two purposes: interrupting a hunt that is destined to fail before it costs the predator it’s life, and forcing the predator to recharge it’s stamina so it’s fresh and ready for the next attempt.



Apart from this, I’ve also continued work on the monogame version of species. I’ve fixed most of the issues, and found a quick solution to one that was threatening to force me to rework the entire creature body-texturing system. Still have a few major issues to address, but there’s clear and present progress.



Leave a comment

XNA 4.0 to Monogame

This was supposed to be easy!

Monogame is XNA, XNA is Monogame. They’re the same framework, implemented atop a different backend: XNA uses DirectX 9, Monogame uses OpenGL. That’s what they’d have you believe, anyway.

Oh yes. I know the truth now. I’ve seen through the looking glass. It’s a conspiracy, I tell you. They faked the moon landing, they tampered with the climate change data, and they really really want you to think upgrading games from XNA to Monogame is easy, for some presumably nefarious reason.

Silliness aside, my first attempt to get the game to compile to Monogame didn’t go so well. I downloaded the framework, created a project and started copying code and content files. Before long I ran up against my first issue: all the 3d models in Species use the FBX file format. The earliest version of the FBX format XNA supports is 2010. The earliest version of the FBX format Monogame supports is 2011.

Guess which version Species was using for all it’s 3D models. Go on. Guess.

So, I had to open all the 3D models and re-export them to a slightly later version of FBX. This was somewhat complicated by the fact that I’m a disorganized humppile who had never bothered keeping track of what settings I used to export each individual models. Some had animation, some used a different up-axis, and a lot of them referenced textures I could no longer find…

So let’s fast forward past that little adventure and just say that, after a week or so, I managed to get all the content re-exported.

Once I’d cleaned up that mess, I found a new one lurking behind it: shaders throwing null reference errors. It turns out the rules for shaders are a lot more strict in Monogame than they were in XNA: if I’m not using a shader parameter in the shader body, OpenGL optimizes it out of existence, and Monogame throws a fit when I try to set that parameter. So, I needed to perform a shader cleanup pass.

Finally, though, I got past those messes. The game compiled and ran. And that’s where this screenshot comes from…

But you know what? I don’t care that it looks like I’ve accidentally awoken Azathoth: it’s still a victory to get the game into a running state. Everything else is cleanup.

The first thing to address was the black terrain. Turns out, this stems from another difference in how OpenGL handles shaders. It won’t let me give shader parameters a default value in the shader code itself. So it’s not black because the graphics card is throwing a fit, as is usually the case: rather, it’s black simply because the light colour and direction haven’t been specified and are still null. Identifying this issue helped me fix not just the terrain, but a fair number of other graphical issues with the water and fog, and make the Monogame version somewhat recognizable as Species again.

Slightly more frustrating were the problems with instanced models. Those hideous black streaks across the screen are actually the Fence Posts on the concrete nursery fence (see how they intersect where the posts should be?). I still don’t know exactly what causes this, but I did (eventually) work out I can fix it by rebuilding my InstancedModel class from scratch and turning off the procedural fence geometry between the posts. That leaves me with no fence geometry, but I’m working on that.

Then, the creature problems. Their bodies are an even more chaotic mashup of parts than they were before, the legs don’t animate and stick out at odd angles (well, odd-er angles), and so on. I don’t mind if the creatures are eldritch horrors, but there should be at least some logic to their appearance.

I didn’t manage to get any screenshots of this, fortunately or unfortunately depending on how much you value your sanity.

Thankfully, these problems were mostly a mix of the ones before them, which is a good sign: if I’m only encountering problems I’ve already seen and know how to deal with, I’m on the home stretch. The lack of animation was an failure to export the animation when I was recreating the fbx files, the weird orientation was a result of Y/Z axis mixups, and there were a few shader and texture setting mixups to be dealt with.

And then, of course, there’s the grass. Turns out, rather than fixing the problem I encountered in XNA4.0, Monogame straight up doesn’t support what I’m trying to do.  No vertex texture lookups in GL’s Shader Model 3.0. So I’m going to have to completely rewrite the code responsible for drawing grass, or forgo it entirely for 0.11.0. I may end up taking an entirely new approach. Kind of hard to say at this point.

While there are still plentiful minor graphical errors (no grass, no fences, the lack of shadows and selection circles, those weird lines on the creature’s back, whatever’s going on with the water and skybox), the game is at least functional in Monogame now. In theory this version of the game is cross platform, though of course I have no means of testing it since I don’t own a Mac or Linux PC.


Unfortunately, this blog has now caught up with my progress: that last screenshot was taken from the development build on the same day I’m posting this. That being the case, I’ll probably have less development work to discuss next week. Fortunately, there’s lots of design work to discuss, so we can do that!

We have fun here,


XNA 3.1 to XNA 4.0

Well. This was an ordeal.

Going into detail about why I kept postponing upgrading from XNA 3.1 to XNA 4.0, and from XNA 4.0 to Monogame, would take a while. I had my reasons, ranging from annoyance with specific software versions (“Open Folder in File Explorer” should not be premium functionality, VS2010 Express!) to a strategic decision not to increase the scale and complexity of pushing out updates by supporting multiple platforms during the alpha stages, so simple awareness that it was probably going to take a while.

Regardless, going into this process I was optimistic. I was aware of breaking changes between XNA 3.1 and XNA 4.0, but I had a cheat sheet I’d found on the internet, and I wasn’t expecting any significant changes between the versions: just syntax and compilation errors.

So I got it into XNA 4.0 and just kept fixing all the errors that popped up until the game was compilable. There were a lot of these, but the good thing about compilation errors is that the text editor tells you where and are and why they’re a problem. So, eventually I managed to pass compilation.

And then had to keep fixing the exceptions that popped before the game loaded. This wasn’t unexpected, but slightly more annoying to deal with. Eventually, though, I actually managed to get into the main menu.

At which point I found this.

Yeah, that’s… less than promising. But maybe the in-game behaviour is still mostly worki- ha ha NOPE.


Turns out the XNA Team had made some pretty significant behavioural changes between 3.1 and 4.0, especially relating to how the framework renders… well, everything. And if I’d encountered this problem immediately, I might have switched gears and forgotten about cross-platform support for 0.11.0. But I’d already sunk two weeks into this, so I started seperating the issues and dealing with them one by one.

Some of these were easy to fix, like turning off Premultiplied Alpha on every texture and model, which fixed a lot of the blueness. Others were more complicated: I *still* haven’t fixed grass rendering, because XNA 4.0 only supports very specific texture formats in Vertex shaders technical blabbering and I’m vertex sampling 4 seperate textures using different formats that touch just about every other part of the game more technical blabbering including the FertTempTexture, which is tightly coupled to dozens of other systems and needs it’s format to have a minimum amount of fidelity in order to support subtle per-frame changes like those emitted by trees and climate devices so much doggamn technical blabbering.

Anyways, after significantly longer than expected, and a few brief forays into “what the hell, no seriously what I just I don’t even” territory…

New marketing strategy: everything looks like Minecraft. Kids like Minecraft, right?

…. I got it… let’s say “95% working” in XNA 4.0. Still no grass because shut up, that’s why, but just about everything else in the game working as it did previously. No signs of performance improvement from the new framework, unfortunately, but what the hey: we’re only halfway done, right? We’ve still got to move to Monogame to allow the game to run on platforms other than Windows.

At this point I decided to move on to the next step. I might still have to cut my losses yet, and who knows? Maybe the changes between XNA 4.0 and Monogame will fix some of the issues I’m having with the XNA 4.0 version-

Hello darkness, my old friend…



Not to worrry, though. I will see this though, come hell or high water. The sunk cost fallacy demands it!



Where to next – 0.11.0

Greetings minions, and congratulations on surviving the incomprehensible eldritch horrors and repeated global memory wipes of the last couple months. You’ll be happy to know I have big plans for the future, and even happier to know a small number of those plans are not convoluted schemes to take over the world.

Among those…


The next update will be something of a milestone, where Species moves away from our little rockpool on the shoreline of the internet and we attempt to put the game onto Steam. Steam is new territory for me, but Mike has experience with releasing games onto the platform, so I’m optimistic about our chances.

In the interests of full transparency: in the months leading up to the game’s launch, I’ll be taking Species 0.10.0 off the site so that everything can go through Steam. The steam release will mark the boundary between the Free Alpha and Paid Beta versions of Species ALRE, and the end of the free alpha versions. Everyone who pre-ordered the game will have steam keys sent to the email address they provided via paypal.


Don’t worry though, I’m not planning to move into the paid beta without making it worth your while! These are the major features planned for Species ALRE 0.11.0:




Underwater Ecosystems

Who wants to evolve creatures under the sea, perhaps in a residence resembling some type of tropical fruit?

  1. New underwater food sources. Kelp and Coral will provide essential food for species that choose to venture into the oceans. I’m also planning to introduce a new simulation mechanic: “shoals”. These clusters of small, indistinct creatures will be a valuable source of meat for carnivores, exploitable only by those creatures fast and maneuverable enough in the water to catch them.
  2. Swim physics. A creature in the water will move differently from how they move on land, based on their body parts and shape. Their buoyancy will also have an influence on whether they swim close to the surface or walk along the ocean floor.
  3. Oxygen. A gill/lung dichotomy will determine how well a creature takes in oxygen from their environment, which will in turn affect their stamina and speed. Simplistic creatures, like P. specium, will rely on an anaerobic metabolism that allows them to survive in both environments, but at a significant efficiency cost.
  4. Body parts to support these new mechanics! We’ll need a variety of fins, tails, legs, feet, and head types to properly support aquatic and amphibious animals.



Social Behaviours

It’s time for the species in Species to forgo their ardent individualism and start acting towards the greater good. The greater good.

  1. Co-operation. Creatures will call when beginning an action, notifying other creatures in their vicinity of their intentions. This will cause other creatures with high co-operation and similar unmet needs in their vicinity to join in, whether this be to hunt as a pack, graze as a herd, or huddle together for warmth as a… flock, I guess? Yeah, flock. Because penguins.
  2. Altruism. Creatures will also call when in need of help. Altruistic and/or closely related creatures whose other needs are met will be able to respond by feeding starving creatures or moving in to defend creatures that are under attack. And I guess huddling for the benefit of freezing creatures? Because penguins again.
  3. Aggression. Social behaviors go both ways. In real life, creatures fight over food, mating rights and territory. I don’t believe I have the infrastructure in place for the latter two behaviors yet, but I do think food fights could be implemented.



Cross Platform Support – Mac and Linux

How hard can it be?

  1. Moving up to Mac and Linux means upgrading the game’s framework to XNA 4.0, and from there to Monogame. This is an engine change that I sincerely hope will allow me to provide cross-platform support.
    • I’d best note here that I can’t actually promise Mac or Linux support for 0.11.0. While it’s a goal, and upgrading to Monogame is a major step in the right direction, I don’t know for certain that it’ll be functional by then.