I have read that Shockwave has the fastest rendering engine but there is very little documentation for it.
I have used Flex before and am good with Actionscript, but would probably prefer using Shockwave's Javascript. Also, price isn't too much of an issue, I would rather spend a bit more now than regret it later.
Thoughts?
I just finished up Robokill (http://www.rocksolidarcade.com/games/robokill), and doing that in the Flash IDE would have been a nightmare.
Incidentally, Flash development tools are very poor. Full of subtle bugs (both compiler and runtime), things get broken all the time randomly in the frequent flash player releases, and there have been multiple year long petitions to get Adobe to fix simple bugs. But if you're going where the customers are, it's a necessary evil.
I posted earlier about how I made one ball bounce around the screen in Flash and it wasnt silky smooth, but the polish on Robokill looks fantastic.
Any tips/tricks for Flex game development? Are there any game frameworks? My previous Flex work was a RIA and it seemed that Flex took care of all the frame drawing for me, do you handle things any differently when making games (ie something like bitblt)?
One gotcha with Flash is the default frame rate is 24 - if you turned that to 60, and bounced a ball around the screen, it should have been reasonably smooth. The smoothing property of an object turns on antialising which helps as you get subpixel movement, which helps too. Also, something about final graphics makes you just not notice as much - alpha blended edges definitely help.
I don't do anything really special. I wrote my own set of libraries, and they're just simple boilerplate that you'd expect. Rendering as in bitblt inside Actionscript would be way too slow, and the Flash render is actually reasonably good at throwing up untransformed images.
Some tips for speed:
* Composite the hell out of everything. Our background is just one 800x600 image, but it looks like there's a lot of variation because it is composited out of different layers (background scenery, large lighting sprite, tiles, decals on top of tiles, free rotated static lights and the walls sprite). You could do all of those as free sprites if you had a 3D renderer (Robokill would chew through maybe 1/40th the juice of my 8800 GTS), but it would absolutely kill the performance of the Flash renderer (and reasonably so - a single x86 core simply does not have the throughput).
* Untransformed images are very, very fast compared to transformed. If you must rotate and scale something, try to make that transform a constant and use the cacheAsBitmap property, which will mean Flash will render it to a cache bitmap making it a simple blit.
A concrete example of this is all of our particles are animated images, which blit untransformed to the game. It works out to about 10x faster than what would be possible if we did rotation/transform on them in real time.
* You can use additive to make stuff look cool with little overhead (the additive formula for pixel blending should be faster than the alpha formula, but who knows with Flash). That's the blend mode that gives you the fire and plasma glow look.
* ActionScript is slow, too, but there are almost always game specific hacks to get the desired performance out of it. Use lazy computation where possible. My enemies use real time pathfinding, because all I do is trace outwards from the player each frame, then reset that when the player changes square. Doing a per enemy pathfind, even using an optimised system such as A star (damn markup), would have been pretty much out of the question.
* Don't forget that you get more of your budget back when the action goes away. You may have noticed the additive lights and idle animations that fade in when the action dies down in a room. It doesn't matter that they're expesnive to render, because they're only there when the enemies (which are more so) are not, but I think they really help the look of the game. Also, our intro just goes over the top using lights like this, since they're the only thing being rendered.
Also, Flex Builder is a bit of a dud, but its profiler is very good. If you can afford it, it will give you very good insight into your code bottlenecks, if the $$ is worth it just for that. I use FlashDevelop to edit in still.
P.S. Sorry if I'm hating on Flash a bit too much throughout my posts. There were a few trivial bugs with serious implications that directly delayed our release, so I'm still quite annoyed. I'm back into Flash for the next project, though, because customers are more important than development comfort!
All of our titles have been Flex so far and it will stay that way for a long time yet, I imagine. We started Stunt Pilot in the Flash IDE but it quickly became apparent that it was a really ineffective development environment for what we were doing. Flex has its problems, but at least the core model is more appropriate (i.e. entirely source code, command line compiler).
It seems that Flash for Mac is much slower at rendering than Flash for PC. The same file with a target fps of 100 runs at around 60fps on my dual core 2.16ghz mac, but runs at 98fps on a 1.7ghz single core PC.
I guess it makes sense that Adobe spent all their time optimizing the PC version.
The best Flash games don't stray from the sweet spot, defined by 2D graphics and high responsiveness. The best Flash platformer is N http://www.addictinggames.com/ngame.html , the best 2D shooter is Ownage Burst http://thestylemachine.com/ownage , the best Flash game overall is Samorost2 http://amanita-design.net/samorost-2/ .
Based on the nature of the game I am developing timing needs to be very precise, Im also very picky about choppy graphics.
I wouldn't recommend going down the Flex framework route so don't code it in MXML. You don't need the extra weight of the framework for something like this, an ActionScript project will do just fine. Also note that the next Flash Player has support for hardware acceleration and you can already download a version of the Flex compiler to target this new version. I guess that choice would also depend on how CPU intensive your game is going to be, when it would be released and what group of people you'd be targeting.
Unless you're looking to do something pretty powerful you'll be fine with flash rather than shockwave, especially if you already know some ActionScript. (AS3 is somewhere between Javascript and Java for complexity depending on how you choose to use it)
Flash has better penetration and far more documentation/community support than Shockwave.
In terms of the dev environment, the above game was coded using eclipse to edit AS files and compiled through the Flash IDE, although you could use Flex to compile instead...
Roll on flash 10 - UDP support!
I really want to say JavaScript just to be different, but JavaScript has timing/performance issues that can be a pain to work around. And you can forget about embeddability: security considerations prevent most social sites from letting you embed JavaScript code in their pages. It gives you mad geek cred if you do a good game in it, though.