Zombie Pirate Robot Attack Windows, Mac, iOS game

Introduction

Playcorp is a new game development studio based in Melbourne Australia, founded by Chris Mosely a veteran behind a number of triple A titles. Pip Robbins is the lead engineer working with Executive Producer and Designer Chris Mosely to bring Zombie Pirate Robot Attack to life.

Unity 3D was chosen as our development platform for numerous reasons. Unity is an incredibly powerful engine and editor platform with top end integrated middleware such as PhysX, Mono, FMOD, Beast. On top of the power, Unity has designed the development process to be simple, streamline and amazingly flexible. It make game development fast and straight ward providing all the necessary tools to allow us to focus on creating the game rather than the tool. Unity has taken good game development features and combined them into a single product. Examples include component based scripting, editor scripting, drag and drop asset import, in editor life preview, debugging and profiling and many other powerful features.

Unity Experience - The good

Community and support

Unity has fantastic support behind it, the developers of unity are working hard with constant updates and unity is continually growing, during the development time ZPR Attack unity released 3 large updates 3.2, 3.3, 3.4 each bringing a lot of new features and improvements, each making a noticeable difference. Updating unity is painless and fast, never once did we encounter any issues with our development build, everything just worked.

The real gem behind Unity is the community, its large, eager and helpful. The community is a big part of Unity, continually working together and supporting unity, making it better and better. Having worked with a lot of other engines, none of them have ever come close to the having the community support that comes with Unity. The community is there supporting each other, if you need any third party add-ons, help to resolve issues or general motivation then its all readily available for you.

Add-Ons

Add-ons are third-party solutions built for unity; due to the large community behind Unity there are plenty of developers focusing on creating tools and features built purely for Unity. These tools allow the users to focus on game development rather then tool development and can help speed up development. There is add-on for everything and thats another large part of what makes Unity amazing. It saves in production cost and uncountable development hours, its just all done for us.

During the development of ZPR attack we mostly used two add-ons. EzGui and Sprite Manager 2, these add-ons by AnB Soft were of great help and saved us a lot of time. The add-ons helped fix Unity's lacking 2D support. It enabled us to quickly atlas sprites and 2D GUI textures, it did all the work, just by providing a list of 2D textures it can compact them into atlas and find most optimal spacing and position allowing altasing with out constant size cells. Both add-on also allow for easy sprite animations and greatly reduce total draw calls.

Other useful add-ons are iTween, Prime31 assortment of add-ons. These add-ons are constantly improved by their developers and like unity the support is great, help is always quickly given.

Unity provides a reasonably complete package; anything not included can easily be filled with add-ons.

Rapid iterations

ZPR attack greatly benefited from fast iterations; due to Unity's streamline approach iterations could be done quickly. ZPR Attack went through a lot of design and feature changes during the development process. Unity made it easy to quickly throw things in and throw things out, this enabled us to constantly develop, test, review and iterate. This method helped us play test the game from early stages, constantly reviewing parts of the game, improving them each time or removing things that did not work out. It enabled us to prototype a lot of different feature and work out what best worked for ZPR Attack. Component scripting enabled us to drop scripts on and off objects easily, we could make multiple solutions for testing, drop the one we wanted to test on, if it didn't work we could just drag it off again or replace it with one of the other scripts. Unity's streamlined approach to asset import is also another great time saving feature, any asset could just be drag and dropped into the scene ready to go, modification of assets could be done both in the editor or in the original modelling package, updating the old version without any hassles. Removing assets was just as easy as selecting the asset and deleting it.

Multiple platform support

Unity is able to build on PC, Mac, iOS, Android, Web and consoles. As ZPR attack was primary focused for development on iPad, Unity provided easy building and publishing to iOS devices. This was a painless process and enabled us to easily distribute and test on iOS. Testing on iOS could be done using the unity remote to stream from editor to iPad, although in ZPR attack we did most of the testing in the editor via live preview and later double checked by simply creating a iPad build. It’s fast and easy. One of the things that impressed me the most was how easy it was to change from an iPad build to a PC and Mac, it was quick and simple and rarely did we have any issues. During development this really helped as it meant we could build Mac or Windows builds and provide them to the people who needed a copy but did not own a iPad. This enabled our contract sound development studio, artist, QA testers and reviewers to play the game, get a good feel of the game and provide better results and to see their work implemented. I know for sure that if we were not able to provide the windows build to our sound guys, the quality of sound effects would not be at the high standard we were able to get them too.

Editor

The editor has built in profiling, debugging and live preview, all features that make life so much easier. As ZPR attack was designed with a lot of units on screen at once, built in profiling really helped to check out how the game was performing, how many tris were on screen, how much draw calls, what was taking up all the memory, which scripts were hammering the CPU etc. All the information was there provided, ready to help optimise the game and close the leaks. Live preview is the ability to play and test the game in the editor, which is awesome! This enabled us to check scripts, variables, objects all in real time, allowing for easy and fast testing and debugging.

Unity Experience - The Bad

Build Size

While this is only an issue on iOS, it effected ZPR Attack. Our initial aim was to get ZPR Attack’s total build size to under 20mb so the game could be downloaded off Apple App store using a mobile broadband connection. Unfortunately even using the unity pro version a basic template is 8mb, leaving little room for development. We soon out grew the 20mb limit as ZPR attack included an enormous amount of content.

Infinite Loops

Infinite loops could cause quite some pain, they can some times creep in without being obvious, and unfortunately Unity does not handle them very well. An infinite loop will cause the editor hang and requiring a force quit. This makes it quite difficult debug the issues and resolve the problem. The crash reports some times provided a trail but just as often it left you blind.

Tags

This is a might be a little bit of a nit pick but I personally disliked the fact that tags on objects are restricted to one per object, it also limits the usefulness of the tag system severely. Tags would be far more useful if you could apply multiple tags to each object.

Memory

ZPR Attack ended up having a few memory issues, which were caused by Unity loading everything to memory on loading of the scene. Whilst this is normal, it can also load some not so obvious extras into memory. For instance in ZPR attack we had all the data for each level stored in to prefabs, each level was a prefab which linked to other prefabs containing other data such as enemy wave patterns and prefabs of which enemies and tiles were spawned. Now all the level were attached to a level manager object in the game scene, the issue was that unity would load all the prefabs for each level into memory all at once causing it to crash on the iOS device, rather then just the prefab required. Now this isn't such a big issue or even unity's fault, it was most our fault and our implementation. This can easily be resolved by changing the implementation such as load them in manually in real time through the resouce.load(). The issue was that it was a little unexpected at the time and not so obvious.

Physics, Lighting and Animations

We found that physics, animation and lighting was a bit fiddly and difficult to get the right results and some times felt a little limited. Whilst unity does have a powerful system for physics, lighting and animation I encountered some issues, which I had trouble resolving and we weren’t able to get the desired results. In terms of physics in ZPR attack when the bonus units were destroyed they would spill out some goodies, although we were unable to get them too spill out nicely, we would have them given a force in a random upwards direction but some times they would just drop altogether and other times they would go flying off the screen. We ended up getting it working alright but never perfectly. Lighting caused a lot of slow down on our original 3D tiles, so we ended up having to recreate the 3D tiles in 2D, we had a lot of issues trying to bake some nice lights on to our units and in general the lighting never was really brought up to making the game look a fantastic as it could be. Animations caused a lot of hassles as well, trying to get them to fire scripts events off at intervals during the animation wasn't as straightforward as it should be. Using the animation event system in the editor would work to a certain extent but all the animations on the objects would have to be duplicated as the original assets were locked, there was also no reliable way to get it to trigger via script, you were able to normalise the current animations progression but if you wanted to get it to trigger something at a certain point during that animation it would often just skip over the point, requiring you to make it a range instead, even still not very reliable and it seemed harder then it should have been.

GUI

Unity's GUI system is known to be slow and not a good solution for iOS devices, in some cases killing the frame rate completely. We used EzGUI add-on as our solution and created a GUI system in 3D space. It would be nice for unity to improve its built in GUI system and optimise it for iOS.

CONCLUSION

Unity was the right choice for us, it is a powerful engine, which has been well thought out and allows us to work on creating games rather then tools. ZPR was built mostly with one unity developer, so we are unable to provide feedback on how well unity can handle a large development team, although unity does offer its own asset server client solution. We have used many other engines such as Torque, UDK and custom built, none of these I believe offer the speed, flexibility or community support that unity offers. Unity does have a few issues but overall the good far out weighs the bad. Unity is really a work of art.

Developer Details:
Playcorp Inc.
Zombie Pirate Robot Attack
www.zprattack.com

Release date: September 2010
Platform: iPad, Windows, Mac OS X
Development time: 9 months
Number of full-time developers: 1 programmer, 1 designer
Number of contractors: 3
Technology: Unity, Xcode, Photoshop CS5, 3ds Max, EzyGUI. Sprite Manager 2

Grab the game now on iPad or PC and soon to be released on Mac!
iPad: Itunes.apple.com
Windows: Indiedb.com