I have been writing Flash games for a while and now I would like to write games for browser, Android and iOS. I am very comfortable with AS3 (coming from Java) have read through books and tutorials, had online trainining from Lynda.com you name it. I would like to hear from real developres some best practice approaches to the 'write once, deploy anywhere' feature of Flash Professional. Namely I would like to know:
These are the main things I would like to know. Feel free to add any hands-on knowledge you would offer me and users of this forum. I think this is a great discussion to have that would elimate a lot of the 'fire extinguishing' that takes place on help forums. I am running CS6 Web Premium on Windows 7.
- Should I use timeline code?
- no. only use timeline code for simple projects (and i can't think of any game that's simple coding-wise) and for testing code snippets. otherwise, you can have relatively complex scope issues to resolve and/or problems working on your code after you've forgotten where each snippet is located.
- Should I include third party engines like Tween Lite. For example, if I have a Tween Lite com folder in my app or game will that compile to native iOS code?
- yes, tweenlite is an excellent choice and there's no problem using it with any flash target platform.
- How should I approach sound clips and music?
- there's no problem with sound and android/iOS. for the web, sound file size is a consideration so, you may want to (pre)load your sounds.
Awesome. Immensely helpful. Your right, the coding on games can be very daunting. Recently, I ran into the "unexpected file format" error and had to learn the hard way to use version control. Are there any other pitfalls that come to your (or anyone's) mind that people should know?
Having a proactive discussion is great so people, like me, who are new to Flash but not to coding can avoid posting question after question while making our app/game/etc.
that's another benefit of class coding: you'll never end up with an unrecoverable class file.
be aware of the stage size differences between your target platforms and decide asap if you can live with one of the stagescalemode settings (so you can easily code one fla/one swf to publish for iOS, android and web platforms). otherwise, use a liquid layout so you can use one fla and publish 3 swfs.
Great point. So far, I am approaching it as writing an FLA for each platform making just minor adjustments (hopefully). I am trying to avoid numbers when setting sizes as much as I can. Instead I'm determining the size of graphics relative to the stage size.
There is another question that comes to mind. In a lot of games I use either counters or the timer events. For example, if I wanted to intoduce enemies onto the stage every few seconds I might use a counter which is basically a "var counter:Number = 0; counter++; Then say, if counter == 250 introduce enemy. I might do the same with the timer events.
My question is, is there a better way to approach this when trying to 'write once, run anywhere?' I ask because I have heard that the timing delays may vary on different platforms. Are there ways around this? Does Flash already account for this?
all timer events and enterframe loops are approximate. meaning, you can expect accuracy on all platforms that can maintain the average enterframe rate. ie, if you overload a platform, the average enterframe rate (and every timer rate) will fall behind the expected rate.
however, flash only attempts to maintain the average frame rate and timer intervals. the duration between loops can and does very tremendously which is not a problem for most games. it is a problem for anyone trying to maintain a musical beat.
Hmmmm. Quick question about timeline code. Will timeline code compile and port into iOS and Android? I have found it very easy to control the functions of a movieclip loaded with buttons and symbols through the timeline. It is just easier for me. I simply write the whole MovieClip's logic on one screen and then instatiate it onto the first frame of my game all as one MovieClip.
If timeline code will compile, I would love to use it. So does it compile and port to other platforms?
Here's a spinner. "Scenes." What's the verdict on scenes in cross-platform design. Should they be avoided? Do they compile 'nicely.' I make a note of avoiding them but they are a very convenient, almost lazy, way of transitioning to different parts of a game. For example, say there is a disclaimer I want to run at the beginning of a game, for non-commercial browser publishing I would just put a scene at the beginning, throw a few hundred key frames into it and it would play, stay for a while and then disappear forever.
Back to the question. Are scenes to be avoided, in cross-platform publishing? Are there any good approaches to using scenes for cross-platform publishing, keeping in mind the 'write-once, run anywhere' portability aspect?
using scenes in as3 doesn't have any unexpected problems that i know of. i never use them but that may be a hold-over from as2 which had a problem with scenes.
you just have to be aware that at frame 1 of the next scene all objects created in the ide are gone. anything created with actionscript will still exist from one scene to the next.
fastalgebra, I'm going to go off the rails (sorry, kglad) and say that I've had tremendous success with timeline code. I've done some class work, but I'm really a procedural programmer at heart. I've done some extremely large and complex stuff with timeline code, albeit with a ton of trial-and-error over many years to learn what works and what doesn't. My code placement is consistent, it's reusable, and it's easy for me to go back to projects from years ago to find things. Granted, I don't use the timeline for actual animation or timing... I just use the timeline as a "filing cabinet" for all my code.
While I haven't done any Android work, I've built apps that work on all iPhones and the iPad, with one .fla and one .swf (or .ipa).
I think there are simply a lot of ways to skin the cat.
Thanks for chiming in AV
No doubt about it. There are, however, a lot of caveats to using timeline code. For example, always remembering to copy/paste into notepad and save in the case of a corrupted FLA, being limited to only one frame vs the tentacles of a document class, weight (it seems all the code loads and runs without waiting to be called) and the list goes on and on. You get the point.
Timeline code is like a filing cabinet, as you put it, whereas the class approach is like a books on a shelf. I think Kglad's opinion was specific to the question I asked, bearing in mind that I was making games. In the case of games, timeline code can become very expenisive. I try to reuse code wherever I can to keep things light.
My approach, so far, is still mostly class based but I almost always use timeline code for animations varying from five to thirty lines of code on average, I would say. Then I just call pre-animated symbols from my document class. Seems to be working so far.
Thanks for sharing that timeline code is porting nicely into .ipa. That is a huge reassurance! That was actually my main concern. Android is still using a virtual machine (so I am not too worried about that) but I heard that publishing to .ipa converts to native code. Hats off to the team who pulled that off.
And like you said, there are definitely "a lot of ways to skin the cat." Happy coding.
Question. When coding for different platforms, would it present a problem to reference a movieclip in timeline code (via an instance name) and then reference the same movieclip in the document class with a different name? I know using the same name may be a namespace conflict but what if the movieclip is called on twice at the same time?
Obviously, this is not a problem for the browser, but what about when it converts to native code or ports for Android?
an object can have only one instance name at any one time.
it can have different paths depending where the code is that references the object and you can use different references/variables to reference the object but you can't assign different instance names.