Just FYI - pictures work in Firefox, but in IE7, an access denied message occurs.
Interesting application, and thanks for the write-up! On May 15, 11:07 am, Rui Martins <[EMAIL PROTECTED]> wrote: > 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.pnghttp://ruimartins.net/dump/unwind/Unwind-1.pnghttp://ruimartins.net/dump/unwind/Unwind-2.pnghttp://ruimartins.net/dump/unwind/Unwind-3.pnghttp://ruimartins.net/dump/unwind/Unwind-4.pnghttp://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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
