- Inspirational Kick-Start
- Terminology
- Game Genres
- Flash Limitations
- Points to Remember
This chapter is from the book
This chapter is from the book
This chapter is from the book
Flash Limitations
Like all software applications, Flash games have limitations. Macromedia has added an amazing number of new features and capabilities to Flash with each release, but it can't do everything (yet). In this section I'll talk about the major advantages and disadvantages of using Flash to develop games, as well as discuss certain types of games that are not easily workable in Flash.
Flash vs. Non-Flash Games
While I'd like to tell you that Flash can outperform all other game-development platforms with its hands tied behind its back, that's just not the case. There are many reasons to choose Flash for game development, and there are many other reasons not to choose Flash. In this section we discuss the major reasons for both.
The pros of using Flash for game development
Not surprisingly, as I've put a lot of time and effort into Flash game development, I'll list the benefits first.
Web deployment—Since Flash files are designed to be viewed in Web pages, Flash is a good choice if you want your game to be available on the Internet.
Small file size—Flash makes use of vector graphics and compressed sound files, so a Flash game's final file size can be exponentially smaller than those of games developed on other platforms.
Plug-in penetration—The plug-in that's required for viewing Flash files in a Web page comes with all major browsers. More than 98 percent of people on the Internet worldwide can view Flash content. The exact penetration for each version of the plug-in is listed on the Macromedia Web site (go to www.macromedia.com/software/player_census).
Server-side integration—Flash games can talk to the server seamlessly. Using Flash's built-in features, you can communicate with server-side applications that make chats, multiplayer games, and high score lists possible.
File sharing between programmer and graphic artists/designers—With Flash, programmers and graphic artists can collaborate using the same files. This is rare in game development.
Ease of use—Perhaps one of the most attractive reasons for choosing Flash is that you can learn the program and start creating games in a very short time. With other languages, it could take years!
The cons of using Flash for game development
As I already mentioned, there are also some strong reasons for not choosing Flash as your development platform. It's important to know them as well, before you get started and encounter unpleasant surprises.
Performance—Macromedia spent thousands of hours making the required Flash plug-in for the Web as small as possible so that the maximum number of people could download it easily. But that required some sacri-fices, and the major one was performance. Flash underperforms virtually all other game-development platforms in speed of code execution and graphics rendering. On the other side of the fence, game-development platforms like Macromedia Director and WildTangent perform very well—but have enormous plug-ins. As a result, few people can view such content without being forced to download the plug-in in addition to the game.
Lack of 3D support—Flash doesn't provide native support for real 3D engines or for any sort of texture mapping (the act of applying an image to a 3D polygon).
Lack of operating-system integration—When you run your game as a Projector file, Flash cannot easily talk to the local operating system to do things like browse files on the hard drive. (But this type of integration is possible with the use of third-party software such as Northern Codeworks' SWF Studio, available at http://www.northcode.com.)
Most of the developers who choose Flash as their game-creation tool do so because they want their games to be available to many people easily on the Internet. If the intention is to have the game available offline on CD-ROM, then Flash is still a choice—just not necessarily the best choice.
Infeasible Game Features
It is much easier to talk about things Flash cannot do easily than to discuss everything it can do. Here I'll touch on some things that are very difficult to achieve in Flash, or that aren't feasible for another reason. I don't want to say anything is impossible with Flash, because there are so many creative people out there with dozens of tricks to make the seemingly impossible possible.
3D rendering with texture mapping
Many people have created 3D engines with ActionScript. A 3D engine is code that can take 3D coordinates and map them onto your screen. While these engines actually manipulate coordinates in 3D space and then map them correctly back onto a 2D screen, there are three major limitations:
Texture mapping—You cannot map textures (bitmap images) onto an object in Flash. As I have already mentioned, many people make creative attempts to get around program obstacles. This is one of them. Some people have successfully done very simple mapping onto flat surfaces. Nevertheless, this is a limitation. Mapping is not achieved easily and only works in some conditions.
Z-sorting—This refers to the order in which objects appear in front of other objects. In real 3D rendering games, the sorting order is not limited to whole objects, but can actually pierce surfaces of objects (if two things happen to be moving through each other). Flash is limited to sorting at the movie-clip level.
Speed—Three-dimensional engines written in Flash can typically handle only simple shapes, and they retain a frame rate close to the frame rate of your SWF. Complex scenes are often very CPU-intensive, and the frame rate can suffer as a result.
Real-time multiplayer games
Creating this kind of game is certainly possible, but for many reasons it is not easy to accomplish. One of the main factors is the nature of these games. Due to network latency, it would be very difficult, if even possible, to create a real-time multiplayer game like, say, Mortal Kombat. However, some real-time multiplayer games that lack interaction between players, such as a scavenger hunt, might be more feasible. We will discuss this more in Chapter 17, "Tic-Tac-Toe: Your First Multiplayer Game."
Intense real-time calculation
I know this sounds like a vague limitation. But when you're creating a game, it is important (although admittedly difficult) to think ahead and try to guess how intense the calculations are going to be. For instance, a game that has dozens of enemies—who all think for themselves and constantly run around trying to decide what to do next—is an excellent candidate to bog down the computer processor! You'll have to do a lot of testing and experimenting to determine exactly how many of these enemies the computer can handle and still perform well.
This chapter should provide you with a better idea of what types of games exist and which ones are possible in Flash. With this book you'll learn about all the pieces you need to build a game, from graphics to sound, and you'll see how everything was put together in several finished games. By the end of the book you should be well on your way to making your own gaming ideas a reality!