I’ve finished stage 1: the UI stat dictionary is no more. All data is now coming from a single, ridiculously complicated source.
I’m not kidding about the “ridiculously complicated” bit, either. Check out how many different stat classes there are, just to hold the various values associated with creatures alongside their descriptions, mutation rates, minimum/maximum, and mutation maps:
It works, though. Pretty much all the important stat data is now coming from the StatData definition class. This is a good thing.
Hmm… eh, why not. It’s possible some of my readers are almost as boring and nerdly as me, so…
Here’s a copy of the source code for the StatData class’s constructor.
In it’s current state, it includes the complete definition for all the stats, including the delegates that actually calculate quite a few higher-level stats. Things like speed, stamina and attack damage: the complete formula for them are all here.
It’s still functionally identical to what’s running in 0.8.0: some syntax and text changes, but nothing that actually changes how the simulation behaves. So you can compare it to the actual game, if you so desire.
The second stage is supposed to be softcoding the entire UI, but… well, that’s looking more complicated than initially expected.
See, rather than just hardcoding data for the UI, I’ve made quite a bit of use of C# abilities. So while some control definitions look nice and simple, like this…
startingWorldGroupBox.Position = new Vector2(0.05f, 0.36f);
… other control definitions are… less simple.
mainMenuGroupBox.Position = new Vector2(screenWidth / 2 - aspectRatio * 475 / 2, screenHeight / 2 - aspectRatio * 316 / 2);
I’m weighing my options.
I could import definitions as strings rather than numbers, with tokens like [SCREENWIDTH] being replaced by variables in the interpreter. I could try to replicate all this functionality with a data-driven system (using anchors, for example), rather than an algorithmic one. I could try to store these values as a node/variable in XML (I think that’s a thing you can do. Really not as familiar as I should be with XML).
… or I could just… not.
The investment is turning out to be larger than I’d originally planned, and although I’d still love to softcode the entire UI for modding purposes, is it really worth it if it takes a few months extra to do so?
The alternative is just doing a more general clean up on the whole thing, while keeping it contained in C# files. I’m really not sure if this is a better option or not.
Luckily, I’ve got another feature I’ve decided to play with while I decide what I’m going to do here, so I can at least postpone that decision while I consider it.
I know how much you all love dense technical jargon about boring-but-necessary coding tasks that don’t really advance the progress of the game, so here’s some. Of that.
Seriously, you might as well just skip this post, it’s gonna be dull. You were warned!
I’m currently finishing up a task that I started back in 0.6.1: unifying the UI Stat Dictionary with the Simulation Stat Dictionary. Until now, we’ve had two separate dictionaries: the UI one was handling things like describing and displaying stats (translating “47 attack damage” to “mostly harmless” or “-0.68 diet” to “herbivore”), as well as populating those horrifying stat dropdowns in the Rover settings. Meanwhile, the Simulation’s stat dictionary handles things like creating and determining stat values based on genes and environmental variables.
This isn’t a major deal, but it was enough to make keeping them synchronized annoying whenever I add a new stat, because I invariably forget to add it to one or the other and then have to deal with exceptions further down the track. I still don’t actually have a “Diet” or “Attack Damage” stat in the Simulation’s Stat Dictionary. The game’s been computing them on the fly.
So I’m killing the UI Stat Dictionary and transferring all of it’s functions to the Simulation one.
After that, I’m looking at ways to clean up the UIManager class. It has around 9000 lines of code, and is exactly as much of a mess as “9000 lines of code in one file” would imply.
Around a thousand of those lines belongs to the aforementioned UI stat dictionary.
Another 5000 or so of that is dedicated to simply defining the UI: the positions, types, starting values, ranges and so on of every 2D Control on every screen in the game. This is usually the sort of thing you’d build a tool to generate, but I typed each of those lines out by hand because I’m an idiot who thought once I had the simulation working, the UI would be easy. Afterall, it’s only 2D sprites! How hard can it be?
One of the major tasks for this update is to take all of that, drag it out into external files (probably either *.cfg, or *.xml, I haven’t decided which yet), and restructure the remaining code to read as elegantly as possible from those files.
I have some interesting idea’s for this as well, including separate dictionaries for each type of control (simply so I don’t have to cast the base class “Control” to “Label” or “ValueSpinner” or “ComboBox” or whatever the control actually is every. damn. time), as well as using either Unit Tests or a pre-compilation pass to detect typo’s in the string keys to make debugging easier.
And after those, I want to transfer the Simulation Stat Dictionary to external files. At first, this will just be data storage: text files for names, descriptions, and things like each individual stat’s mutation rate, maximum/minimum bounds, etc.
Further down the track, I’d also like to transfer the actual calculations for each stat into these files, in Lua format. This might require some reformatting, and probably some optimisation as well (it’s doubtful Lua could match the performance of native .Net code, so I may have to experiment with a hybrid system which only uses Lua for modded stats) but it would give modders a chance to read and play with with the fundamental calculations that define the simulation.
This would also require the long-overdue upgrade to something later than VS2008, so I could use .Net 4.0.
Not sure if this will happen for 0.9.0, but it’s on the table. I’ll keep you informed.
And after all (or at least some) of that is done, then we’ll get to move on to the fun stuff. :)
While I work on smaller items and gear up for the UI overhaul, let’s have a discussion about the design of the facility around the nursery.
The original and still-present concept is that the nursery is part of a larger facility, with several other buildings including a Gene Lab, a Natural History Museum and a Rover Garage. Unfortunately, this concept runs afoul of the first design issue:
The default (world size 1) species terrain map is 153.6 meters on a side (one terrain polygon is 30cm and there are 512 of them). On non-water maps the outer 10% on both sides are restricted, so that’s a maximum map size of around 120x120m. This is even further reduced on water maps (for now).
A good sized house-and-yard (in my local area) might be around 600m^2, or a square 24x24m.
Even if designed to be fairly compact, a realistically-scaled facility with room for expansion in the future is likely to dominate the landscape and make the wilds appear smaller in comparison, which isn’t what I was aiming for. Despite the microclimate elements, it was never my intention to aim for a pocket-world visual style. I would like Species to provide at least a moderate sense of scale.
One way to avoid this would be to provide an off-site facility. Then I could make it as large as I want, and provide as much room for expansion as I want, without affecting the wilds. This, however, falls afoul of the next design goal:
One thing I don’t want to do is stop the simulation when the player visits the facility. The wilds and the facility should exist in the same world, so that while the player is waiting for natural evolution in the wilds they can play with the tools in the facility, and vice versa with the artificial selection in the facility.
If the two environments are completely seperate however communicating this to the player is difficult. The way most games work, when you visit one gamestate, nothing happens in any other until you return to them.
Additionally, it reduces the sense that the wilds are, in fact, Wild. With the facility in the center of the map, it makes sense that the area around that is where the player would focus their effort and time. With an offsite facility, it raises the question of why the rovers are driving to this specific location to mess with the wildlife.
One way to solve both of these problems, plus those of scale, would be to locate the facility underground. But, of course, there is always another issue. This time, it’s…
A softer issue than the others, but still very important to me personally, is what tone the design of the facility sets. For Species, I’ve always planned to aim for something between “Jurassic Park” and “NASA”. It’s a game about science, about all the things that make science fun and awe-inspiring. An important element of the game’s theme is that it relentlessly portrays science in a positive light, even (perhaps especially) in cases where it would be contentious or morally ambiguous in reality.
Cloning? Yes. Gene Splicing? Hell yes. The science in the game might be naive or blind, it might cheerfully play god, create genetic abominations and even cause suffering and death on a massive scale, but it’s important the *game* doesn’t treat it as malicious or bad.
A remote underground base doesn’t quite fit that tone. Even the most benign and purely scientific of underground facilities, like CERN, doesn’t exactly evoke the same “science is awesome” tone that a building like the Kennedy Space Center does. There’s a reason (albeit an unfair one) CERN tends to used and abused more often in conspiracy theory fiction.
tl;dr: In fiction, science done in underground bases usually leans towards the Bad end of the Sliding Scale Of Good Science To Bad Science. That’s a trope I’d rather avoid bumping into in Species.
On the other hand, nothing is absolute. With the right lighting and architectural design, including skylights and vegetation, an underground base can be a lot less ominous and imposing. Which leads us to the…
Out of those three issues and options, there are design choices that can offset the impact of each. A compact aboveground facility combined with an increase in the default world size in future versions, could potentially work to reduce the scale issue.
Alternatively, enough animations and the presence of actual creatures in the nursery could reduce the feeling of ‘seperation’ between the wilds and an offsite facility.
The easiest approach to take, however, would probably be artistic. Deliberately design the underground facility with large spaces and good lighting to counter the tone it sets by being an underground facility. It may be a bit whimsical to think that the designers of the facility would build it that way rather than just building something on the surface, but the Species universe has always had a bit of whimsy in it, and I’ll try to provide hints as to why it was built like that.
First of all, let’s go over what we won’t be focusing on. I’ll keep making tweaks in these area’s as we go on, but the central feature of 0.9.0 won’t be any of the following:
Not Simulation Depth
Species has a viable simulation in it now. It’s got a long way to go yet, and there’s still lots and lots of neat features to implement, but in it’s current state with the new AI, it works. That’s probably the first time I’ve personally felt able to say that about it. It feels good.
If I could say the same about the rest of the game, I’d have no hesitation driving the development straight for even more complexity and depth… but I can’t. There are other area’s that don’t quite reach my idea of “viable,” so I feel like I ought to to address them first. Simulation depth won’t be the focus for 0.9.0.
Performance is also viable. It’s not great: much like simulation depth, there’s a lot of room for improvement. But it covers a large enough number of creatures on a wide enough variety of machines to be functional, and thanks to the new in-game world options, the player can take measures like reducing food efficiency to control the population and recover their fps.
In truth I tend to agree with the species forum users (there was a poll) that these elements of the game are very important, probably the Most Important, but the fact that they’re in a viable state while other elements are still half-arsed and placeholdery makes me think they need to take the back seat for 0.9.0.
So, with those off the table, which elements do I consider worth focusing on in the upcoming months?
Species has a ‘semi-viable’ UI system. From the user’s perspective, it mostly works (there’s some design flaws, like the 3 modes, but it’s not too difficult to use). But from the programmers perspective, it’s a pile of crap: difficult to change and extend, impossible to modify without recompiling, and easy to break. It needs some work. A lot of my time between now and 0.9.0 will be taken up with overhauling it.
But that’s kinda boring.
So, to reveal the far more important focus for 0.9.0:
I consider Species current gameplay cycle completely non-viable.
This is a major problem, because gameplay cycles are a central pillar of game design. They’re everywhere: in X-Com you cycle between base management and field operations, in KSP you cycle between build and launch. Even in non-simulation games: shooters like Half Life cycle between puzzles and shooting, sandbox games like Saints Row switch between doing story missions and generally faffing about.
Species has some implicit gameplay cycles (most notably, observing the world 1x speed and running the simulation at 10x) and a load of disparate features (creature tools, ecosystem tools, gene editor), but none of it is tied together. It’s just a bunch of toys to play with, with no central thread.
So the foundation of 0.9.0 will be an attempt to give Species a proper gameplay cycle.
The centerpiece of this evil scheme will be Nursery, a small walled-off area where the player can keep their own Species.
Within the nursery, artificial selection will be far more efficient, relying less on the rovers somewhat indiscriminate feeding/culling and more on directly controlling which specimens get to reproduce (and culling those who don’t, if you’re impatient). This will allow you to rapidly customise your species through artificial selection, at least in comparison to the selection rate in the wild.
When you’re done customising, you can choose to release a few members of your Species into the wild. And it will be your species, too: the moment the population in the nursery speciates from the wild ones, the game will start tracking them and their descendants as the Player Species, and they will be highlighted on both the clade diagram and sat map.
This should generate two things: an implicit goal for players (create a species that can survive in the wild) and a gameplay cycle directly related to that goal (customise and release). Still no explicit goals, of course: the game is still fundamentally a sandbox. But it will provide a mechanism for implicit goals and player-imposed challenges: create a sustainable carnivore, create a sustainable herbivore, drive every wild clade extinct, create creatures that can do X, etc.
It also cements the rovers as more than just a game entity you can use to muck with things, like the creature tools and ecosystem controls are. The rovers and nursary belong to the world of Species, and have a history in it. We won’t be exploring too much of that backstory for 0.9.0, but I’ll try to remember to include a few hints in their design…
I’m actually fairly excited about all of this: the nursary and player species ties together a number of existing features and turns Species from a toy you play with into a game you play. Throw in the UI cleanup and maybe a few Clade Diagram improvements on the side, and we’ve got ourselves plenty of scope for an update.
All images shamelessly stolen from google images to prevent this post from being a boring wall of text.
http://www.speciesgame.com/ is currently down. We’re working on fixing this, but in the meantime…
The site is still accessible via http://www.speciesalre.com/. Some links don’t work right at the moment, however, so you can use these direct links to get to the main parts of the site:
Nothing ever goes perfectly. You build an orbital superweapon, it gains sentience and decides it doesn’t want to work for you. You release horrifying biological abominations on an unsuspecting populous, turns out they were totally expecting it.
And you release a game update, and it immediately needs fixing. Oh well, we can do that one at least.
· Added Berserk Behavior
· Fixed Anger >> Drive Off Target behavior loop
· Fixed compressive stress energy loss being doubly-exponential, which was causing sticklegs
· Fixed Middle Limb Droop no longer influenced by Torso Width
· Fixed creatures hunting newborns on other side of map
· Fixed extinct species clade not being revived when species is
· Changed creature sprite to show legs in neutral position
· Changed Water Height Display to round to 2 decimal places instead of 1
To install the hotfix, if you’ve already installed the game:
– download the zip file
– extract the files with winzip or similar
– copy them into your Species ALRE 0.8.0 folder, overwriting the existing files
This hotfix should be compatible with your existing 0.8.0 saved games and exported creatures.
Go forth my abominations! Deorbit and seize this world from it’s puny inhabitants!
And while they’re having fun, everyone else can download Species 0.8.0 over here on the download page!
Here’s the changelog! The following is by no means exhaustive, but it should give you a good idea of the main things.
• Behavior-tree AI. The big one.
• Emotions. Hunger, fatigue, anger, fear, discomfort (temperature) and amorousness are represented, each with a course of action creatures can take to address them.
• Personality. With mutable genes affecting how easily each emotion increases, as well as slightly more complex traits like empathy and motivation affecting their food seeking behavior.
• Rationality. Creatures will (attempt to) logically determine the best method to find food, based on their personality, diet and circumstance. They may choose to graze, browse, hunt or
• Perception. Creature's can now see, hear and smell with the appropriate sense organs (though smell's a freebie).
• Sleep. The "Energy" bar is now strictly for pre-digested food. All energy losses now come out of health, and a creature can sleep to restore health from energy.
• Pregnancy. Creatures will now carry a child for a short period of time before spawning it, during which they will experience rapid health loss (as the energy is transferred to the fetus).
• Double the number of music tracks. Special thanks to Brain Sugar, who bowed out of the project some time back, but left us with a few awesome extra tracks to use.
• Separate Run/Walk speed Although it's not hugely noticeable at this stage, they run when hunting or fleeing other creatures.
• Weather particles. Ice, smoke, splashes and delicious firey burningness.
• Sea Ice. Strong enough to walk/drive on at that.
• Creatures explode when they die. Most. Important. Feature.
• Cliffs. They're cliffs. I got nothing.
• World Settings editable in-game. About time!
• Random Generation World Seed. Seed 58 is a pretty cool 2-island map. Try combining it with a longitudinal temperature map for a cold island and a hot one!
• Stability improvements. Lots of bug fixes and tweaks.
• Long term simulation tweaks. The simulation's fidelity as a whole is looking a lot better. Significantly fewer exploits and broken survival strategies mean a far more interesting world.