Features

Development Platforms for Casual Games

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++ is sort 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.

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service