CoderHump - Latest Comments in Making Flash The Console For The Web

Re: Making Flash The Console For The Web

Jeff — Fri, 10 Jul 2009 10:25:40 -0000

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

Re: Making Flash The Console For The Web

Dale Beermann — Thu, 09 Jul 2009 13:39:24 -0000

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.

Re: Making Flash The Console For The Web

Jeff Johnson — Wed, 01 Jul 2009 17:11:02 -0000

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 :).

Re: Making Flash The Console For The Web

Jeff Johnson — Wed, 01 Jul 2009 17:02:08 -0000

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.

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 17:06:08 -0000

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

Re: Making Flash The Console For The Web

John Dowdell — Fri, 26 Jun 2009 15:38:20 -0000

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

Re: Making Flash The Console For The Web

Jeff Tunnell — Fri, 26 Jun 2009 15:17:32 -0000

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

Re: Making Flash The Console For The Web

Tony Richards — Fri, 26 Jun 2009 14:55:40 -0000

"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.

Re: Making Flash The Console For The Web

wonderwhy-er — Fri, 26 Jun 2009 14:31:24 -0000

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...

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 14:06:29 -0000

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.

Re: Making Flash The Console For The Web

Iain — Fri, 26 Jun 2009 13:25:54 -0000

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.

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 13:10:05 -0000

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

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 13:08:52 -0000

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.

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 12:49:43 -0000

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.

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 12:45:53 -0000

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

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 12:44:54 -0000

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....

Re: Making Flash The Console For The Web

Ben Garney — Fri, 26 Jun 2009 12:42:51 -0000

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

Re: Making Flash The Console For The Web

Iain — Fri, 26 Jun 2009 12:41:53 -0000

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

Re: Making Flash The Console For The Web

wonderwhy-er — Fri, 26 Jun 2009 12:34:47 -0000

I think those who want already find some things like http://mochiland.com/articl... 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.

Re: Making Flash The Console For The Web

Troy Gilbert — Fri, 26 Jun 2009 11:59:13 -0000

@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.

Re: Making Flash The Console For The Web

Troy Gilbert — Fri, 26 Jun 2009 11:44:42 -0000

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.).

Re: Making Flash The Console For The Web

Troy Gilbert — Fri, 26 Jun 2009 11:37:26 -0000

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.

Re: Making Flash The Console For The Web

Troy Gilbert — Fri, 26 Jun 2009 11:35:08 -0000

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.

Re: Making Flash The Console For The Web

Troy Gilbert — Fri, 26 Jun 2009 11:33:09 -0000

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!

Re: Making Flash The Console For The Web

Squize — Fri, 26 Jun 2009 10:58:12 -0000

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.