Thoughts on TA!CZI

I wrote a bit of a nice little programmer specific commentary about TA!CZI that I wanted to share on our dev blog – because I can. So without further ado:

Tower Assault! Curse of Zombie Island is a top-down RTS set in reverse tower defense fashion where the player controls a zombie horde to do their bidding via firing brains from a cannon. The brains then act as attractors for the zombie horde, who moves towards them to eat them up. The player can also fire brains at towers and other scenery to make the zombie horde attack that location. It again used geWiz:ES (Bruno architecture) with a freshly revamped architecture (fixing many of the major issues we had the first time around), the iPhone SDK, and came in around 120k LOC (160k with the XML data files) over the course of 8 months of work (with another 4 months for design). It featured a lot of work using sprite sheets, artificial intelligence driven entities, a quad-tree spatial partitioning based collision system, and more.

After iRis AG, the design of TA!CZI started more along the lines of a traditional tower defense game, but involving zombies. We also had another idea we ripped off a certain 80s movie that involved using a gelatinous cube to eat medieval villagers (as long the kids keep popping in quarters – ring any bells?). Our design process we revamped was now largely aimed at early bad idea rejection with proper risk analysis and product analysis (so we didn’t waste a lot of time building a design up for something that wasn’t going to work out or blow up in our faces – changes of which would have probably made us cancel iRis AG), so we spent much more time in design, and that really payed off. We actually wound up combining the two ideas and came to the idea of the reverse tower defense game (as in, attacking towers with the horde, instead of defending against a horde with towers). After a lot of hard design work, including a few focus group conversations, a few prototypes to test uncertain mechanics, and a lot of conceptual artwork, we started production and knew we had something good.

Some of the more complex technology that went into the production was set up purposely in a “testing-the-water” sort of way in hopes we could build something simple enough in the meantime that would work for the game now but then later be revamped and added into the main geWiz:ES core architecture but with an improved design (which worked out great in the end). Before production started, we also knew we needed a few more key engine components added in regardless, especially with the sprited billboards that we planned on using for the main entities. We developed a sprite sheet exporter for Blender as well as a sprited billboard and sprited image component, and even got to do some vertex key framed mesh animations. The object tree system of the engine again proved invaluable in making the towers animate (fall down), and our artist did an amazing job building and animating the 3D towers even using a Blender physics tool to set up the appropriate interpolation curves, as well as rigging and animating the characters to form the sprite sheets. We also did all our imagery work at twice the size we needed so we could utilize the higher resolution screens on the iPad and iPhone4 (releasing a separate iPad HD version). The XML parser was expanded during the course of this, as well as adding in a few test components, such as a particle system. We used more of the GLES extensions and cached IMP routine pointers (to avoid the costly true dynamic method invocation feature of ObjC), which helped performance.

Overall TA!CZI sales were much more stronger than iRis AG, and we got a fair amount of publicity for what we accomplished. We were actually very satisfied with the end result, which took a LOT of effort amongst several team members. We didn’t come without issues though. For instance, the level editor wasn’t built until later in the project (which we later added into the public release as an easter egg). The game mechanics had to be tweaked constantly to get everything right. We even made the AI/FSM just a bit “too good” and eventually had to dumb-it-down in order for the player to actually feel in control of their zombie horde. We underestimated the repetitious gameplay situation, even though in design we tried to fix that with the additions of different level types (invade the village, capture the treasure, etc.). We also had some speed issues right after release due to the newer SDK released at the same time wound up having too many background processes open that messed with the game, but that was quickly fixed by doing more heavy optimization work. We did however do a lot of things right, and the biggest one was making something that was, in the end, actually fun and contained an interesting story line. It was really cool to see various nephews and neices playing it and having fun with it over the Christmas season. Given the complexity of it, though, not sure we’ll be topping it with any future work anytime soon – the game was just a bit too complex and time consuming to build.