I might have to investigate Flash further now. Firstly, at the time I started the project, there was no Flash plug-in available for my OS (64-bit Linux). Secondly, I would have preferred using only open standards for this open source project. Finally, and most imporantly, I didn't know Flash or Actionscript.
Unless the purpose is to make this into some ginormous company, I'd highly recommend excluding IE from your list of worries. If it's a love-of-the-game project, do it to your (and your friends') satisfaction.
I recently looked into using Flex to develop a Flash interface, and found it quite simple to get started... just beware of problems with asynchrony (that's what tripped me up the most).
Many operations in Flex occur asynchronously, such as when accessing remote services. That is, they spark a remote query, and you must explicitly wait for the response (such as by binding a function to the appropriate change event) before you can continue a computation. Sometimes this occurs when you may not expect it, in which case you'll see problems such as UI controls not being updated, or exceptions from using nil values (because they are used before the response comes back).
When you do expect it, you have three options: 1) you always wait for a response before returning, making your function sychronous (thus maybe killing performance), 2) you pass the responsibility to handle this behaviour to the caller (thus creating an abstraction leak), 3) or you define a custom event that you trigger when the response occurs (best behaviour, but needs extra code).
Certainly not a huge issue once you get the hang of it, but something that can definitely trip you up when you're just learning it.
It is very similar to ajax. The problem I have is when a game gets into the 2KLOC territory and above; when you have multiple files loading at different times in the game engine in order to offer the player a better experience. This leads to many, many handlers and a lot of chaining, and your pretty UML will quickly become incredibly hard to see in the program flow.
For instance to save the user you can't just call User.Save and then go about dependent routines, because there is a possibility that call fails or takes a long time and then the player is out of sync. This is especially important if you want to try to minimize cheating, as the longer the client goes without syncing, the higher the probability for tampering, replays, etc.
It seems that Flash doesn't even have a "yield" operator. And if you try to busy-wait, the machine grinds to a halt, because Flash events do not preempt code execution.
Speaking of openness, if there was a large open source game written in Flash (such as FreeCiv), the swfdec/gnash developers might be willing to invest the effort to be able to run it.
Ha, yeah. In a way it has already begun: the revival of Java in the browser is GWT, obfuscated Javascript is the new bytecode, and canvas is the new Java2D.
