Posts Tagged content loading
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.
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:
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:
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.”