I am on a bit of a U10 kick recently after doing a U10 game for my presentation at Flash Forward. Craig Babcock wrote a comment on my previous entry and as I started to rant I thought it would be better to respond as a post rather than a comment. The U10 breaks every notion of key events that I have had and manages to be internally inconsistent with itself.
In Flash 4 player world, you don’t have Key.isDown to poll a key position to do smooth interactions. Instead you rely heavily on the accessibility feature of key repetition. You hold down a key and it fires once, pauses, and then fires repeatedly and rapidly. It doesn’t make for the best experience, but with some ingenuity, you can make pretty fluid movement.
On the U1o, when you add your SWF to the device, you quickly find that the key never fires. Since we are using an accessibility feature, I wasn’t all that pissed that key repeat didn’t work for a device like this, even though I was disappointed since this narrows the types of games I can make. What did frustrate me though is that the key repeat does happen on the device UI. In menus, holding down the side of the player (the key) will continuously scroll (and even accelerate and optimize the display) until you let go. In media player and radio settings, there is functionality that relies on your holding down the button for a longer period of time.
Clearly something strange is going on. I have a few guesses of what could be going on (I have no evidence to support any of these ideas):
- FScommand2 - Perhaps there is a custom fscommand2 that can poll the key like
Key.isDown. This would be essentially impossible to detect as long as it is only implemented in the protected UI. - Different Player - The Flash games are running in a separate instance of the Flash player from the UI. You can tell this because you can set the frame rate of your game without it being slaved to a master SWF frame rate. You can also use background color and the
_targetfor your file’s main timeline is just/. You can also tell that the UI player is not destroyed since randomized backgrounds still show their original pattern for a moment before being re-loaded. Since they are separate player instances, it has gotten me wondering if they are separate player versions. The player isn’t huge for a storage device like an MP3 Player. If I wanted to add functionality like the ability to launch the video or other broader actions and didn’t want this functionality exposed to the developer API, having a custom player for the trusted content would certainly be a route I would want to explore. None of the device identification elements seem specific enough to provide useful information on this theory. - on() event shenanigans - I have the most negative evidence for this one. I thought that they might have mapped another key on the keyboard for for the purpose of a keyUp action so I created a button that maps every key that I could think of that was mappable in Flash 4. None returned anything unexpected. The only other things I can think of is a custom event like a keyUp (though that precise name didn’t seem to work) or there is a key that I am not thinking of to listen for.
Since I am pretty well thwarted I only have one possible test left. Some of my experiments with the UI have ended up screwing up the buttons. If I can find where they sit and unload the parent of the buttons, any buttons I add in my custom SWFs should start firing.
IMPORTANT NOTE: If you decide to give this a try, put your actions in something like a thumbnail file, NOT the background. If you screw up your UI in a thumbnail, you can restart the device and go back to the main menu. If you screw up your background, you could make it very challenging to get the device able to sync to your computer to overwrite the bad SWF. Since the device uses Flash buttons to give permission to the Power & Data selector, you need this to remain functional. Luckily, the power button seems to be a device control, not a Flash UI control, so you shouldn’t be able to break that.
Recent Comments