Not too long ago I posted about my desire for a game framework that was as useful as the frameworks enjoyed by the whole “web 2.0″ crowd. Call it envy, if you will. Those web 2.0 geeks have great toys to play with. The concluding paragraph of my post pondered, “Maybe I shoud just shut-up and start using Flash…” Well, I did.

Stop what you’re doing right now and go to OSFlash. It’s the home for open-source software devoted to all aspects of Flash development. You’ll find tools for creating assets (vector art, animation, slide show wizards/convertors, etc.) and you’ll find tools for creating code (IDE’s, compilers, build systems, decompilers, etc.). You’ll find instructions for how to build an entire toolchain without touching a single proprietary tool or anything with Macromedia’s or Adobe’s name on it. So that quashes my whole “it’s proprietary no matter what Macromedia leads you to believe” complaint.

My second complaint was the feature set of Flash, mainly performance. The rendering engine in Flash is fairly specific, based initially around vector artwork. But all you have to do is check out the most recent official Flash Player release, version 8, to see that Adobe is paying attention. They’ve added the fundamental building block of 2D gaming: raw access to a linear frame buffer. The new BitmapData object has optimizations for bit-blits (CopyPixels), scrolling and — shock and horror! — blend operations far beyond the standard alpha-blending. And it’s all nicely accelarated in assembly under the hood. And there’s now an option for bitmap caching which even speeds up vectors as well as helping the develop do trivial double-buffering of rendering.

And, if that wasn’t good enough, Flash Player 8 has a much faster virtual machine. And all of this gets better: the version of the player currently in public beta, version 8.5/9, is even faster in both the virtual machine and bitmap areas. And the nice thing about the Flash Player is that your code gets faster without you having to do anything — it’s like having Adobe ship out a new video card to all of your customers once a year!

Are you looking for a ubiquitous computing platform? The Flash Player is more widely distributed than Java, Quicktime or Windows Media Player, so it’s technically a more universal platform for video than any codec (now you know why YouTube and Google Video use Flash). And, considering the compatibility issues between web browsers, it’s actually the only true write-once-run-anywhere application platform in the hands of the masses.

That’s right, the masses! Some version of the Flash Player is installed on 95%+ of web-enabled devices. Note, I didn’t say “PC’s”, I said web-enabled devices: smart phones, PDAs, settop boxes, video game consoles, handhelds… And 85% of them are nearly up-to-date to the latest! As of December 2005, 3 months after the release of Flash Player 8, it had 45% market penetration. If the trend follows as it has for the 7 previous versions (and if you view a graph of the version penetration, you’ll see that the adoption trend has been nearly identical with each new release), the latest player will reach the “ubiquitous” 85% market penetration by the end of summer 2006. If version 9 releases on schedule, it’ll reach that penetration by this time next year. And I would fully expect version adoption to accelerate as broadband reduces download time and web users become generally more savvy. (BTW, download size for the latest player is still in the ballpark of 1MB, I believe).

And it’s not just for the web anymore, either! While you’ve always been able to wrap your Flash file in a “projector” to create a stand-alone executable, it’s gotten far easier (and cheaper!) with the recent move of ScreenWeaver to open-source. So now you can create your web-based game (try-before-you-buy) and then have users download the deluxe version (which will be a normal EXE to them, but to you is basically the same game compiled into an EXE). The advantage? Using ScreenWeaver (and similar projector apps) you can embed additional native code into your game (by providing hooks to Flash through DLLs) that can provide tougher AI (they can run faster in native code) or nice touches like full-screen and video mode changing. See the PopCap model for ideas.

You simply can’t understand (or maybe you can by counting exclamation points in this post) how excited I am about Flash now. For those that know (or care), back in the dot-com days I started a project called OpenSWF.org along with a few Flash programmers of the day. Back then, Flash didn’t have anything but the most trivial of scripting capabilities. Our plan was to create an open-source Flash player (written in Java) that could be seamlessly extended using Java’s remote class loading facilities. It was a cool idea that never got off the ground, and I personally burned out on Flash after many years of wrestling with it. At the time, there were a paltry few open source Flash projects, with most of them dedicated to automating basic Flash tasks (like creating a slideshow or a text ticker).

Jump ahead eight years (wow, eight? oh my god…) and I found that the open source Flash community has reached parity with what Macromedia or Adobe are providing (accept in the case of vector animation editing — some competitors, but Flash still seems to be preferred). Command-line compilers, IDE’s, SWF-to-XML round-tripping, build systems, standard code libraries… even support for alternate languages (C#!). In addition to all of the stuff that goes into your actual finished product, there’s a huge set of libraries for nearly any language for generating Flash files from your own tools. In other words, the ideal game development toolchain exists surrounding the SWF target format.

And last but not least: the programming language at the center of it all, ActionScript. I’ll have to admit, I’m a die-hard C++ and C# programmer, but I’m growing to love ActionScript. I’ve heard all the love heaped onto dynamically-typed languages but have never spent much time using one (unless you count BASIC). I’ve got to say, it’s really growing on me. The beauty of ActionScript and the open-source command-line compilers is that you can run them in a “strict” mode that requires you to statically-type all of your variables (even if it’s just to the universal base class, Object). And I truly love the fact that the type system is dead simple: all numbers are of type Number, whether they’re floats or ints or bytes; all types inherit from Object with no need to manually box them; strings are built-in; and it’s all managed, i.e. garbage collected. Don’t like ActionScript (EMCAScript or JavaScript)? Try C#, there’s a compiler for it as well!

Last night I was working on a piece of code in a data-driven game engine. Leveraging my “old fashioned” C++ OOP concepts, I started building in some base classes and other infrastructure to provide me a property system for my game objects. I kept adding fields, refactoring them into base classes, sticking in compositional objects, etc., until I realized that the virtual machine was already doing this work for me under the hood. And what do you know… ActionScript allows me to leverage it directly. Because of the dynamic typing (and this is even more dynamic than I understood that term to mean), I’m able to create a new, generic object containing whatever properties I decide to add to right at the spot of invocation. In other words, I can say…

var person:Object = {name:"Gina Vechio", children:["Ruby", "Chickie", "Puppa"]};

…and have a well-formed, custom-built object right there. No type needed to be created. This is ideal for data-only objects. Furthermore, I can even iterate over these properties, and if I define the base class myself, I can override the way the code handles getters/setters and function calls. That bears repeating in it’s own paragraph…

ActionScript exposes it’s OOP underbelly such that you can truly treat it as a fully interpreted language: you can dynamically change how your types react to method calls for methods that don’t exist and for member variables that don’t exist. You can treat functions as first-class objects inherently, you can use “eval” to execute strings as code, and you can access properties (member variables) by string name (or by string concatenation). You can even access and manipulate, in code, at runtime, the object that represents a function’s scope.

It’s about as soft a language/machine as I want without feeling like it’s analog. And that’s just ActionScript 2, apparently it’s even been improved more in ActionScript 3! (Coming soon in Flash Player 9.)

You’ll notice this post is devoid of links to any of these wonderful projects I’m in love with or specifics on my techniques or setup… that’s intentional, and not because I’m lazy (which I am). Don’t worry, I’ll soon do a follow-up post. In the meantime, you should be able to google everything you need.

Oh, and one last thing to check out: at GDC 2005, Scott Bilas gave a presentation where he basically reached the same conclusion I did. Don’t know if you know Scott, but he’s a smart cookie: he wrote the streaming engine for Dungeon Siege (or at least he’s the one that explained it to me and others at an earlier GDC). His talk on continous worlds was inspirational in the same way that his recent (last year) talk on Flash was inspirational. I hope it inspires you. I hope I’ve inspired you.

Viva la Flash.