[Golist] READ THIS POST: RESPONSE REQUESTED

Wed Apr 2 03:35:58 PDT 2008

Hello Moses,

Happy to hear that GO will be featured in this book, excellent way to spread
the word ;)

* Do you use AS2 + Fuse in your work?

Currently I use AS2 only for maintenance purpose of previous products or for
projects requiring specifically as2 (banners, .. ).
When I use AS2 I can't go without using Fuse/Zigoengine. 
As soon as I heard about Fuse I jumped to it, previously I've used an home
made tweening system based on Robert Penner equations and official MM
tweens.

* How much are you using AS3? If not at all, do you plan to start?

I use it 100% of the time

* You get the Open Source Flash book... it has a tweening chapter by
Moses...

__Fuse/as2 no more?
Well I think that Fuse should be quoted on the introduction, but that the
article shouldn't focus on Fuse because it is Actionscript 2 only and at the
time the book will be published (delays to gather articles, correct them,
layout the book, produce it, distribute it), most will use Actionscript 3
(hope for them ;)). I guess that it may difficult to you, because it is a
reward to be featured in such a book and let Fuse behind may be like to
loose a bit of recognition for the amount of your work. 
Of course if it was an historical book about OSFLASH Fuse should be one of
its corner stones ;) 

__"Fuseparser" ?
I feel that it is crucial that a simple Parser class is made available for
GO to benefit from the opportunity offered by this book and its wide
audience.
On the one hand I think that your choice to create GO is a very smart one in
term of architecture, efficiency, and a lot of other things and I'm very
enthusiastic and supportive about it. On the other hand Fuse was around for
a long time, respected, trusted, used by a lot of companies (famous or
not,big or small), the name is well known by the community. Fuse is a brand
with excellent recognition... So it is a pity that you completely loose this
potential by switching to another concept, I mean in term of name and brand.
If I were you, I would propose a parser for GO named Fusesomething, it is
just a matter of naming your Parser with fuse inside (and writing classes ;)
).
1: people who will never go in depth with tweening, will enjoy using the
parser, and make quickly the transition (but of course they'll know that the
sustaining technology/architecture is GO). Maybe one day they'll need to go
further and they could write their own parser or use one which fits other
requirements.
2: people who needs to go further, may skip completely the fuseparser and go
with their own development from start. 
So everybody may benefit from GO and you won't loose one audience painfully
"obtained" along years and hours of support. 
I feel that if you propose a technology which is very efficient and one of
the best, I think that advanced developers will come naturally or at least
keep an eye on the technology. It looks to me harder to "acquire" more
simple users (or hardcore user that haven't time to go further). If you give
them something which is very quick to start with, directly usable out of the
box (cf proposing FuseParser), I guess that the word about the technology
will spread quickly. When advanced users will meet GO and see that
technologically speaking it is very advanced and that they could use it in a
very flexible and open way, they would use it. 

__"FuseParser" may be better for beginners than Fuse 2
I think there is one big advantage of GO is that your "fuseparser" may be
more strict than in the open approach of Fuse. I mean in Fuse you can do
things different ways, it was something crucial for advanced users, but
sometimes confusing for beginners. These drawbacks existed, I guess because
Fuse targetted various audience at the same time. Now with "Fuse parser" you
can propose something very clear, with well defined steps to do things. If a
user needs to go further he/she can switch to custom parsers and open doors
of advanced features and community parsers/tools library.  

__My TOC

Regarding the TOC, from the top of my head, I would go for:

INTRO (5%)
Short introduction about tweening (historical, anim without the timeline, MM
tweenings, Robert Penner,...)
Forword on Actionscript 2 and Fuse.

THEORY (10%)
Tweening solutions available for Actionscript 3.
GO conceptual approaches, advantages, benchmarks.

PRACTICAL (60%)
Presentation of Fuse 3, FuseParser (cf my proposition above)
Examples basic use.
Behing FuseParser,  creation of a custom parsers (cf your video tutorials, I
liked very much you explanations using timeline).
Example/tutorial
The GO community, cusotm parsers library.

ADVANCED (20%)
Advanced: GO behind tweening:
Intro about Physic engines (which are available, best usage for each)
Go and physic engines.
Short examples
Intro about Collada and similar formats
Go and advanced real time 3d animations
Short examples
Future expectations.

END (5%)
Conclusion

If feel that practical part is the one which may have best impact to spread
the word on the widest audience, so it should be longer and more in depth.
Of course it depends on the target audience of this book...

I've gathered here few things I thought about GO along past weeks (basing
also on previous posts on the list).
I hope this will be useful.

Best regards.

Cedric M. (aka maddec)

Interactive Creator
Adobe Flash/Flex/AIR Specialist 
Since 1998
----------------------------------------------------
http://analogdesign.ch
http://analogdesign.ch/blog
visual & interactive communication
----------------------------------------------------