Making Flash The Console For The Web

One of the main reasons PushButton Labs chose to use Flash as our first platform this time around was its ubiquity. I think it is proven that it is good enough to make great games, and they are getting better all the time. I love the fact that we can make a game one day, then release it to a world wide audience of a billion or so users the very next day. I have done a presentation on this, and that is more than ALL of the gaming consoles audiences in history COMBINED! I love that.

On the other hand, if Adobe were to include some form of hardware acceleration, there are new ranges of games that could be made. I am a game designer that just wants to make FUN games, so I do not care if we have enough 3D power to make uncanny valley, sweat rolling off the football player characters, but I would not mind enough power to make a decent flight simulator.

I think a nice compromise would be for Adobe to provide a level of hardware support that might reach 50-70% of the installed base. Since Adobe can keep stats on the players, they would be able to tell developers how big the installed base is. Then, as we are creating games, we could make the business decision to go for 1BB people or something smaller, say 500MM.

What I don't want to see is an arms race of technology that is a constantly changing bar requiring tons of QA and product testing for many different hardware configurations. We've all done that in the PC market, and actually still continue to do do today. I don't want to go back.

-Jeff Tunnell, PushButton Labs, Managing Partner

I have to agree with Ben in regards to hardware acceleration. For Jeff, Troy, and Ben, you may be able to guess why. Sharendipity was originally implemented as a Java applet, with hardware acceleration via OpenGL. All other Java issues aside, when you're looking at casual games then you want a unified user experience. We couldn't provide that in Java with OpenGL, no matter what. And we spent all of our time trying to figure out why Sharendipity wouldn't run on machines like my dad's laptop.

Jeff, you touched on this as a bit too: if %30-50 of the install base either can't run or has an app running at a different speed than the other %50-70, you have a lot of problems. Imagine if even 30% of the people on Kongregate couldn't run most of the games there (and why doesn't Kongregate support Java applets then, or Unity, or...). If there's a way to provide the same user experience to everyone, that's great, but I don't know how it's possible when you're throwing hardware configurations into the mix. Differing CPU speeds by themselves provide enough issues for game developers (as Troy said, to be developing for XNA is in many ways a lot easier than developing for the web/PC). And if Adobe goes down the path of having different versions of Flash (accelerated or not) or supporting different hardware configurations, we run into the Java problem all over again. This is the worst case scenario.

I think that one of the main reasons Flash has achieved the ubiquity it has is because of the unified user experience. If you're targeting %50-70 of Flash's install base, then why not go with something like Unity which will be more accepted by the demographic you're developing for and provides the functionality you need?

As for the tools, well Ben and I have said our piece directly to Adobe. Flex Builder (Flash Builder...) needs to be 100 times better. I've reiterated it to every Adobe evangelist I can find. We just need more people on the bandwagon.

Ben, great post.

I disagree with your analysis as to why Flash has achieved ubiquity due to a unified user experience.
I would argue that Flash has such a large user base because they were the only viable platform for RIA during the ".COM boom". Java, historically, has been clunky and slow until more recent iterations. You can never make another first impression, and most people's first impressions of Java Applets were not good. The first Applets I used were terrible. This always left a sour taste in my mouth for Java, which I still feel today (unjustified for sure...as Java has matured considerably). On the other hand, my first experiences with Flash were with Flash 3 & 4, which were "great for their time" (aside from "flash intro hell").

I have no data to go with, but I would venture that ANY computer that can run Flash 8+ and provide the same "user experience" that I have with Flash on my PC, then they have the capability of supporting basic 3D acceleration via OpenGL.

I am not a game developer (right now...), I don't want 3D for games (right now...). I want it for development of Computer Based Training. I can do some great things in 3D with current software engines like Away3D...but hardware accelerated OpenGL support would enhance what I can do greatly. I would also guess that supporting OpenGL 1.x would actually make a MORE unified user experience for my customers.

I think the user experience is dependent on the developers. If I develop a flash application with thousands of animated vector graphics, then it's going to provide a rotten experience for everyone. That same paradigm must accompany 3D content.

Flash is installed on hundreds of millions of computers. Why not inject a small piece of code to identify what 3D acceleration capabilities are available (during install or upgrade) and report that back to Adobe. That way they can gauge how much support they would have and make a decision based on the analytics received.

Just my 0.02

I agree with Jeff (mainly because my name is Jeff as well). Enough 3D acceleration for modest 3D graphics(openGL 1.X anyone???) and as much performance consistency as possible.

The most important thing to ask of Adobe are things that are impossible (or highly inefficient) for the community to provide. For example, the community can't provide a faster virtual machine, native per-pixel collision detection or improvements to the AS3 language (Haxe being the exception).

The community can provide common game components such as the oft-mentioned high score table, game frameworks, etc. Sure, it'd be great if the talented engineers at Adobe put their efforts into that, but let's be honest: they don't make games for a living. Do we really want community components for games built by folks who don't necessarily have experience making games?

In regards to collision detection, I kinda split with Ben on this one: in *most* games (going back decades), collision primitives have been distinct from the rendering primitive, not only for performance reasons but also for the general abstraction of the game mechanics from the visuals. That being said, per-pixel collision detection is a fine example of something very useful generically (in many situations outside of games as well) and something that can be orders-of-magnitude faster when natively supplied by the Flash Player as opposed to being written in AS3 (and this is coming from someone who's most popular blog post is on a per-pixel collision detection class for AS3).

Sound is a great example of where the Flash Platform needs lots of love and attention that simply can't be done well above the VM (in AS3 or the bytecode). I don't necessarily have to see MOD support specifically, but the underlying performance-intensive bits of MOD support should be built into the Flash Player (high speed multi-channel mixer, pitch shifting, programmable audio effects ala shaders, etc.). MOD support would then just be a data parsing and logic exercise (as would be XM support, et al).

Hardware acceleration is good. There's a much larger percentage of the installed base with video cards capable of *some* hardware acceleration, mainly in blending operations. This is tricky, though, as it has the potential to degrade the "looks the same everywhere" aspect of Flash. I think the Flash team is moving in the right direction on this front.

I don't think we need threads. They would add a great deal of complexity to the VM (so I'm told and believe) and would make performance far less predictable across hardware (particularly when you start thinking about mobile platforms). Most of the tasks that multiple threads are used for in games are already multi-threaded by the VM: network and rendering. There's probably a lot of performance that can be gained in those areas by leveraging multiple cores, etc., many optimizations that would not be (transparently) possible if the VM ran multi-threaded code.

I agree with Ben on DRM: it's a losing battle (i.e. a distraction) to build it into the Player proper, but the performance-intensive supporting functions would be nice to have (e.g. fast crypto libs).

And my biggie... better tools! Flex Builder seems unnecessarily focused on bizapp RIA makers, not general AS3 developers. For example, why must the Embed metadata bring in symbols with a Flex-based class as opposed to whatever their natural (original) library class is? Why is it virtually impossible to use Flex Builder's editor for an otherwise Flash-based project? Why is there still two distinct (at least at the user level) compilers: Flash and mxmlc? Why can't Flex Builder do slightly better code completion on par with what we've seen in Visual Studio for at least 10 years? Why can't I "inspect" a SWF with official Adobe tools (when it's near trivial to do so in AS3)? IDEs, compilers, linkers... these are largely "solved" problems in the world of software yet Adobe seems to be starting bag at the beginning and working toward all of the advancements folks enjoy over in C# (or even Java) land... and those are with far more complex ecosystems than Flash!

Great post, Troy. I totally agree with you on all of this. Thank you for posting.

There seems to be a theme here of "Don't worry, there's a 3rd party way to do that already", but, I'd kinda like some first party support.

Games are finally on the agenda, and to be honest I want as many first party goodies as we can get after years with none at all.
If we ask for 50 things, and get 25, we're still better off than we ever have been.

So yeah I'd love to see native MOD player support, even if the tracker for making the songs was an Air app knocked up in a couple of weeks.
Like I've already said I'd love to get a Hi-score table component that I could just drag onto the stage and skin easily. I may personally never use it, but there are a lot of newer devs who would, it would save them a lot of time, the design wouldn't be wildly different for every game and having a standard way of doing things isn't a bad thing even in games where we all fight to stand out.
There are a lot of hoops to jump through with as3, so any first party help to that so people can focus on the gameplay rather than the top and tails can't be a bad thing.

Ok, these could be classed as "nice to haves", but that's the whole point. Let's not just say we want the fundamentals for fear of those being ignored due to people asking for pretty components. Let's ask for it all when we've finally got Adobe's ear.

PushButtonEngine's business model is based on Flash NOT including many gaming features, so maybe a little bit of a vested interest here?

We give the engine away for free.

We want to monetize by making games ourselves - which I assume you are OK with - and by selling kits written by third parties to make it easier to develop games. Like a platformer kit or a card game kit. If you can persuade Adobe to make that product and it is good, we'd be first in line to buy it.

Troy said (very nicely), "The community can provide common game components such as the oft-mentioned high score table, game frameworks, etc.". And they are! There are a bunch of great libraries out there. That's WHY we wrote PBE the way we did. It's designed to make it easier to leverage those great libraries. Or built-in Flash functionality.

Things that Adobe does to benefit those libraries benefit PBE, sure. They also benefit me when I am trying to write a game. They also benefit the guys writing non-game RIAs. They also benefit you when you work with the platform.

Oh. When reading the post, I didn't know you were affiliated with PushButtonEngine. (For the future, it's good to clealry disclose... provides context to readers.)

tx, jd/adobe

Good call. I allude to it at the end but I could probably be clearer.

Ok I'll give you a break this time. Just for the record I have downloaded PBE, looked through the code and read all the docs. It is some clever stuff with some nice ideas that I have borrowed some of for my own framework. Grunts is also an amazing looking game and I wish you the best with it. Just trying to figure out why you would argue against adding features that would help less-experienced developers. In the AS1/2 days flash was a great starting point for a beginner game developer - not so any more. This is all to do with the language being static and unforgiving now. Having thought about it some more, I think the best thing Adobe could do would be introduce an optional dynamic mode to AV2 that acts more like AV1 - e.g. make things like parent.gotoAndStop() work again.

Hmm actually you can set AS3 to not strict mode which will allow doing what you said. I mean parent.gotoAndStop() but I think I know what you mean as there are some other examples where it is impossible to use AS3 like AS2 was used. Like child.newVar=something; is now not possible on not dynamic classes or even system being kind of harder to use in simple cases. I think it could be solved tough with better code hinting from one side and some aspect programming on other side. Tough I doubt that Adobe will go towards aspect programming anytime soon with all that ECMA4 problems...

I think you can either have a system that is good for building industrial strength code OR you can have a system that is super easy for beginners to get into. TBH AS3 does a great job of straddling that line. But it is definitely trending towards "real" software development and away from easy-to-use-for-beginners.

Really good tools go a long way towards helping make stricter languages more palatable. Because the language has more strictness, more can be inferred by the editors and tools, making them more effective.

I've seen this evolution play out a lot of times in scripting languages. I don't know that there's a magic bullet that satisfies both sides of the coin. And if the basic language is good enough you can throw a simpler scripting runtime on top of it to bring it back around to the less skilled coders.

"I've seen this evolution play out a lot of times in scripting languages."

We've seen this evolution play out a lot of times with everything, not just scripting languages, not just game engines, not even just in software.

You simply cannot add power and flexibility without also adding complexity.

AS3 so far has indeed done a fantastic job of straddling that line.

I think those who want already find some things like http://mochiland.com/articles/introducing-mochi... and it shows that you or me can solve it and make widely available if needed. But no one except Adobe can make some stuff that still everyone without exceptions needs and that's what they should preoritize over stuff like bone, 3D , physics and leaderboards....

Yeah game relates stuff would be nice thing to add for non programmers and beginners but it is not first thing in the list that should be done. You even mentioned your self that easy to restyle components overall is more important then just leaderboard.

"Do not listen to the people who want per-pixel collision primitives. For, lo, they are lazy as hell and do not realize that it is a bad idea to tie collision to visual appearance. Every serious game from Super Mario Bros on down implements collision using bounding volume checks behind the scenes. Many games use good collision libraries, which are more easily extended and debugged than native code in the Player."

- Dude you could never make a game like Fancy Pants Adventure without using the view for collision detection. You're just plane wrong on this one. Bounding box or polygon collisions leads to some very square games. Even Unity3D uses the artwork's geometry for collisions.

I think his main point was that it's not a priority. There are libraries for that like CDK already and real problem is that AS3 is not fast enough to compete with built in functions. And that's probably the reason things like that are demanded from Adobe. Because community and third parties can't do it right now... If it was fast enough it would not be a problem I think so that's on what Adobe should concentrate first.

Exactly. Nicely said, wonderwhy-er. What's there is obviously good enough, because Brad Borne was able to write Fancy Pants on it. So maybe it is not the most critical issue for Adobe to fix or spend a bunch of time working on.

Thanks, Ben. So, would I be on-track here, with this list of requests?
o no further rights-management offered by Adobe;
o less hardware acceleration, to keep devices more equivalent to each other;
o no gaming frameworks from Adobe;
o no per-pixel collision detection (which is in Player already, see Mike Chambers this week);
o consistent cross-device performance (without options for hardware acceleration);
o some additional type of tooling.

Did I summarize accurately? If so, I think I'd get pushback like "Don't use acceleration or frameworks or services if these are not desired." How can I better get across the idea?

tx, jd/adobe

Mr. Dowdell,

I don't think it would be too much of a stretch to ask for OpenGL 1.4 or 1.5 hardware acceleration capabilities from Flash Player. I would venture that at least 80% of your userbase can support this, probably more. I know that it would be a massive benefit for me (not doing games, doing online training for the military and utilizing basic 3D models for teaching how military hardware works would be a huge boon). Right now, my IT manager is pushing Silverlight over Flash and we are doggedly going back and forth about which is better. My argument is for ubiquity, his is for speed of coding and features. Cmon...even the playing field a bit :).

I think Ben's main idea is "don't spend resources on these items *until* these other items are fixed/improved." Sure, in an ideal world we wouldn't turn up our nose at more hardware acceleration or frameworks or services, but we all know engineering resources are limited. Don't spend those precious resources on things the community can provide (even if it doesn't currently). Spend the resources on things that are *impossible* for the community to provide.

Thank you, Troy. I was trying to figure out how to best put this, and you've got it exactly. :)

Sorry, I'm not sure I can yet summarize this accurately to others.

First you said "Please make Flash into the ultimate console for the web and mobile devices," but instead of learning what you think that might be, there were a number of things you didn't want. There was a request for "consistent performance", but I'm not sure in what environments, with what metrics you saw the key difference. There was a request for "excellent tools", but all I know of what you're seeking is "Flex Builder is not that great". I'm not yet sure how to persuade others to help work to what you want.

Maybe I'm tired, sorry, but can you summarize, into something others can unequivocally understand in a sentence or two? Thanks.

jd/adobe

Thanks for coming by. It's good to see Adobe folk participating.

You're totally right, I focused on negatives more than positives. At root what I am asking for is "make sure that the basics work really well, because once you have those 3rd parties can build user-friendly libraries on top of you." Like, when you develop for the XBox 360, you don't get a game engine, but you do get a graphics API that is reliable, you get a minimal sound playback system, you get some very minimal input routines, you get a great compiler and IDE, and some other tools. And on top of that people build lots and lots of great games.

So in each category I touch I am trying to say, don't do a bunch of fancy stuff, just give me something basic that works really well and that I (and others) can build on. Or in some cases, don't do it at all, it's not worth a lot of brain cells.

If you want me to go deeper, please drop me an e-mail and we can have a longer more detailed conversation. ben dot garney at gmail dot com. I want to work with you guys to make things better.

I agree with the above, but also FIX THE BUGS IN SOUND and give us a sound.pause and sound.resume. Gamemakers should not have to make their own solutions to that. And give us easy keycode lookups. Keycode.A should return the keycode for A, I should have to look that up or use a 3rd party library.

So far sound has been OK for me. Flash Player 10 is a big improvement. I want the runtime to be fast enough I can write my own mixer and not have to care about their audio features. I think it is pretty close now.

I just want Flash games to not suffer from massive, unpredictable hitches in frame rate and input responsiveness.

It needs to be possible to implement a version of Tetris in Flash that doesn't turn into a game of chance after a few levels before it can be considered a viable platform for anything that requires any level of precision in input timing.

I don't know what needs to be done to fix this, but I assume it's low-level enough that it falls to Adobe to offer a consistent solution.

Don't care about 3D.

To be fair, there is a great deal of framerate hitches and input responsiveness caused by the browsers. While there is definitely some improvements Adobe could make at the VM/Player level, I've found the browser to cause the most headaches in these two areas.

I wonder if that's the real benefit of fullscreen with input. Not the fullscreen part, but that it would let you play the game w/o browser screwing it up....

If you treat the GC right, it will treat you right. I'm actually writing a book on video game optimization, and I just finished the chapter on dealing with garbage collectors and managed languages like AS3.

(To be fair, there are some things Adobe could do to make it easier to do game memory management. But that's for another blog post.)

i fully support this sentiment

That was meant for Ben, misreply failure!

Heh need to disagree there. While it may not seem crucial from an architecture / code deep side, I think there are a lot of places where vectors are still relevant and useful! The Flash IDE's import could definitely use a bit of polish, I think Flash CS4 was a good first step in that direction. :)

I stand corrected. :) Thanks for weighing in, Tim.

And... Adobe, please make importing assets from other tools like Illustrator or Photoshop work like a charm. How many iterations of Creative Suites will it take you to reach the proclaimed roundtrip of asset creation? Flash Catalyst is just a very little baby step... we need more than that!

See, I don't view that as very crucial. I guess it depends on what you are doing. But for our games, 99% of the art is just PNG sprite sheets from the artist. They render faster and look better than equivalent vector art. And we don't use the Flash IDE. So I'd rather Adobe spent time making Flex Builder really reliable or having a better compiler than doing art roundtrip stuff like that.

Bear in mind: I am a programmer so I have certain biases. :)

A year ago, I would have agreed with you whole heartedly, Ben. But in a few recent projects it has become abundantly clear that there are some huge advantages of using MovieClips from Flash as opposed to sprite sheets. A good Flash artist (i.e., one who knows how to get the most bang for the byte out of Flash animations) can do incredible, *flexible* animations that take orders of magnitude less space to store as vectors in a MovieClip.

Absolutely, pre-rendering these MovieClips to bitmaps can make huge performance differences and I wholly advocate it. But I love the fact that an artist can hand me a SWF of an object exploding that I can just add to the DisplayList and "play"... if the artist decided to include bit of debris flying off, or a 10 second vibration before exploding, I don't care. And the bandwidth/memory usage doesn't suffer for it. That's flexibility you can't get with filmstrips.

Besides, you can always put a bitmap on each frame of a MovieClip and get the equivalent of a filmstrip without having to have any particular logic in your filmstrip player (such as horizontal vs. vertical stripping, looping, re-using frames, etc.).

Between you and Tim, I can't argue this point. Well put. :)

Sounds consistent tough I can't stop but to throw some comments.

Firstly I do agree that Adobe should have their priorities straight and first thing is probably AS3 ans AS3 compiler. We do need generics, multi threading (there are mobile phones CPU's that are multi cored coming out this or next year already... Not even mentioning larger devices) and really better compiler to bring AS3 to Alchemy and VM built in functions speeds.

With DRM and Game API's I completely agree. We already have myriads of hosting, engines, libraries and other solutions for those so it's not that it's a priority that much... Tough may be we lack tools for not programmers for those so that's where it may be is tricky.

But with Video cards... I can't really agree with that... It is yet another thing community can't do and so it is something Adobe should do eventually. You mentioned that it is important to have consistent and comparable speeds on all platforms including mobile phones. I do agree with that but does it mean that we don't need GPU support? I thin not. May be we don't need high tier AAA games aimed GPU support but netbooks and even mobile phones have low or average performance GPU's now days that can run games like Quake 3 on them while Flash only got to level of Quake 1... HTC G1 has processor with built in 3D features, iPhone has separate GPU, Palm PRE has separate GPU, Nokia 810 has GPU and even Nvidia has made GPU especially targeted on mobile phones. So I can't agree with you completely on that... It's something that should be prioritized too as I know many that switched to Unity even tough it is still kind of rough on the edges... And they are growing big... Probably in 2D games Flash will still win but in 3D it just looks humiliating if you compare it with what people do on iPhone, G1, Palm PRE while I have lags on my more powerful notebook with Flash... Boy there are even OpenGL+JavaScript projects there like V8-GL and Canvas 3D...

Wow, big comment. :)

I think better compiler is really important (see my post on HaXE and Adobe). Generics would be cool. I think threading is not a big deal. Why not do a threaded rasterizer if you are on a multicore system? Flash spends a ton of time in the rasterizer. As opposed to letting people write and control threads... Can you imagine if every Flash ad spit out ten threads that didn't work right cuz the coder was an idiot? True coroutines for cooperative multithreading would be nice, but I think having threads in the web player would be a bad idea. Maybe a good idea in AIR.

For 3d... sure, giving us some basic accelerated 3d would be nice (and a big improvement from where we are now). But the whole idea of a console is that it is consistent. All PS3s have the same capabilities. All XBox 360s render the same speed. I think Flash would benefit a lot from picking some level of performance and guaranteeing it across all devices. That means on some systems (with bad drivers or minimal GPU) running the software rasterizer. Sure, new netbooks and high end smartphones have ok (or even good) 3d, but I want to write Flash games that can be run right now, not in five years when the new netbooks and phones are the low end. And I am sure that Adobe will end up doing more 3d support than I personally would use in a shipping game because 3d is sexy and you can do nice things with it.

But good art looks good even when you have a primitive renderer. And games are fun even if they are 2d. And if everyone can play your game, you'll get a lot more sales/players. I hope that people don't overlook that.

I actually think about banner problem a lot lately. I think there are some interesting ideas that would solve that problem of performance hogging Flash sometiems does. Firstly some externally(HTML params) or internally adjustable parameter that marks Flash as executable when off screen and not executable so that apps that need some background server communications or something will have it and banners who don't will not be executed while not shown.

And another thing is some kind of performance profiler + limiter. Would be good firstly to be able to get something like amount of operations/processor time your Flash makes per frame. And the secondly would be good to have some kind of limiter again either internal or better external that limits amount of operations/processor time Flash can order from CPU per second. So then sites can set this limiter to say 1% of CPU and by this way enforce performance limitation on to the developers.

And that would also solves your performance consistency problem in some way. It just that I don't think that Adobe, you or me can say "for now we target 2Ghz single core computers without GPU" for all Flash platform. It's not for any individual or company to decide but for each separate project developer separately for their projects. So you can provide consistency on your project/site/network telling that all "2Ghz single core computers without GPU" and up will work fine while someone else will target "2Ghz dual core computers with 32Mb GPU". It's Flash games portals who are consoles of the browser not Flash platform. Flash is only a tool to make games for those portals/consoles.

I think that is a promising direction.

Yes, indeed. I'll sign a petition if you have one. :)

Wow, you manged to single out nearly everything I posted at Mike Chambers blog as being on my wish list as things you thought were sucky.
It's like we were separated at birth :)

Thank you for taking it well. :)

I suppose if we ever meet, it will result in mutual annihilation and a quanta of pure energy being released. ;)

Seriously, though, I think it's really exciting that Adobe is starting to look at gaming more seriously. They are smart guys. If they can make it a goal and focus their culture on it they will do a fantastic job (and it will not matter if that job looks like what you proposed or what I am suggesting, cuz they will do a good job).

Meanwhile, all we can do is cheer them on. ;)

I'm not sure if I find it exciting as such, more overdue ( Yeah splitting hairs, we're like brothers now, it's allowed :) ).

Unity still makes Flash laughable in comparison as a gaming platform, and I can't see F11 no matter what they throw at it, as being able to bridge the gap too much ( And before anyone throws penetration in my face ( tehehe ), sheer volume of numbers is not the same as a good gaming platform ).

I know you're not won over by something like say a hi-score component, but things like that shouldn't have to be left to third parties, no matter how good they do it ( I've had to code more than enough in my time, and it never gets any more fun ).
A skinable hi-score table would at least have been a bone to game devs who have had very little in such a long time. There are only so many scroll bars a person needs.
Same with the pixel perfect collisions ( Don't worry, I'm not going to try and defend every point, things like built in path-finding, physics and AI I've seen requested are just a bit mental imho ). as3 has raised the entry level for people to come to Flash. It's now a pretty much full blown programing language, rather than as1's scripting language.
Let's make life a little easier for people coming to Flash with no previous experience, rather than pushing it into more of an elitist club of oop cleverness. It shouldn't be so hard to make a preloader using Flex for example, it doesn't help any one. Movieclips have been crippled too, and they're as much a part of Flash as it's possible to get. And for fear of getting flamed, even getting a button up and running is a lot more effort than perhaps it should be for such a core part of what Flash does.

On the other hand, a better compiler is a given, esp. after the whole Alchemy thing has shown just how lacking it is now. Also little simple things, like being able to get info on how quick the computer is the game is running on so we can scale things in real time ( 486 ? ok, only 10 particles for you ).

One last thing, if you're running a couple of parallax layers on a 600px wide screen with a handful of sprites, your whole life shouldn't have to grind to a halt for a week whilst you use the most obscure tricks to keep that frame rate up, not when I can nip over to the Unity site and walk around a 3D island without it even breaking into a sweat.

@Squize: "And before anyone throws penetration in my face ( tehehe ), sheer volume of numbers is not the same as a good gaming platform."

Theoretically, no, but from a practical perspective the penetration of the Flash Player is absolutely critical in this discussion. If it wasn't, then we'd all just go use XNA (where none of these problems exist).

I don't think Flash should strive to be a good *all purpose* gaming platform, like the Xbox360 in my living room. I think Flash should strive to be a good *web* gaming platform. And while these two things are converging, we have many years before we'll stop making that distinction.

It's a losing battle for Adobe to try to compete with Unity, just as it's a losing battle for Unity to try to compete with Adobe. They have different goals, and largely different user/developer bases. There is definitely some overlap, though Unity still suffers from the "it costs money" problem. ;-)

@Squize: "...things like [a hi-score component] shouldn't have to be left to third parties, no matter how good they do it..."

I don't understand this argument. Why not leave components like this to third parties? High-score components more often than not hook into a backend, one managed by a third-party. Most game developers of any significant skill would not find building the high-score component to be a difficult part of the process, and I don't see what a user (or developers) would gain by having a "common" high-score component.

In fact, I'd see Adobe giving us a skinnable high-score component as just what you say, a "bone". I don't need bones, I need meat! I'm not looking for more Adobe handouts... the gamedev community *made* the Flash Player ubiquitous long before web video did, it's been a long time coming that they catered to this critical part of their audience.

@Squize: "It shouldn't be so hard to make a preloader using Flex for example, it doesn't help any one. Movieclips have been crippled too, and they're as much a part of Flash as it's possible to get. And for fear of getting flamed, even getting a button up and running is a lot more effort than perhaps it should be for such a core part of what Flash does."

I absolutely agree with every one of these points. It boggles the mind that things that were damn-near-trivial in Flash even *before* it had a virtual machine would become difficult-to-the-point-of-impossible with a sophisticated language like AS3.

Excellent post Ben! Bravo! *slow clap*

Thanks for the support, guys. :) I am confident Adobe will get this figured out in time.

Right on, Ben! I'd sign my screen if it would help.

Well said. But... I can't help but associate the last bold sentence with something like "will code Flash for food" ;)

Hahah... Right now that is about where I stand. :P But I'd like to move up to gourmet from Ramen...

Ramen is a mandatory part of any startup!

Well said! Signed twice!

Agreed 100%!

Right on, signed!

Well said. Bravo!