About the gameThe game is a piano song game, that you can play both in touch mode and with your own real piano.
The idea is to give a tap-tap/guitar hero like experience, while being on the more educational side (e.g. piano keys are real-life sized + there's a game mode with a musical staff that you can learn reading sheet music through) + instead of playing with a toy guitar, you can play with your own real instrument, so you're actually practicing.
Here's the game trailer, so you can get a hunch of what's the game like:
For more info, visit the game's homepage: www.joytunes.com/piano
The link to the game: http://itunes.apple.com/us/app/piano-dust-buster-song-game/id502356539?mt=8
- We chose to develop the game in pure objective-c and not some cross platform framework like Adobe AIR. Mainly for performance reasons (recognizing which real piano note was played in real time) and it also allowed us to give a native look-and-feel for menus etc.
- The chosen game engine was The Sparrow Framework. The main reason for choosing this framework is because JoyTunes's existing games were written in ActionScript and Sparrow is imitating the ActionScript SDK pretty well.
I also found it much easier to learn than the popular alternative - cocos2d.
- A major part of the game was developed in TDD (which I'm sure is not something you can say about many games in the app store).
Lessons LearnedSince this is both the first iOS app and the first game I developed officially, I learned A LOT and have a tons to share:
- A good second programmer can increase productivity in >x3 factor
I started to develop "Piano Dust Buster" as a sole programmer, and about 2-3 months later another rockstar game developer (@noamgat) joined JoyTunes and started to work with me on this project.
I was actually lucky enough to have known Noam previously, and we actually took a very thorough programming course together, so we also had a real good understanding of each other.
The increase in development pace was unbelievable.
In the first few weeks, we did pretty much only pair-programming. This was my way of mentoring him both on the existing codebase, and on Objective-C and development tools. The benefits of pair programming are well discussed here, and I can really relate. You would think that pairing with someone new to the technology and to the codebase would slow me down, but it really did the opposite - I found myself spending much less time on pondering what would be a good design here and what would be a good behavior there, which were taking a very large percentage of my time when working alone.
Needless to say that when Noam got the hang of things our velocity was improving constantly. We still consulted each other about tricky decisions and could get through them quickly, and of course dividing the more straightforward tasks between us helped us finishing them much faster.
- It's amazing to work on something that you have a real passion towards
My 2 greatest passions in life are software development and music.
I felt so amazing being both a part of the musical production team and the development team of this game. Also, I could solve problems like an algorithm to locate a note correctly on a musical staff, while applying advance TDD techniques such as Uncle Bob's Transformation Priority Premise - a classic combination of my 2 big passions.
A piece of advice: If you are developers and have an additional passion in life (like I do), when the opportunity arrives to work on something that relates to this passion, don't hesitate and take it.
I left a really fun job at IBM in order to join JoyTunes, working more hours for less money, and I don't regret it for a second, because of all the things I learned and the amazing fun I had combining my loves while developing this game.
- Prototyping is a powerful and important tool.
Requirements from a game are much fuzzier than developing a server-side application, especially the requirements from the UI layer.
You rarely have a good idea of what is the "correct" behavior, and how things should look and interact on screen.
Therefore, you have to just go ahead and write a lot of half-baked prototypes for different game modes and interactions, then give it to a bunch of people and see how they feel about it. You will quickly get a grasp of what's working and what's not.
- Start usability testing early
Due to the fact that you can know if your menus and your game levels are behaving "correctly" until the players interact with them, usability testing is a crucial phase before releasing.
For us, it was especially important to see how children of different age groups interact with the game, and how people with various piano experience level do.
I can say we found tons of issues in our usability tests, and I actually wish we started the tests in a much earlier phase, because we had to delay our release date in order to fix all the critical usability issues.
- Don't take every criticism and feedback too hardOnce again, it's hard to define what feels "right" when playing a game, especially when it comes to a game with a lot of visual art and background music.
You need to remember that different people have different opinions and different taste. The more usability you do, the more different opinions you are going to get. It's going to be impossible to please everybody, and it's going to be impossible for you to release the "perfect" game that has no usability issues at all.
Heck, I'm sure if I look at successful games like "Angry Birds" from a judgmental point of view, I'll easily come up with 2 pages of things they could have done better.
So just know your 80-20 rule, and know which feedback is critical and should be fixed immediately, and which feedback is what you are aware of and are willing to live with. You will never release otherwise.
- Analytics are super importantWhat's a better usability test than the data arriving from all the app store users of your game?
There are a lot of good analytics frameworks out there that can help you with this task. We used Flurry.
In order to get useful data though, you need to make sure you collect analytics about pretty much everything, and you need to design it carefully so you would be able to extract the essence of your problematic use patterns and what's causing them from the data.
Also, we often forget to test the analytics part of our code, since it's not something you usually look for testing in the QA phase. However, if you have a bug there when you release to the App Store (which we did), you would be stuck with the bug until your next update, which could be quite painful.
- Continuous Deployment is a pain in iOS development
Nothing would make me happier than the ability to add a tiny feature and simply deploy it to all our users and see its impact immediately.
Unfortunately, since releasing an update for your app includes a review process that takes approximately 1 week, continuous deployment is not an option. Also, an update has other hidden meanings like losing all you current version's ranking and reviews. This makes an update something you really need to plan carefully, which is problematic for many reasons (see any continuous deployment presentation/book).
A solution for this issue that is only partial: Use the TestFlight API to automatically build and deploy to your up-to 100 beta testers after each commit. At least you'll get some feedback. However, what's 100 beta testers compared to tens of thousands users in the app store?
Spread the word!That's it for now. As you can see, I had a blast working on this game, and we have tons of features and big plans for it in the future. I hope you enjoyed this post and I think I'll post some more thoughts of this kind in the future.
If you have an iPad, it would be really cool if you download the game and give it a nice review in the app store, and if you don't - it would be really cool if you would share this to someone who has :)