I started a separate blog for the Go beta here: go.mosessupposes.com. This will give us a public forum where we can get into specifics. Note that the blog is also linked from the MosesSupposes category under the BlogRoll at right.
Animation is an important element of many Adobe products. Following the Macromedia buyout and the addition of a fully standard-compliant scripting language, it is one area that could use some tidying up in looking toward the future.
This is a call to developers in the Adobe user community to work together to create a standard shared codebase for any animation system.
Update: A more recent post on this topic can be found at the Go blog, here.
There are several reasons to make this step. First, at this time various animation systems tend to have different APIs but contain similar code. As systems proliferate this can lead to conflicts, behavioral discrepancies, compounded filesizes, with no clear path to correct such problems. (If working from a common base, systems would be more synced and efficient, similar elements can be combined, and developers will have a clear common thread to work between various packages at once.)
Secondly, it will truly be putting our best foot forward to demystify animation scripting for the general Adobe developer community. We should provide a helpful stepping stone, a simple and clear path to writing animation code with little up-front study, and the assurance that this work will be easily shared and used by others. Complete packages that adopt the standard will likewise become far less opaque and easier to modify or tie into larger programs.
Finally, physics scripting should be supported by the same standard. By creating a shared base for both physics and linear animation (as Robert Penner suggested several years ago in his book), we will be truly defining a central hub for motion scripting that can function together.
Currently the focus is on AS3.0 for Flash and Flex, but this standard should be ultimately portable to other Adobe animation products such as After Effects.
I am currently leading an effort to define such a standard in AS3.0 along with a small pool of Adobe developers who have expressed interest in the end goal, and I plan to pass the project into public domain as soon as it takes shape. We are naming the standard Go. That's not a brand name, just the shortest word that implies animation.
Please contact me if you're interested in participating in this project!
{What is Go? Please see the introduction, a few posts back.}Well this is inspiring: Apprarently Go is not just a concept but you actually can do stuff with it. This came in a few days ago from a Go beta tester (and good buddy of mine) Steve Schieberl:
cooooool. i'm basically building my own version of tweener without doing a lick of math. but one that runs really fast and works with filters. yeah, this is dope. i get it now. it's not in competition with tweener, but is something that tweener should be implementing.mine just does alpha and blur right now, because i need those for this project, but i definitely want to develop this out. note that tweener still doesn't support filter tweens, and i just built one using go in like 15 minutes. very cool. it's just like the ultimate number cruncher.the thing i'm making is more like the tweener syntax, except that i just have *everything* inside a single object that you pass as an argument. it's also a static class. so you just do this:TweenGo.tween({target:my_mc, blur:[20, 20, BitmapFilterQuality.LOW], alpha:0, duration:1.5, onComplete:function():void { removeChild(my_mc); }});this code makes things blur/fade out. once this is finished, it will be reeeaaaally easy to right a visualizer that looks really cool.thanks,steve
I'm really pleased that Steve seems to have nailed the purpose and concept beyond just being able to use Go to write something useful.I should be quick to point out that the syntax example he shows is not a standard Go syntax. Go doesn't have one! Read the rest of this entry »
{What is Go? Please see the post just before this one for an introduction.}
In March of 2006 I talked to Sho Kuwamoto to discuss my idea of a system that could be shared between Flex and the upcoming release of Flash 9. I was too late: Adobe was just then announcing the release of Flex Beta2, sporting a robust animation system of its own. (Generously, Sho said he wished I'd approached him 6 months prior.) Later a proposal by a certain Mr. Skinner and myself was turned down after Adobe hired Robert Penner. My plea for Unification fell by the wayside, although that was for the best. Robert is the right man for that job and, like everyone out there across the board, I have the utmost respect for him. His copy/paste Motion package is a really elegant upgrade to Flash's capabilities.
Adobe has in fact produced quite a number of excellent animation libraries, including the whopping Effects system shipped with Flex, that really couldn't make application transitions any easier. In many ways it's a dream, and whatever developers still lack they can find in 3rd-party kit solutions. My own such kit, Fuse (for AS2) gained wide adoption including many top agencies, and now a similar kit called Tweener for AS3 is being developed by one of the early scripted-animation proponents, Zeh Fernando. And all along, Alex Uhlmann's excellent and fully object-oriented Animation Package has set a strong standard. (Alex is currently kicking Flex Effects up a few notches, to great – well, effect.)
But in the midst of all of this activity, there's an underlying issue that has been troubling me. Read the rest of this entry »
I have an idea cooking, now in private beta, called Go. I will be posting shortly with some background information on what led me to this approach, but right away let me share the concept and architecture with you.
Go is not a kit solution like Fuse or Tweener, it is an architecture and a set of base classes that in fact do nothing by themselves. If you're a solid AS3 coder and this project fits your interests, feel free to email me directly to apply for the private beta (some very light screening will follow; if you don't get in now don't worry, we'll be opening the beta up very soon).
Go architecture (subject to change)
go_architecture.pdf
{Note: You can see the gears turning here that led to the Go concept outlined in the following post.}
To forewarn the fanbase, this is not a release announcement, no major progress to announce at this time.
I've been holding my cards close since I came up with these concepts around January of this year but it's time I layed 'em on the table.
Imagine "binding" a target object's properties to Fuse, then applying physics motion and canned animations without having to worry about the complexities under the hood.
As with Fuse 2, everything could be sequenced in a simple declarative format. But we're also planning for such 'dialects' to be add-ons to a standard OO library, so there could be MXML flavors, etc.
Read the rest of this entry »
You are currently browsing the archives for the Fuse 3 category.