Posts Tagged Shader Model 3.0

Black-Ground Bug, Stat Development and Body Physics

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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




, , , , , , ,