Your linked images do not work....
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
-~----------~----~----~----~------~----~------~--~---
