Marc Melvin’s Blog

The current version of Tetroid has hit somewhat of a brick wall in terms of ability to move forward, and the fact that everyone is making extremely clear in their comments to me is that it is lacking several key features that should’ve been there since the beginning. Since I had never planned on releasing it in the first place, I skipped over some of the seemingly fundamental design elements needed for a successful mobile game, the biggest of which would be the pause feature.

With that being said, I’ve decided to take an all or nothing approach and rewrite Tetroid from scratch, this time following the recommended practices provided by Google. Here are some of the features that I’ll be focusing on:

• There will be a pause feature in the next version, both manual and automatic.
• There will be plenty of room, performance wise, to add in sound effects and animations.
• Multiple styles of play (not just classic Tetris) that should keep the game interesting.
• Online high score system to make it competitive.

This game was my first Android game and my first mobile game, so I’ve learned a lot in the process. I’m going to take one last stab at going back and doing it right from scratch, then I’m going to move on to my next project which should be a much more original, and hopefully way more fun, mobile game.

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

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

• Complete facelift on gameplay screen.
• Movement calculation algorithm for all supported inputs have been improved.
• Sensitivity settings have been improved.
• Width/height of play area can be changed.
• Touch movement support added.
• Touch/drag up and down options for rotate/drop added.
• Level and lines indicator added.
• Game gets a tiny bit faster with each level increase.
• Next and swap preview added.
• Touching the swap area will exchange the next and swap pieces.

And probably a few things I’m forgetting. Here’s a few screenshots of Tetroid for those that haven’t seen it and are curious. Click for larger image:

As always, keep your eyes open for more updates!

 
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.