Where da tweens at? Why doesn't Go come with any tweens?

What? Screw you, pal!

;) Teehee, sorry – always wanted to see that on an FAQ page.

There are already tons of packages out there that define tweens for you. They're also telling you exactly how they think you should interface with your animations. Go takes the opposite approach, it's totally generic and invites you be the one to define the specifics how you like them. If you build something big, like a full tween API over Go, you're the designer.

Also here's a zinger: LinearGo actually is a complete, functioning tween class! Gotcha.

What it animates is a number from 0 to 1, doing the math for you on each in-between value. You can make a new LinearGo() then add an UPDATE handler that fades a sound, runs a transition, whatever you want, using that percentage value. You'll still have all the controls – delay, duration, easing, start(), stop() and so forth. So, there's no law that you have to subclass LinearGo to use it, that's just what you'd do to package the functionality for reuse.

As far as the scary details of complex animations, relax. You're not trapped in a classroom with a quadratic bezier math quiz in front of you. (Wake up, you were having a nightmare!) Stroll around: You're actually in an open-source showroom, and all the shiny new-model tween API's have their hoods popped open for display. Just be sure to honor the specific copyrights and attribution clauses of other people's open-source licenses, which is your responsibility.

But be creative too. If you come up with a new tween idea and can make it work, the community will most likely recognize you for it.

What are the bare minimum requirements to using Go?

Shirt, shoes..... jeez, at least put on a bathrobe....

Well if you're extending LinearGo to say, build a tween in 3 easy steps, you don't really need to worry your pretty little head over this, it's all done for you. But for you über-geekz out there, I'll answer this (actually pretty common) question.

Bare, bare minimum? Okay, take any object and implement IUpdatable. That adds a pulseInterval property & an update() method. Now have the object call GoEngine.addItem(this) to start its update-pulse. You're now using Go.

In practice though, you'll also dispatch GoEvent, and inherit PlayableBase/IPlayable. This adds start(), stop() and other play controls, play-state constants like PLAYING, etc. and a state getter. But, that's it. LinearGo – core as it may seem – is entirely optional, as are all other utilities. The only other parts of the platform that can tie into your code are managers, which are optional.

Go stops there. At the utility and parser levels, there's no "framework" to worry about. So there's not really much to Go at all – a very few core classes & interfaces, and a clearly defined but simple architecture, with a handful of common utilities thrown in for good measure.

Why should I take the time to learn Go when other kits are easier?

Okay that's a valid question... punk. If you're just looking for an easy tween API for a project, try Tweener, TweenLite or one of the tons of great products out there right now. Don't sweat it, wait a while for Go to start rolling and hopefully people will be building easy kits with it in no time.

If you're interested in the idea of building & sharing your own animation tools, you'll find that Go is surprisingly easy to learn. You're just gonna have to take my word for this, but it's one of those things that looks really complicated until you do a video tutorial or read a couple of docs, then you're amazed by how simple it really is.

There are consumers and there are makers. This young phase of the project is a great time to get involved – who knows, your work may end up being one of the de facto standards!

Is GoEngine just like, a big Timer?

It's true that GoEngine encapsulates the various pulses of all active Go items. It allows each item to define its own pulse (most tween engines allow for just one pulse by the way), either on ENTER_FRAME or a millisecond value, then runs the items' update() callback on the pulse.

See how the Flash9 Tween class is at the bottom of the benchmarks chart, running only around a quarter of Go's speed? It is coded very well, the lag is due to an architecture choice: Each Tween object is its own separate manager with its own pulse. So as you can see, "just running a timer" is actually far less efficient for multiple animations.

Go's engine is extremely efficient, and literally as "synced" as is you can get in the current Flash Player (9 when this was written). Tweens with similar pulses are updated in lists for efficiency, and the Go system very purposefully uses only tightly-coupled communication at the core level.

The other biggie: Having one central hub is really the key to Go's unique "decoupled management" architecture. This extremely flexible design not only lets every user opt-in to use any manager, but also lets you create custom managers as needed, like a custom hitTest.

What about file size?

Filesize complaints invariably come out of one corner of the interactive industry: banner ads. Luckily some excellent projects now cater to that segment (notably TweenLite & Tny).

Go's approach to this issue is to make almost everything optional, even the management layer. (See bare minimum requirements on this page.) Banners aside, if you want your flash movie to affect a complex filter transition or something, that code has to exist somewhere in the swf.

Luckily with Go it will actually be your extensions adding the filesize so, maybe I'll hear fewer complaints – ha! ;)

Does Go manage memory well?

Go does... I'm another story. :P

Memory management was sticky in AS2, particularly with code written in the Flash timeline. This led to more complicated tween engines, which often tried to shield the user from object-creation while tightly tracking items & listeners internally.

Another issue arose in AS3 – particularly apparent with the Tween class shipped with Flash – Tweens that self-manage can get Garbage-Collected and stop in mid-run, unless you remember to store a persistent reference to them in your code. Which can lead to extra work & clutter.

Go's architecture works well with AVM2's improved Garbage Collection to eliminate these issues. In essence, you don't have to worry about it. Whether or not you retain references to playable items they will not evaporate during play, and if you haven't made hard references to them in your code they will be eligible for GC on completion.

AS3 Good Practice Tip: To ensure GC of objects you don't store hard references to, be sure to pass true for the useWeakReference option in addEventListener calls on that object. This way the event system won't trap a reference to the object.

How does Go differ from the proposal to Adobe for a Core animation bundle?

A proposal has been submitted to Adobe by MosesSupposes.com suggesting that they provide a unified animation code library that would be portable across all of their products that support ECMA Script. More information including charts can be found at this blog post.

This initiative is entirely separate from Go and differs on some key points. First, Go is an initiative to provide a common library for AS3 only, meaning Flash and Flex only, whereas the proposal to Adobe discusses a library that exists outside all of their products and is ported in for specific languages and APIs.

The second major difference is that the proposal to Adobe includes actual animation processing classes, such as beziers, color transforms, filter transforms and physics calculators, whereas Go does not. Go tries to provide a thin, unobtrusive supporting framework on which those more specific classes can be built. This leaves more to the AS3 developer but also provides the maximum amount of flexibility. If Go receives even moderate adoption in the AS3 community, those sorts of processing classes (tweens and physics handlers) will emerge as open source Go extensions or existing 3rd-party animation API's could be ported to use Go in an effort to make them more compatible with each other.

The Adobe proposal would be an ambitious undertaking and touch many different product departments, so it's not realistic to assume by any stretch that they will take it up. But if they did it would entirely change the way Web developers approach scripting animation systems. There would no longer be any need for a stopgap solution like Go, that only partially addresses the redundancy and cross-compatibility issues with current systems. Solving those problems would likewise not be left in the hands of the larger AS3 community to voluntarily adopt and agree upon—an admittedly optimistic experiment.

Even if Go is all we have for now, please approach it not as gospel but as a working dialogue. The Go codebase should be refined by its users in the AS3 community to become as lightweight, efficient, flexible, and widely portable as we can make it. Meanwhile, if you see the value in Adobe eventually offering a core animation bundle, please take the time to leave a comment here to show your support where people from Adobe might see it.