“feelforit is my favorite iPhone project that I’ve made, and Transcend is my favorite iPad project that I’ve made. I’m even more excited for the upcoming release of Tumult…”
Why Port from iOS to Flash
iPad 2 came out recently. Just like when iPhone 4 came out, and iPhone 3G, and as has happened routinely with required software updates from Apple, it broke several of my iOS apps.
While I wait for someone else I know to buy an iPad 2 I can borrow, on which I can diagnose what stopped working then fix it, I wanted to make some of my iOS apps accessible to iPad 2 owners frustrated by their downloads not (yet) working.
Each time I repair these periodic breakages I pause and consider a few reasons to port:
- I have to fix these iOS apps several times a year to keep them functional after OS updates and new hardware releases – not just for new users on new devices, but occasionally for current users for whom things used to work fine. This pain gets amplified since I have so many apps on the store. I gave up on fixing ColdWorms and took it down. Some people liked it, but now no one can get it. We can still play old console and DOS games in an emulator, but once an iOS game is no longer updated to ensure compatibility with the latest OS version on all devices, it ceases to exist for the foreseeable future. Compare to: most Flash games from 2006 still run fine on any home computer, in browser, with no install process or trouble over emulator/control configuration, and have typically required no modification post-release to remain operational.
- Young people can only get to my iOS apps if their parents own smart phones and trust the kids with them, or their family is so well off the kids have access to their own mobile hardware. It is important to me that my projects are available to young people.
- Apps I make on iOS are only available to people that own a particular brand of expensive device, and by extension, can only be shared between people that own the same brand of compatible device. Many otherwise interested players can’t get to my iOS content because they happened to choose Pepsi over Coke, Levi’s over Guess… anything over Apple. Of course, a Flash game runs on virtually any home computer by any manufacturer with any operating system.
On the flip side, my iOS apps, the few that I don’t give away for free, have admittedly earned more money than all my Flash projects combined. (In Flash’s defense, I’ve also turned down sponsorship/branding for my Flash applications, since I think it would interfere with what I’m trying to do. This is the same reason I have avoided making my free iOS apps ad-supported.)
In fact, while we’re acknowledging the role of money in all this: Tumult, Transcend, and feelforit were created as part of my decision to shift away from making videogames/software as my primary source of income.
When porting, there are two objectives: (1.) faithfully recreate the original, preserving what’s important or central to the experience, but also (2) make minor polish updates, so long as doing so does not significantly hinder or alter the rest of the experience (i.e. what tweaks would be desirable in the next bugfix/update to the original platform). The second one would likely be frowned upon if being ported by a third party, but when porting our own work it’s not an issue since we can keep the original goals and direction in mind.
That first bit is where things become complicated – the purpose isn’t to exactly reproduce the visuals, audio, and controls (which in many porting cases may be impossible anyway due to hardware differences), but to reproduce as closely as possible the experience of playing the original. In the same way that word-for-word translations can botch textual ports by switching connotations, breaking rhythm, making familiar cultural references appear alien, and presenting idiomatic speech as literal, sometimes the work translated needs to be expressed differently in order to be received the same. To stick to that metaphor, a good translator is less concerned with what the actual words than with what they accomplish, and how, in terms of ideas.
And so, in a few cases for these ports, aspects have been introduced or changed in order to keep the result feeling more like the original, rather than striving to stay as close as possible to the original in terms of implementation.
(Note that these Flash ports were not made in the Adobe Flash CS animation tool, they were instead programmed in text files and compiled at command-line. My tutorials on how to do that are here: MXMLC Free Compiler Setup.)
Play the new Flash port
(based on Walden by Thoreau, looks like vector-drawn terminal)
My main reason for working on Transcend first was that it makes the most sense to be accessible to anyone. It’s based on works in public domain, Walden and Gord MacKenzie’s terrific LibriVox reading, and the source work seems slightly at odds with the type of luxury smartphones represent.
Transcend was mostly a straightforward port, however I did make a few changes:
I added a cliff on the second screen which used to not be there, and it’s serving three purposes: I like the visual it creates when standing atop at the edge, it demonstrates early on that there is a maximum jump height (foreshadowing the platforming challenges later), and it reinforces that this is a one way journey.
As a matter of usability, I added cyclical dots to the loading screen, since all the vocal mp3s add up to a larger-than-usual Flash application, and seeing an unchanging screen that long in Flash gives the impression of a crash.
Since SWF files have a way of finding their way all over the internet (one I posted a couple of years ago has been hosted on more than 400 websites – information I track with MochiBot), I needed to inject the game title and credit into it. The title matters because it sets the tone; on iOS players necessarily see the title when going to touch the icon, but I have no control over how this SWF will be framed or presented elsewhere on the web. My credit matters not for sake of vanity, but because if people like this project, knowing my name can help them find more things like it and about it (the same reasons it’s helpful to know a book’s author).
Lastly, I removed the wobble effect that occurs from dragging fingertips – on iOS that was a code carryover from my first iPad app Wobbly – since dragging seemed like an interaction significantly less likely to be assumed with mouse control vs touch, and it was mostly there to acknowledge drag input.
Play the new Flash port
(swirly laser light interactive particle notgame)
iOS version (original trailer):
When developing the iOS version, I was leaning heavily on OpenGL to produce the pretty effects. Part of my challenge in porting was finding ways to trick ActionScript 3 into drawing OpenGL-looking things.
There is an expectation of visual polish on iOS content which it’s easy to ignore when doing tiny apps that can be played online. Not only is there no money at stake for a little web application, but there’s no significant download time, no account password to enter, no app icon to arrange/categorize. The barrier to use is low, in the same way that the barrier to use for a shelf-racked PC or console game is comparatively higher than an App Store app. The higher the barrier to use, the higher the quality bar that has to be met for someone to feel they were justified by the time they put into set up or acquisition.
One of the other changes to the design that arose from going to iOS and back is that, whereas in the original Flash experiment the mouse position was tracked constantly, on iOS that wasn’t an option, since a finger is not necessarily always on the screen. Some of the best effects that arise from Tumult either occur from leaving the focal point still to let a pattern emerge – easier when input isn’t constant – and when the focal point switches abruptly from one coordinate to another, the latter of which occurs more easily through click control than rapid drags. To recreate that functionality, Tumult HD now only updates the focal point when the mouse button is held down, rather than tracking it constantly.
Multitouch, of course, could not be ported over.
Since the keyboard is available, and shaking a laptop is out of the question (that’s how the options menu is brought up in the iOS version, detected through accelerometer readings), I used number keys in place of the title screen’s toggle switches.
I was tempted to put something in Tumult HD to cross-promote between this app and Transcend, or to acknowledge that this app is also available on iOS, but decided ultimately that making marketing words show up in this otherwise minimalist application had the potential to change the overall tone of experience with it in an unfortunate way. As a compromise, I included my credit as the web domain which points to my miscellaneous other work (writing “ChrisDeLeon.com” on the second line, rather than “By Chris DeLeon”).
feelforit – iOS details
Play the new Flash port of that iOS game
Graphically, I built this on top of Tumult, since it uses similar vector fade effects. The original version had bouncing dots in the background, in color cycle, closer to what is seen in the new Flash port, though when source code was lost to a hard disk crash and I needed to fix iPhone 4 breaking the app, I wound up rewriting it from scratch atop Tumult and leaving the particle spirals as the background.
The goal is to orient the device such that the bright, moving arms overlap the dark, stationary arms of matching color (bright red completely overlapping dark red, at the same time that bright green completely overlaps dark green, and similarly for yellow). Each time this is done, a new random target orientation is determined, and the darker “shadow” arms change position to show the player the next goal.
Despite being composed of so few elements, this app was the hardest of the three to port, since the original input was designed around using the accelerometers – feelforit on iOS controls by orienting the device in space. Transcend and Tumult HD were mostly code porting, but this one required rethinking the design of its main ‘feature’.
feelforit’s general mechanism was discovered in my InteractionArtist project RoboDefuser, in which mouse horizontal position rotates the “shoulder” while mouse vertical position rotates the “elbow”. feelforit’s mapping is similar, except each arm rotated with one pairing of the X, Y, and Z accelerometer data normalized into a full circular rotation. If the single arm in RoboDefuser is thought of as turning ((mouseX/screenWidth)*2*pi) for the shoulder and ((mouseY/screenHeight)*2*pi) for the elbow, feelforit can be thought of as:
AngleX = (((accelerometerX+1.0)*0.5)*2*pi)
AngleY = (((accelerometerY+1.0)*0.5)*2*pi)
AngleZ = (((accelerometerZ+1.0)*0.5)*2*pi)
Arm1: Shoulder=AngleX, Elbow=AngleY
Arm2: Shoulder=AngleY, Elbow=AngleZ
Arm3: Shoulder=AngleZ, Elbow=AngleX
(Where (accelerometerX, accelerometerY, accelerometerZ) is normalized to a point on a unit sphere, so each being in the domain of -1.0 to 1.0 but altogether having a magnitude of 1.0, marking which direction is down toward Earth. Remember that even when held “at rest” an accelerometer still detects gravity! Even more exciting, Einstein showed that it’s impossible for an accelerometer to tell gravity from acceleration, because they are the same thing… )
Note that as a side effect of this pairing, the arm positions always show 3 pairs of parallel angles, with the angle of each arm’s shoulder matching the elbow angle of another arm.
To be clear, this is not animating a possible gameplay movement! It’s only showing that the arms consist of 3 pairs of parallel lines.
Games researcher Adam Smith pointed out to me that this is really only based on two angles, not three, since rotation perpendicular to gravity (ex. spinning the phone on a table, in any orientation) is undetectable to accelerometers. This should have occurred to me, since the random target chosen is determined by selecting a random azimuth and zenith angle, or longitude and latitude if that makes more sense, and finding the components of a vector connecting the origin to the point at that angle on a sphere.
That’s how it works on iOS. As crazy as this may sound, it’s really a relatively straightforward extension of the two-variable control in RoboDefuser to the three accelerometer data values on iOS. I in no way had to go out of my way to complicate things. This is, more or less, the simplest and least complex solution possible.
[Trivia: the focal point of the Tumult spiral in the background of iOS feelforit, the center pivot of the forces, is a globe projection giving the current azimuth and zenith angle detected as the direction of gravity coordinates stretched horizontally and vertically to the screen.]
feelforit – Flash port
Play the Flash port
Right – now to do the above with a mouse, all that needs to happen is to work backwards. We use the mouse horizontal position to determine an azimuth, and the mouse vertical position to determine the zenith angle, much as if we were mousing over a flat projection of a world map and getting the longitude/latitude readings at that point. Those angles are then converted into 3D cartesian coordinates, and the X/Y/Z values of that position on a unit circle are treated as which direction the accelerometer reports as downward.
Unfortunately, with the X/Y mouse axis positions being mapped straight to points on the circle, if I had stopped there it would have been easy to align one shoulder going left to right, then align the other two shoulders by sliding top to bottom. That type of easy algorithm is not present in the iOS version, mostly because an entire rotation transform gets ignored which mucks with the brain’s reasoning about how orientations correspond to on-screen position. The gameplay consists of performing broad searches until all three are close enough to fine tune in – and recognizing when a local maxima is going to produce a dead end from trying to keep two lined up when the third angle is far opposite.
To mitigate the trivial mapping, I performed one more final pair of transformations: rotating the mouse coordinates around the center of the draw area before performing the other calculations on them, and scaling the rotated coordinates to ensure all angle positions are reachable. After each matching occurs, that angle gets randomized, making it impossible to memorize a direct mapping between position and target coordinate, and ensuring that the game gets played by applying a scan algorithm of similar complexity to what players use for the iOS version.
The port lacks the spatial sensation of using feelforit on iOS, which is certainly a core part of the original (many players get stuck the first time the target solution involves holding it awkwardly overhead and looking at it from underneath). However the main concept in gameplay, applying a certain type of search algorithm to hone in on the answer for multiple variables at once, was successfully translated to this new format which can reach significantly more people.
Much like with Tumult, which also had its roots in a simple mouse control game, translating the dynamic to iOS then back to Flash introduced and revealed new intricacies. In this case though, the transformation was more dramatic.
The other changes were more clear instructions, added up top in the Flash port, along with a question to prompt user reflection, “Can you see what to do before doing it? Or can you only see what to do by doing it?” The answer to that question depends on the task being done. In particular, to answer to that question is the difference that turning the mouse-controlled RoboDefuser mechanism into accelerometer-controlled feelforit (iOS) ported back to accelerometer-controlled feelforit (Flash) changed:
RoboDefuser: Yes, we can see what to do before doing it. Seeing what to do by doing it can conceivably train that.
feelforit (iOS): Yes, technically speaking, you can see what to do before doing it. But in practice, the complexity of memorizing orientations on a constantly reorienting device prevents memorization, making it into a game where we see what to do by doing it.
feelforit (Flash): No, we cannot see what to do before doing it. We only see what to do by doing it.
I intend to port the remainder of my self-published iOS apps to Flash within the not-too-distant future. Including ColdWorms, which I have missed ever since I gave up on maintaining the iOS version.
As a reminder, though: the fancier iOS apps that I developed using pretty graphics – Topple, iZombie: Death March, Alice in Bomberland, etc. – are the property of publishers (Topple is ngmoco’s, iZ:DM and AiB are Sonic Boom’s…), i.e. they are not personal projects of mine that I’m free to port whenever I decide. It will mainly be my abstract experimental projects, like LASEReflect, burnit, and possibly Wobbly.
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!