Call for an open standard for Adobe animation systems
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!
October 8th, 2007 at 2:28 pm
Moses,
Very interesting post and great concept. Your points are valid, especially with development groups where contractors are also contributing to large scale projects. It is inevitable that these overlaps will occur. Currently we have to track down all conflicting code and migrate to the package of choice, this is very time consuming. A solution like you describe is much needed.
Thanks for taking the initiative to put this out there.
October 18th, 2007 at 11:36 am
Moses,
My company has been using Fuse for about 2 years — much thanks to you as you’ve saved us time and made numerous things possible for us that simply weren’t feasible in our timeframes before.
As such, we have three developers, myself included, who would be interested in this initiative. We’re currently looking to transition to Flash CS3/AS3 for our development/design platform, but really would miss fuse. The Tween class is powerful, but not as elegant and quick to program complex animations as Fuse is.
October 18th, 2007 at 12:00 pm
Fantastic, thanks very much for the feedback on Fuse. The reality for me is that although I’ve gotten a lot of positive feedback, I rarely get to see how it’s used in the real world. Every so often I get a report that a whole company relies on it, their contractors bring in long complex Fuse sequences and they’re immediately readable & usable by the company’s developers… Hearing this sort of thing is exciting for me since there’s no way for me to see it in action!
Have each person on your team email me to get on the Go beta!
October 23rd, 2007 at 1:49 am
[...] He also is calling for standards in Flash Animation kits but this is good and bad. I agree a common syntax should be used and the base components should be agred upon and integrated into Flash, but standards need to be extremely simple and performing systems. We have seen how packaged Tween bloats and I think the Go appraoch mentioned below is a good direction for that. Adobe seems more open to this though talking about including SWFObject and possibly helping other kits like Papervision3D with performance enhancements. [...]
October 23rd, 2007 at 12:43 pm
Hmm, hopefully I’m just misunderstanding… Are you suggesting that this new open standard be named “Go”, which coincidentally is the name of your AS3 animation package?
Imagine Microsoft saying they thought it important to have standards in web browsers that everyone could use as a “base” to build off of and they were going to name this standard “Internet Explorer”.
I loved Fuse and would be happy to finally see you make an AS3 animation package, but it just doesn’t sit right to be one of the last one’s to jump on the AS3 Tween engine bandwagon and then decide that the engine you’re creating is going to be the industry standard.
Hopefully I have just misunderstood…
October 23rd, 2007 at 1:37 pm
Nate, thank you for the post but the answer to your first question is: Absolutely Not!
Go is first of all not a tweening Kit like others. It is an entirely different approach, and is not put forth with self-promotion or Fuse in mind, although Fuse 3 certainly could be built using the standard once it’s developed.
The reason I’m one of the last to “jump on the bandwagon” as you say, is because I have voluntarily held off on putting Fuse 3 into the marketplace due to some concerns I have about the overall situation for all of us. By releasing Fuse3 quickly I would have been putting out another top-to-bottome Kit solution that doesn’t work with any of the other kits out there, and further adding to what I see as a potentially problematic scenario for all of us developers.
Go is an invitation to create an animation standard that is by and for the community, in an effort to at least have the possibility in the future that one or more of these kits will be able to work together without as much redundancy, and also to make animation scripting open and accessible to all developers so using kits is not the only easy option.
I hope I’ve answered your questions but will probably make another blog post about this since I can see that everyone’s first response is to assume that I’m just out to self-promote and further pollute the environment – quite the opposite on both counts.
For more on this topic please see my post Go, and why as3 needs it
October 23rd, 2007 at 3:12 pm
Thanks so much for the clarification Moses. I do agree on many counts with what you are saying and am very happy to hear that I just misunderstood. Let me know if there is anything I can do to help out.
October 24th, 2007 at 3:28 am
I think that a base is a good idea. And natural evolution of systems builds on common platforms. But I am wondering how much can be added to an animation kit as a base that wouldn’t add bloat. The ColorMatrix class by Quasimondo is common, the easing equations are common (some use the ones in flash, others embedded), common patterns for complex tweens could be an area of improvement, filter-bezier-special tweens could be another standard area, syntax another. I think many of these things are being decided by what people like in kits like Tweener and TweenLite. Also, Tweener and TweenLite themselved can be called a base to other kits or extending them. I think a good anim kit probably shouldn’t be bigger than 10k with the basics. There can be add-ons that add more size (sometimes even design patterns bloat). Bandwidth and embedded swfs that have to compile these in need to be limited. I have been looking at this and will have more time but just think it could be more of design patterns and agreements. But a very performance friendly, tightly written base, that uses even short names and limited design internally to decrease size is useful to build upon.
I think that the success of kits so far are size, simplicity, able to use in AS2 and AS3 and performance.
October 24th, 2007 at 11:40 am
Thanks for the comment Ryan.
One of my concerns with bloat is “phantom bloat”.. boy, that’s an ugly term, ha! No, but seriously when you have someone who diligently builds out every feature they think people will want to use, but keeps it in an open, extensible framework that’s great – in theory. However in practice, how many emails have I received explaining that people really enjoy reverse engineering something like animation package or Tweener, to customize it for a project? None. In reality you either have to swallow the bitter pill of reading docs once right up front, like with Cairngorm, then have smooth sailing for all your days ahead, or you have to strap a manual to your back and tote it with you to keep referring to over and over and over.
In the end there might be no difference between an end-product built on Go or a big package with all the bells and whistles – except one: if you built the Go package, or have used Go before, modifying it to your project needs is very simple.
Go is definitely anti-bloat. Check the comment on this blog from a go beta tester who whipped out the tweens he needed for a specific project in just a few minutes, and had a lightning-fast, bloat-free system that was his own code that he had full control of.
January 10th, 2008 at 6:04 am
AS3 Tweener engines, GOASP and Adobe….
Go is not Fuse 3. It would be possible to build a Fuse syntax over Go, in fact you can start doing that now since Go ships with Sequencing. But, Go is a generic set of base classes that should support many kinds of animation systems.
……