“…Atom Zombie Smasher is painless… it brings on many changes…”
Here at Embalmit we do many things, one of those things (and the least requested of them) is to review games that we think are relatively meaningful to what we are doing. One of those meaningful games is Atom Zombie Smasher. A fantastic take on three of the past decade’s fads (now probably dying fads): Zombies, Casual Games and Indie flare. And boy does AZM (for shorts) goes to town with all of these.
A few weeks ago Adam did the unthinkable, he released a new build of the game!, and boy it was awesome. Currently we are still in Alpha state, but that shouldn’t stop us from posting a few screenshots of our work in progress.
The screenshot above shows the game closer to our intended release version: It displays a working version of our trusty GUI, most of the buildings we’ll end up using (we are still missing a lot of buildings though) and features 18 out of the 23 planned units we have for the game. We still need to work a lot of the 3d assets, so it’s placeholder country for almost everything 3d.
It’s that time when newer sprites show their face around Cairn. Previously we went through the exciting Free Blades and the awesome Thermocrats. Now it’s time for sprites that have no human form: these are the Fey and the mechanical Spiders.
Coming up, in Embalmit.com, your source for that sweet sweet, badass retro RTS: Cairn!
I know we have been a little quiet since we’re working on the new beta release! It’s going to be fuckin’ badass, I promise. Until then, we are going to tide you over with some inside looks into the development of Cairn. The first area we’re starting with is the GUI. Over the next several days I’ll be writing about the change of our GUI from the bare bones version, to the super slick version we have now.
We are going to be starting the sprites for a race known as the Arcole soon. They will have units in all playable factions, but we wanted a unique body shape for this race to set them apart from the human, slek, and mechanical units. So Danny Samuels is helping us with some fresh new concepts.
And so, in just a few tired more weeks, Cairn will be on Beta status. Adam is actively coding up a storm. Death animations and the final sprites pack are in the works and the GUI is in the process of being coded in (although the final version might differ from what you see).
They are here. The heroic, technologically advanced and oppressive Thermocrats are now part of the game. It took a few good months to get all the animations in place, but this time we bested ourselves and came up with 7 new units for the game.
Cairn uses hand drawn sprites, which are painstakingly made by one person. The process takes around 3 weeks with a work process that was developed by us here at Embalmit. Here’s a bit of an insight of how this process usually goes for any given sprite we make for the game.
I talked previously how much a game object manager improved performance in Cairn, and I want to make sure anyone using Unity has the opportunity to use it in their game as well.
When I started researching a work around for Unitys Spawn & Destroy methods I came across a large number of pre-existing solutions. There are free scripts and expensive packages that could handle the issue, but I wanted the best of both. Something easy to use, something I can understand, and something free. This ment we had to grow our own solution, but I didn’t have to start from scratch.
Since the rest of Cairn is in C# I converted the script to that language. This allowed me to walk through the script and get a better handle on what it was doing.
Overall it’s pretty simple. Build a stack of Game Objects, mark them as active or inactive, then when something requests a new object determine if one needs to be created or if one needs to be reused.
I changed it handle more like the built Spawn & Destroy functions within Unity. The new script takes in a prefab, using it’s name to create a Game Object Pool for that specific prefab, and handles the stack of objects as the original script did from there.
You’ll notice some string manipulation and comparison that could be improved or edited, but for what I was trying to accomplish it works like a charm.
Cairn has grown. The game now includes over 20 types of units, a huge variety of attack types with fully working combat mechanics, almost 9 different Landmarks can be built, destroyed, and taken over, and dozens of doodads that have to be navigated around or destroyed for resources. All of these pieces coming together in the most recent builds has created some unique problems, mostly with the management of memory.
All of these different pieces create other objects within the game. Landmarks create projectiles that are thrown at enemies, Units create blood splatters as they take damage, and doodads break apart as they are destroyed. Everything in the game has it’s time to be removed from the game, a blood splatter is only there for a second, as it fades away after the initial hit. This spawning and destroying of game objects was really starting to hurt performance. Lets look at some figures & performance charts to better explain the problem.