Way, way back when I was making the original game I had my buddy, Lance, build the soundtrack. That sound file takes up between 1.5-2mb because it’s a bit long and high quality. In the course of testing, a couple people mentioned it would be nice if there were a different soundtrack on each chapter (every chapter is five levels). At the time that seemed outlandish given that would add at least 12-15mb more to the total game size.
Some full disclosure: I always turn off the music right away in any game. For the most part, they don’t interest me and don’t seem to add to the game as much as they subtract. But in this, I know I’m the minority. Music has very strong associations with experience and many people enjoy having it tailored into the ride.
After some considerable thought and a few more conversations with Lance, I decided to go ahead and hire him to do a different soundtrack per chapter. To my delight, these songs have been incredible. Per my point from above, I rarely enjoy video game music, yet I find myself enjoying it while testing over and over again. I’d call that a good sign.
Since the beta, I’ve been doing a number of things to further optimize the overall game in both memory and performance.
The game features bumpers between levels where chalk gets drawn on to boards for added tips and instruction. It’s meant to feel like a coach giving a play to his team. When I originally made them, they were six pngs per board with alpha channels layered one on top of the other. At only 20-40k each png, I figured it wouldn’t take up much space. But after some investigating, it turns out the iOS application doesn’t compress these as well so they each ended up being about 1.4mb!
Obviously the boards needed a complete overhaul which took several days because they were being recreated as smaller elements within Unity. Moreover, I took the opportunity to redo them all with some new filters in Illustrator and Photoshop which gave them a more consistent feel.
Performance-wise, I found a number of things I finally got around to that had been on my list for a while. There were some UI elements that were offscreen yet active which I now have completely inactive and undrawn when not in use. The world map also had a number of level indicators that I now separate into layers, turning on and off the relevant ones when needed.
Yesterday I delivered my first beta to my test group of around 30 people. The group was put together on Facebook through friends and friends of friends.
At first I was going to have a forum that I’d host here. But given everyone was coming through FB, I had the idea of just creating a secret group and doing all the footwork there to save time/energy. It’s proven surprisingly effective. Sure, it’s not the most ideal of outlets and I technically can’t control the data should it go down or blocked for whatever reason.
I’ve had a hosted Jira account since the summer and am now diligently putting all new feature and bug action items in it. Right now it’s sitting around 24, but I expect it to keep growing as the testing continues. My fellow developer friends have mixed feelings on Jira, but I’ve found it to be pretty useful on the overall for tracking tasks with development.
Overall, the beta is going very well. Lots of positive feedback on the polish of the game and its general feel. While there’ve been a few blocker bugs, they’ve all been very addressable — nothing as bad as a structural memory leak, for example.
The only bit of bad news is that I’ve found I need to do a lot of optimizing. Right now Xcode estimates the overall size of the app to be around 112mb in the app store. I’m going to need to do some optimizing to bring that down quite a bit. Obviously I want this as small as possible given it’s meant to be a very impulse buy-friendly game.