> Flash as a distribution format for video was distinctive and successful because it was essentially a standardized abstract machine for demoscene demos
While it WAS true, it's not COMPLETELY true. The first versions of Flash had very little scripting support, it was basically limited to switching between scenes. The first Flash that could do something non-trivial was Flash 5, released some time in 2000 and by that time Flash domination had already been established.
The secret was in its authoring tools and the concept of timelines. Basically, you inserted "key frames" and Flash interpolated between them automatically. So if you need to draw a triangle moving from point A to point B, you just add it to the timeline at the starting position, then move down the timeline, insert a key frame and drag the triangle to point B.
And these timelines can be composed, looped, triggered by scripts, etc.
And that's it. No need to write any fancy code. Flash would do everything for you, and it's baked right into the file format, that was specifically designed to be compact and concise.
It is free, open source and surprisingly good(for simple things), but developement is on hold or abandoned. (I looked at the source and it is not great, but not horrible either, but with the original creators not around anymore and lack of documentation, would be a pain to overtake)
Tweening and animation programs are hard to find for young people.
I remember one I saw running in a video on an Atari ST that pretty much outdid anything I've ever seen since, indie developer too. Wish I could remember the name, maybe he made another version.
To be clear, I didn't (exactly) mean that the author of a Flash animation has to think in terms of creating a "demoscene demo." I rather meant that the Flash abstract machine is designed to primarily do the types of thing that demoscene demos do — i.e. to use vectors and gradient fills and clipping masks to achieve procedural visual effects. You could say that the SWF abstract machine has a "demoscene-alike Instruction Set Architecture." Most of the work of figuring out how to achieve particular visual effects on that abstract machine, though, is domain-knowledge built into the "Flash compiler" of the authoring tool.
In my previous post, I emphasized Flash as a distribution format for a reason. While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around (potentially texture-filled) vector objects on a canvas. Writing SWF bytecode directly, would be similar to programming against a retained-mode fixed-function graphics API like OpenGL — just without any 3D support. In other words, it would be like writing a demoscene demo.
Or, to put that another way: the core of the .SWF export format — before all the user programmability stuff was added — is basically a cousin of PostScript, but with a finishRenderAndWaitForNextFrame command, and the ability to set spline points' velocities. Which is very much unlike declarative vector formats like SVG. The closest comparison, I think, might be to the object-oriented vector display-lists used in vector-based arcade machines (see e.g. https://www.youtube.com/watch?v=smStEPSRKBs.)
But, in both the arcade games I mentioned, and in Flash, if you've achieved the effect you want and are now optimizing the final work for size and performance, doing so will mostly be a matter of modularity and reuse of small repeatable design elements. Having "mechanical sympathy" for what the Flash export format looks like, will push you toward certain authoring decisions, e.g. building complex scenes using many smaller primitive objects that each independently animate (or in later versions of Flash, are independent state-machines); creating objects that can be uniform and so constructed by cloning rather than redefinition (leading to a surprising number of 2D flash animations and later games that were built out of colored, untextured voxel boxes); etc. And — despite there being no actual programming involved in the Flash animation authoring case — this is still very much akin to the process of optimizing a demoscene demo.
> While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around
I mean, you can describe SWF like that, but it's not really what people think now when you say that it's an abstract machine. The SWF file is indeed a series of commands like: "put this object in this layer, and assign this matrix to it".
However, SWF still preserves the notion of persistent vector objects (called "characters") down to the display level. You're not just preparing a command list and then submitting it to a GPU for rendering (like with OpenGL), and then re-doing it again for the next frame.
Characters in SWF are persistent. Flash does all the composing, clipping, and it even does automatic interpolation for you for morphing.
SWF format is now open: https://open-flash.github.io/mirrors/swf-spec-19.pdf - the page 35 contains the description of the most important instruction "PlaceObject" that was used to actually do the animations.
While it WAS true, it's not COMPLETELY true. The first versions of Flash had very little scripting support, it was basically limited to switching between scenes. The first Flash that could do something non-trivial was Flash 5, released some time in 2000 and by that time Flash domination had already been established.
The secret was in its authoring tools and the concept of timelines. Basically, you inserted "key frames" and Flash interpolated between them automatically. So if you need to draw a triangle moving from point A to point B, you just add it to the timeline at the starting position, then move down the timeline, insert a key frame and drag the triangle to point B.
And these timelines can be composed, looped, triggered by scripts, etc.
Here's an example video that shows that: https://www.youtube.com/watch?v=NOPCPZO5YOA
And that's it. No need to write any fancy code. Flash would do everything for you, and it's baked right into the file format, that was specifically designed to be compact and concise.