Actually, if he knows how to code, and he's doing anything more complex than Space Invaders, I think Flex is definitely the right choice. You don't have to use MXML with Flex - your entire project can be in Actionscript.
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.
Wow, I think Robokill might have sold me on how smooth graphics with Flex can actually be.
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)?
Thanks! We spent a lot of time to make this one as good as possible.
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.
Basically, Adobe Livedocs, and trial and error. Although from a rendering perspective just knowing the theory behind it (write code to just rotate an image without concern for quality and it's instantly clear that it'll always be slow) gives you pretty much everything you need to know - it's just connect the dots from there.
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!
Thanks for the great information. One quick question... when you say you're "back to Flash" for your next project, are you talking about moving back to Flash (as opposed to Flex) as your dev tool/programming paradigm or did you stray from the Flash engine entirely?
Oops, I should have said Flex. I meant it in the 'oh well, back to the grind' sense. :)
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).
UPDATE: So I discovered the reason why the bouncing ball didn't seem to smooth, yet people insisted that it should be.
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.
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.