Anyone that once tried to develop a game or program of a certain size by his own knows that eventually you reach a moment where all the careful planning you've done previously goes to hell because you discover that there is something else you feel in your guts is mandatory to do ( a feature quite always ) and you didn't planned a word about it.
Quite often, beside with this "unplanned-but-incredibly-awesome" feature comes the "damn-this-implies-to-change-alot" crisis. Well, this is more or less what happened to us when suddenly, one day, after showing/demoing our mobile-device game to a couple of good friends one of them said:
- "Jesus! this game is really good! You should publish this on PC too!!. By the way... Do you have PAD support?" -
Suddenly a bomb exploded inside my head...
Even if it may sound strange we never thought about, but it really sounded like a good idea. So our first estimation was simple: "supporting the PAD as a game controller? Sure, no problem... give us a couple of hours and consider it done."
But suddenly the nightmare was unleashed: "How do you plan to navigate the GUI menues with the PAD...?" well, not a big deal a thought... "How do you plan to navigate the integrated editor with the PAD...?" and there I started to hear an "ups!" inside my head.
This kind of things can be really a pain in the ass, more than for its difficulty because they were not planned since the begining (de per se). Anyway, after a lot of struggling and trying different methods we reached the "always-welcome" solution this is: the "simple-but-effective" solution (not perfect, but effective :P )
In order to achieve success we need to fulfill one single requirements:
All the interactive GUI elements should inheritate from the same class. Quite often this is true, and luckily for us, we have on 3 different interactive elements:
- Holdable buttons
Therefore the idea was, as soon as we build a GUI screen we select one of the "interactible GUI elements" as the origin. Then, depending on the direction selected using the PAD we navigate to the closest GUI element on that direction.
So far, so good... but we found some situations where this solution was creating some artifacts. Two elements that are closer than a third one when you would like to navigate "logically" to that third object... It may be difficult to explain but easy to see. Take a look to the following image:
Imagine that we have this button arrangement, and you want to navigate from the button A to the button C...
Naturally you'll be moving to the "right" direction with your PAD. However this (following the previous rule) will be navigating the scope from the A button to the B button... due the B button is "closer" to the A button than the C. So here comes the trick/exception: if there is another button in that direction that is perhaps not so close BUT is aligned to the original (focused) button, we choose that one.
It may look simple, clumsy, sill or stupid... doesn't matter...
It works like a charm! :D