- Shopping Bag ( 0 items )
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
These days people are looking to the Internet for its gaming possibilities. Whether it's real-time role-playing you're after with 30,000 of your closest friends, or just a solitary round of crazy golf, the most versatile piece of web animation software just made itself more approachable for designing games!
This book takes us deep, deep down into the realms of game design, and hunts out the features that are really going to evolve your Flash skills into full-on game wizardry. We are going to discuss what makes a good game, and what makes a great game. We grapple with the concepts of 3D and how to get Flash to produce cutting-edge game environments, while keeping our sensible shoes on by reducing those file sizes and download times. We conduct a battle of wits with artificial intelligence, and have a good crash around with some collision detection in platform games. All in all, we are pushing Flash to its breaking point to see what lies beyond.
The Studio series assumes you already know your way around Flash's basics, and it aims to boost your knowledge and help you master some advanced techniques. Flash 5Games Studio draws its inspiration from the full spectrum of Flash's capabilities. Amongst other things, it explores:
If you want to turn your open-ended Flash animations into challenging, high-quality games, then this is the book for you. You will benefit from it if you are:
Whether it's real-time role-playing you're after with 30,000 of your closest friends, or just a solitary round of crazy golf, the most versatile piece of web animation software just made itself more approachable for designing games!
This book takes us deep, deep down into the realms of game design, and hunts out the features that are really going to evolve your Flash skills into full-on game wizardry. We are going to discuss what makes a good game – and what makes a great game.
We will take as a starting point our tank project from the last chapter, and try to evolve it, taking in a few more complex routines along the way. Here's what we'll do:
So then, clip events are pieces of ActionScript attached to the movie instance; which wait to be triggered by an external event. The great thing is, since the code is attached to the movie's Object Actions window, and therefore not actually on its timeline, it doesn't matter what frame your ' movie clip is on for the code to execute.
This new method allows you to store user controls, collision detection and movement scripts all in one place, making it easier to read through and edit your FLASH file at a later date. Anybody who has walked away from a file for a week or so, only to come back and feel like it was written by a stranger, will know that this type of organization is a lifesaver.
Let's start by taking a look at each of the onClipEvent options, and how they are going to help us with game design.
With the load event, it's possible to initialize values for a movie clip the moment it appears. This is extremely useful in games, as obstacles or enemies often act within preprogrammed parameters. These parameters can be assigned once here, then other scripts can use the information however they choose. This is also a great place to initialize functions, such as the way in which an object is to move. Functions only need to be introduced once, so the fact that load is only run when the movie clip is loaded makes it the obvious place to put them.
Often going hand in hand with the load event is the enterFrame event. This event triggers its code at the beginning of each frame. What this means is the code is running constantly, executing at the current frame rate. Because of this, it's a great place to add code that looks after the maintenance of a movie, such as whether or not a bullet has hit anything on its progress across the screen. Later on in this chapter we will be applying an (enterFrame) event to our tank's shells in order to check whether they have hit any of the randomly scattered mines.
There is a lot more that can be put in this event handler, such as checks for user controls and timers. Rest assured we'll be looking at those towards the end of this chapter.
The opposite of load is the unload event. I rarely use this code for games, because the number of events that may prompt an unloading is pretty large. The unload event is triggered whenever the movie clip is no longer present, whether that is by simply not being on the timeline anymore, being removed by removeMovieClip, or if either happens to any of its parent movie clips. In a lot of games, it's not the simple act of leaving the stage that is significant, but how it leaves.
It's possible for an element to leave the screen for any number of reasons. Maybe it has been destroyed, or maybe it's just the end of the game. In either case, the code for a movie would have been processed. I much prefer to add the code to the event that triggers the object's destruction. Adding this code to the code that causes the unload event is going to be easier to read later on.
This triggers when either external variables or SWFs are being loaded. Every time Flash receives a section of data for a loaded SWF, or when the last variable of a file loads in, this event is set off. We'll see this in action later in the book when we build a level editor and use the data event to check when a new level map has been loaded, and to display it when it has.
Elsewhere in the onclipEvent window we have a series of user input related events. These events are mouseDown mouseUp mouseMove, keyDown, and keyUp. In the next section not only will we look at the role of these onClipEvent events, but also the events associated with the on statements, as part of buttons.
Certain games call for a lot of different controls, but these are not generally meant to be used at once. For instance, tile-based RPGs will often have a lot of commands, like pickup, drop, inventory, attack, talk, open, and so on, but these are things that you neither have to do quickly nor at once. In an arcade game like a space shooter, you have only a few controls, but you have to do things quickly and often simultaneously.
There is a balance that you as the game designer can decide for yourself, but if your controls are intuitive and comfortable, you should be safe. "Intuitive controls" pretty much means borrowing from what's considered the most common controls. For the keyboard, that often means the arrow keys for the directional controls, or the I, J, K, and L keys which for a long time were considered to be the default direction keys. Whatever you choose, if you design a keyboard interface, make sure your users don't have to play the finger equivalent of a tongue twister before they even get to the actual challenges in the game.
Also bear in mind that there are different keyboard types. Putting a lot of controls in the center of your keyboard may work fine for a standard keyboard but may be awkward on a split keyboard or a laptop keyboard where the player also has to use a track-pad. Also, depending on the type of computer you have, there may be different keys, specific to an operating system, such as the ALT and CTRL keys on the PC, and the COMMAND and OPTION keys on the Mac. While you have access to almost all of the keys on the keyboard, be sure not to choose controls that simply won't work on another keyboard or may be arranged in an unusable way.
Now that we all know about what we have available to us, let's talk about using them to control a game. There are a few different ways of dealing with input from the mouse. Flash has inbuilt event handlers for both keys and mouse, and as we briefly discussed in the onClipEvent section, there are also some for movie clips. We can also create scripts that access the status of the mouse or keyboard. We'll touch on these quickly here, but in the large part we'll leave them for the section on building our own checks later.
We'll start off by looking at the button's event handlers, as they will be the most familiar to those of you who have used Flash as a tool for creating user interfaces. After that, we'll look at the onClipEvent events that have to do with the keyboard and mouse, and finish off with looking at the properties available to us when we start building our own event handlers.
Here the hit area is a bit larger than the actual button graphic, and is just a simple shape. Since you don't ever see it, there is no real reason to decorate it. Also, since the point of a simple button is to be pushed, I often find it a good idea to expand the hit shape of the button to a larger area so that the user has no problem interacting with it. Also keep in mind that hit areas are completely static. No animation can occur. If you place any type of animated symbol in this frame, the hit state will simply be the first frame of that symbol.
Whenever the mouse enters this hit area, the cursor (if visible) will turn into a hand. For a game this can be a good or a bad thing. If you are trying to show your player that this is an area you can interact with, this is an excellent way of doing it since the hand is a symbol users will recognize as an interactive spot. This is helpful in exploratory games where you want to give the user some hints.
On the other hand if you are creating a shooting game, changing the cursor may not be such a great thing. If your targets are marked by a cursor change, that may be giving the user more information than you want since it might be too easy to spot the targets if they are supposed to be hidden.
With the mouse, you can set up handlers that execute code when you enter a button, press it, let go of it, or when you leave the button without letting go, let go outside the button, or enter the e button with the mouse button already pressed. With all of that, there are certainly a large number of games where you can use buttons as the main interaction, but these are normally puzzles, or other games where you need to choose something, or use a drag and drop style interface. Arcade games made with buttons as the main interaction are generally quite limited to shooting galleries and whack-a-mole style games.
The best way to create a deft control system is by using the keyboard. But we have to be careful; there are limitations that we have to be aware of. The main one of these comes with the on (keyPress "key") command, as it works just as if you were typing normally: If you hold down the key, it triggers once, then there is a pause, followed by a repeating trigger: While that may not seem so bad, a lot can happen in the time it takes for the action to repeat. Also, in most game applications where you need to continuously hold down a key for a persistent effect, it really helps if the action happens smoothly.
Unfortunately, the limitations of the keyPress event handler don't finish there. As with typing, you can only have one character being produced at a time. If you hold down two keys, the one that registers second blocks the first, and that command is never received. In the last chapter we looked at the beginning of a tank game where you had to use two controls simultaneously since you had to control the tread independently. This sort of thing would not be possible with the keyPress event Handler.
The last major restriction is that unlike the mouse button, using the on (keyPress) method you can't detect the release of a key. In games where you need persistent actions, you need to detect when the action stops. For something like a game using a slingshot, if you wanted to have the user hold down a key and let it build up power until the player lets go, you would have to use another solution since there is no easy, accurate way of detecting when the key is released, telling the game to let the slingshot go...
|1||Introduction to Gaming||7|
|What Makes a Good Game?||19|
|2||Optimizing Graphics for Games||35|
|A Day in the Life of a Frame||37|
|The Price of Graphics||37|
|The Price of Vectors||43|
|File Optimization: Sweetening the Download||72|
|Final thought: Think ahead||78|
|3||Flash's Built in Objects||81|
|Defining an Object||82|
|Objects for Games||84|
|Getting Intimate with the Movie Clip||89|
|The onClipEvent Function||112|
|Button Event Handlers||115|
|Event Handlers Applied||120|
|Spawning and Initialization||136|
|5||Turn Based Games and Advanced Logic||152|
|Game Definition Fundamentals||153|
|Coding a Turn-Based Game||162|
|6||Structured Real Time Programming||195|
|Structured Real-Time Programming||196|
|Getting Ready for Real Time||196|
|The Need for Speed||196|
|GameWorlds and GameSprites||204|
|Examples of Our gameWorld||206|
|Our Flash Timelines||215|
|Example 2||Building a Scrolling Shoot 'Em Up||230|
|The Indivividual Objects||237|
|How it works||264|
|The arms Movie Clip||275|
|7||Designing a Platform Game Construction Kit||281|
|The Platform Game||282|
|How the Game Works||283|
|Building a Level Editor||295|
|The Data Structure for Levels||307|
|Exending the Level Editor||311|
|Adapting the Game Engine||312|
|Why Games are Different||318|
|Basic Sound Scripting Actions||321|
|Applying Sound to a Game||325|
|Sound Hierarchies - Targeting||334|
|9||Music in Games||353|
|Aspects of Music||355|
|When and What to Play||360|
|Music in Flash||361|
|Exporting Music From Flash||362|
|10||Understanding Artificial Intelligence||379|
|A Being of Your Own||380|
|Your First Virtual Pet||382|
|11||The Third Dimension||402|
|Rendering a Shape||471|
|Limitations of Flash||510|
|The Flash Polygon Engine||511|
|Making it 3D||520|
|Speed Considerations for Games||526|
|Cs Mech Attack||529|
|The Story So Far||530|
|What's Going on in the Game||532|
|What is PHP?||596|
|What is mySQL?||597|
|Reading Minds with Flash and PHP||597|
|Keeping the score||608|
|15||Multi Layer Applications||624|
|The Socket Object||656|
|Director for Flash Users||682|