Hello GDNet community,
I came here to ask this question as this is the right place for it, among all of you game-makers.
So, here goes:
Why do people choose to use Adobe Flash to make games? Does it provide good features for game development?
I know it has got a lot of nice portability, to web, desktop, and mobile in one nice simple way.
But what are its advantages over other methods such as native mobile development, native desktop development, etc..... (Web is not a major for games here, really, because anyone can download a few megabytes of an SDL (or other) game.)

Thanks in advance,
David D.
-wiz3kid

It's a well tested. Also a lot of people use Flashdevelop with the Flex SDK which is a free alternative to the Flash IDE (and much better for programming when developing bitmap based games). Native mobile development has the advantage of speed usually. Flash games generally run very poorly or not at all on mobile phones. Also the interfaces for flash aren't designed for touch input. Hopefully that clears up your confusion.

Why companies choose flash:
- Users already have it installed, so it's one less "barrier to entry". In monetized web games, barriers to entry are probably the single most important consideration.

Why beginner programmers choose flash:
- Because they are aware of it, and it seems easy to make a small project pretty quickly. It's quicker to get graphics on the screen and sounds playing than with anything else.

Why experienced programmers choose flash:
- Because (as far as I can tell) web developers are masochists when it comes to software engineering. Give them a dozen different languages to learn, each one incapable of doing everything on its own, and they are happy. Give them one technology that provides everything and boosts productivity, and it is shunned.

Downsides of flash (from the point of view of someone who has used a large variety of technologies):
- ActionScript 3 is not designed for large scale projects. Annoyances about language design are magnified by project size. If you ever work on a facebook game on the scale of FarmVille or Social City, you'll very quickly realize the disadvantages of AS3's design.
- The IDE has various extremely annoying bugs (memory leaks, hangs, inability to have a project in a folder named xyz/.../xyz).
- The compiler is RIDICULOUSLY SLOW. I'm used to C# where I can build a HUUUGE project in under a second. AS3 projects I'm working with take 30-40 seconds.
- The profiler (CPU and memory) are almost completely worthless and untrustworthy.
- Horrible (and inconsistent) runtime performance (Due to how the language and runtime work).


At first, I thought Steve Jobs was just being a dick those times he said Flash sucks and they'd never support it. I'm not a Mac user, I don't take what he says as truth. However, after actually using Flash, I am in 100% agreement with him. Unfortunately, I don't see a whole lot of difference between Flash and HTML5 (which he stated as what people should use instead) in the areas that I care about (productivity on large scale projects).

1. Why do people choose to use Adobe Flash to make games?
2. Does it provide good features for game development?
3. I know it has got a lot of nice portability, to web, desktop, and mobile in one nice simple way.
4. But what are its advantages over other methods such as native mobile development, native desktop development, etc.....
5. (Web is not a major for games here, really, because anyone can download a few megabytes of an SDL (or other) game.)

1. Because that's what the market force says. As was pointed out, it has a huge installed base on multiple platforms, it has a large collection of tools, it mostly works okay, and so on. Flash is far from ideal in the general case, and it is very often painful to use. You don't have to like something to choose it; you simply have to dislike it less than it's competitors. What is the competition? Java applets? Java deployed packages? AJAX? Buggy and broken and uncontrollable implementations of HTML5? None of them are attractive solutions.

2. Yes, many features.

3. You are mistaken. It has horrible portability. No matter how much you try you will get support calls about how when it is run on an XYZ computer, with version A of flash in web browser B, with certain video settings, it will crash. Or it doesn't run on the flash player on device N. Or it stalls when played on firmware 2.7 of the PDQ phone web browser. The portability still stinks, but it is less bad than Java's "write once, debug everywhere" issues, or the low adoption rate of HTML5, or the bandwidth hog of AJAX. All of these are much better than passing along a PC-only executable that you hope they have permissions to extract, install, and execute.

4. It is not a choice between a field covered with daisies vs a glade of wildflowers with a mountain spring. No. The industry and the market are not that mature. The options are between The Rack, the Iron Maiden, the Brazen Bull, the stake, the stocks, and thumb screws. Prefer those you are most likely to survive, or those that the pain is over quickly. Look at how small the existing web games are. They are either executed server-side and processed results are sent to the user, or else they are extremely small applications. Given the state of the tools, those relatively small applications are the extreme limit of what can be done without permanently destroying the developer market. It is not pretty.

5. No, the statement that "anyone can download a few megabytes of an SDL game" is blissfully ignorant of the reality of online games. Downloading, installing, and running "a few megabytes" is still beyond the skills of the mass market, it is extra steps that add a completely unnecessary barrier, and it artificially limits you to a specific set of machines and a specific set of users. Breaking through a firewall to network that tiny little game is another relatively small task that is also beyond the limits of the rank and file mass market. It is not an easy thing to support an unbounded number of machine configurations, multiple operating systems, and devices ranging from tiny slow phones to fast PCs, network connections ranging from a handful of bits per second up to megabits per second. No, it is not something anyone can do.

Downsides of flash (from the point of view of someone who has used a large variety of technologies):
- ActionScript 3 is not designed for large scale projects. Annoyances about language design are magnified by project size. If you ever work on a facebook game on the scale of FarmVille or Social City, you'll very quickly realize the disadvantages of AS3's design.
- The IDE has various extremely annoying bugs (memory leaks, hangs, inability to have a project in a folder named xyz/.../xyz).
- The compiler is RIDICULOUSLY SLOW. I'm used to C# where I can build a HUUUGE project in under a second. AS3 projects I'm working with take 30-40 seconds.
- The profiler (CPU and memory) are almost completely worthless and untrustworthy.
- Horrible (and inconsistent) runtime performance (Due to how the language and runtime work).

I've worked on several Facebook games of that scope and we never really ran in to any of those problems. If you are using CS as your IDE and compiler then yes, its a horrible, horrible experience. Try using FlashDevelop instead. On my workstation it takes the project a couple of seconds to build (the client builds faster then the server). The debugger and profile for FD 4 is pretty good. Yeah, its not Visual Studio quality but for being free it is very good. The only annoyance about the language I've really came across is how functions and variables are defined. I do find myself trying to use C style declarations when I've been working outside of AS3 for awhile. Hands down we get stuff done quicker in Flash then we ever would in C++ though. Only thing I can't really defend is runtime performance. But since Facebook games are typically slow paced turn based games it doesn't really matter. Of course if you want to do some kind of intense FPS then Flash is obviously not the choice. But for what its used for its pretty hard to beat.

I've worked on several Facebook games of that scope and we never really ran in to any of those problems. If you are using CS as your IDE and compiler then yes, its a horrible, horrible experience. Try using FlashDevelop instead. On my workstation it takes the project a couple of seconds to build (the client builds faster then the server). The debugger and profile for FD 4 is pretty good. Yeah, its not Visual Studio quality but for being free it is very good. The only annoyance about the language I've really came across is how functions and variables are defined. I do find myself trying to use C style declarations when I've been working outside of AS3 for awhile. Hands down we get stuff done quicker in Flash then we ever would in C++ though. Only thing I can't really defend is runtime performance. But since Facebook games are typically slow paced turn based games it doesn't really matter. Of course if you want to do some kind of intense FPS then Flash is obviously not the choice. But for what its used for its pretty hard to beat.

I use both Flash Builder 4 and FlashDevelop. Both are lacking (mutually exclusive) things that I require when I'm developing. FD lacks a general 'navigate back/forward' that both FB4 and VS have. FB4 has horribly broken path handling that prevent me from setting up a project so that I can actually compile it (something to do with substring path manipulation instead of REAL path manipulation. What kind of shit is this when they can't handle paths properly?)

So I have to use FD when debugging and FB4 when editing. It's extremely cumbersome.

Next issue is doing low-level analysis of the game. We need to do CPU profiling to deal with unacceptable performance (probably because we're doing 3D software rendering and the code has a bunch of complicated systems related to that). We also need to hunt for memory leaks. FB4's profiler is completely untrustable as far as we can tell. We have a third-party open source profiler that works better, but it lacks many useful things common in .Net profilers.

As far as memory goes, there is apparently no real way to examine the object graph and look for forgotten references. I am almost to the point where I'm going to hook up a native debugger to the flash player process and reverse engineer their heap so that I can dump the true object graph. Also, from scanning numerous blogs and forums, apparently nobody really knows how the flash garbage collector works. Does it have problems with cyclic references? Does it have some internal leak somewhere in certain cases? Does it not actually traverse the entire graph when it runs? Does the player itself ever free up virtual memory? Nobody knows for sure. It's really worrisome that nobody understands how it works.

As far as C++ goes though, I agree; ANYTHING is far more productive than C++. I normally develop in C#, however. C# easily beats Flash in productivity.

Strangely, I have never had a chance to try out Silverlight. Hopefully the non-C# parts of SL don't suck too badly. I never forgave Microsoft for WPF's "let's go back to design-time declarative text files" betrayal.

Thank you all for your replies. I was wondering whether it would be worthwhile for me to learn to make games with Flash. I guess everything has its pros and cons, so I'm stuck between deciding on various technologies. Thing is, next 3 years I am taking a course on Java game development, and I don't really like Java as I heard it is very bloated. I want to choose a single development language for my upcoming projects and I have taken into consideration C#, C++, Flash+AS. Since there are a lot of comments about C++ being very non-productive ( I tried it myself, certainly requires ultimately hard debugging ), I would drop it out of the question.
So do you guys think I should try both (C# and Flash+AS)?

Thanks in advance,
David D.
-wiz3kid

PS: I already have decent programming exp w/ C#, so that isn't really a MAJOR decision. Just asking whether I should try Flash at games. It seems widely accepted.