- Even more Optimised: As boring as it is to say, Lunacy has undergone yet more optimization! Everybody’s favorite element of games development.
- Music: Andrews’ awesome music is in game, now if only I could figure out how to squeeze it into the next Dev Vid without me having to stop speaking for ages.
- Searchable Buildings: Buildings can now be searched for supplies, there’s some definite survival game flavour sneaking into this action game.
- Close Quarters Weaponry: Melee/Close Combat weapons are in and working! To be specific a particularly nasty looking baseball bat filled with nails.
- Lighting Overhaul: Lunacy is now lit by a mix of vertex lighting, baked light maps and my sweat and tears. In layman’s terms, it’s prettier!
- +1 to Scenery: Cars, ambulances, new lampposts, porch lights, new hedges and some suspiciously Cretaceous footprints have been added.
- +1 to Ergonomics: On screen joysticks are larger, more sensitive and aligned with the camera in a more constructive manner.
- Camera Upgrade: The camera is now angled in a more interesting way, and automatically adjusts itself should buildings block your view.
- Smoother Zombies: Zombies now animate and turn more smoothly.
- Moar Zombies: The zombies in the suburbs have diversified into Classics, Runners, Sprinters and Crunchy Ones and been color coded for your convenience. I imagine I’ll do a post about the differences between these guys sometime soon.
Only the werewolf transformation and survivor tracking mechanics need to be done now. Then all the core bits that make up a game session are complete and focus can move in the direction of menus, journals, leveling up etc.
This post is about something a little different, I’ve spent a lot of time fussing with optimization during the course of Lunacy’s development and I thought I should share some of the more obscure things I’ve learnt, on the off chance I can save somebody else hassle in the future.
There’s already a lot of information on the web about the more common approaches to optimization, lowering frame rates, removing lag etc. Repeating all that information isn’t the purpose of this post, so to that end I’ll only provide links to the following webpages, which were a great help to me.
The actual purpose of this post is to highlight a few of the less well-documented potential sources of lag/lower frame rates I’ve run into so far:
1. Unity Planes
Unity planes, (the ones from game object -> create other -> plane), are not your friend. Firstly they come with mesh colliders, you’ll want to change these to box colliders, as mesh colliders are more intensive. (And as far as I can tell, completely unnecessary for a plane.) Secondly, these planes consist of a great many triangles, so you could potentially stand to gain by replacing them with simple (two triangle) planes you’ve brought in from a 3d modeling program. Doing so will make you unable to effectively use vertex lighting on the planes or things like fog. However if you’re not using fog and using baked light mapping, which you’ll probably want to do as its less intensive, then the 2 triangle planes should serve you fine.
2. Too Many Active Objects
Now this may seem ridiculously obvious, but it wasn’t for me so for the sake of any likeminded folk reading this I’m including it.
My trail of thought was that I would be able to get away with large amounts of objects as long as they weren’t within the camera’s rendering range, weren’t referred to by any active scripts and were just simple objects. I tested this with basic cubes with box colliders in Lunacy, queried Unity Answers, but ultimately came to the conclusion that I was completely wrong.
As long as the objects are toggled to active, even if they’re very simple, are not having their polygons rendered and are not interacting with anything, they will still cause a significant drain on performance in large numbers.
We had always intended to have fairly large and expansive areas in Lunacy, to compensate for us not having the manpower to produce a large variety of them. But of course large areas require lots of objects and I ran into this issue. Ultimately to counter act this issue I scripted a system in which all the environmental objects in each area are activated and deactivated in tile-marked segments as the player moves around. The cost of this is the occasional brief loading pause mid level, but it’s a price we’re willing to pay.
3. Dynamic Text
This one comes down to using a custom font set to dynamic, as they are by default. (Set under “Character” in the font import settings.) Dynamic means that Unity generates a texture for each character in the font on-the-fly the very first time that character is displayed. I’ve found in certain circumstances this can cause tiny lag spikes the first time specific characters are displayed. A simple enough solution to this issue is changing “character” in the font import settings to ASCII default set. Though this will mean you’re stuck with only one font size per font file and can’t align the font to center or right.
A Final Note
I should stress these are simply things I’ve found to be the cause my own problems via my own experiments, so they won’t necessarily be the cause of any problems you might be having or even be worth worrying about in your game.
Furthermore, this is my first time working on an iOS game, I’m still learning, so if somebody out there does have reason to disagree with any of my conclusions or can shed light on why number 2 happens, do let me know!
I should also mention that we’re developing in the free version of Unity 4, so if you have Unity Pro I imagine point number 2 could be less of an issue, as you can use static batching.
Going back through our original 29 page design document, I can’t help but notice how incredibly uninspired the enemy types were. For example two such enemies were the bloated zombies and abominations, just generically larger zombie creatures, the result of mutation and/or Frankenstein-esc body modification.
Now that should sound very familiar to just about anyone who’s played any game with undead antagonists. So familiar I doubt their appearance in Lunacy would cause players to bat an eyelash or even briefly consider what those creatures are doing there. After all I’m pretty sure it’s a commonly accepted trope that wherever there are enough zombies in videogames bigger zombies just happen. Even if that’s not the case its pretty much expected practice of any evil antagonistic faction to start taking their undead apart and putting them back together in horrific, if not questionably practical, ways.
So why am I bringing this up? Well Lets face it, by indie standards Lunacy is not a startlingly original game and I don’t think including such a predictable roster of enemies was going to at all help in making it memorable. As such I’ve been trying to take the enemy roster in a new direction.
So what is far more likely to catch peoples eye, make them interested and maybe even get them to think about the situation a bit? A Vampire T-Rex!… or that’s the theory anyway. This all fits back into a thematic flavor I was initially uncertain about. Where in the game fully embraces the ridiculousness of werewolves fighting zombies and strives to push that quirky insanity further as it goes on. Introducing such wonders as a Vampire T-Rex and Zomb-bees whilst still trying to maintain some measure of logic and not entirely unhinge into sheer randomness. Ideally having the characters question the sanity of the increasingly surreal nature of their opponents in their journals as they go on.
Admittedly, I might also be somewhat motivated by me thinking a vampire T-Rex is the most awesomely ridiculous thing ever, though that might just be the fault of my growing isolation-fueled insanity. Anyway I hope you’ve enjoyed this little delve into my thoughts, we’ve finally finished with some of the more tedious development tasks so the next progress update should be far more interesting.