Posts Tagged Game Development
The code’s finally in a stable enough state that I feel justified in announcing a release date. So here goes nothing…
Species 0.6.1 will be released on the 1st February.
This update includes a lot of the cleanup and polish elements originally planned for 0.7.0. A lot of the changes are background
improvements to the underlying code, but that’s not to say you won’t see some changes to the game itself…
A variety of major 0.6.0 bugs have been addressed, most notably:
- 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
(Of course, it’s entirely likely we’ve added our own set of new errors to replace them, so don’t get too comfortable)
Quite a few visual improvements:
- 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.
Plus a number of subtler ones, like adjusted tree shaders, a better wasteland texture and we got rid of that weird blue shading on trees when you pause the game.
It’s not been all about code and shaders: we’ve also overhauled the content in some of the less-developed area’s of the game.
- Body coverings: fur, feathers, scales and skins. Also octopus suckers, toad warts and Quasars forearms (ewwww…), but we’re probably better off not mentioning those.
- Leg shapes: from 6 to 20, meaning a much greater variety of knees.
- Heads: a number of additions (and of course, the existing heads had to be adjusted to provide beak and mouth textures and fur polygons).
I’ve been creating Things That Should Not Be. Alright alright, I’ve actually just been modelling limbs, but the Things That Should Not Be are a direct side effect.
Ignore the graphical errors, such is the nature of the development version. I’m much more comfortable creating things when surrounded by unfathomable hideousness and strange transparency artifacts. It’s like Linus’ security blanket, except for me it’s non-euclidian geometry and broken texturing artifacts.
Or possibly I just have a tendency to break things and put off fixing them because coding is more fun than content creation. Irrelevant.
In addition to monstrous abominations of tentacled science, I’ve also been breaking and then fixing and then breaking again (repeat as required) a few other things.
I created a dedicated HighlightTint object for managing colour coding and status flashes on a per-creature basis. Different highlight causes now have priorities, and lower priority causes can’t override higher priority ones. This should fix those display issues with creature’s not showing that they’d been spliced or attacked because of the grazing or feeding cycles. Not the highest priority bug fix, but it came free with the code cleanup and I’ve always been a sucker for bargains (that’s a total lie, I don’t buy anything unless I’ve thought about it and decided it’s useful and practic- YOU CAN BUY QUADROTERS FOR ONLY $50?! GIMME!).
Let’s see… I also glared silently at the QuadTerrain generation algorithm until it surrendered to my will and reduced world-loading times by about 30%.
And I fixed a difficult problem that had been plaguing me for weeks, ever since I modularised the SpeciesList, which is that the species count wasn’t going down when creatures died. Found out it was caused by a typo adding Creatures to the Species twice. Easy fix.
And the Body Part Voting Competition has reached Round 7. It features a choice of heads from Avialae, which is objectively and indisputably the best-est clade. And once again, the choice I voted for is doing miserably.
I’ve been playing with the torso height system.
As I’ve mentioned before, the creature’s are drawn from the torso outwards with their limbs ‘hanging’ off them, like a jellyfish or an octopus or the incomprehensibly alien True Form of our current Prime Minister [“He knows! Get him!”]. In order to give the impression of standing on their legs, the creatures in Species need to calculate a vertical offset called “torsoHeight” before they draw.
The previous system for establishing this offset was fairly simple: every frame, check each limb against the ground, and if none of them touch, reduce the torsoheight. Inversely, if the limbs are underground, push torsoheight upwards.
This dynamic system led to torsoHeight becoming one of the most abused values in the game: I’ve used it for gravity, anti-burrowing measures, the ‘bouncing’ when they’re attacked, etc. Unfortunately, this sort of abuse leads to emergent behavior, and not the good sort: this is the reason creatures float up out of the ground when they’re born, why they can fly when continually attacked by multiple attackers, and why they drop down onto their torso when the LOD stops drawing their limbs.
And more importantly, it’s why I haven’t been able to use torsoHeight for selection pressures. When two identical creatures can have different values based on Level Of Detail, using it would introduce strange artificial pressures based on where the camera was and what it was focusing on.
So for 0.7.0, torsoHeight is being replaced by a non-dynamic version: it will be calculated once at birth based on the creature’s skeleton, doubled when they grow to adulthood, and not updated again until they die, vanish and are recycled. I’ve broken it out into 3 components: ShoulderToCoG, ShoulderToAnkle and Tipheight.
It never as simple as it looks, of course: needed a bit of trigonomtery for ShoulderToCOG (why didn’t anyone tell me trig would be useful in school?), a few world-space transforms for converting bone matrices back into world co-ordinates, and I needed to find a way to test each component seperately because I tend to go through a lot of trial and error with this sort of thing.
But after a few hiccups with floating/burrowing creatures it’s finally starting to work out (though there’s still a few oddball cases that cause floaters), and eliminating those emergent properties I mentioned above makes things look quite a bit neater. Especially noticable is that creature’s no longer drift up out of the ground as you approach them, which makes it more apparent that the stuff popping in was there, but just not displayed before. It’s just polish, but it gives the game a slightly more professional feel.
And better yet, since torsoHeight is determined at birth now, I have a good solid foundation to work from and I can start considering what other parameters it’s going to affect… [insert maniacal laughter]
Hey look, the runners up from the last few rounds are back for another go for BPVCT Round 5:
Also, here’s a picture of a crowd of fluffy Primum specium (and one scaley one), just to prove that progress is still being made.
Though I still need to fix that horrible horrible mouth texture… 🙂
Development continues apace. I’ve been building a pair of simple Development Tools.
This is the Spritesheet Compiler, for making spritesheets like the one in the last post. Should save rediculous amounts of time when we’re creating Body Cover textures. It allows us to treat each sub-texture as it’s own file, right up until the point where we compile them for viewing.
And this is the Object Visualiser, a program to quickly load up Models and Textures and render them using the same techniques as the game. Should make it a lot easier to make and test new models: previously I’ve been importing them into the game proper, loading up Initialise Random, and going on a safari to see how they turned out.
And for something completely different: fur! And a hideous mouth texture!
These are placeholder textures, of course. I’m actually using one of the Grass texture for the fur’s alpha channel. And we’ve got tooth textures too, but P. specium doesn’t have teeth (ooh, idea!).
The new rendering system is not without it’s problems: it’s very intolerant of misplaced Texture Coordinates, and the fur polygons take forever to model in (we’re experimenting with various techniques to apply them faster: should probably do some research). But hey, at least it looks okay! Well, by some people’s standards. Mine, anyway.
Welp, Round 2 had a three way tie (roughly… it depends when you take the count) and people took my comment about merging the headtypes seriously, so it looks like we’ll be modelling something lovecraftian, similar to the image below, for 0.7.0. Yay!
That’s a poor precedent to set though, so in the future ties will be broken by some (hopefully fair) means, rather than putting the parts through another horrific bioblending. Sorry guys, but I think it’s gonna be more fun this way. I reserve the right to perform horrific bioblendings for special occasions, though. Like weddings.
Round 3 offers up four beautiful insectoid head pieces, because nothing says “we love our fans” quite like a massive dose of entomophobia. Your options are:
Go here to vote before the 13th: http://speciesgame.com/forum/viewtopic.php?f=24&t=309
“More weddings should be accompanied by horrific bioblending.”
(Edit) You can now suggest your own idea’s for Head Types for future Voting Competition Rounds! I’ll pick out my favorites and/or the most popular ones to use as the Poll Space for Round 4!
If you played Species 0.5.0, you may have noticed an evolutionary bias towards brightly coloured creatures over grey, black or white.
If you’re thinking entirely in terms of natural selection, this might seem odd: colour is a completely neutral mutation in 0.5.0. There is no selection pressure related to colour. No, not even a hidden special one I haven’t told you about. Colour does not affect their survival or reproduction in any way.
And yet the creatures consistantly evolved from grey to bright colours. Why?
This is where an evolutionary mechanism known as Genetic Drift comes into the picture.
For a value that randomly mutates or ‘wanders’ in a single dimension, Genetic Drift has a fairly negligible influence. As you can see below: the wandering line hovers around it’s original horisontal position. It can still wander fairly significantly, but simple statistical pressure mimimises the effect of drift:
The same does not apply for a value that wanders in two dimensions. A value wandering in two dimensions is unlikely to return to it’s starting point, because when it does both the wandering x and wandering y co-ordinates have to be there at the same time. This rarely happens.
This effect increases with every dimension of wandering: if you allow the point to wander up and down as well, it’ll will move away from it’s starting point even faster. And for a creature in Species, with a genome of almost 100 different values or ‘dimensions’, this statistical bias exerts is a very strong pressure.
And this is where things relate back to colourful creatures. Colour is represented in computing terms by 3 values: red, green and blue. Each of these values mutates randomly. In order to get a monochrome colour like black, white or any shade of grey, these three values all have to pass through the same spot at the same time. As said before, this rarely happens.
So the end result is that even with no selection pressure applied, genetic drift causes continual change towards brighter, more distinct colours.
Genetic drift doesn’t get the attention that natural selection does in textbooks and introductory curriculum (afterall, ‘things diverge statistically’ is hardly as memorable a concept as ‘survival of the fittest’), but in reality a lot of the biodiversity in the world is likely more attrituable to genetic drift than to selection pressures. Selection pressures only provide traits that are strictly functional in the creatures niche: simpler neutral mutations like differing plumage and skin colours, facial features, fur growth patterns and so on are almost certainly the result of genetic drift.
The two aren’t so easily distinguished from each other, though. They’re intertwined: genetic drift is a statistical effect of random mutation, which means it provides the raw material for natural selection to work with. If Evolution were a games industry, genetic drift would be the indie developers who put out loads of crazy original idea’s, while natural selection is the AAA industry who rarely contribute new idea’s but do take the best idea’s and refine them to be even better.
Genetic drift also provides an interesting counter point to the common anti-evolutionist claim that “natural selection reduces information”. The common answer to this claim is that mutation increases information, which is true, but doesn’t tell the whole story: as you can see in the first example above, is mutation was a simple, 1-dimensional measure it would only provide small amounts of new information. Genetic drift makes up the difference by providing new combinations of information, and is a major contributor to rapid evolutionary effects like Punctuated Equilibrium.
Oh, and a note about Species: Genetic Drift in Species has a tendency to drown out Natural Selection. If you reduce the Mutation Rate, you’re likely to see much more in the way of selection pressures.
With all that said…
The bright colours looked garish and kind of ugly. They didn’t look natural at all. But as I said in the comment thread this came up on, it would be go against my design philosophy to ‘fix’ the issue. The bright colours are a valid result of Genetic Drift: applying counter-biases towards less bright colours would amount to me preprogramming my own preferences into the simulation.
There’s another option, though:
The RGB representation is unnatural in and of itself. In nature, pigmentation is handled by chemical compounds of certain colours that are pushed to the surface of the skin. A chemically-accurate pigmentation simulation is beyond even my level of bio-programming masochism, but the point is that there is more than one way to represent colours: we’re not necessarily locked into using RGB.
An alternative solution is storing colours as Hue-Saturation-Luminosity. This would mean the genetic drift would seem less directed: similar numbers in HSL would still be less likely than differing ones, but they don’t have any sort of correlation to a specific tone or shade.
As the test above shows, randomised HSL colours have a much higher incidence of desaturated black, white and grey’s, and in general look a lot less circus-y and a lot more natural than the equivalent randomised RGB palette. HSL randomisation can still generate bright colours, but they’re less common.
Of course, there are always going to be problems. The increased incidence of black makes it difficult to make out body texture on quite a few creatures in the game, for example. But that’s something we can deal with via graphical upgrades, like gloss mapping.
0.6.0 uses a hue/sat/lum shader, and even though the difference is subtle, it’s noticeable if you’re looking for it.