So I made a small list of failures during my game development journey. I probably couldn’t solve any of these problems on my own, I’ve found solution to almost every problem by reading android developer website, stackoverflow, wikipedia or blogs written by android developers. Part of this reason this blog is a bit like collection of great links that have helped me to fix my failures. Right now I have fever so I apologize if my post gets too delirious.
1. Not Planning Enough
Okay I didn’t went just to write code, and noticed that I had written useless dead end code, when I started my project. I took pen and paper which is probably the best way to start planning any programming project. I drew umlish mind map which described how the turn-based engine worked, but I left Android activities out from it. I didn’t revise my plans when making radical change either. So after I while I was wasting time pondering what to do next and do I have to change something from current code if I do it.
Since software architecture planning is quite vast subject (and since I am such a lazy person) I think just explain my point with links. Here is somewhat simple introduction to UML: http://www.ibm.com/developerworks/rational/library/769.html. UML is a great way to visualize classes and their methods just as longs one doesn’t overdo it.
Here is a Android app concept design that I found great example for android app with lots of activities: http://faucgutier8.wordpress.com/2012/08/13/animator-creator-app-design/ . It looks a bit complicated first but it’s so comprehensive it’s way easier to start writing code. Plans are perfect if the time after planning is spent in programming and other practical stuff like making graphics, not wondering what to do next. Of course perfect plans are really rare in software architecture so better be prepared for errors in planning, but the errors are not reason leave proper planning out (okay I admit that was a bit vague way to put it).
2. Using Android emulator
After my Android phone broke, I thought my only option was Android emulator that came with the SDK. And boy do I hate that emulator. I mean I really really hate it! In Finland we have this idiom that fits here perfectly, “Android emulaattorin käyttö on yhtä tervan juontia”, wich means, “Using Android Emulator is like drinking tar”. I was actually interested in android development before I had my Android cellphone but the emulator in Eclipse scared me away.
In Android development blog there was a post how the emulator is now faster (http://android-developers.blogspot.fi/2012/04/faster-emulator-with-better-hardware.html). Well I don’t see any difference, it’s still like a pint of tar. Okay part of it might be because I have a really old computer and I’m not emulating Android 4.0. But there is another faster way to test Android programs without Android phone. Android-x86 is an Android OS made for personal computers and VirtualBox is software for virtualizing operating systems. Virtualization with these is way faster than emulator. But there is no reason for me to explain how to set them up since there is well detailed blog on how to set up VirtualBox and Android-x86 for testing Android apps on Eclipse (http://blog.gokifu.com/2011/05/android-x86-faster-emulator/).
3. Not Using Revision Control
Well I didn’t have any catastrophic, “I replaced big part of the working code with useless code”-moment, but I had many, “It would be so much easier to go back”-moments when the Ctrl+Z just isn’t enough. I did very brief research on revision control softwares and solutions. I chose Git on emotional grounds (if manual says it’s, “the stupid content tracker”, it’s have to be good). So I’m using it in eclipse with EGit (http://wiki.eclipse.org/EGit/User_Guide) which I’m still learning. There is also entire online book about Git for free (http://git-scm.com/book). Here article about revision control that I found through Wikipedia: http://betterexplained.com/articles/a-visual-guide-to-version-control/.