This chapter is from the book
This chapter is from the book
This chapter is from the book
Cut Back
In this step you decide if any features or game rules need to be changed or cut. If you could not meet any one of the requirements in the previous step, then you should consider cutting that feature. Following are some grounds for cutting a feature from your game:
Not being able to meet all the needs specified in the previous step.
Realizing (from your basic testing) that this feature would cause the game's performance to suffer.
A tight deadline will prevent you from finishing the game on time if you try to include all the features.
For example, one of the intended features of this 8-ball game is that it be multiplayer. In order to create a multiplayer game, you need to set up a piece of software on a server that functions as the link between all the players. This is called a multiuser server or a socket server (as will be explained in Appendix B, "Multiuser Servers"). If you are running your own dedicated server, you can, of course, install whatever you want. But chances are that a regular, commercial ISP will not allow you to install software. So then you are left with the choice either to pay for a more expensive hosting plan (a dedicated server) or to axe this feature of the game. If you cut the multiplayer feature but don't want your audience to have to play alone, then you may have to consider changing another feature. For instance, you might want to develop the game so that two people who are on the same computer can play against each other. Or if you have the time and inclination, you can program an AI computer opponent.
Don't have a dedicated server? Don't worry!
In Appendix B, "Multiuser Servers," we briefly explore options for people who do not have a server with which to host the multiuser software. For example, you may be able to host a simple game from your own home computer!
Another potential problem is the Flash Player application's performance. While Flash is great for developing games easily, one of its greatest limitations is the (lack of) speed at which it executes actions. In other words, it is easy to give Flash too much to do on each frame, hence increasing the amount of time that Flash needs to stay on each frame, which makes the overall frame rate lower. In our 8-ball example, if you don't employ some very tricky or extremely optimized ActionScript, chances are good that the Flash Player will play at a reduced frame rate when calculating collision detection between the 16 balls and each of the six pockets (I know this from personal experience). That is a total of 216 collision-detection checks per frame. While the speed at which these actions execute is dependent on the Flash Player, it is equally dependent on the processor of the computer running the game. If you are using a Pentium 4 computer with a 2-GHz processor and the game barely runs smoothly for you, then you can bet it will not run very smoothly for people with average computers.
So what is the solution? You can spend days or weeks finding ways to optimize the ActionScript for speed—or you can step back, take a deep breath, and cut down on the number of balls your game uses. The pool game called 9-ball uses only ten balls. That means it would only have to calculate 105 collision-detection checks per frame. While calculating this many checks may still be slow on some machines, it is less than half the number of checks for your original game of 8-ball. With some simple ActionScript optimizations you can cut this down even further. For instance, you might only check for pocket collisions when a ball collides with the wall. That would bring the detection down to 45 checks per frame.
The more time and effort you have invested in developing an idea, the more important that idea becomes to you, and so cutting back its features can be difficult. One of the best things about using a design process like this to plan ahead is that you can cut back on some features before spending the time to develop them and getting emotionally attached.