Posts Tagged tutorial

How to Mod Species

Alright, let’s get into how the Mod Maker works at the moment. Short version is: you can create a new body part, body covering or colour pattern, and import it into the game. It may then appear in the game naturally, by mutation.

(As a bonus, I’ll also show you how you can cheat the system to swap out almost any existing content, from textures to models)

There are roughly three categories of mods: Textures (Body Coverings, Colour Patterns and Feature Textures),Models (Heads, Feet, Features), and Animated Models (Limbs). The steps are slightly different, but very similar, for each.

Step Zero: Install XNA

Unfortunately, if you want to make mods, you’ll need to install the full version of XNA Game Studio (not the redistributable version you already installed to play the game. Sorry). You can get it here. Don’t worry, it’s free, and not too big.

Edit: Crud, it looks like you may have to install Visual C# 2008 Express (also free) before you can install XNA. How irritating. Oh well, once that’s done it’s easy to make parts…

First Step: Make Your Content

Species Sample Scenes and Textures (you can use these to follow this tutorial, as well as reference material)

Naturally, you can’t do anything until you have something to import. There are a few tips you’ll need to know for this, depending on what content you’re making…

Textures:

1. Body Coverings are the easiest thing to import. For your first mod, I recommend taking a random texture photo (bricks or something) and importing it as is: it’ll appear on some of the creatures in your game. You don’t really need to know anything special about making body coverings, except that pale or greyscale colours work best.
2. Colour Patterns and Feature Textures are also easy to make. Red will be converted to the creatures primary colour, and Green or Blue respectively is the secondary colour (why are they different? the better question is, why have I not noticed that they’re different until now?).
3. Texture Size doesn’t really matter. I generally use 512×512, but it’s up to you. Just don’t go above 2048×2048: some graphics cards can’t handle it.
4. Texture Format again doesn’t really matter. The mod maker will accept a variety of formats, including jpg, png and bmp.

Models:

1. For modelling new body parts, you’ll need to obtain a 3d editing software, like Blender or Maya or 3ds Max (I use 3ds Max).
2. Next, open up or import one of the sample scenes (link above) There’s two each for Heads, Feet, Features and Limbs. This should give you an idea of the size and orientation of a default body part, and you can easily hide or freeze it and begin work in that file.
3. Model your body part. There are loads of online tutorials for modelling, and the help documents for modelling programs are quite detailed.
4. Recommended steps: (Not strictly necessary, but I generally do these before exporting every model to save on headaches later. There are a plethora of things that can go wrong when exporting models: these steps eliminate at least a few of them)
a. Convert your model into a single object, if necessary (3ds Max: Convert To Editable Poly => Attach).
b. Position the object at [0,0,0]. Also move the Pivot Point to [0,0,0]. If you have to reposition it after this, select it’s vertices and move those directly.
c. Remove any textures you may have applied (just give it one of the default materials).
d. Reset XForms.
5. Export your models to either *.FBX (Autodesk) format or *.x (DirectX) format. These are the only formats the mod maker accepts.

The Mod Maker

Once you have your content ready, open the Mod Maker application. You will be greeted with this horrendously hideous screen, the mere sight of which caused the ugly duckling to grow into a vulture:

Obviously, the first step will be to pick what type of content your content is. Do that and click “Next”. You’ll be asked to select the content file: do that now.

The Mod Maker will import your mesh, and you will find yourself looking at the next extravagantly disgusting screen.

Here you can define the in-game statistics of your body part. Most of these stats are self-explanitory: look in the vanilla folders or ask me a question if you are wondering about the usual ranges for some of the statistics. After you’ve specified your stats, click “Next”.

Modded parts are stored in Mod Packs: self-extracting Zip files, which can contain any number of modded parts. You will need to create and select a Mod Pack (with the create button) to add your part to. When you’re done, click okay.

The next page you are greeted with depend on what you are making. If it is a Head, Foot or Limb, you will go to the Mutation Map page.

For these body parts, you will need to add the part to the mutation map. Click and drag to attach the new part to an existing part, allowing mutation between them. If you want to see it appear immediately, attach it to “None” or “Gen1”. (I’ll try to put up some basic screenshots and data about the vanilla parts on the Wiki)

Once it’s added and you click next, or if you were making a texture or feature, you’re done!

The part has been added to the Mod Pack you specified earlier (which can be found in the Mods folder), and will appear in the game the next time you play it.

To uninstall it, simply remove it from the mods folder. Easy!

Now, for the bonus stuff!

If you want to replace an existing vanilla asset (recommended: make a backup!), for example if you’re trying to create a hi-def texture pack for the game or want to replace the background model, run the asset through the Mod Manager as a Body Covering or Feature Model (depending on whether it’s a Texture or Model). Once that’s done, edit the zip file to match the directory structure of the Content directory: specifically, the location where the original file is stored.

Finally, move and rename the *.xnb file to the same location in the Mod Pack as it is in the Content Directory.

And you’re done! This mod pack is now a replacer: the next time you run Species it will replace the existing file with this one and you’ll see it appear in game, replacing the old asset.

(Note: you’ll probably want to take a backup of the vanilla asset, just in case things go wrong)

, , , , ,

3 Comments

Render Targets Are Evil

aka. Misadventures In Implementing a Real Time Tree of Life Graph. Note: this post is a logical sequel to the previous post, though it also doubles as a what-not-to-do tutorial of sorts when it comes to implementing real time graphs and render targets in XNA. Fair warning: It’ll probably be a bit incomprehensible if you’re not a programmer.

/tangential progress report: we’re about 40% of the way to the alpha release deadline and about 50% of the way through the “list of crap to do”. So we’re ahead of schedule, but not by much.

It’s probably worth noting that part of the reason I’m cutting it so fine is micro-feature-creep. A major advantage of programming on your own is the ability to indulge your inner ADHD-sufferer: getting distracted by something that sounds like fun and wandering off to code it. Some of my favorite features in Species have come about via ooh-shiney moments like this, but it slows down my progress on the stuff I’d planned out in advance.

Okay, back to the topic…

I not-so-briefly touched upon my very first tree of life graphing attempt in the previous post. This image…

… shows the end result.

Frankly, it’s ugly. It’s barely recognisable as what it’s supposed to represent, and it’s a performance hazard. Each one of those bars is a seperate sprite representing the life-time of a creature, which means I’m calling DrawSprite() a couple thousand times every frame. This would be manageable if I stopped drawing the simulation in the background (a tactic I’m may have to adopt when I get around to trying out the life-web I mentioned last post), but because I was rendering it as an overlay this wasn’t something I spent much time considering.

The idea behind this graph was that it would show the culmative effect of population changes by displaying all the creatures lives at an individual level. Admittedly, it manages this to some extent, but it does so extremely poorly. The rapid movement to the right, for example: that’s not natural selection, that’s just the logical result of measuring mutation from the starting location. If you start a value at 1, and your children are 0.9 and 1.1, it doesn’t matter that they are going in opposite directions: they will both appear at 0.1 on the graph.

But as far as first attempts go, it taught me quite a bit about what I was trying to achieve. That’s the whole point of prototyping: try something, learn, then try it again using the information you’ve learned. In this case what I learned was that showing individual creature lives was too microscopic to paint a good long term picture. I was going to have to summarize, and for that I’d need to use the species and speciation tranking system… which, despite post order, I hadn’t implemented at this stage. The above graph was generated entirely from random colour changes and the genetic distance algorithm.

So I went and I implemented species and speciation tracking while researching and considering my next move. Surprisingly, for such a simple concept, there are a whole variety of ways to implement a real-time graph. I’ll get to those in a moment, but first: what I decided I wanted to achieve was a population tracking graph that would show the relative size of each species and the effects of speciation, so you could see whether the splintering population was a single sterile creature, or a large segment. It would also need to be able to dynamically move and re-arrange population lines, to keep them from overlapping and under-representing the total population. This… turned out to be more ambitious than I expected.

I narrowed it down to a number of ways to do this:

1. Brute force sprites: draw a lot of sprites to form the shapes you want. This was the method I’d used for the previous version, and despite my complaints, for that version it was actually feasable: the number of sprites involved aren’t a negligable performance hit by any means, but they’re manageable and they’re easy. But to do this for a graph that shows changing population size on a per-frame/per-pixel basis? On a modern monitor we’re talking about 1080 sprites, multiplied by the number of species shown. Not viable.

2. Vertex List: dynamically changing geometry to represent the shapes you want. I didn’t spend much time looking into this option, but it has a number of things going for it: dynamically re-arranging Species Lines would be easy to do. The biggest problem with it is the bottleneck between the GPU and CPU: dropping that much vertex data on the GPU every frame can’t be a small performance hit.

3. Shader Trickery: sending the raw population data to the GPU and having it do all the work in the pixel shader by, essentially, drawing the graph on a transparent slide right in front of the camera. This is probably one of the best options here: it defers a lot of work to the GPU, is easy to implement, and allows the things I wanted to do, but… older shaders can only handle so many variables as parameters (255 for shader model 3.0), which is nowhere near enough. The CPU-GPU bottleneck issue still exists, but Shader Parameters are designed to be modified on the fly in a way that Vertices aren’t, so it’s not as bad. If I was targetting a later shader model this would probably be my preferred option, but as it stands… no.

4. Colour Arrays: generate an array of Color objects, modify it directly every frame, then save it to a texture and render that texture to the screen. Similar to option 3, except done entirely on the CPU rather than the GPU. I actually tried this one out: turns out that for full-screen textures it leaves a pretty massive footprint on your performance.

Yeah... note the frames per second counter, top left.

5. Render Targets: Oh god.

I hate render targets. I’ve had several dealings with them in the past, and every time they’ve given me a whole new bunch of reasons to hate them. Render targets are evil. /title drop

Don’t get me wrong, Render Targets are a vital and powerful aspect of the XNA framework, and there’s no doubt we’d miss them if they weren’t there. But they’re still evil. I still have nightmares about debugging Render Target issues. (okay I don’t really, that was hyperbole. My nightmares are more only have ordinary everyday things, like giant zombie demon spiders with flamethrowers held in their pincers. Also, the moth. Everybody has nightmares about the moth right?)

If not, you do now. You're welcome.

The basic concept behind this approach is to render only the ‘front’ pixels of the graph, then move the entire thing 1 pixel along next frame and render the next set of ‘front’ pixels. For a single line graph, this means you only have to draw 2 sprites: 1 for the line and another for the entire graph that was rendered last frame. This is a very efficient way of doing things, with the disadvantage is that what is drawn is drawn. I can’t modify the graph later if I want to move population lines to the left or right in response to population pressure.

But you can’t just do this straight onto the screen: I’m rendering everything else onto the screen, so I don’t want to be moving all that one pixel to the left every frame. Just the graph. And that means render targets, which are basically extra screens that you can activate, draw stuff on (without overwriting anything else) and return to later. Sounds easy, right?

A few points about render targets, for XNA users who are interested in avoiding the same horrible spiky pitfalls I fell into, climbed out of, then tripped and fell into again:

1. A render target has to be removed from the device before you can retrieve the texture from it. Failing to do so causes an exception. To remove it, call GraphicsDevice.SetRenderTarget(0, null);

2. Switching to a render target, then switching back, has an unfortionate tendency to clear your screen to a certain shade of purple. There are reasons for this (mostly because XNA is designed to work with the XBox, which has it’s share of quirks), but I didn’t know them at the time. All I knew was “suddenly purple WTF?”. To avoid this, it’s necessary to render to any Render Targets’s before you draw anything to the backbuffer.

3. A render target cannot render it’s own texture. In order to do what I said before (render a texture, then move it one pixel to the left and render again) you actually need to switch back and forth each frame between two render targets.

4. A render target cannot be used to render to multiple textures. You’d think you’d be able to render an object, then copy the result into a Texture2D and render a new object. This is what I wanted to do with the population lines so I could move them left and right: draw each one seperately and move their parent sprites. Turns out no: copying the result into a Texture2D only copies a reference to the Render Targets texture, so when you render the next thing in the list you overwrite the earlier Texture2D.

5. There is apparently a limit to the number of render targets you can have, so you’re not allowed to render multiple seperate objects that way, either. It’s nothing concrete, but somewhere between 40 and 60 targets the program will start to glitch out. For me, the sky went white, the game briefly lagged, and then it crashed out with an incomprehensible exception. I have no idea why these were the symptoms of too many rendertargets: I choose to believe I’d accidentally imported an identical anti-matter universe into the game and everything except the earth exploded at once. The few seconds of lag were just waiting for the shockwave to hit.

So how can you render an unknown number of seperate objects, like population lines, into seperate textures? There’s only one way: use a single render target, and perform a deep copy of the Texture2D before you move onto the next object so you copy all the information of the object and not just it’s reference. So how do you perform a deep copy? SetData() and GetData(), two of the slowest texture related functions in the framework! As it turns out, this performance hit for an almost-full-screen graph was almost as bad as option 1, way up there earlier in this post. So that’s out too.

(It’s probably worth noting that this method, can be possible for smaller images, like 256×256 thumbnails, where there’s less data to copy. I still don’t recommend doing it more than once per frame, however)

Eventually I gave up and left the population lines alone. The current system lets them stay where they are, overlapping.

No. No I do not forgive you just because you're working. I will forgive you only when the mental scarring goes away.

I’ll leave the fancy visual stuff to the proper phylogenetic tree, which won’t display population histories and will be implemented later WITHOUT RENDERTARGETS. SCREW RENDER TARGETS. (okay, maybe with one render target).

Hatethemhatethemhatethemhatethem…
Qu

Apparently he hates rendertargets almost as much as he hates multithreadin-“
NO. YOU DO NOT SPEAK THAT WORD IN THIS HOUSE.

, , , , , , ,

4 Comments