CoderHump.com

Dear Adobe,

Please make Flash into the ultimate console for the web and mobile devices.

Do not listen to the people who want you to make DRM. Centralized DRM for games doesn’t work. Adobe, we developers are a fearful lot and wish not to face the reality that all DRM can be cracked. It is much better for 3rd parties to do their own DRM. People will claim they want you to do DRM, but don’t listen to them. Adobe, they do not know what they are asking. A good fast crypto library would be nice, though.

Do not listen to the people who want you to add high-end GPU capabilities. Games don’t need to be able to launch a background thread that does deferred collision using a secondary GPU. They need to be fun. HW accelerated rendering on the platforms that can support it would be nice, but it is more important that there be consistent performance than that there be high performance on some computers and bad performance on others..

Do not listen to the people who want you to write their game logic for them. Adobe, they do not know it, but they are asking for a monoculture that will ruin your platform. Let the distributors and publishers create good high score and friend and sign on features. They will promote them and make them good because they are financially motivated to do so.

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.

Oh Adobe, devourer of companies, creator of digital art tools, hark unto the example of Microsoft. For were they not like the wild beast of the field, clueless as to the nature of game development? Then they created DirectX 1, and it was shitty. DirectX 2 was right out, and DirectX 3 could draw sprites ok but not do 3d for beans. Did it not take Microsoft fully eighteen revisions to achieve a game API that was good?

But what truly made their API good? Was it the functionality, which was adequate? No, it was the tools and the consistency! The consistency they achieved by enforcing it on hardware manufacturers and having strict standards! The developer tools they created for the XBox and the XBox 360! These excellent tools made developers love working with the XBox 360. Even Carmack switched to using the 360, because of these excellent tools!

Adobe, make Flash like unto a console! Give us consistent performance! Give us excellent tools! Flex Builder is not that great, Adobe. Your compilers could be a lot better, too. Don’t worry too much about lots of fancy features. People who have to have super high end 3d and do not want to run everywhere will use tools like Torque or Unity that do 3d really well. Be everywhere, run well, be easy to develop for, and you will be loved and well rewarded.

Adobe, I have a vested interest in you succeeding. Please listen to my words. I have spent years developing game middleware on a variety of platforms. Now I am working with Flash. If Flash dominates the game industry, it will be possible for me to afford to eat.

Please, Adobe. I am hungry.

Your Pal,
Ben

If you’re in the Flash space, you’ve probably seen a lot of coverage of HaXe lately. HaXe targets Flash 9 and 10, as well as JavaScript, PHP, NekoVM, and most recently C++. You can write code once and easily retarget it to different platforms, which is very exciting. This has been used to good effect by Hugh Sanderson, who is developing an iPhone path.

HaXe is cool not only for platform compatibility with things like the iPhone (and who knows - maybe other platforms like Android or Windows Mobile), but also for its language features. They deployed support for the new Flash 10 high-performance memory intrinsics before the official Adobe compiler. HaXe has generics/templates, decent conditional compilation, inlining, a big performance margin over AS3, as well as better memory management options.

And performance is a big deal when you’re an interpreted language trying to run on Netbooks and televisions.

Since my day (and sometimes nights, too) job is working on a Flash game framework, HaXe looms large on my radar. AS3 and HaXe can already interoperate so if you want to use a HaXe physics library from your ActionScript 3 code, there’s no problem. But should we switch the core engine over? Having a seamless way to target iPhone would be big. Having an easy way to run your server code without requiring an integration with Tamarin would also be nice.

Ralph Hauwert over at unitzeroone summarizes the HaXe situation very well:

The language is great and has many features ActionScript lacks. It baffles me how one man army nicolas can single handedly write a language and a multi target compiler, and in many respects stay on top of the ActionScript compiler.

My first problem with Haxe is just that. The one man army. Should nicolas decide he doesn’t feel like it anymore, the platform is dead. Sure, there’s more people working on it, but in it’s core it seems to be that nicolas is the driving force. My second problem is that although there is a huge pool of ActionScript developers, which can work together within the industry standard called ActionScript. There’s not even near that many people who’ve even touched haxe, let alone the number of developers who are able to call themselves “Haxe Professionals”.

HaXe is very cool. But it doesn’t have the ecosystem and infrastructure to justify targeting it exclusively. As a small startup, we only get to target one platform for our technology, and AS3, although it leaves performance on the table, wins in terms of the pool of potential developers and the accessibility of the toolchain. How many people out there are using PHP or Java vs. x86 assembly?

If the basic technology is good enough, ease of use always wins out over performance. So for now we are going to stick with ActionScript 3 for PushButton Engine. You can write compelling content on it. If you really need HaXe for something, the option is there to link it in.

But I want to put the plea out to Adobe. I love you guys and all you have done in the Flash space. But please update your compiler technology. At least give us the compiler optimization wins like inlining and generics. It’s simply embarassing that one guy’s work can outperform you on your own VM!

Adobe, you have smart people working for you. You have smart people in your community. You have pretty decent tools. None of us want to jump over to a third-party technology, but if HaXe keeps beating you at your own game, it might be necessary. Buy HaXe if you must, or else match it with your in-house tech, but either way - I know you can solve this problem.

The web is catching up with you on the player front. You could dominate on the tools front and make the world better for everyone. Please. As a middleware developer, I really don’t want to have to support anything other than a single mainstream language and platform.

Google released O3D, a web plugin for 3d rendering, today. It’s a pretty sweet piece of work. Definitely check it out if you have any interest in 3d rendering, the web, or JavaScript.

There are a couple of cool pieces to this puzzle, and I wanted to call them out to other people who might be reviewing this technology. The two sentence review: I am blown away. They got this right.

(FYI: This post isn’t meant to be a full walkthrough, just a quick indication of the cool jumping off points in the codebase.)

Stop number one is the graphics API abstraction. This is rooted in o3d/core/cross/renderer.h, which provides an abstract interface for performing render operations. This is sensibly designed, oriented for SM2.0 through SM4.0 level hardware. It will also deal with DX11 class hardware, although it won’t expose all of the niceties DX11 gets you. It wraps GL (o3d/core/cross/gl/) and D3D9 (o3d/core/win/d3d9). The purpose of all this is to provide a common ground for all the higher level code to issue draw commands from. It is not directly accessible from JavaScript (although some of the related classes like Sampler and State are.)

As an aside, writing a Pixomatic or Larrabee backend would not be hard. At GarageGames, we had a rendering API similar to this (unimaginatively called GFX), and it was fantastically useful. Last time I checked, there were DX8, DX9, DX10/11, GL, and Pixomatic backends for it in varying states of usefulness. We even had one guy write a backend that would stream draw commands over a socket, which was pretty cool. In the context of O3D, they have an implementation of Renderer that queues everything into command_buffer, then streams it to a command buffer server running in a separate thread, which issues the actual draw commands. It’s unclear whether this is used in the current version of the plugin based on casual inspection, but it’s a great example of what good design can get you.

The next piece is the DrawList, which is where most of the heavy lifting for drawing happens. JavaScript, of course, is not really desirable to have in your inner rendering loops, so you queue everything you want to draw (DrawElements) into a DrawList. This is wrapped by higher levels, of course, but it represents the lowest level API that’s available to JS code. All the sorting and state management to get stuff on screen happens in this area.

Alongside the DrawList stuff, you find the material system, which is pretty slick. You write your shaders in their shading language, and it converts to HLSL SM2.0 and Cg (arbvp1/arbfp1). This is enough to do almost anything you might want to (as fantastic as SM3.0+ is it’s not really necessary for most rendering). There’s a full SAS system so you can interface programmatically with your shaders.

Above this, you get into the scenegraph. Now, I subscribe to Tom Foryth’s views on scenegraphs, which is that they are basically a bad idea, but I think the Google guys were smart and set up their API so intelligent developers can avoid being screwed by the scenegraph. The scenegraph-esque stuff they do have (they call it a rendergraph) is powerful enough you can do most rendering without going nuts, and lets a lot of the heavy lifting stay in native code, where it will be fast. You end up doing retained mode-ish things, but since JS is slow, and most JS developers come from a DOM background, it works better than you might expect.

There are a lot of cool miscellaneous features, too. They embed the fast V8 JS engine right in the plugin so you can have consistently fast JS execution. They support falling back to an error texture (via Client.SetErrorTexture) when you fail to bind a sampler. You can group objects via Pack objects for easier management and stream things from archives, too. There are debugging aids and libraries for math and quaternions.

You should check out the samples. There’s a lot of impressive stuff. There’s the beach demo in the video at the top of this post, but they also do some cool stuff with animation, HUDs, text rendering, picking, and stenciled teapots. And everything is done in JavaScript right in the web page. Even the shaders are embedded in <script> tags!

O3D is a great piece of technology, and I hope it thrives. I’m excited to see what people build on this (and I’ve got a few ideas myself ;).

View from our room at The Westin

PushButton Labs went down to San Francisco last week for the Flash Gaming Summit and GDC.

We drove down Saturday. Our hotel was The Westin, right by the show - in fact, the closest I’ve ever stayed. In the past I’ve done GDC on the cheap by staying at a distant hotel and walking ten blocks past hobos and sex shops. IMHO, you’re better off staying close and being there fewer days if price is a concern. You save a lot of time and pain by being close.

Flash Gaming Summit was cool. It was great meeting most of the players in the Flash space under one roof. Major props to Mochi Media for putting it on - Ada Chen especially was great (she even got me in at the last minute - thanks Ada!). Unfortunately, the format and talks were a little limited, especially from my perspective as a Flash technology guy. Greg McClanahan from has a great post on some problems they ran into in terms of content. I hope next year has multiple tracks and a little more coverage of the hows of Flash game dev.

After FGS, we had a gap of several days before GDC really got swinging. I don’t buy GDC conference passes - it’s a lot of money for the two or three talks I really care about. What I said above about cutting costs by staying fewer days? Broke that rule. Tuesday ended up just being an expensive way to write code in downtown San Francisco.

Since PushButton Labs is a little tiny startup, we didn’t get a booth. My first few GDCs, I worked the show during the day by standing at a booth. You get great exposure here and if you can make the upfront investment of time and money, it can pay off pretty well. If you’re just one or a few guys, you work the show at night during the parties and at the suites. You also set up as many one-on-one meetings as you can. Go where the volume is low enough to communicate, and talk till your tongue dries out. Have a lot of business cards.

The most striking thing at GDC was seeing the job market totally packed, and the show floor with big empty spaces where they couldn’t fill in with booths. End of the world? No, but you could tell that people are doing business a little differently.

The second most striking thing was OnLive’s game streaming/cloud service. Smells like snake oil to me, but Dave Beermann from Sharendipity wrote up a great analysis of the service. Dave actually spent several years in academia working on very similar technology, so give his post a read.

We left town Thursday morning. I would have liked to have stayed for Thursday night, but we had already spent enough time at the show - in fact this time was the longest I’ve ever been down for GDC. That’s not saying much, but Jeff has been going for twenty years and it was the longest he’d ever been down, too!

Spent most of Friday recuperating - GDC is hard work! But I’m glad we went, and I’m pumped to get back to work on the PushButton Engine. Did you know it’s in open beta now? Check it out - PBEngine is under the MIT license, and ready for you to download!

Our latest game, Grunts: Skirmish, has 200 tweakable parameters. There are 9 player units with three levels of upgrade, and another 9 enemy units. Each unit has between three and ten parameters that can be altered.

We tried a few approaches - hand-editing a large XML file (but it was too large and spread out) and an in-game tweaking UI (but it was too much work to get the UI to be friendly to use). The old standby of having the designer and artist file bug reports to have the programmer update the game wasn’t getting us very far, either.

“Well,” says I, “We’re some sort of Web 2.0 startup, right? And we’re developing a Flash game aren’t we? And Flash can talk to websites, can’t it? And don’t we use Google Docs for everything?”

It turns out there is an XML feed from public Google spreadsheets. And ActionScript 3 supports E4X, so you can directly manipulate XML without any extra work. Now we tweak our game using a shared spreadsheet up on Google Docs.

I wrote a parser for their format:

// Extract the entries. It's namespaced, so deal with that.
var xmlns:Namespace = new Namespace("xmlns", "http://www.w3.org/2005/Atom");
tweakXML.addNamespace(xmlns);

// Parse into a dictionary.
var cellDictionary:Dictionary = new Dictionary();
for each(var entryXML:XML in tweakXML.xmlns::entry)
{
   cellDictionary[entryXML.xmlns::title.toString()] = entryXML.xmlns::content.toString();
}

And wrote a quick component that would fetch the spreadsheet feed, parse it, and stuff it into the right places on named objects or template data. Now I have a little entry in our level file that looks like:

<object id="googleTweaker">
   <component class="com.pblabs.debug.GoogleSpreadsheetTweaker">
     <SpreadsheetUrl>http://spreadsheets.google.com/feeds/cells/0d8somekey848x/od6/public/basic</SpreadsheetUrl>
     <Config>
        <!--  Grunt Level 1 tweaks -->
        <_><Cell>B3</Cell><Property>#TheGruntProxy.creator.WarPointCost</Property></_>
        <_><Cell>C3</Cell><Property>!Grunt.health.mMaxHealth</Property></_>
        <_><Cell>D3</Cell><Property>!Grunt.ai.AttackSearchRadius</Property></_>
     </Config>
  </component>
</object>

Each line maps a cell in the spreadsheet to a property on a template or active game object. Some properties have to be set several places, which the system deals with automatically.

The biggest wrinkle was Google’s crossdomain.xml policy. Basically they do not allow random Flash apps to access their site. So I had to write a small proxy script, which sits on our development server next to the game and fetches the data for it. Figuring out I had to do this took more time than any other step.

The main difference between the snippet and the full code is the version in our repository is 220 lines long. I only have around 150 of the full set of 200 parameters hooked up, but after a hard afternoon’s work, the process for tweaking the game has become:

1. Open Google Docs.
2. Edit a clearly labeled value - like level 1 grunt health.
3. Restart the game, which is running in another tab in your browser.

This takes you about a minute between trials. Not too bad. Before this, the process was:

1. Get the game source from SVN.
2. Find the right XML file - there are several.
3. Find the right section in the XML - altogether we have 200kb of the stuff for Grunts!
4. Change the value.
5. Commit the change.
6. Wait 5-15 minutes for the build system to refresh the live version of the game.

Ten minutes per tweak is not a good way to develop.

I’ve heard about developers using Excel spreadsheets for tweaking, but can’t find anything about using Google Docs to do it. But Google Spreadsheet is obviously a better choice. It has built-in revision tracking. You can edit it simultaneously with someone else. You can access live data in XML either publicly (like we did) or privately via their authentication API. It’s absolutely worth the half-day of your time it will take to add Google Spreadsheet-based tweaking to your game - even if it’s a non-Flash game, downloading and parsing XML is pretty easy with the right libraries.

I strongly suspect this feature will find its way into the next beta of the PushButton Engine. Which, by the way, you should sign up for if you are interested in developing Flash games. We’re bringing people in from the signup form starting this week. If you want more information, or just like looking at cool websites, click below to check out the new version of the PBEngine site, which has a bunch of information on the tech. Tim did an awesome job on the site design.

Edit: Patrick over on the GG forums asked about the proxy script. It’s actually ludicrously simple. Not very secure either so I wouldn’t recommend deploying it on a public server. I got my script from a post on Aden Forshaw’s blog. In the real world you would want to have some security token to limit access to your proxy script… but since this is for tweaking a game that is in development I didn’t sweat it.

A buddy of mine from GarageGames days, Orion Elenzil, posted some notes on how to get started with the free Flex SDK. Take a peek to see just how simple it can be to get started with Flex.

for those who may come across this post on their search to learning how to set up a command-line-only Flex environment, and who also know previously zilch about Flex/AS/Flash, i sketch the steps very roughly here: http://elenzil.com/flash/flash_1

– Orion

If you’re into Flash coding, you should also read Rob Sampson’s post on AS3 Math Optimization – int is the new floor(). Rob’s been doing ActionScript a lot longer than I have, and I love the historical perspective he can provide. You can tell he’s a graphic designer - his performance charts look awesome.

I have to quote this from Jeff Tunnell’s blog, Make It Big In Games:

I stumbled across this YouTube video of Gary Vaynerchuck of Wine Library TV giving a presentation at Web 2.0 Expo. At first I just thought the guy was a dick, and he even calls himself that at one point in the presentation, but it turned out to be a fascinating 15 minutes of video. Gary essentially says what I have been saying, i.e. make sure you love what you do, work hard, and things will work out, but he says it in a much more succinct, hard edged way than I do.

Check out the video here.

Update: I filed a bug about this issue.

This post starts out with a finite state machine, but it ends up talking about how iteration is implementing in ActionScript.

There I was - implementing a finite state machine. Each state had transitions, and the transitions are named and, additionally, processed in order. This is useful because you can order your transitions for consideration from most to least specific. Usually the last transition is unconditional.

Unfortunately, I began encountering issues with users who had the release player installed. Enemies would move erratically and transition between states inappropriately. Adding and removing log statements would sometimes make the problem go away, other times not. I suspected the VM or compiler.

As you may be aware the for and for each keywords in Flash are not guaranteed to iterate over keys or values in a consistent order. And of course, my loop for checking transitions looks like:

      	// Evaluate transitions in order until one goes.
      	for each(var t:ITransition in Transitions)
      	{
      		if(t.Evaluate(fsm) && fsm.SetCurrentState(t.GetTargetState()))
      			return;
      	}

The icing on the cake is the hashtable implementation in Tamarin, which is used internally for storing object properties as well as (partially) for Arrays. Whenever you store a value by key, the key is converted to an atom, and the atom is used as the key for the hash table look up. Atoms are (basically) pointers, so the location in the hash table is based on the memory allocation pattern of your SWF (as well as the allocations of the player binary you are using). (See HashTable::find for the implementation behind this.)

In other words, the order of iteration will be random, but consistent for a given combination of player binary and SWF (and execution pattern). In my case, the iteration order was what you’d expect (order of addition to the Array) for debug player, and backwards for release player. A case of good luck turning bad, since it led me to believe that everything was working correctly in the debug player.

How does this relate to the log statements I mentioned earlier? Because iteration order is tied to memory allocations, it looked like a VM or compiler bug, since adding or removing code would change memory allocation patterns.

From this experience, I have two pieces of knowledge to share.

First, if you need to have both non-integer keys and values, but want to iterate in a specific order, you can’t use any of the built-in ActionScript classes. Instead, use a class like senocular.com’s AssociativeArray, which subclasses flash.utils.Proxy to implement custom iteration logic.

Second, some parts of ActionScript do iterate in a consistent order:

• “Dense” Arrays will iterate in order from first to last element. You can see the implementation for this in ArrayObject. “Dense” mode is heuristic but activated by having numeric indexes, especially starting at zero.
• XML nodes. Children have a definite order based on the document and are iterated in this order.

The docs don’t describe this, to the best of my knowledge, which is why I post here. The best I can find is this from the online docs:

For example, you can use a for..in loop to iterate through the properties of a generic object (object properties are not kept in any particular order, so properties may appear in a seemingly random order)

Is there any more information out there? I’d like to think I’m overlooking something!

Thanks to Steven Johnson of Adobe - his feedback was essential in the process of sorting this out. Creative Commons picture by davebluedevil.

I found some old screenshots on a backup, and uploaded them to my Flickr account.

As I was filing them away, I looked back in my .plans at GarageGames and realized that I had never talked about it publicly. At least, the site search didn’t turn anything up. Well, I think it’s probably safe to do so now.

Way back in April of 2005, I wrote a Blitz3D loader in Torque for Adrian Tysoe. It loaded Blitz3D files, with all their texture and material data, and it did polysoup collision, as well. This was several years before I released the OPCODE-based poly soup resource, which I think is now (in some form) in the official Torque codebase.

I love seeing how graphics code comes together, so I thought I would share this with the world - you might like clicking through the images and seeing how each step changed things. By far the biggest pain point was parsing the (sometimes obtuse) Bitz3D format. The format might be a pain, but in the hands of a good artist like Adrian, it gave really solid results. This was all before shaders were mainstream, of course, but still - the sand had a nice specular highlight, there was lots of clever texture layering, and the whole thing was pretty fast to render.

The more interesting aspect to doing the B3D loader was the prevailing opinion in the Torque community at the time that loading a non-DIF/DTS format was impossible - as was deviating from the collision models those formats used (convex polyhedra mostly). I’m not quite sure where they got this idea, but it was awfully frustrating at times to see people beat their brains out on those formats when there might be better options for their specific situation.

Partially, I did this project to prove to myself that I wasn’t just bullshitting people when I said that writing a loader/renderer was easy (certainly easier than canceling your project because another format wasn’t working for you!). It took me a month or so of part time hacking to get it all together. It didn’t animate, but it was just for environments - DTS is actually an awesome format for characters, and the 3Space runtime is very tight, one of the best parts of Torque in terms of features. (Aside: I hope they get a good Collada->DTS converter as the main pipeline sometime soon!)

Two years passed before anyone put polysoup in without rewriting the rest of the engine to use some other physics SDK. Actually, I ended up being the one to integrate polysoup with DTS. :-/ I was surprised no one else beat me to it! I brute-forced it - every triangle as its own convex. Torque ran this approach like a champ as long as you didn’t feed it tiny triangles. Did the same trick again when it came time to write Atlas1 collision a few months later, but that wasn’t really “polysoup” in a meaningful way for anyone since it only imported heightfields.

It’s interesting to me that the current Torque maintainer (and all around good guy) Matt Fairfax wrote loaders for .3DS, Quake3, and Unreal formats, and the maintainers that came before me (Rick Overman, Mark Frohnmayer, and Tim Gift) have also done things of this nature (in fact, they are at least partially responsible for DIF and DTS). I guess you don’t get to hold the reigns of TGE unless you’ve written a couple 3d renderers/loaders.

I think in total I’ve done 4 loaders with renderers - Blitz3D, Chunked LOD (for Atlas 1), Atlas2, and OBJ. Really, OBJ doesn’t count. Every graphics programmer in the universe has hacked up a OBJ loader - from Carmack on down.

In conclusion? I guess there are a few morals to draw from this nostalgia-inspired post:

• Keep shots from your old projects. It’s fun to reminisce! I have a few hundred shots from Atlas development that might be fun to write about some day…
• Don’t be afraid to buck common knowledge and go out in a technical direction no one thinks is feasible. Try it small and if it works, keep going.
• Do projects for fun! Good stuff will always find an opportunity for reuse - be it some code, or a technique, or even a fresh perspective. The ideas and techniques I came up with for this project ended up helping me for years to come. Working with Blitz3D’s format helped me see Torque’s approaches in a fresh light.

Edit: Adrian Tysoe posted on GarageGames about his side of this experience - here’s what he had to say:

Heh, I remember working on this with you. I figured they were the starting point for some of the later torque advancements. Just wish that the DTS had been updated to support more than 1UV. Was pretty fun to work with and performance was decent.

The worst part was trying to match invisible torque terrain collisions to .b3d meshes just to get the nice water blending around the edges. The terrain used the coldet collision for the actual character and weapons etc.

Was pretty neat and I enjoyed having 2UV’s to playwith so I could bake my own lightmaps in 3dsmax of gile[s], in many ways the most useful thing to make TGE rendering look a bit nicer.

Here’s a couple more pics the project Jeremy and I started using it.

My Default Playstation Home Avatar

PlayStation Home came out not too long ago. Penny Arcade pretty much said what needs to be said about it, but I had to try it myself. Naturally the first thing you do is create your character from a randomized (I hope) default character.

To the left is the default character that I got.

…

Sony appears to be targeting the coveted 18-25 male Caucasian skinhead/serial killer demographic. I’m kind of surprised that they didn’t filter the default characters to avoid characters that appeared obviously threatening/defective. If this guy showed up at my front door, I’d call the cops.

Naturally, I ended up tweaking him to try and make him freakier, but honestly, what I ended up with was less terrifying. He resembled a creepy real life version of Robbie Rotten.

He stood out nicely compared to all the cookie cutter people on Home, but nobody really cared. In fact, it was hard to communicate with people or interact with the world at all. The loading times were ludicrous. The difference between last gen and this gen is that you can let things load in the background while you stare at the room you’re stuck in. Why would Sony spend millions of dollars and years of time on something like this?

Does anyone else get the feeling that big game projects don’t have fun on their agendas?

There is a right and a wrong way to set up Flex Builder. The wrong way is to get the Flex Builder package from the Adobe site. It’s running on a super old version of Eclipse, and it lacks a lot of useful editors and functionality. I have lost many man-hours of productivity to this version of Flex, which is why I am writing this post.

What you want to do is this: Go get the latest, vanilla Java-IDE version of Eclipse. You can do this at the Eclipse downloads page, the package called “Eclipse IDE For Java Developers.” (Not Java SE, unless you want an extra hundred megs of Java tools.)

Now, go to the Adobe Flex download page, and go to download it - but scroll waaay down and get the plug-in instead.

Finally, install Eclipse - then install the plugin. Now you have a fully up to date, ready to go version of Flex, as well as a bunch of nice tools that come with Eclipse for Java. In my experience, this is significantly more reliable and responsive than the all-in-one build from Adobe.

Edit: Don’t forget to do Help -> Search for Flex Builder Updates and Help -> Software Updates… to make sure that you are fully up to date!