Which platforms work the best for developing casual games? Which are the most practical? Phil Steinmeyer evaluates the field, contrasting Flash, Java, and Compiled C/C++ hooked to DirectX, as he tries to find the answer to these questions.
Overview
I've just spent the better part of a couple of weeks playing with a wide variety of languages and platforms. In part, my goal was to broaden my programming horizons. But my primary goal was to evaluate platforms and languages that would be suitable for commercial development of casual games or other games that would be browser-playable and/or easily downloadable. C++ was my default choice - it's what I knew. But would any other languages beat it by enabling faster development, and/or allowing the use of a single platform for both browser play and downloadable stand-alone play?
Languages fully evaluated include Flash, Java, and C/C++, and I also took a short look DarkBASIC, BlitzBASIC, and a few other alternatives.
Background
Of late I've been interested in different alternatives for commercial game development. After spending 12 years developing deep strategy PC games for retail sale, I want to take a break and try something different. One area I'm considering is casual games, mainly puzzle games, which have grown in popularity recently.
To be commercially successful, casual games must be small (because of low-bandwidth internet connections), and the most popular ones generally feature simple gameplay and 2D graphics. In particular, casual games that can be run in a web browser, with no separate download and install, seem to have the best prospects for success. So I wanted to evaluate platforms that would allow fast development of small simple 2D games, and ideally, allow them to be browser-playable.
Some Basics
About 99.5% of retail games for PC and console are developed in C/C++. But casual games, for playing in browsers, and to a lesser extent, phones and mobile devices, are developed on a wider variety of languages and platforms, particularly Flash and Java.
C/C++ games are generally compiled to native code, and distributed with a variety of large supporting libraries (like Direct X). But for security reasons, browsers don’t like to run native code (it can accidentally or intentionally do all kinds of damage to a user’s computer). Downloading a game as a standalone installer, installing the game, and then running it outside of a browser is a possibility, and indeed, it’s the general method used to sell a user the $20 "deluxe version" of a game. However, for casual gamers browsing the game portals and sampling different games, the need to download and install a game (then uninstall it later), is a major barrier, and it seems like all the most popular games allow users to try them on-line, in-browser. Indeed, those who run the gaming portals have a strong desire to have the games playable in-browser, and either won’t carry your game at all, or will give it much lower prominence, if it’s not browser-playable.
Adding in other important factors, my feature checklist looks something like this:
1) Easily playable in-browser, by the vast majority of users
2) Development Ease
3) Can be made into a stand-alone, browser-free, downloadable program as well
4) Support across the widest variety of PCs, new and old, and including alternate platforms like the Mac and Linux
5) Speed and flexibility of code execution
6) Small deliverable size – both the size of the executable code and accompanying libraries, and the ability to work with tightly compressed sound and graphics files.
7) Promising future – a language that won’t be obsolete in a year or two
Quickly Rejected Languages
Initially I was pretty wide open. I looked into a lot of development alternatives, but eventually settled on three (Flash, Java, C/C++). Before I get to those, here’s some I gave up on early. Note, some of these may be suitable for small games, I just felt that given my experience and needs, they were clearly inferior to one or more of the three "finalists". Also, in places where I list features as missing or of poor quality, it’s possible that the features really exist and/or can be improved with plug-ins. But if I couldn’t locate the important features and use them quickly and easily, it’s a bad omen for the language.
DarkBASIC – A $100-ish version of the classic BASIC language, catering towards game development with 2D and 3D features built in.
This language might be suitable for a beginning programmer. I took a look at the free demo version and quickly ruled it out for myself. The language appears to force you to use the integrated, ugly looking, full-screen IDE, which is apparently hardwired to 800 x 600 mode only. There is no integrated debugger that I could locate. There is no built in design tool for windows or U.I. elements. When you compile standalone EXEs, they’re quite large (1.5MB for the simple example they include). Finally, various forum postings from people I trust indicated that if you dig deeper, there are more problems – BlitzBASIC was more recommended for a game-oriented Basic language.
BlitzBASIC – This is, rather confusingly, a set of three different language products, all made by the same company and costing $50-$100.
The products are BlitzPlus (aimed at 2D development), Blitz3D (aimed at 3D), and BlitzMax (apparently the be-all end-all product they’re working on at the moment, but it’s only available on Mac OS-X at the moment). From the site, it appears that all 3 are incompatible. However, I downloaded the trial versions for BlitzPlus and Blitz3D, and in fact, they're very similar. They have virtually identical IDEs, and the credits list the same lone-wolf programmer as the sole creator of both. I don’t understand why he split 2D and 3D functionality into separate packages. Note that BlitzPlus has support for creating a GUI, but Blitz3D does not (hey Blitz guys, even 3D games need an interface).
The IDE, while better than DarkBASIC, is still nowhere near state-of-the-art. It has a very simple debugger (the only option is ‘Debug Enabled?’ - yes or no). It runs in a window, and has a few semi-modern conventions like tabs. The version that supposedly supports GUI development (BlitzPlus), has no GUI design tools -i.e. no way to lay out a GUI interactively -it all has to be done in code.
A major problem in evaluating the Blitz programs is that they include only a very cut-down set of documentation in the trial version – the all important Command Reference (which tells you what functions are available and how they work), is only in the full version. Also missing from the demo (full version only) is the ability to compile to EXE – you can only run games from within the IDE. These limitations make the demo by itself almost useless except for looking at the IDE and running the demo programs. That said, it looked like a better package than BlitzBASIC, and probably a good starting point for a new programmer. But there was nothing here that was going to revolutionize game development or cut dev time down for an experienced C programmer. Next.
C/C++ with Active X - For a number of years, Microsoft's solution to browser-playable content (including games), was Active X (aka .COM), a sort-of Microsoft alternative to Java. Since MS makes it, it only runs on Internet Explorer, and it only runs in Windows. But the big problem with Active X is that it’s totally insecure. For Flash and Java, an application that has run amok (intentionally or not), cannot damage the user’s system. But for ActiveX, which was designed to have more power to use native functions, a haywire or rogue app can do just about anything, from reformatting the user’s hard drive to turning the user’s machine into a zombie. Even Microsoft now realizes this, and they’ve essentially abandoned Active X. They’re not developing it any more, and if the user is running I.E. in Windows Service Pack 2, trying to run an Active X app will cause all sorts of scary warning messages to appear. Active X is basically dead, and once I had educated myself on this, I didn’t fiddle with Active X any further.
Microsoft is planning to replace Active X with .NET, a secure solution that’s a lot like Java. But .NET is not pre-installed on ANY PCs now, and it’s a 19MB download, so it’s not really viable for casual games.
Note that one major casual game developer, PopCap (Bejeweled, Zuma), is using Active X for their browser-playable games. But their recently released open-source framework does not expose the ActiveX elements, and in reading the FAQs and other info on their site, their support for Active X seems a bit tenuous, going forward.
Objective C - Interesting variant of C in many ways, but it can really only produce executables for the Macintosh, and perhaps with some fudging, *nix OS’s (i.e. Linux). With no ability to target Windows, it’s easy to rule out.
Visual Basic, C# - Both are Microsoft proprietary implementations of Basic and C, respectively, that are included for free in the Visual Studio .NET software (which I own). I checked out Visual Basic - it’s as I remembered it from my corporate days more than a decade ago - very easy to lay out forms and access data from corporate SQL servers. You can even compile to EXEs. But it requires users to download the 19MB .NET assembly. Fine for a corporate environment, but not realistic for downloadable games. I didn’t actually test C#, but it’s got the same limitations as VB (19MB .NET download required), and, from reading up on it, doesn’t offer any really big advantages over regular C++ to justify the limitations for the games market.
Perl, Python - I didn’t actually try these. They appear to be popular for web apps, but I saw little evidence of anybody using them for games. (The top google site for Perl Games yields a few text-only, downloadable games. Googling for Python games yields only downloadables, not browser-playable games). If few are using them for games, there’s probably a reason – I skipped them. If anybody has any compelling rationale why these do a good job of fitting my criteria above, let me know.
Shockwave - Macromedia, the makers of Flash, also make a higher-end product called Shockwave. You create Shockwave playable games in their $1,200 Director program. Shockwave has support for 3D and more optimized 2D than Flash. But the Shockwave player has a much lower market penetration than Flash. Moreover, Macromedia seems to be de-emphasizing Shockwave and pushing many of it's features into the more ubiquitous Flash. So I skipped Shockwave in favor of Flash.
WildTangent - Like Shockwave, another product that theoretically allows advanced 3D games to be played in-browser. Also like Shockwave, it appears that end-user support for playback is low, and that WildTangent as a platform is fading. I saw virtually no discussion of WildTangent as a viable option among development community-forums. It appears WildTangent's day has passed, and so I skipped it.
The Finalists
With the above languages ruled out, there were three contenders:
1) Flash
2) Java
3) Compiled C/C++ hooked to DirectX, using the SDL library.
The first two all promised the elusive goal of in-browser gameplay. The last option requires the user to download and install something, but it was my fallback solution if the others proved inadequate.
Before talking about the language features, I want to go into in-browser support, since that was the #1 criteria at the start.
In-Browser Support
Users are reluctant to install things. Moreover, since the advent of Windows XP Service Pack 2, Windows offers far more warnings (many of them rather severe in tone) when users try to install stuff. Sometimes the user won’t get the option to install at all - they don’t notice the ‘click on this bar to unblock this’ message, or
firewalls prevent any kind of installation.
So the goal of in-browser support is, if possible, to avoid any kind of install and any kind of scary Windows messages. If that’s not possible, then the process should be as low-pain as possible.
Flash is the clearest case. Macromedia (the makers of Flash) have done a great job in getting wide distribution for Flash. There’s little question of future support – Microsoft has no real ambitions to squash Flash, and pretty much every PC sold these days includes Flash pre-installed. If the user has the right version of Flash installed, your Flash app will run cleanly with no Windows warnings. Flash works on all browsers (including Firefox), and all major platforms (Windows, Mac, Linux). One vendor, Macromedia, controls Flash, and there’s not too much version confusion and the like.
Java is a bit more muddy. It has been a pawn in the struggle between Microsoft and Sun for control of the internet. Developed by Sun, the first versions (1.0 and 1.1) were integrated into Netscape and Internet Explorer early on. But, when Microsoft was unable to grab control of Java, they stopped updating the version of Java that was pre-installed on I.E., meaning that most users running vanilla I.E. on any machine bought before 2004 are probably running Java version 1.1, which was originally released all the way back in 1997. Then, last spring, to resolve a long-running lawsuit, Microsoft pulled integrated support for Java out of I.E. I.E. can still run Java (the latest version is 1.5), but they have to get it from Sun’s Java website (a 9 MB download), or their PC maker has to pre-install it (which many, but not all, do).
Finally, if you're prepared to give up in-browser support, you can use plain old C/C++, ideally with a graphics library (I used SDL) to help you along. But this kind of app must be separately downloaded and installed.
Development
I programmed a simple, classic game (Snakebite) in each of these three main alternatives (Flash, Java, C). I had no prior experience with Flash or Java, whereas I have extensive experience (12 years of game development with C). The following evaluations are based on my experiences making that simple game.
Flash
I started with the 30-day trial version of Flash MX 2004 (full version costs ~$500) and a copy of Glen Rhodes' Macromedia Flash MX 2004 Game Development. The book is excellent - diving right into the games without a lot of upfront tutorial. It includes all code, assets and a tutorial for the development of seven different 2D games of wide variety, all suitable to be played in a browser. I spent my first day reading the book and playing with the examples, then spent my second day building a Flash version of Snakebite.
Flash shows a lot of promise, but is extremely frustrating for an old-school developer like me.
Pros:
1) Very tailored towards 2D graphics - API has rich support for scaling, rotation, transparency, etc. Many animations can be laid out in their integrated graphics editor and played back from code with a simple function call.
2) Basic rendering pipeline is very easy to use - Basically, there is no pipeline. You just add objects, either in the graphics editor or dynamically with your code, and the Flash player auto-magically handles rendering, page-flipping, etc. The user can resize the playback window (if you let them), and the graphics automatically scale.
3) Deliverable size - Flash has good tools to support compressed graphics and sound, and it keeps your codebase small, too. Flash packages everything up into a single .SWF file. My .SWF for Snakebite is only 45KB. And that .SWF can easily be launched from a website, or simply run on your desktop by double-clicking on it.
4) Syntax - Flash and Java both use a C++ like syntax which is easy for a C++ veteran like myself to pick up. That said, the higher level organization and details of Java are more C++-like than Flash, so it's easier to take code between Java and C++ than between Flash and C++.
Cons:
1) The U.I. for code editing - It's awful. This app was clearly tailored at graphics artists doing simple 2D animations and the like. The support for code/scripting has been bolted on over the years, and is not graceful. By default, Flash wants you to enter all your code in a tiny box comprising perhaps 15% of the editing window. You can resize it and make it larger, but every time you run your app (i.e. to test it), Flash changes the size of your code editor back to something smaller.
2) The U.I. in general - Aside from the actual code-editor, the overall U.I. is the worst I've seen on a major app in 10 years. Basically, the U.I. does not like overlapping windows or tabbed windows - it wants every possible window to be either tiled or minimized. Because you need a lot of windows open to get anything done, each one tends to be very small, and you have to use the scrollbars within them constantly.
3) The Debugger - ...is terrible. You're more or less reduced to printf debugging.
4) Variable naming/declaration - You can declare any variable at any time, and Flash generally won't give you any warning. If you declare a variable at the top of your code, then try to call it further down, but misspell it, you'll get no warning - Flash assumes that you've got two separate variables. This leads to some very hard to debug cases (which are even harder because of the bad debugger.)
5) Performance - As detailed in the Benchmarks section, Flash executes complex code and complex drawing VERY slowly - enough to matter for even modest 2D games.
6) Portability - As detailed in the Market Share section, Flash is a better solution for cross-platform browser playback, and both Java and Flash can fairly easily be made into stand-alone desktop executables on both PCs and Macs. However, beyond the PC/Mac space, Flash is much less useful. You can't easily take Flash code to consoles, mobile phones, or across to C/C++ for use in other specialized instances. Java is more broadly supported on mobile phones, and Java is more C++ like, so it's easier to port Java code to C++ and use it that way.
7) No MIDI support - MIDI is a great solution for game music playback on the web - a four minute song can be represented in about 25KB, versus about 3840KB for MP3. But Flash doesn't support MIDI (only the larger, and less versatile MOD is supported), so it's very difficult for a small Flash game to have decent music.
Note that many of the U.I. flaws can be worked around - see this article for full details. But out of the box, Flash is not a great code-development environment.
2D/3D
Flash does not support 3D at all. You could probably hack a crude renderer together in Flash, but you wouldn't want to - it would be very slow. Flash's big brother, Shockwave, does support 3D, and there are a number of 3D Shockwave games at www.shockwave.com. That said, the Shockwave player is only installed on about 52% of all PCs, so you can't count on most users being able to play it painlessly. At the moment, for 3D gaming, you're generally looking at a download for the end-user, so you might as well program in C with a good 3D library/engine.
Java
I downloaded the free Java SDK from Sun's site and took a stab. Java by itself does not come with an IDE. Hard core Java-heads develop using Windows Notepad and a command line compiler. That sounded rather primitive, so I tried two well-regarded, free, Java-oriented IDEs - NetBeans and Eclipse. However, the combination of powerful, but very complex IDEs with a language I was unfamiliar with was too much. I was soon overwhelmed by both and unable to do much beyond compile their "Hello World" examples.
After putting Java aside for a while, I purchased two books - David Brackeen's Developing Games in Java and Andrea Steelman's Beginning Java 2. I tried to start with Brackeen's book, figuring I'd get right to the game development as I was able to do with Flash. But Java is a complex language, and Brackeen's book assumes a knowledge of Java before you start. So I switched to Steelman's general book and made rapid progress.
First, Steelman urged using Notepad or another simple text editor such as the excellent TextPad. This time I took the advice and started simple (I used TextPad). This proved successful - I was compiling and tweaking the examples quickly, and was able to grasp the fundamentals of Java within 4-5 hours (greatly enhanced by my experience with the very similar C++).
Then I tried to move to Brackeen's game book again, and again I was put off. The game book starts with, of all things, a lengthy lecture on threading. It then moves into games, but the entire game content of the book is aimed at full-screen, stand-alone Java games. I wanted in-browser games (that could also be made stand-alone). The Brackeen book proved unhelpful, so I abandoned it, ventured onto the web, and found an excellent site here, with examples of simple 2D games running in browser - just what I wanted.
In very little time I had the example up, and soon was building out my own Snakebite game. As with Flash, building the game took about a day, and there weren't any major stumbling blocks. Developing in Java felt very much like developing in C++ - I wasn't relying on an overbearing IDE, but on the flipside, I missed Flash's great graphics layout tools. Overall, I felt comfortable in Java and felt that I could make a full transition, with my C++ skills, in a very short time.
Pros:
1) Flexible - You can use any IDE you choose, write any functions you want, and so-on
2) C++ like - Felt very familiar and comfortable for me. I was able to bring in logic from C++ programs with very few changes
3) Debugger - While you can't debug easily using the Notepad/command line approach, I tried using Eclipse to debug the one problem that stumped me, and was very happy with the Eclipse debugger - it was roughly the equal of Visual Studio .Net's excellent debugger.
Cons:
1) Version confusion - There are a lot of Java VMs and versions floating around. After completing my app on my primary machine, it wouldn't run on any of the other three machines I tested on, due to version issues. However, using info from here and old Java VMs from here, I was able to test under different Java VM versions on my primary machine, and I quickly isolated and fixed the problems. My game now should run on any Java VM from version 1.1 on.
2) 2D library not very deep/robust - The 2D library calls in Java 1.1 (the version my app tailored to) are pretty basic. Sprites can't be scaled or rotated. It is possible to write routines to do these things, but the routines would be interpreted, rather than native, and therefore rather slow.
Overall, Java seemed like a great language and one I'd be happy to work with. However, it does not have the market penetration of Flash.
2D/3D
Java can support 3D, through either 3rd party libraries or direct interaction with OpenGL. However, from what I can tell, all such 3D support requires the user to make separate downloads of either the libraries, or a compiled version of your game. So, if you're really targeting 3D, the users will have to download regardless, and in my opinion you'd be better off just going with C++, which has even more flexibility in this regard.
C/C++, Using the SDL Library
I'm a C/C++ veteran, with 12 years of game development experience using C/C++ games, the majority of it doing 2D games. But I had been working with graphics libraries that had been built up over time, and are proprietary to PopTop, my former company. Those libraries did a lot of work to get around Direct X's eccentricities and handle error cases. Moreover, the libraries weren't cross-platform. I wanted to see how fast I could bang out my Snakebite game starting without any proprietary/legacy libraries, and trying to create something that's cross-platform, too.
I had already bought Microsoft Visual Studio .Net 2003, for about $560, saving a bit of money (legitimately) using an upgrade work-around.
After some research, I settled on the open-source SDL as my graphics library. It supports Windows, Linux and Mac, is mature and offers good 2D support.
I was very impressed with SDL. I was able to get a sample app up very quickly, and then moved rapidly into SnakeBite. I got the basic Snakebite logic up and running in perhaps two hours. I spent longer dabbling with font drawing, sound, and secondary issues. Overall, I did the game in a day, but spent a fair amount of that time experimenting with pieces that were only semi-related.
I have not as yet verified how easily the code can be compiled to Mac and/or Linux. I just ordered a mini Mac and an extra (really cheap used) PC for Linux. Neither have arrived yet - results when I get the machines and test on them.
For me, C/C++ issort of a baseline to compare everything else with. That said, here's my view of the C/C++ with SDL approach.
Pros:
1) Great IDE - Visual Studio has a wonderful (though complex) IDE. Fortunately, I'm already very familiar with it.
2) Great Debugger - Edit-and-continue debugging only works sometimes, but general purpose debugging is nearly flawless.
3) Cross platform support - Apps that use C/C++ with SDL can run on the 3 major desktop platforms (PC/Mac/Linux). And basic C++ code with different libraries can power games on pretty much any platform, including consoles and mobile devices.
4) Powerful - Any game you've seen can be built with C/C++ - most of them were built with C++. Although it can't create browser-playable games, it can do most anything else.
5) Fast - The Visual Studio compiler is very good, and because you've got direct access to the system, you can optimize the inner loops as much as necessary to achieve any result.
Cons:
1) Not browser-playable - Unfortunately, creating a game that can be played in a browser was my main goal, and C fails in this regard. There are some solutions for browser-playability for C (Active X, .Net, WildTangent), but Active X is insecure and very problematic, and very few users have the necessary libraries installed and configured for .Net and WildTangent.
2) Complex - I've already climbed the learning curve for C++. But for those who haven't, it can be very intimidating.
3) Fat - The compiled EXE and DLLs for my game compress to 489KB, versus ~10KB for Flash and Java. I could pare that size down by writing some libraries myself in a tighter fashion, but that would take a fair bit of work.
Alternative 2D Libraries
I played mainly with SDL, but there are actually many, many libraries available to C/C++ programmers that provide varying levels of support for 2D games. The two most prominent alternatives are Torque2D, priced at only $100 and available from the indie-focused publisher Garage Games, and the PopCap Games Framework, by casual games developer/publisher PopCap, makers of Bejeweled and Zuma, among others.
I have not looked too closely at Torque2D, but from the info and example games on their site, it appears to be aimed more at action 2D games, with features such as physics and a particle system. It supports Windows, Mac, and Linux.
The PopCap Framework was only just made public, at the beginning of the 2005 GDC. Since PopCap's games have primarily been 2D puzzles, it shouldn't be surprising that the framework seems tailored towards that game style. The framework has plenty of support for interface elements (buttons, windows, etc), and fonts, but no support that I can see for action game staples like particles and physics. The framework currently only supports Windows (with optional support for hardware acceleration), though on their forums, at least one Mac developer plans to port the framework to the Mac in the very near future. The PopCap framework is free, requiring only an acknowledgment in the credits or documentation.
2D/3D
While my focus is mainly on 2D at the moment, there are many solutions to creating 3D games in C/C++, including a number of free/cheap libraries to give you a jump start.
Market Share/Reach
The #1 reason (for me) to use Flash or Java over C++ or any other alternative is that games using the first two should be playable, painlessly, by the vast majority of would-be gamers. But how well does that hold up? Here’s what I was able to find:
To try to sort out how widespread the support for Flash and Java is, I did a bit of research. Macromedia claims Flash is the real winner, with 98% market
penetration, versus Java’s 87%.
But, dig a little deeper, here:
http://www.macromedia.com/software/player_census/flashplayer/version_penetration.html
and you’ll see that a lot of that support is for old versions of Flash. The current version (version 7) only has 83% penetration in the U.S. (though version 6 is much better at 95%) And while Java is shown to have an 87% overall penetration, I was unable to locate any specifics as to Java versions. So I did some ad-hoc testing, as follows:
First, I checked the four machines we have in the house, of varying origins. They came back as follows:
All these machines have been used for web browsing and the like for 1-4 years, yet only two of them had the current Flash version and only 1 had the latest Java VM (and that was on my high-end Compaq - I can't remember, but it may have gotten the Java 2.0 VM when I went to install the Java SDK).
So then I went to my local Circuit City to see what was installed on the demo machines there - all current machines running Win XP, presumably assembled in the last 3 months or so. I'm only listing manufacturers here, as software pre-installs are generally uniform across a manufacturer's entire product line:
So, between my menagerie of machines and those at the store, Flash was supported in every case, although frequently it was version 6. Java support was far more varied, with a couple of machines omitting it entirely, and others stuck with the old MS JVM at version 1.1 (dating from 1997).
Note that all Macs ship with Java and Flash (latest versions, AFAIK). Java and Flash can also both run on Linux, though I believe they're rarely included in standard Linux distributions, because they're proprietary, and the default Linux distros only include open source software.
It seems that using Flash and sticking to version 6 is the best way to use a fairly current-version development language and be able to run right off the bat for the vast majority of users. Macromedia's quoted 95% penetration for Flash 6 seems reasonable, given my above data. Note that while Flash 7 has an option to publish SWFs in Flash 6, when I tried it, the resulting .SWF file still wouldn't play on a Flash 6 player. If you plan to publish to Flash 6, my advice is to buy an older copy of the Flash development tools off of EBay.
For Java, it seems like the way to go is to target the lowest common denominator - version 1.1. Even at that threshold though, two of my 11 test cases completely lack Java support. Again, this is in accordance with Macromedia's statistics.
For the ~5% and 15% respectively (Flash and Java) who don't have the product installed, it would appear that for Flash it is easier to add-on, with the download coming in at 700KB, versus 7 MB for Sun's Java. Both installs do require a reboot for Windows users, though.
The Future
How will Java and Flash fare in the future?
In general, I see no reason for Flash's prospects to change much over the next couple of years. There's no real current competitor for Flash from Microsoft or anyone else. Microsoft is rumored to be working on a technology called Sparkle, which may be loosely targeting Flash in their upcoming Longhorn version of Windows. From what I've read on Sparkle though, it doesn't really seem like a Flash-killer, and anyways, Longhorn is likely 1+ years from release, and 2-3+ years away from widespread market penetration.
Java's future is dicier. Sun seems to have wavered a few times over the last 5 years in their commitment to Java on the desktop. Microsoft hates Java and would like to kill it. They stopped bundling it with Windows XP in spring '04, and now only those manufacturers who have a deal with Sun include it. (Admittedly, this is similar to Flash's situation, but Macromedia appears to have had success in getting Flash pre-installed on every new PC, whereas Sun's record is spottier).
My seat-of-the-pants estimate is that it's probable that Flash's market penetration will remain high for at least the next 3 years, whereas Java's penetration might begin to slip further in that timespan.
Game Portals
If you want to commercialize your casual game, you have to reach an audience. These days, that means distributing your game through one or more of the ~6 major and ~50 minor game portals (Pogo, Yahoo, AOL, MSN Games, etc). Do these portals have a strong technology preference?
I browsed the major sites and played many of their games. You can usually tell that a browser-game is made in Flash by right clicking on it (which gives you some Flash specific options). Java games are obvious because while they load, a Java-standard loading screen is shown. From this type of inspection, as well as reading a summary of their opinions as of last year's GDC here, it appears that most of them are technology ambivalent - open to either Flash or Java, and in a few cases, still supporting ActiveX as well. A lot has changed in the last year, i.e. the impact of Windows XP Service Pack 2 (which really killed Active X), and the Sun-Microsoft Java settlement (which hurt Java), both events occurred in the last 12 months. But for now, anyways, it seems that both Flash and Java are acceptable to the portals.
Benchmarks
There are two kinds of relevant benchmarks to compare Flash, Java, and C++.
Benchmark 1 - Arithmetic
First, you can compare their raw ability to execute code (semi-interpreted for Flash and Java, compiled for C++). Here's my results from a very simple benchmark I performed a couple weeks ago (details here)
Arithmetic processing results (milliseconds to complete benchmarks, lower is better)
Visual C: 16
Java: 352
Flash: 10,753
For general purpose processing, Java is much slower than compiled C, and Flash is much slower than Java. Since I posted that story, a couple readers posted comments indicating ways that Java might be sped up. Admittedly, I'm no expert - there probably is room to improve the Java results through various voodoo. Flash, on the other hand, doesn't seem to have a lot of options for improvement, performance-wise. It's a pig.
Benchmark 2 - 2D Graphics
Probably the most important benchmark for my purposes is the ability to draw 2D graphics. Can a game with complex 2D graphics run at a reasonable frame rate on the kinds of older PCs often used to play casual/browser-games?
My benchmark was to measure the frame rate of my Snakebite test game. I unlocked the frame rate, added a frame rate monitor, and measured the results on a few different machines. Since the game is so simple, I also wanted a simulation of more complex 2D graphics, with more overdraw. So I tested by drawing the entire screen (background and objects) from 1 to 10X before blitting to the screen. In my estimation, a static-screen puzzler would probably, on average, be most like my 2X overdraw result, whereas a scrolling action game would be most like my 5X overdraw result. Flash is NOT included for now (see below)
In general, the Java versions held up respectably - much more so than Benchmark 1's arithmetic test would suggest. The reason for this is that drawing 2D graphics is primarily a function of memory copying/blitting, and internally, the Java Virtual Machines are undoubtedly executing this with a compiled, native mode function. I only did a side-by-side C versus Java test for the first machine - the AMD, and on that machine, Java outperformed C in the heavy overdraw cases that most closely resemble a complex 2D game. Carrying the Java test across the older machines shows that performance doesn't take that much of a hit as the CPU and video card drop down. Again, 2D graphics are primarily about memory speed (system RAM, not video card RAM), and system RAM speeds haven't been improving as much as CPU speeds over the years. A new machine with a CPU that's perhaps 4X faster than a 3 year old machine will have system RAM that's perhaps 2X faster than the 3 year old machine.
I've listed the Flash results separately, because the testing for Flash had to be done differently, and produced some odd results. Flash is not very conducive to this kind of test. The Flash player manages the rendering process itself. Framerate is capped and can't really be unlocked. Because Flash manages the screen draw (using a dirty rectangle system), using the overdraw system I did wouldn't really work (Flash would just ignore the overdraws). I could only do the 1X overdraws (i.e. no overdraw), and I had to force Flash to draw the whole screen by positioning objects that changed visually in opposite corners of the screen (thereby forcing Flash's dirty rectangle system to consider the whole screen to be dirty.
I initially tested by double clicking on the .SWF file on my desktop, and the results were good - 77 fps on my AMD 3000+, vs. 97 for C and 56 for Java at comparable 1X overdraw levels. However, when I uploaded that same SWF to my website and launched it in Firefox, the framerate was cut in half, to 37 FPS. Running in Internet Explorer also produced a speed hit, but not so severe. I tested on a different machine and found a similar speed drop off between I.E. and Netscape 7.5 (Netscape 7.5 and Firefox share code origins and both use the same Gecko rendering engine). I went back and re-tested my Java results and found that Java performance was the same in I.E. and Firefox. I couldn't test Java outside of a browser as my game was not set up for that.
My best guess is that the Flash player plug-in is particularly optimized for desktop playback, and particularly unoptimized for Firefox/Gecko playback. But it's worrying that, running in Firefox, my simple 2D app only pulled 37 FPS at 640 x 480 on my high-end system. On the lower end system, at 1X overdraw, in Firefox, Flash ran at 18 FPS, versus 28 for Java. For more details on Flash performance considerations, see this article.
Conclusion
Java should be fast enough for any reasonable 2D game thrown at it. Flash should be able to handle any reasonable static screen game. Neither is very good at heavy duty arithmetic (Flash in particular is abysmal at this), so complex simulations (like my Tropico or Railroad Tycoon 3) rely on a lot of math under the hood, and their economic models would have to be greatly simplified to have acceptable performance under Flash.
Conclusion
Overall, I was pleased with the results of my experimentation.
There are two viable languages for browser-game development - Flash and Java. Other contenders, notably ActiveX, are not suitable.
Both Flash and Java allowed me to develop my Snakebite game in about 2 days each - 1 day to learn the language and 1 to write the game. I was able to create browser playable examples right off the bat, though I did have to test and tweak against old versions of Java, and my Flash code is written to version 7, whereas, for compatibility reasons, I would use version 6 going forward.
SDL proved to be a great companion for C/C++, and I was able to rapidly code the game in that environment, as well.
Assuming I go ahead and make more browser-games, either simple ones like Snakebite or more elaborate ones for distribution on gaming portals, I give the slight nod to Flash among the choices. Although it has many drawbacks, including poor performance, it also has the broadest market penetration, and therefore the best and easiest experience for most game players.
However, if I was thinking about something with complex, scrolling graphics, I would do a quick test to see if Flash could sustain an adequate frame rate, and be prepared to fall back to Java.
Neither Flash nor Java seem to be great choices for stand-alone, downloaded games. So I may just choose to write my first full app in C++, using either SDL or the recently released PopCap framework, then port back after the fact. For porting from C++, Java seems slightly more attractive than Flash.
Additional Resources:
2004 IGDA Web and Downloadable Games White Paper (93 pages, very detailed)
Excellent Article on Commercial Flash Development (by former hard-core C game developer)
Evaluating Java for Game Development (lengthy paper by an academic, has some good insights)
SDL Home (Free downloadable SDL library, for cross-platform C/C++ development)
______________________________________________________
Read more about:
FeaturesYou May Also Like
