I just released my first game on the iOS and Google Play stores and I learned a lot of good stuff along the way. My game, Zone of Fire, was created using Unity3d and was my first major project with Unity3d. I did all of the game development myself.
I first tried Unity3d sometime around late summer of last year so a lot of the stuff I went through was completely new to me. I had been a software engineer for the past 22 years or so working on Mac/iPhone, C/C++, Objective-C and a little Java for Android. The switch to C# in Unity3d was pretty easy. C# seemed pretty strict (which is good for someone new to the language) and had a lot of documentation/support on the web.
When I first got Unity3d, I thought that I’d try to make a game that I like, a tower defense game. It really only took a couple of days to have cube units moving around a maze and cube towers shooting spheres at the units. At about day two I discovered the Unity3d Asset Store. I found TDTK (Tower Defense Toolkit by Song Tan) on the store and by about day four I had the basis for my game. With the rapid progress I was seeing in this game, I didn’t really bother to think about some things that could have saved me a lot of time later, although I probably wouldn’t have known enough to think about them in the first place.
Some things I should have thought about
|
% of my time |
Item |
| 5% | Basic tower defense game setup |
| 20% | Game performance optimization |
| 50% | Gameplay balancing |
| 20% | @#$!# Achievements |
| 5% | Everything else |
Dynamic Level Generation
As it is now, Zone of Fire’s levels are all manually handcrafted. Each level besides Level 1 has 20 waves of bad guys and each wave probably averages 3 different kinds of bad guys. I’d estimate that I spent about 50% of my total development time tweaking gameplay balance. Tweaking gameplay balance means adding or removing bad guys, changing their hit points, changing their spawn interval, changing the amount that come out, choosing what kinds of towers to use, adjusting tower attack rate, adjusting tower damage rate, and even determining if I’m overloading the system with too many bad guys.
A number of improvements could be made to this process do make things dynamic and smarter. It probably would have been worth the investment in time to write a heuristic to determine whether or not the bad guys could be defeated (and by how much) and it would have been an improvement upon that to dynamically spawn the heuristically determined bad guys. If that was too big of time hit, it would have been useful to write a “calculator” to determine bad guy/tower balancing outside of the game so that I could just calculate whether or not the level would be good.
Because I didn’t have any heuristics in the game, doing the tweaks took a really long time because I had to play-test the game to make sure it was ok each time I made a change. It probably took about 10 minutes to test each change and I made a LOT of changes.
Achievements
I could have spent a lot more time experimenting with Achievements before actually implementing them in my game. I’d usually get questions from friends like, “When is the game coming out?” And my usual response was, “Soon, but I’m trying to fix some issues with achievements.” I think Zone of Fire would have released a few months earlier except that I constantly had issues with achievements. Most of the problems were the fact that I didn’t really have experience using them.
When I first implemented achievements, I used Unity3d’s Social API. The API seemed pretty simple and I managed to get Android achievements working within a few days. I spent a lot of time debugging it because achievements just wouldn’t work for iOS. After a lot of online research, I came to the conclusion that Unity3d’s Social API doesn’t work for iOS.
I decided to buy a package from the Unity3d Asset Store that does Android and iOS functionality such as achievements. I bought the package based on the decent reviews that it got. I assumed it would be easy to integrate like all other Unity3d packages I’d used so far. I rewrote the achievement code to use the new API and its design. After testing, I was pleased to see that it did work (to the extent that I tested it then) for iOS, but then it wouldn’t work for Android! I decided that I would just release it for iOS first and fix the Android achievements later. After more extensive testing, I discovered that there were other issues with the iOS achievements and it probably took me another month to figure them out. I released the iOS version on April 15 and started working on the Android achievements.
It took a lot of testing but I managed to figure out what was wrong with the Android achievements. Here’s a tip: Make sure that your achievements are exactly how you want them when your product is shipped before you even test them internally because you cannot change them, EVER! I had to re-create my app information on the Google Play store because I overlooked the “Incremental” checkbox for a couple of my achievements and now they were forever non-incremental.
Performance
It’s easy to speculate and talk about why a game is so slow, but it’s hard to prevent that slowness unless you have the experience of having to debug a slow game. I bought the smallest capacity iPad Mini 1st gen just to use for testing. It turns out that iPad 2’s and iPad Mini 1st gen’s are the most popular iPad’s out there now. When I first started testing my game on the iPad Mini, I did notice that the FPS would drop from 30 to 20 or so on the first level. Of course the first level was an easy level that everyone should easily beat and doesn’t have that many bad guys. I didn’t actually create a second level to the game for a few months after I started.
At the point at which I was satisfied with the gameplay, I decided to create a second level with lots of bad guys and different towers. It was sad to see my game go from 30FPS (frames drawn per second) at the start of the game to about 2FPS by the 3rd wave of bad guys. Yeah you read that right, 2!!! For a couple of months all I did on the game was tweak things to make it faster. I found a lot of tips online that gained me 1FPS or so at a time. Eventually the game would only get to 5FPS when things started getting busy. Five FPS is unplayable and I really needed to figure out a drastic fix. Not only was the speed slow, but Zone of Fire was about 1.4GB in size!
When I couldn’t get any more improved performance (I was still pegged at 5FPS), I decided to try to figure out how to make the game smaller. It’s when I started to cut down the size of the game that performance really improved. As an inexperienced game developer, I didn’t realize that I needed to reduce the size of all of my graphics (some of which came in large formats from the Asset Store). As it was, my game probably looked crystal clear on a 4K TV! Once I figured that out, I was able to get the game to be a steady 30FPS and it’s less than 150MB.
Final thoughts
I think it’s important for the development time of the game to be short for an indie developer, probably no more than a couple months. Zone of Fire took way too long to develop. Game balancing needs to be smarter (heuristics) or the game has to be a lot simpler for an indie developer. Play-testing the game for game balancing took way too long (sometimes 10 minutes per game). Even if I knew what I was doing, if I were to do it again it would still take too long because of the complex levels.
|
|