Showing posts with label adobe flash. Show all posts
Showing posts with label adobe flash. Show all posts

Monday, December 26, 2011

in defence of the flash IDE.

I develop online learning experiences for users. These tend to involve some kind of interactive UI that enables the user to view content and interact with it in the form of simulations, tests and assessments of some kind, and tracking/session management stuff aka bookmarking.

These experiences are generally one time experiences with little repeating.  They sometimes want to be reused extensively, but to me the quality of learning tends to go down with extensive reuse even though it does save some money.  I have had the fortune of working on projects that really push the envelope and make memorable and intriguing first impressions for the learners and have a proven rate of retention and ROI for my customers.  My latest opportunity at SweetRush as CTO is no exception, and Ive been able to work with some of the best folks in my career on designing and developing training content for some very impressive and demanding clients.

Although I can certainly build these projects using non-Adobe Flash IDE (Integrated developer environment), I really enjoy working inside the flash IDE because its where I started, and creatively its a wonderful tool to use.  I tend to write all my code inside the flash IDE on projects where I'm the sole programmer/creative and decouple the scripts from the artwork using simple includes on projects where I'm the sole programmer but not the artist.  I find this approach enables me to work very fast, and build projects that function reliably with few if any bugs out the gate.

My type A approach is fairly simple.  I use the timeline as a logical flow line (a hold over from my initial training in authorware)  Starting with the first few frames as preload/init frames, then dividing the user experience into what I call "action points" where some code gets executed to display some content, provide a small game or what have you.  Then users can visit the AP's in any order, loop through them incrementing a value (like using 1 AP to display a question, but using another AP as a count incrementing element that just loops back to the question display AP until all the questions are done, at which point it then moves to the next logical AP).

Then by the AP's , I can set bookmarking logic to each of them as well as garbage collection, necessary inits and component/class instantiation.   This allows me to use the timeline to visually layout the user experience and enables an animator who is unfamiliar with code but knows how to move keyframes around to have the ability to change the logical flow without editing code.  The flash IDE provides all the objects, the library of components, and types of symbols I can provide the animator to tweak, change or even discover how programming essentially works in an environment that is familiar to them.

As a general rule of thumb, if a segment of code in a particular AP becomes more than a few hundred lines, or that code is getting reused in other spots, it becomes clear I need to move that code to the first frame where I put all my globals.  I tend to have all the global variables, functions, and common data defining/parsing logic there. I also like to push all dynamic text and content URI's out to an external XML file that always gets loaded as a global to be used anywhere in the application.

I find the flash IDE endlessly flexible in this regard.  I can visually represent objects as movie clips each of which can be visual or not, and can carry out functions, or just hold functions for use by other movie clips or the main timeline.  Being able to make any code anywhere behave as a visual object definitely has its advantages.

Of course, one can write endlessly messy code that is nearly impossible for others to navigate in the flash IDE, so its important to be very consistent in keeping the library neat, the main timeline reserved only for logical flow and any artwork/animation to be encapsulated and contained to a specific and well labelled layer with instance names that allow it to be controlled externally.

Other advantages are the integration of the compiler in that you don't have to jump through several file settings or create elaborate folder structures with strict names on the computer to work, you can do it all inside the highly optimized work environment of the flash IDE.  No need to find compilers, and moving/renaming MC's or "classes" is all monitored and tracked by the IDE so there is no need to update paths.

All this makes for very rapid application development.  Provided a disciplined approach is taken, I have found one can use the flash IDE to make very flexible, very reusable and very powerful applications all with the built in power of handing the file to non-programmers to tweak art/animation/sound aspects within the same working context.

I think a primary perceived disadvantage is the reliance on the IDE vs being able to pull out the code and edit it using a text editor or source code editor of choice.  While there are hundreds of thousands of flash coders like myself who feel completely comfortable implementing what could be considered "valid design patterns" inside the flash IDE, I think there are also a lot of detractors who feel that the flash IDE represents a step backward or is a tool that does not have the capabilities of a tool like Flex, for example.

I would challenge anyone to building something in Flex that I couldn't build in the flash IDE, and have it work equally as reliably, and be equally as flexible and scalable, provided other coders had access to the IDE as well for the bits that were non xml or external script.

That said, I can clearly see a few issues / disadvantages to the IDE.

1. The IDE is too permissive, in that you can use untyped variables, haphazardly scope variables and functions, and put code anywhere making it difficult to find.
 - all of these are true, but they are not the rule.  Any disciplined coder can write bad code in any environment.  I think the need for discipline and neatness becomes heightened in the flash IDE, but I also think visually the ability to lay out an application clearly is greatly enhanced in a visual programming environment like flash.  Its not as literal as author ware where you had a literal vertical line and you could drop logical objects on the line with visual loops, visual branching all iconically represented, but its similar in power.

I think of it as the difference between looking at pages and pages of VRML textually representing a 3d model, or the 3d model itself.  If you can "see" the 3d model when looking at the code, wow, good for you...but you can't argue that actually seeing the 3d model itself fully rendered gives you a different perspective and often illuminates problems that a human couldn't possibly perceive when looking just at text.

That, to me, is the main difference.  I like to represent code iconically, and the flash IDE/timeline allows me to do that, and just as looking at a rendered model enables me to see the object as it is, so the IDE enables me to see what I'm doing as I'm doing it rather than furiously writing incredibly elegant looking code-all indented and outdented perfectly with inline class autofilling...I can actually see the end result, the user's experience, as I'm writing it.  (not quite exactly...but certainly closer than when I'm writing an app in Flashdevelop or some equivalent).

As a career coder I think its important to know a little bit about all the approaches, and to not think one is necessarily better than others as long as the primary stated goals are met, and try to apply best practices wherever they may apply across languages.  If I write in Ruby, Java, Python, C++ or what have you and can learn something from a timeline / visual developer then great...and vice versa.

So why so defensive?  I think that flash has branched out to make its technology more palatable and familiar to those coming from a traditional OOP background, and created Flex/Flash builder for that very reason.  The sense, however is that somehow meant that Adobe was "admitting" that the flash IDE was somehow a failure and that Flash Builder was the superior step in evolution of the product.  If that was true, of course, the flash IDE would have been phased out or at least severely "dumbed down" in order to push developers towards FB.  I certainly felt that way and it pushed me to learn to do strict OOP, embracing a class/inheritance/interface approach and writing some fairly sophisticated projects in flash builder.  After really getting down that rabbit hole I came out the other side thinking that there was a lot of what I considered unnecessary complication with that approach, and that while I thought it certainly made sense for some kinds of projects like the one I was working on for example, I didn't think it necessarily was the be all, end all approach for all projects.

One very interesting development is the advent of the javascript/html animation tool Adobe Edge.  Over the past couple of weeks I had to build a project using Edge with some serious tweaking and I found that even though the product is in beta, and its buggy, I really enjoyed using it and appreciated the ability to edit the source files and find most of my edits were retained in the IDE, with only a couple of minor exceptions. So far, Edge looks a lot like the flash IDE, the only notable difference being the timeline works in seconds rather than in frames.  But, like the flash IDE, I can place code on a timeline or all in one place at the beginning, reference external code, and use the timeline to trigger/organize events that can also be manipulated by animators.

I think the Edge tool, either merged with flash IDE or kept as a separate tool will ultimately continue the legacy and impact of timeline coders, perhaps to the ire of OOP programmers but I certainly hope to see more interoperability among skillets and disciplines rather than an eventual monoculture of development.

Finally, on a creative level the IDE enables animators to "see" code, and coders to "see" artwork. I think if animators stick to tools like illustrator and photoshop, they will never get "rich media".  I also think the same is true for programmers that wall themselves up in code.  The flash IDE is the glasnost, the common ground where folks from an artistic background and those from a programming background are forced to literally work in the same environment and gain a very intimate understanding of each other's work.  The best stuff I've seen in flash has been built by coders who were also amazing artists and animators, who really understood fluid motion dynamics, colour, font design, traditional animation technique, photography, bit mapping, sound editing and mixing, and of course were excellent programmers who really had a grasp of OOP.  While these "one hit wonders" are tough to come by, I think the flash IDE provides the opportunity for a collective to "get inside each other's heads" and become that one mind that can then, collectively, become more than any individual team member can.

Saturday, May 1, 2010

The future as I see it...HTML 5? Flash? whatza whooza?

I see Flash/Actionscript it as I've always seen it, a specialized UI tool for building rich internet applications, and there isnt anything else on the market that accomplishes this task as well as flash at the moment - and in the forseeable future. Should something come along that does it better, I have no particular loyalty to Adobe and would be the first to embrace the new technology, in fact, for the latest stuff I have been building flash files in non-adobe products for the most part, only using the free flash compiler that comes with the flex sdk to do my compiles - but I could be using something else if I felt it was worth the effort.

I think if Adobe is smart, they have an opportunity to blur the lines between HTML 5, flash, and anything else by simply making an authoring tool that compiles to any format, and even player technology or scripts that interpret flash to HTML 5 and back on the fly. This would effectively end the debate of HTML5/flash, and render "player technology" irrelevant, which it pretty well already is since flash is embedded so deeply in most browsers outside of the iFamily. End users dont care if their games are HTML5, flash, javascript or whatever, the only people who care are developers, so the drama continues. Adobe clearly realizes it is not in the "plug in" business, it is in the authoring tool business, so their authoring tools should continue to output in every possible format for every possible platform, the only limitation being the platforms and formats themselves. Adobe is in a better position than most companies, it knows how to write RIA authoring tools better than anyone, hell, it invented the concept. Adobe is capable of being so flexible, no other large corporation can really hurt it. For example, Apple said no flash on iPad. So, adobe makes a compiler within a few days that authors app store compliant software for the iPad. Apple gets angry, and responds by blocking any content that is authored by flash cs5. This is ridiculous, because you can bet almost every visual on the apple platform was partially designed using an adobe product, including the hardware. Apple has succeeded in making itself look like an immature baby, and Adobe simply says "fine, we did everything reasonable, and if you want to act retarded, we simply will focus our energy on another platform...android". Apple thinks they've beaten adobe...ha ha. Adobe's dreamweaver is CURRENTLY the best authoring tool for HTML 5, which Apple believes is competition to Adobe. Again, ha ha. Adobe outputs in SVG (HTML5's parent technology) - which Adobe essentially invented, and compiling html 5 from the flash authoring system is actually very logical, and flash CS5 will likely be the #1 choice for making html 5 canvas based content. Apple makes more money than Adobe, but they dont get content authoring like Adobe does. Neither does Microsoft for that matter.

What I am suggesting means that if a user who does not have a flash capable browser visits a flash site, the site could, on the fly, prepare an HTML 5 version for them automatically. This is not difficult, or particularly processor intensive, as it would only need to be done once for the particular platform. A "flash to html5" converter could reinterpret almost any flash site into HTML 5 automatically, so the legacy content would all continue to work without a hitch, and new content could be published directly to HTML 5. That is why HTML 5 is not the future. The future is..."who cares technology", IE the path of least resistance, lowest cost.

If I am an animator and it will take me 25 weeks to produce a cartoon in HTML 5 vs 2 hours in flash, there is no contest. If I can output in both formats with a 1 button publish, then there is no debate, not even a conversation about it. My animation will work on old browsers, new ones, iPads, apeDods and dewDads. THAT is the future, I believe. Whatever is cheapest, easiest, and gets the nerd junk out of the way so creatives can express without having to ftp the htp and mno the qrs. Html whatsit? Flash-a-who-eee?

There will always be a need for niche, customized software in spite of all the attempts by the drupals and nings of the world to provide an easy button because if something is too easy, it becomes nearly impossible to differentiate yourself from everyone offering the same product for free. So in this respect, the best language for the job will be the tool of choice, and right now the clear winner is OOP ECMA. All modern languages are ECMA compliant, and the others are dropping off because they are hard to use and clumsy in comparison, like Objective C, C, C++, Perl, PHP, etc. are the "olden days" and ECMA represents the modern languages like C#, Javascript and its growing libraries, Actionscript 3 etc, all of which can now be authored in eclipse. Again, path of least resistance for developers. I can write in ECMA languages for pretty well every platform, and they are all standard compliant, so the only difference is the compiler/player, which, quite frankly, I dont give a damn about. For me to publish our LMS in HTML 5 in two years, I likely wont have to rewrite any code, there will simply be another checkbox for "output to html5" and voila, done. Company saves millions, and I can concentrate on adding features instead of trying to comply with a non standardized language to rewrite everything...which is incredibly inefficient. ECMA is the "english" of the programming language world, and its already won. Javascript, jQuery, C#, and Actionscript 3 are all together on that front.

They used to say "content is king". I imagine that is still the case, and the amount of flash content out there that is in flash is massive, several orders of magnitude more than what is contained in the "app store". At the same time, only some of that content is video based and can be easily converted to HTML 5 for the iPad/iPhone. Its much easier to write a translation tool than to redo all that content, so that is most likely what is going to happen. Check out www.homestarrunner.com on your iPad for example. Those guys will NEVER spend the time and energy to convert 3 years worth of weekly flash episodes to HTML 5 manually, but a converter would take care of it instantly. The ONLY thing stopping a converter from being made is HTML 5 itself. The format simply isnt ready to handle the complexity required by that content to render properly, but you can bet the second it is ready, some free converter will be available and it will all run smoothly everywhere. For Steve Jobs and the iFamily's sake, that will hopefully happen sooner than later, otherwise many consumers will drop their iFamily product in favor of Android or whoever offers a full flash player because they can get all the app store games for free, as well as all the legacy flash content out there that will likely never be converted to HTML 5 manually. "If I can get "boob shake" app that Apple refuses to allow in its app store on Android for free without having to use iTunes or sign any kind of confining DCMA and basically remain anonymous...well, my iPod touch is going in the bin of old adapters and pocket pcs." says joe daily show fan.

Sorry about the long post, of course, but the issues here are complex and intertwined.

Sunday, February 21, 2010

The iPad vs flash issue is a red herring. The real issue is the iPad vs. the Keyboard and Mouse.

In a recent article shown to me by a co-worker, blogger and flash developer Dan Eran Dilger makes a case in support of keeping Adobe Flash technology off the iPad.

In the article, his chief arguments seems to be centered around UI elements such as mouseover, keyboard controls, and multiple mousebuttons so many flash applications depend on to function properly.

I would counter that the idea of slighting flash for supporting this functionality is backwards, instead, the argument should be leveled at the iPad for actively blocking this kind of functionality.

The fight of the iPad is not between it and flash, it is between it and humanity. It has thumbed its nose so to speak at the mouse and keyboard, and while multitouch certainly has much promise in adding significantly to the ways we interact with information, it is by no means an alternative for every user input device.

Further, flash is just a software development platform like C++, Java etc. The question isnt whether it will have multitouch and accelerometer support, the question is how will that become standardized across devices? Currently Apple is curiously vacant from Adobe's open screen project for example, and seems uninterested in a standardized approach to multitouch UI design outside of their own platform. This is shortsighted and disappointing.

Like Apple's "one button mouse" that looked like a hockey puck and every serious Apple user replaced the first chance they got with a real mouse, Apple is attempting to force users to interact with what is really the end users OWN content and information in a way Apple believes is the best, rather than providing end users with a pletora of tools and allowing them to pick and choose.

Personally, I believe Apple should jump off its "high horse" and simply support an external mouse and keyboard, and perhaps a small stand. That way, users could interact with the iPad like a normal computer OR use it like the tablet, depending on the context of the particular activity. That said, the list of things the iPad should be or should have is staggeringly long, so I'll cut it short there.

Apple, its not flash, keyboards, mice, or the internet that is being immature here, its you. You have some neat ideas but you need to grow up and share your toys.

Monday, May 4, 2009

XML Extensions for AS 1 and AS2

For those of you using XML and actionscript 1 and 2, I made this set of xml extensions that I use regularly and wanted to pass them along to help you and your projects that involve XML parsing, sending and loading etc.

Here is a quick list of functions and descriptions. Script and docs available for .zip download here.

getRootNode();
returns the root node and all its children(see docs for useage examples)

findNodes([searchName],[callBack Function])
searches all the node names and return them to a callback function as they are found.

getFirstNodeByName([searchname]);
returns the first node with the specified name in a set of childnodes. Use this when you dont know exactly where the node you need will be in relation to other nodes in the list, but you only need one node and its children for your specific function. You can use a loop to grab many of these as its a quick function that doesnt require a callback function.


getFirstNodeValueByName([search node name])
works as getFirstNodeByName but this one returns the nodevalue. Textnode or not. (I hate that nodes have to be textnodes in order to read the node value so I bypass that using a function called returnNodeValue I'll describe later.


returnNodeValue()
The XMLNode docs tell you that a node has to be a type "textNode" or type 3 or you cant use the basic xmlNode.nodeValue to grab the text in a node. Unfortunately loading in XML from anywhere generally is not that type, it all comes in as type 1. So I wrote this function to extract the nodevalue even if the type is not 3.


getTotalNodesByName([searchName]);
This returns the total number of nodes in your xml file that have the specified name. A handy searchy tool.


getNextNode([search name],[callBack])
works almost the same as findNodes except it returns an undefined node when its finished. Havent really found a use for this one yet.


findNodesWithAttributeValue([search name],[callBack])

works like findNodes but searches for a value attributed to an attribute anywhere in the XML.

findNodesWithAttribute([attribute name to search for])
Works as findNodesWithAttributeValue with just the attribute name


Enjoy! If you find any bugs or have ones you'd like to add just comment below! If my script looks lame or you have suggestions, again, comment below, I'm always looking for constructive criticism.

Make it a great week.

Sunday, April 12, 2009

My RSS Feed aggregator

Finally got my RSS feed aggregator working. Whats an rss feed aggregator? The little widget below reads a list of RSS feeds RSS from an XML file and displays the RSS feed news items from all the feeds in order of most recent to earliest. Theres a few of these out there, but mine is free for you to use, and has some interesting features. If you press the grey button underneath a specific feed name you toggle it on or off in the list. Pressing the red button makes the feed become "solo" or the only one in the list, and you can toggle that off and go back to your previous settings.







The "reset" button resets your filter feeds toggles as they are saved in the flash shared object "cookie" (to let your website visitors pick which blogs they want to keep up to date on and not have to keep resetting that)

You can popup the viewer here and see it resizes with whatever window you put it in. Working on adding custom colors/fonts etc.

I'll continue improving it, but for now you can view source and embed/tweak the above code to play around with it on your website if you want. Ive tested it with blogs from blogger, twitter feeds, and NING blog feeds. Known issues...turning off all the feed sources causes a weird display I need to fix, workaround is you just turn one back on. Also if you are on a slower connection try to let the feeds load before clicking buttons. I havent really built too much "idiot proofing" into this yet. This particular one is built in AS1, my next one will be in AS3 as I get time and guage the popularity of this app. Updates to come...Enjoy!

Thursday, April 2, 2009

Do I have to learn Actionscript 3? Is AS1 outdated?

Actionscript...1,2,3...they're all good! A biased opinion piece from an old hand at flash.

Executive Summary for CEO types:

Actionscript 3 is a good move if your company is large, well funded, and well staffed with low staff turnover. You have a good chunk of your budget put aside for R&D, and another good chunk for training and employee personal development, and process is important. Also customers don;t dictate how to run your company or what you are selling. They just trust you and depend on you to provide them with results and profit.

Actionscript 1/2 are great if you are effectively building your airplane at 30,000 feet or in startup/recovery mode. You constantly have to spin on a dime, retool overnight, and have relatively high staff turnover (staff last less than 5 years on average) and havent really settled into exactly what it is you do. You will make whatever the customer wants and on their schedule. The flexibility and lack of strictness in AS1/2 lend themselves perfectly to this, as well as the short learning curve for new incoming staff.

The essential differences


First of all, AS3 and AS1, while similar in appearance, represent two distinct virtual machines in the flash player. They are about as different as Java, C++, and Pascal are from each other. In fact, to send messages from a VM2 (virtual machine 2 / actionscript 3) to a VM1, you have to invoke the same communication as you would between the flash player and the containing HTML page, or java object or whatever. Suffice it to say, even within the code the two are strange bedfellows sharing the same containing plugin.


History
Actionscript 3 came about because Flash/Adobe are trying to compete with Microsoft and other "big" language platforms so they had to tighten up the rules to play in that space. They did a great job, but, in many ways, they lost the original appeal of flash as a kind of coding "sketchpad" where you could rapidly deploy prototypes, games, and interactivities for one off purposes.


Disadvantages of AS3 (from a business and practical perspective)

First, my personal perspective as a coder...
I have built apps in both languages with equal sophistication. As a coder, I find AS3 far more elegant and fun to work with, its less of a Kludge, and truly object oriented. I really, really like working in it, and I think as I coder I am more useful and "hire-able" being proficient in both.

In the following I will point out the potential pitfalls and objections to moving to Actionscript 3, but only to ensure companies move to the new technology without any misconceptions about the costs and real benefits.

Procedures and Housekeeping

AS3 requires a far stricter process, naming convention, and organizational set of rules and processes to work beyond 1 coder. There is no room for any flexibility in naming conventions, file hierarchy, or even root script file locations. File management is very complicated and requires a lot of housekeeping to keep everything straight. The end result is a cleaner, more scalable and robust product for sure, but if the project is under 2000 lines of code total, the housekeeping can easily outweigh the actual coding in terms of time and resources.

Comparatively, AS1 / Flash is relatively flexible. If a particular bit of code works, but maybe is inelegant or quickly written, the compiler will pass it. in AS3, the compiler is extremely unforgiving so a lot of time is spent finding "bugs" that aren't causing actual problems, but just represent inelegant wording or phrasing according to the compiler. (this is a highly simplified approximation of what is going on...but accurate nonetheless)

In fact, the language is now so complicated, that they had to invent another language called 'flex' that sits on top of it along with a lot of paint by numbers style components, in an attempt to simplify it to decrease the learning curve. Why build an entire set of classes, folders, and establish naming conventions when all you want is a silly banner ad that lets you click a golf club and hit a golf ball into a little hole...?

The converse of this of course is, if you are sufficiently able to reorganize your production team to handle the rigors of AS3, you will be more scaleable and capable as an organization, and ultimately your software will be more robust, and less dependent on one individual's idea of organizing things. This is an expensive thing to affect, can be worth while, and if your company isnt thinking about making software as part of its overall business model, well, thats like being any company that plans to deliver its product with no control over a key part of its supply chain. In short, scalability and process in software development is everyones problem, even if you make concrete tubes.

Stability
VM1 is fast, does most things you need in a production, has 12 years of evolution and bullet proofing behind it, and the VM2 still hasn't proven itself as truly faster than VM1 in all applications...actually in any.

I have also yet to find any instance where the VM2 actually outperforms the VM1 at least from the end user perspective. Certainly the VM2 is faster but the AS3 language demands it has to be. VM2 is, in this way, a bit like Windows Vista. The computers are faster, but the mundane tasks have actually seemed to become much slower because of all the overhead associated with a truly object oriented language.

I don't have any actual VM 1 vs VM 2 developer content statistics to quote, but I'm willing to wager that 90% of the interactive flash content out there is VM1.

Conversely, the best practices required by developers and the stricter language acts like a micro manager whipping your developer work force into shape, which again promotes stability, scalability and reusable code.

Why 90%? Well first of all, I'm not talking about videos. I imagine that easily the statistic for flash video on the web is the other way around, 10% swf and 90% flv/h4. Im talking about interactive flash content, or its primary "raison d'etre". I say 90% because if it was 100% VM1 3 years ago before VM2 came along, my guess is most flash developers at the time tried AS3, couldn't figure out how the document class worked, then went back to flash mx and kept working...then got hit with the recession and said...screw CS..im just sticking with what I know 'cause I gotsta eat.

On the other hand, many developers also tried AS3 in the flash dev, hated it, then tried flex. Flex didn't offer much originally because of the lack of components. Now with a few more components, its more palatable, but any developer who is ultimately responsible for performance of their apps knows that becoming dependant on a plethora of components built by everyone and their dog can lead to a lot of customer support calls that go very bad.

The other choice, VM1, means that you can deploy apps on a tried and true platform quickly and without a lot of housekeeping so you can keep your consulting rate low and know that all the code out there is yours, so you can be responsible for it.

So what exactly can you do in VM2 that you cant do in VM1? Precious few things.


Cool, useful effects
As long as you are publishing in flash player 9 or higher, you have full support of all the filters and transitions offered in the CS Suite of tools. That means blur, drop shadow, transitions everything...all available to you in VM1, although you might have to write in actionscript 2.


Coding Elegance
Actionscript 2 is kind of a kludge compared to AS3, but if you are thinking future, you can write in AS2 in very close in form to AS3, almost indistinguishably in fact.


Neato 3d Components
There are quite a few components built in AS1, but some really interesting 3d ones built for AS3. This is a curious one. Neither VM is as good of a 3d rendering engine as the major ones out there, and Flash will probably always be many years behind the leading 3d rendering engines in terms of physics, ray tracing, procedurals etc...because getting flash to do 3d is like trying to make surgical tools out of bananas...honestly.



Sort of possible but why ?

I ask you to compare Papervision 3d's latest doo hicky to any of the top game titles of today, like Unreal, Half life, Portal, Fallout 3, Bioshock..etc. or even Second life, which is basically a kind of a "platform" sort of. Even Google earth kicks ass over anything 3d in flash, even with the "optimized player". Again, bananas for surgical instruments.

Standalone Applications

With AIR, now you can make desktop applications with installers that run as a standalone in flash! Well, heads up sparky. You've been able to do that with AS1 for many years using programs like Screenweaver. And you can build those without requiring the end user to run a pointless "installer". Just double click the icon and run the program when you want, and when you're not running it, its not pervasively existing in tiny pockets throughout your massive maze of folders in the mysterious c and d drives.

Speed Advantages
Since the VM2 player is, in fact, much faster than VM1 in terms of computations per second etc, you should be able to see marked improvements in high end math applications, working with a lot of children classes that exist and disappear rapidly to form various effects, and procedurals like smoke, water etc. Well, in reality, the VM2, while faster than VM1 for this kind of thing, is still years behind more optimizable code like C++, Java, and processor array specific languages that do the big number crunching that again, flash will never hold a candle to or be practical for. It is fun to play with this, but in the real world business app, not worth investing in the learning curve or the cost of the latest CS4.

Mobile devices and Social Networking apps
Since VM 1 is a smaller, simpler player that ran very well on very slow machines in years past, and netbook computers and cellphones seem to be taking us developers back to those 800mhz days and downgrades to windows XP on the rise in spite of Microsoft dropping support for it, all the new bells and whistles in AS3 may not end up being supportable on the mobile devices. Developers who become dependant on the new components because they couldn't learn to build their own will be stranded until the phones and netbooks can support them.

Even the most successful social networking apps are still very simple, and don't even begin to scratch the surface of what a developer can do in AS1 or 2, so the need for 3 is still a long way off, and at the bleeding edge, if Second Life or some other real 3d engine came into open social, well, the papervision guys would be cut off at the knees over night.

Competing technologies
Microsoft Silverlight, Google Android, and many others compete directly with Flex and Actionscript 3 as platform development tools.

That said, none of the competitors can fit exactly what VM1 does, because that is what flash originally was, and what made it so popular. A very shallow learning curve on a simple app "sketchpad" where you could add fairly decent code to a bunch of pretty good graphics without having to go too code-nerdy with classes and methods and all that weirdness, and could focus on the graphics, animations, and fun stuff. It is an invented niche that flash VM1 still owns. No one else can touch them or compete, and it accounts for 95% of the interactive web games out there still, and they all are running very solidly with no sign of slowing down. Stuff I built in '99 in flash still runs just fine on my vista PC. I never did any updates, never had to rewrite anything. So as a VM1 developer, you essentially have no competing technologies to contend with.

Developing countries
As developing countries come to the table with their massive numbers, developers who have only had access to older flash development environments and definitely cant afford to keep up with Adobe's latest and greatest corporate edicts will again continue pushing out VM1 content for many years to come, and have even less interest in joining the party ranks of Adobe's VM2 crowd.

Business Case and Cost
Even if their developers really want to move to AS3, for flash dependent business there is a heavy price to pay. Some businesses have invested in the VM 1 heavily (whether they realize it or not-many CEO's probably don't) and the cost of moving to VM2 in terms of staff training, turnover, upgrading machines, changing general production policy, etc. may keep them away from it indefinitely, particularly if there is no business case that is compelling enough for them to move over. Trying to explain to a CEO that a number after the letters VM is worth 300,000 in staff turnover and training and platform rebuilding just to keep up with the Joneses when, essentially, it "ain't broke" is a hard sell for any nerdforce.

Adobe itself
Since Adobe managed to come up with "vm2" in the first place, what is stopping them from suddenly creating a "VM3" that only supports "Actionscript 4" and so on. Even though it seems crazy, it is possible that Adobe's head is so far up their own butt that they would actually do this. AS3 is already 3 years old now, VM2 has been around for a while, and devices continue to evolve in strange and unpredictable ways. Adobe has not indicated this sort of plan, but I dont think anyone but the most naive would assume that VM2 is the last of the VM's.

Nevertheless, and I can't stress this enough, as a developer you SHOULD learn AS3, become very good at it as a matter of professional learning. Even if you end up doing most of your work in AS1 or 2, you will be a better coder if you learn 3, and learn it well. It is a lot of fun to work with, and if Adobe is really stupid, may be the only thing you can build for in 2-3 years.

But given the fact that AS1 content constitutes 90% or more of currently being made (not to mention the huge amount of content made over the past 15 years) flash interactive content out there, the idea of Adobe dropping VM1 from the player is extremely unlikely in the foreseeable or even long term future. As VM2 gets bloatier and bloatier with more and more components and add ons, VM1 will remain a small, tight and efficient player that continues to do what it does very well.

Thanks for reading, I hope it helped. Please add your comments and particularly your criticisms below. I cant learn if you dont tell me why Im wrong!