|[ LiB ]|
I think it's time for a demo, don't you? On the CD, you will find a folder called GDA_CH02, and in that folder you will find a file named GDA_PROG2.1.swf. Go ahead and double-click on it. A splash screen similar to that in Figure 2.3 will open .
You can play the game by moving your mouse up or down to move the paddle. Try to make the ball bounce back to the computer player. The objective of the game is to make the computer opponent miss . Once you get 30 points, you win. On the other hand, if the computer gets 30 points, you lose.
I chose to make a simple game like this one so you wouldn't be distracted playing the game while you should be reading the chapter! Actually, the real reason is that I can easily strip this game down to its bare design bones. This way, I can demonstrate the production pipeline to you with parts of the game that you can relate to.
What went on in my head before I produced Battle Ball 2003 ? Well, like any project, it all started out with an idea. Ideas for a game are usually developed from a story, but I decided to skip the details of the story for this demo. The story, in this case, isn't the most important thing. So what is? The fun factor! It can't be considered a good game if it's boring!
No matter what crazy ideas you have for your games , always consider the fun factor. No matter how many pretty graphics and awesome sounds effects you may have, you won't have a great game if you don't also make it fun to play. Otherwise, it's just another Flash movie.
Before I go on and talk about how I prepared my idea for the demo in this section, I would like to talk about how you can conceive an idea for your game.
Assuming that you're a game player, you have definitely seen things in other games that you like. I suggest you start a checklist of effects and/or functionality that you would like to program into your own game. From this list, other ideas spring out that you can also jot down until you have a well-rounded idea for a complete game.
No idea that you think of in the beginning is to be etched in stone. Most of the best ideas in this industry occur during production, so don't reject anything that sounds goodthe idea you thought sucked can turn your game into a bestseller.
As for the demo in this section, I decided to dig up an oldie that was a hit in its time. This game has a simple computer opponent that tracks the position of the ball, and when it makes contact, the ball bounces back to you. Your job is then to hit the ball back and not let it get past you. If you miss the ball, then the opponent scores. Whichever player gets 30 points first wins the game.
As it's basically a sports game, a story wasn't really necessary. So I went ahead on to the next stage after I figured out all the details. These details consisted of how the opponent is supposed to act, how the player's input would be processed , and how the ball will react to all this battling.
Throughout this stage, you shouldn't think of touching the computer until you have a solid idea for your game. Many novice programmers have the bad habit of going straight to the computer and coding away. These are also the people that end up spending most of their time fixing errors in their programs. If you are not careful, the ideas stage can take up more time than actually coding the game. If you're organized, coding is a breeze .
How would you approach a program like this? Well, think of your options. You could go ahead and work on the superficial stuff like the graphics, or you could work on an area of code that you think will be the hardest. These two methods of approaching the program are called the top-down approach and the bottom-up approach, respectively. The top-down approach means starting with the basic idea and refining it and adding details, while the bottom-up approach means starting with individual details and then expanding them and connecting them with each other until they form the big picture. In other words, "top" means the general, basic idea, while "bottom" means the nitty-gritty details. Makes sense, doesn't it? Which approach you choose will depend on the project at hand.
I didn't feel Battle Ball 2003 should be graphics- intensive , so I left the art for last. I actually went and ironed out my idea on paper. It's always a good idea to make some preliminary sketches on paper in order to have a better idea of what your game would look like in the end. More importantly, it will give you a guideline for how you should approach and design the visuals later on.
Besides all the chicken scratch all over my notepad, I got a few important things out of my sketches: I decided that the opponent will have a very simple AI, or artificial intelligence. But before I present the AI, I would like to introduce what is called pseudo code . Pseudo code is an English representation of computer code. It usually helps to write, or sketch out, your stuff in pseudo code before you hit the computer because it helps you nail down the logic (for your program) as you originally planned it in the idea phase of the game. There are no rules when writing pseudo code and people tend to have their own style when writing it. The point of it is for you to gain a clear vision of what you are about to code in ActionScript and it's also a way you can work out logic on paper. Take a look at the following listing.
Whole books have been written on AI, but this book doesn't concentrate on making opponents too smart for two reasons. One: I wouldn't want computers taking over the world. Two:You need to concentrate on your solid programming foundation!
IF Ball is coming Towards me THEN IF Ball's Y-Position is Greater Than mine THEN Move towards the ball's Y-Position END IF IF Ball's Y-Position is Less Than mine THEN Move towards the ball's Y-Position END IF END IF
If you try to read through this pseudo code, you will see that there are a few comparisons happening here. Let's step through the code, shall we?
The first IF statement checks to see if the ball is coming towards me. In this case, me represents the computer opponent. If it is, it then executes anything inside the IF block.
An IF block is generally anything inside the IF...THEN...END IF state ments.We will see what ActionScript blocks look like in the next chapter. For now, we'll be happy playing with pseudo code.
The next line checks to see if the ball's Y-position, or vertical position, is greater than mine. If it is, then I'll try to match the ball's position. Stop right there a second! It seems as if I'm just restating the pseudo code. And guess what? I am. The logic is so close to English that you can almost understand it right off the first read. Computers happen to use similar logic, so it's a good practice to "think" like the computer by using pseudo code.
The next block checks to see if the ball is lower than the computer's position. If so, the computer opponent then goes and tries to match the ball's position. Keep in mind that neither of these two inner IF statements will execute if the outer IF isn't true. In order words, Player 2 won't do anything if the ball is going away from him (or "it," in this case).
And that is the extent of the opponent's AI. Did you ever think it would be this easy? I recommend you go to the game one more time and examine the way Player 2 behaves. Isn't it freaky ? It sometimes seems to "think." Check out Figure 2.4.
I know that some concepts that I'm explaining may be unclear at this point, but I just want you to get the overall feel for this.We get to the real stuff in the next chapter and the chapters after that.You will benefit more from this book if you read it straight through while doing the exercises all throughout.
Notice that in Figure 2.4 I slightly changed the pseudo code. My objective is to introduce you to ActionScript slowly in a non-intimidating way so that you can feel comfortable and take over the world if you like. I prefer if you use these powers for good, but who's stopping you? Anyway, the pseudo code you see in Figure 2.4 goes like this:
If Ball._y < this._y then Move this._y down!
This is still not ActionScript. It's just a tease. It is very similar, especially in the dot notation. For instance, Ball._y means that _y is a property of Ball and none other. So what this code is saying is: "If the property _y, or vertical position, of Ball is less than the property y , or the vertical position, of this, then move this._y property down in order to match the ball's position."
The code for Player 1 is the simplest of all. It basically matches the cursor's vertical position. Check out the following listing and see how similar it is to the computer's AI.
IF Mouse's Cursor Vertical Position is Different than mine THEN Match Mouse's Cursor Vertical Position END IF
Simple enough, but let's go through it anyway. Notice that we aren't restricted from moving at any time. The computer was allowed to move only when the ball was moving towards it. In the preceding listing, you can see that
IF Mouse's Cursor Vertical Position is Different than mine THEN Match the Mouse's Cursor Vertical Position
This basically makes the graphic that represents Player 1 jumping to where the mouse is located. Since you are tracking only the Mouse's Cursor Vertical Position, the cursor's position only allows us to move up and down.
And now for the ball's AI. The following listing shows you just that.
IF Ball hits top wall THEN Reflect Position IF Ball hits bottom wall THEN Reflect Position IF Ball hits either player THEN Reflect Position IF Ball reaches left side of screen THEN Add 10 points to Player 2's score IF Ball reaches right side of the screen THEN Add 10 points to Player 1's score
There's a little more code here but it's a bit repetitive. This repetition allows us to break it down and understand it completely. When the ball hits the top wall, its vertical position will be reflected, making it appear as though the ball is bouncing. (All this math will be explained later, so sit tight.) You see something similar when the ball hits the bottom wall: it also reflects. If the ball goes by either player, it will bounce off that player.
The next section is the juicy stuff. This is where all the scoring takes place. The game is governed by the scores when it comes to winning or losing.
IF the ball reaches the left side of the screen THEN Add 10 points to Player 2's score.
The score is also updated on the screen in this block but no need to worry about that now. You will be an expert on that when the times comes.
IF the ball reaches right side of the screen, which means the computer misses, THEN Add 10 points to Player 1's score.
The score is also updated on the screen in this block.
There is a section in the pseudo code that will analyze the scores and change the flow of the game as the game progresses. This will also be covered later.
Now that it seems that you have a complete game with a purpose, you can begin putting together the FLA file. That's exactly what you'll see in the next section.
What elements does a game need? Questions like this are what you should think of when preparing the source FLA file.
For one thing, the game needs a splash screen. This is the first screen that you see in any complete game. You also need the stage where the game is played. You also need the appropriate screens for winners and losers. Instructions should also be included, for people who have never played your game before.
Before touching the computer, I recommend tracing this setup out on paper. Make a simple checklist of what you need and then incorporate all the elements. Check out Figure 2.5 and try to follow it before reading on.
Here I put together what my overall game logic should look like. Doing this on paper can usually solidify your idea, and more advanced concepts can be applied from there. For the purpose of this chapter, I kept it simple enough so that anyone could understand what's going on.
I originally wanted the splash screen to have instructions, so I posted it that way. From the splash screen, a game will usually branch out and give the player various options for how to play, but this game is so simple that no options are given. The user will be able to go right from the Intro screen to what is called the main loop . This basically means that the program will keep doing what it's doing until something changes it. In Battle Ball 2003 , one of two things can happen: the player can lose or the player can win. If the player loses, a Game Over screen is displayed and the player is given the option to go back to the main menu, where everything starts all over again. If the player wins, he is taken to a winning screen and given the option to go back to the beginning and play again.
Now that you have mapped out exactly what's going to happen, you can go to the computer and start clicking and typing away. Everything should be a simple application of all this setup planning. This should be the fun part.
If you don't perform any of these setup procedures, you will probably live to regret it. I want you to like programmingthat's why I stress preparation and organization so much.
If you followed all of my suggestions in this chapter up to this point, you should have diagrams of your overall game logic, pseudo code for all your game functions, and an idea or sketches for each of your screens. All this preparation will aid you in the code writing process even though I haven't gone over how to sketch out ideas for your screen design yet, so don't freak out. I understand that most people are not artists , but sketching on the computer is also possible, and I recommend it because many other ideas usually sprout out from a simple brainstorming computer-sketch session. Try saying that three times fast.
We will mainly focus on writing code in the rest of the book.You will actu ally do exercises that will get you used to the process of writing code. As you progress through the book, I will start assuming that you know how to do very simple tasks like opening windows .
There are a few things that are worth mentioning again and again to the novice programmer. Here's one: you should test your code throughout the whole coding process. Don't wait until you've written 500 lines of code to test your program. The errors will drive you crazy. It's a good idea to keep your program sections about one screen length. This way you can easily trace errors and concentrate on solid code. Once that section is nice and complete, you can then move on to the next block.
One harsh reality when it comes to programming: You will always make mistakes. Don't think that after reading this book you will be an expert. You have to practice, practice, and guess what? Practice some more! The only way to become an expert is by practicing all the time, not by simply reading really good books like this one.
This is the time when you roll up your sleeves and start hunting.
Bugs can lurk in your code even though all your code was read in correctly. For example, let's say you wrote up a set of instructions to move your little character across the screen. He's basically supposed to walk forward and at the end of his journey, pick up a prize. Instead, when you run the program, you catch the character doing the moon-walk! You do not want this, because this is a nasty walk...I mean bug .
Errors in your programs are com monly called bugs .The process of finding and fixing these errors is called debugging .This is a very criti cal stage when you are doing com mercial work. Run-time errors is another term for bugs.
Why can't we just call the debug-inator? Oh waityou are the debug-inator! So when did you officially get this position and title? You earned it when you started to learn how to program. Now how do you put this title to use?
Well, before anything else, you should work to prevent bugs from occurring in the first place. I've set you on the path already by explaining good programming habits.
It is a good idea and practice to test parts of your code to make sure the pieces work.This way, if all the smaller pieces are intact, then you know the whole program will be a solid composition!
The next step is to find the bug. When you run your program, you have to push it to its limits and assume that the user will try to break your program. You have to make it break-proof. You'll encounter various examples of making a program break-proof throughout the book and book demos.
If you've been dedicating yourself to fixing up Battle Ball 2003 , you've probably found a few annoying bugs. I will leave them for you to figure out. Try letting your opponent beat you. Then try beating your opponent.
Okay, to satisfy curious minds, an example of bug-preventive program ming would be how Player 1, in Battle Ball 2003 , doesn't go past the upper or lower bounds of the screen when the mouse is pushed to the extremes.The implementation will become second nature to you soon enough. If the code wasn't written for this situation, you would actually be able to see Player 1 go off the screen when the player (the human one) got overly excited using the mouse.That would definitely not be good.
See if all that is working correctly. Then play some more and try to crash the program. This is part of the great debugging stage.
As a matter of fact, a lot of the big-time game programmers started out as game testers. This job entails essentially playing the unreleased game for hours on end and helping the producer to find bugs, in order to make it ready for public distribution.
And those steps, coming up with an idea, figuring out an approach, setting up the source and fixing bugs are what you should focus on for your future productions . Make sure you understand everything in this chapter before moving on.
|[ LiB ]|