Hello again, and welcome back to another week of the blog about feelings induced by the making of games! This week, chaos happened, and then I fixed it. Also some planning.
After making the decision to keep working on the project I thought it was about time we set some guidelines for ourselves. Despite having a rather loose project structure it’s still very useful to know what our goals are. We just need to compile a simple list of everything, so I busted out a spreadsheet and went to work. We’ve decided to aim for five levels instead of the original ten, each one with about 20 unique art assets (many of which are broken down into multiple variants). That leaves us with about 100 entries in total, most of which need a model, UV-map and texture. It’s a lot, but not completely absurd when shared between two artists. If we work hard I think we could probably make it by summer.
On the programming side things are a little bit different. Most of the basic content is actually already done, it just needs a lot of polishing. So my goal is going to be improving the general player experience. That means everything from menus to game feel to performance, taking every little disjointed piece and fitting it into the core experience. It’s rather nice and relaxing work, if a bit unorganized. But you know what? I think that’s going to work out really well. I won’t be able to devote myself to the project the way I previously have, what with life getting in the way and such, so it’s going to be really nice to just be able to sit down and do some smaller adjustments every day. It’s easy to get into, but also makes for steady progress every day.
So to start off this polishing process I decided to do something you should probably never do if you’re serious about game production: I upgraded Unity. Upgrading software you rely on, as anyone who’s ever been an early adopter of an OS can attest to, is like a game of Russian roulette. At some point it is bound to go horribly wrong. So I loaded up the project files and was greeted by this monstrosity:
That is pure game designer nightmare fuel. Luckily, the problem turned out to not be nearly as bad as it first seemed. I’ve actually had something very similar happen to the project before, so at the very least I had some leads to follow. In computer graphics there is something called a draw call. Think of it as an instruction from the CPU to the GPU asking it to draw something. Since the two are independent units you want them to communicate as little as possible and focus on doing their own thing. In the case of the GPU, that thing is processing very large amounts of data very quickly. So to keep it occupied you want to send it the largest possible draw calls as rarely as you can so it doesn’t have to depend on the CPU. Unity allows you to do this by using a technique called static batching, which mashes all your static objects into a single big polygon amalgamation. The engine does all the work, then you just send the lump of objects to the GPU and let it chug away. Notice how the objects in the image look like they’ve been stretched out and unraveled? That’s a clear sign of static batching gone awry. Somewhere in the depths of Unity a triangle or vertex has been corrupted, lost or misplaced, and now the entire polygon chain is broken. But why does something like this happen after an upgrade?
Usually these symptoms mean there’s something wrong with one of the model’s you’re batching. Last time I encountered the problem there was one mesh that clearly broke everything when enabled. But not so much this time. I hunted for that one object for hours, but surprisingly enough the problem turned out to be our lightmap data. Lightmapping is another technique used to improve performance, where you render out your lighting effects into a texture file rather than draw them every frame. Imagine a wall with a spotlight on it. Then imagine you paint over the light on the wall to look exactly like it and turn off the lamp. That’s lightmapping in a nutshell. Somehow this data had been corrupted when we upgraded, so I decided to clear it out and regenerate it. And wouldn’t you know it, that fixed the polygon issue as well. I still don’t know exactly why. It seems to me like they would be completely separate systems. I’m guessing the mesh combiner applies the lightmap data like any other texture, and when it found some of it to be missing it freaked out and lost control of the process completely. Whatever it was it works now, and seems to have been the last of our upgrading woes.
(Don’t worry about the giant glowy ball, that’s just the bloom effect going crazy for some reason)
That’s not to say upgrading is all bad. I actually spotted something very exciting in the Unity Roadmap just a few days later. It seems like we’re finally getting geometry instancing! That probably doesn’t mean much to most people, but for us it’s a super useful feature that has the potentially to drastically improve our performance. Remember draw calls? In a game like ours with hundreds of enemies each enemy means doing at least one draw call. They’re complex, animated objects, so you can’t easily batch them. They are, however, very similar, and each use the same model. With instancing, we can tell the GPU to draw the same model a bunch of times with different parameters in a single draw call. That is game changing for us. For a long time now we’ve been performance bound by our huge character counts. If we get instancing working right that operation is going to become trivial. Since it is an engine update we’re just going to have to happily wait until march 16th before we get it, but once it arrives I can’t wait to go through the whole upgrade song and dance again. It may be a game of Russian roulette, but it’s a game where one chamber is loaded with an endlessly tempting piece of candy. I usually tell myself that makes it worth it.