Marc Melvin’s Blog

Tetroid v1.0.4 for Android is released to the marketplace.

 
I’m a strong believer in agile development. No matter how big or small the project, from my experiences, agile methodology always yields the best results. Release early and release often should be every developer’s mantra, and user feedback should be the device that drives future development and modifications. In a perfect world, this should always result in a solid product that matches user expectations while reducing the development time involved.

I’ve been asked by several people in the Android community, “What in the hell were you thinking releasing Tetroid the same night you started it, and especially when you knew that you would get negative feedback on the flawed controls and missing features? Aren’t you worried about all of the negative feedback that will follow the game all the way through to the point when it is polished and perfect?” My answer to this is no. I have nothing to lose from it, and the end-user will win in the end because of it.

First, let’s examine the alternative. Let’s assume for a moment that I had started working on Tetroid over a year ago when the Android SDK was first announced by Google. A year is a lot of time to develop a product, test a product, provide a featureful application, and remove any inherent flaws in the process. After a year of waiting, the first release of the game would probably be very polished and very clean; however, no matter how hard you try, you can’t make everyone happy. There is no software product in the world that is without a negative review by someone somewhere. There would still be negative feedback regardless of how “perfect” it seemed at time of release because everyone’s view of “perfect” is quite different. Unfortunately, after a year of development, most of the processes have been decided upon and are tightly coupled in the application to the point of not being able to be changed easily. To change a piece of an application that is so deeply embedded in the logic at this point is extremely difficult and takes a lot of time, therefore creating much longer release cycles. Something that would seem so simple to change could take weeks, and might not be able to be changed at all without producing a seemingly different application in the end.

Now, let’s examine the agile methodology of “release early and release often.” By immediately releasing the semi-working Tetroid that was designed, developed, and tested in a period of 8 hours, I was able to receive immediate feedback from the user base. Of course the feedback was 99% negative (and actually surprisingly more constructive than I was expecting!), but unhappy customers are the best source for great product feedback, and man did I receive plenty! The following day, I released a second update that attacked the issue that I felt was mentioned by at least 75% of all negative feedback I received: trackball support. Believe it or not, I never had any intention of supporting the trackball (after owning a Blackberry for several years, I am fairly ANTI-trackball). If I had waited years, months, or even a week to release Tetroid to the public, it still would not have had this feature and I might not have put myself in a position where I could add trackball support in a single day like I did. This easily could’ve required weeks to refactor the logic to support trackball input, and the user base’s faith in the product would’ve been completely destroyed by that time.

There are plenty of advantages/disadvantages to using agile and not using agile, but I believe that it has really made a big difference here. Tetroid went from being unplayable to playable in a single day, and it may be only another day or two before the negative feedback relating to ”fun factor” is resolved.

As for the negative feedback following the product through each update, I am counting on the users to change their comments and ratings as time goes on and Tetroid improves. My logic for this is that if they had time to bash it initially, they will probably put in the time to praise it for its improvements. If they don’t, then oh well. The only thing that matters is that the product is improving and the people that are willing to ride the updates and provide constructive feedback along the way are the ones who will win in the end.
 

I have been disappointed lately at the quality of games on the Android platform. Specifically, I haven’t seen too many “classics” in the mix, simple games like Tetris, Chess, Checkers, etc. I’ve been meaning to jump into the Android SDK and start messing with it, but last night was the final straw for me. I had to make a playable game for my phone, see the capabilities of the device for myself, and if something good came out of it that I could release to the world, I would jump on the opportunity.

With that being said, I built and released my first Android game last night, from scratch, into the marketplace. It is a Tetris clone that I called Tetroid, complete with a cute little Tetris Android guy for an icon. In about 7 hours, I had to reacquaint myself with Java, learn as much as I could about the Android SDK, and build a playable Tetris clone (including beating my head against the wall to come up with what turned out to be an EXTREMELY simple algorithm for rotating any shaped piece on the fly). Tetris is something I’ve always laughed at other developers for building because of its sheer logical simplicity. Well, I am happy to report that it has started out to be a fun and challenging project, one that I plan to continue working on dilligently over the next few weeks when time permits.

Almost immediately, I have seen the power of the Android marketplace to reach the community. My inbox has been flooded by people praising me for finally building a Tetris clone for Android as well as flaming me for the lack of features. In addition, I’ve received offers to help, lots of positive feedback (which I used to create the nice little to-do list that you see below), and possibly made a few friends in the process. Not only that, but the comments in the marketplace itself have been both enlightening and positive as well as downright rude and ignorant. But I have a feeling that all of this will make me into a better developer in the end.

So, with that being said, here’s my list of to-dos for the upcoming releases of Tetroid:

1. Add trackball support.
2. Add motion gesture support.
3. Add options menu to enable/disable all these options as well as adjusting sensitivity.
4. Make blocks smaller, increase height of playing area, maybe make all of this adjustable if I can.
5. Make game get faster/harder as it progresses.
6. Create a top score service to track scores of everyone around the world.
7. Add optional “special” pieces to add a bit of a twist to the game (like bombs, for instance).
8. Add optional sounds/music support (maybe).
9. Add special effects to the blocks for better visual feel.

It is a pretty hefty list, but I’m already well on my way to completing a few of these right now. For anyone aspiring to create Android games, I must urge you to do so no matter what excuse may be stopping you! It has been an unbelievably positive experience, and I’m not even 24 hours into it yet!

If you have played Tetroid, please leave me a comment or two below and let me know what you think! I will be using my blog to report updates on the game’s status as it progresses, so please subscribe to my feed on the right to stay updated!