Hi guys and gals, here is the aftermath about the project I have submitted to ADC.
In a very short description, "Unwind" is a mind puzzle game, conceived to nurish your brain cells for their daily challenge dosage. "Unwind" is a game like no other you have seen, and I assure you, that if you have a thriving mind, you will get hooked in 40 seconds ! :) But lets go into some background first. I'm a long standing fan of computer games, having learned to program on my own, when my parents gave me my first computer a Sinclair ZX Spectrum 48K ! After this first experiment into the world of computers, all my life got strongly biased to computers in general. I wouldn't call myself a geek, but more of a life hacker, in the true sense of the word, i.e. I'm a curious fellow, I like to learn how stuff works, specially from the inside out :) So later I got a colleage degree on computer engineering and I started to work in the IT field. But my passion was and still is games, not only computer games, but board games and others, basically, everything that challenges my brain cells in some way. :) I have a full time job, as a software engineer/developer, so my programing hobbies (games) are only done at night or sometimes on weekends, so it took me a while to decide to commit to the ADC, mostly because I was already doing some overtime at my work before December. I also knew, from experience that picking up a new API, would take some time to get confortable with it, and since it was an alpha version, many efforts would go into dead ends, when bugs, miss features, lack of documentation, or simply stuff that just doesn't work yet, or is not covered by the API. I finally decided to start Android development near the end of January, when my job overtime was mostly over, and I could plug in some more time for hobby programming, and I now had what I think is a great puzzle game concept. But this decision was made with a clear understanding that this endeavour would eat all my free time until the dead line (March 2). When I started messing with Android SDK, I had already started a prototype of "Unwind" in C++ and OpenGL, a very basic one, just to test the gameplay, and how well the idea actually worked. First idea was: Ok, I can reuse the prototype code I have, by porting the core C++ code to Java and OpenGL-ES, and build from there. Good idea and bad idea at the same time ! Good, because the core game algorithm was already there, which add some good collision code that I had already built and tested. Bad, because it made me go for OpenGL-ES, which proved to be a huge waste of time, which I could have avoided since the game is inheritly 2D, so I really didn't need OpenGL functionality. From good programming practices, I make a clear distinction in my code from core functionality and code to generate output or graphics. This saved me a few weeks later from a big headache when I decided to dump OpenGL-ES, although OpenGL already took away almost 3 weeks of work, with some blind trial&error too. And why did I dump OpenGL-ES? Basically, because it was really slow on the emulator, I also had some problems using textures, and finally because the constant conversion between float representation (which I needed) and Fixed Point Math was killing any chance of real usage of the game in the emulator. By the way, it doesn't make much sense to have an API wich requires Fixed Point values, and not have a basic Fixed Point operators API, namelly to have the basic operations ( add, subtract, multiply divide, etc) and some conversion methods to and from different types. This lack of Fixed Point API, forces everyone to build their own, which is a waste of time, due to all the testing that is required to make sure it's working properly. Hope Android Team will address this issue on the next SDK. After I was done with OpenGL-ES, things started to improve, and slowly some results were starting to show up, and the game was starting to look like a game. My next hurdle, was finding a suitable look&feel for the game. I decided that it should have a "futuristic" look, so I went with that, but now I had to actually define what is "futuristic", so that I could implement/design it ! This took me many hours, searching for inspiration on the web, checking some DVDs I had, and stuff like that, just to build an image in my mind of how the game should look like. After I nailed it down (escruciating process for an engineer :P ) I had to put my own skills for conceptual creation/drawing and basic image editing into it, to materialize my view. I'm happy with the final result, but I know how hard it was, which gives it some extra value in my eyes at least. :) Meanwhile, I was also concerned about music for it, so I request the help of a friend, which by the way is a qualified composer :) that I had worked with before, with great results (we won two awards in a previous context, "Best Game Concept" and "Best Music Score", with the game "Magnetic", that I created from scratch too). But here I fell into a pit again :( How in hell do I tell him what I want ? I really couldn't verbalize what was the kind of music I wanted, and of course I pitched him with the "Futuristic" adjective :) but that was clearly not enough. I realized that if it was hard to me to verbalized what I wanted, it would be even harder for him to score the music I wanted. So I started thinking, and after I while I convinced myself, that the only way that I could convey the music info, was through music in itself. Now, this was a huge endeavour, and took me a lot of time, because I went googling for music, or anything related that I could find, whatever I could get my hands on just to see if I could find something that could express what I wanted. After a while I was able to narrow down what I wanted and give it a name, apparently for the menu music, what I wanted was something that I could translate/relate with the word "suspense". I started to gather a few music scores, where I managed to pinpoint, specific features of each music, sometimes it was a specific instrument, sometimes a sound in the background, sometimes just a second or two of a specific music, that translated what I wanted in the game music. And believe me, the music "definition" was really the hardest part for me, but I'm pretty happy with the outcome, my composer friend "João Camacho"(http://SonicDaze.com/), did a hell of a great job, once again, thanks my friend, if you are reading this, wouldn't have done it without you. After this I though, from now on, this will be easy ! :) Dead wrong again :( I got into trouble, as soon as I started adding new activities to my app ! At first, it was due to some misunderstanding of the Intents and how they relate with the Activities, from my part, but then I also had problems with some limitations that the API poses, due to the threading architecture and messaging concept and how they relate to each other. There where a few days, that I could only launch Activities from the Android default menu, but If I launched them from inside a View it gave me weird errors and messages. I don't know if this happened to everyone, but the original documentation didn't help me much, it was only after some forum chats that I was able to pinpoint what I was doing wrong, and how the concept actually worked. I believe what made it obscure for me was some forced casts that where required, that didn't look right to me, it felt like a hack, so I didn't understand the concept from early on. I must also say, that Android community websites help a lot, in many ways, but in this specific case, I got trapped in by these weird errors, due to some Activity inicialization code that I took as example from one of those forums. Probably the other guy didn't understand the concept in it's entirety too, like it happened to me, and probably throwed a few guys of track for some time, like me. But this is bound to happen when we are all digging to get somewhere, sometimes almost like blind people, touching everything until we find the right exit. But for all the help, and info that I exchanged with others it was very worth it. The sense of community really shined! After this, I started to have problems while playing music! First odd thing was that it took a 2 to 3 seconds just for media player to start playing, and if we stopped it, it would never recover again, unless we restart the application. These two reasons togetther, is why I have a "Loading..." screen in my game, because I had to preload the musics, so that I could later use them, just by play/ pause, hence avoiding the initial music load hickup. I also found out, by pratical experimentation, that the music was limited to files less than 1MB, because the player was hacked to do the job in M3 SDK, so that it uncompressed the entire music file into memory. So they had to add a size limit to the file, in order not to blow up the Android OS memory usage. Of course, the correct solution would have been to correctly stream the music from the file, but ok, it's an alpha version, better work with limitations, then not work at all (but they could have warned us, in the docs!). During development, M5 SDK came out, and I was skeptic to change, because I was sure there would be new stuff, some working, some broken, and eventually some previously working stuff that would be now broken. And that was indeed the case. I ported from M3 to M5, one month or so after it was released, I had read all the problems that people had found out already, and I was confident, that now, I could probably port succesfully. No so unfortunatly. I had more problems with music play, and the worse of it was that now they were kind of random, there was no sure way to avoid them. this forced me to go back to M3. Since the start I had made a conscient option, of not using any of the widgets (buttons, etc...) that Android provided, because I knew, once again from experience, that they would change, and that the change could be drastic and would probably break any layout I would have setup. But since I was doing a game, it felt reasonable to go with a graphical interface of my own and not use the system default widgets. However this had two side effects, one initially expected, I had to make and test more code, and the other side effect, that I hadn't accounted for, was that it probably would make the game look that it was ported from some other platform, which it wasn't! But since the User Interface didn't use any of the Android widgets, it probably was penalized by being tagged as a Direct Port of some game from some other platform. I also did an effort to support Touch and keyboard through out the entire game experience, since touch was a really important part of it, and I managed to make it work in every screen and widget, except the one where you choose one of the already played levels, when you restart a gamming session. I just didn't had time to polish this part ! Only someone replaying a game session, would ever see this, so I though shouldn't bite me to hard ! :P In the last 2 weeks I also ran into some problems when I started to add some GUI animations. Once again, the animation framework, was not really what I was expecting, since I thought it was more generic, but it was really tightly integrated with Activities/Views. It took me some time, and some hacking, until I figured out that the Animation API would not fit my needs, so I had to roll my own once again, after I did that, independent animations where easy do quickly add to my Views. And in this case, I must say that the 2D API is really great, besides a few small bad corners, it works and the API is great. I also had a problem that I wasn't able to solve in time for the contest, and apparently there isn't a clear cut solution for it until today.I'm talking about frame rate or frame management. Basically there are two possible approaches currently, either post "REFRESH" messages at a specific time in the future, as a simple way to try to control Frame rate, or just simply invalidate your screen/ view after you have done everything in onDraw(...) The first doesn't work that great and has some side effects, namelly, posted messages seem to build up in the queue, whenever the emulator can't keep up with the required frame rate (20 to 25 frames per second) which is usually the case in my computer. The NASTY side effect is that touch events are delayed, due to this queue build up, making your GUI seem unresponsive, even if you force to clear the message queue on every onDraw, before setting the next post messsage to "REFRESH" in the future. The really weird stuff is that keyboard input doesn't suffer from the same problem. Keyboard events seem to be delivered, internally, via some other mechanism, because they don't get delayed. The second approach, will refresh at max system speed, which works great for emulator or contest, but in a real application will eat all your battery in no time. There is a lot more to be done to complete my vision of the game, including a tutorial, replay, network support (to be able to create and share new puzzles), and some other stuff I won't reveal yet :) Finally, I must say that if google hadn't postponed the deadline I wouldn't have made it so far, in terms of look&feel (music included), since I really didn't had enough time for doing it all, even though I worked nights, full weekends, holidays and even took some vacations to finish it to a reasonable state. The typical "One Man Project" problem ! Not enough Man power ! But I'm happy with the outcome. I was not in the first 50, and I don't know where I stood my ground, but I'm proud of being part of this event, this community, and of the work I did. Now lets see what the future will bring. Now about the game The GUI is fully animated, however "in game" screens try to only refresh when needed by triggering screen invalidation only on event delivery like touch or keyboard events. This was a conscious choice, which precludes much animation to be done "in game". But this is a puzzle game, so no need to over complicate things :) For the curious ones here are some screenshots: http://ruimartins.net/dump/unwind/Unwind-0.png http://ruimartins.net/dump/unwind/Unwind-1.png http://ruimartins.net/dump/unwind/Unwind-2.png http://ruimartins.net/dump/unwind/Unwind-3.png http://ruimartins.net/dump/unwind/Unwind-4.png http://ruimartins.net/dump/unwind/Unwind-5.png Now for the tricky question: Would this game "sell" to you in the magic 30 seconds pitch of experience with the game !? (I mean just by looking at the pictures, because animated I'm sure it would make a greater impression) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Challenge" group. To post to this group, send email to android-challenge@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-challenge?hl=en -~----------~----~----~----~------~----~------~--~---
