Friday, January 12, 2007

Flash PnC tutorial - 1. Frames and layers

I knew very little about Flash when I started writing Revenge for Sonia. I still know very little, but what I’ve learned might be useful to someone so I’m gonna write it up.

Frames and layers

In PnCs, a frame is usually going to be either an individual scene or a fixed portion of the play screen. A frame can exist for the length of one frame, or it can be stretched across several frames. I know this is a little confusing, but this is what layers are for.

When I started doing this, I could find no instructions on what layers are for, apart from the obvious fact that items in a higher layer are going to be displayed on top of items in a lower layer. Maybe I didn’t know what keywords to look for. But organizationally speaking, it took me several restarts before figuring out a schema that made sense.

In a PnC you have inventory, places to go, things to do, and people to see. These are the four essential layers: inventory, backgrounds, actions,and dialog. Yeah, I'm pushing the analogy a bit, but what the hell.

Let’s try to make some sense of what frames and layers are.

In the above figure, Inventory is layer with a single frame that starts in frame 2 and stretches across most of the entire length of the game. In other words, it exists in every scene but the first and the last. It is a layer by itself and is essentially one frame with a lifespan, so to speak, of 34 frames. Code associated with the inventory objects (manipulating them, their descriptions, etc) is also stored in that layer.

The dialog layer has two frames, one starting at 1 and the second starting at 11. This layer contains my dialog box (the smaller blue box below), where the game gives messages to the player, e.g. “You are now in the living room.” The first frame, spanning 1 through 10, is/are my introduction scenes; 11 – 36 are the actual game. The only difference between the dialog boxes is a slight change in size. The introduction scenes are more wordy, and I needed room for the Next/Skip buttons to the right of the box.

The game part has less text, so the box is not as tall, and text looks better balanced with even margins, so the textbox is stretched.

A frame with a clear dot means the frame has no objects (pictures, buttons, movie clips, etc). It turns black when you put one of these items in it. The alpha symbol indicates there is Actionscript code in that frame. Sonia has 36 frames and 11 layers.

I separated the backdrop pictures (‘background’ layer) from the buttons and movie clips that do stuff (‘actions’ layer). These backdrop frames have essentially no code. Most of the code is in the actions layer.

Looking at the layers list again, I see that ‘bgloop’ could probably have been consolidated with the ‘dialog’ layer, since their lifespans, so to speak, are identical. Bgloop was where I kept the background music loop and the sound on/off button. More keyframes make your Flash file fatter, so you want to reduce those when possible -- but this also has to be balanced with your organizational sanity.

Each keyframe can contain code (Actionscript), which executes upon entry into that frame. A lot of different things can be happening, which is why organization into layers helps keep your sanity. A keyframe automatically has a number, but it can be named as well. The red flags in frames 11-36 in the background layer indicate the frame has a name. This is essential for controlling navigation from one scene to the next. You can have your navigation buttons refer to frame numbers, but if things are still open and loose and you insert a frame, well, your navigation is now fucked because, unlike inserting cells in Excel, the code will not automatically adjust numbers to compensate for the new frame. If you name your frame and your nav buttons refer to those names, they will always find the desired frame.

When you tell Flash to go to a frame (whether numbered or named), all the layers that also have a keyframe in that frame are executed. For example, frame #15 has a keyframe in the Actions layer and a keyframe in the Background layer. If you execute GotoandPlay (15), all the instructions in those two layers get executed. Instructions in the Inventory, Dialog, and Bgloop layers were executed earlier and are being held in memory; they will not be reloaded, but functions defined there are active and can be called by objects in frame 15.

1 comment:

Yancey said...

Hey there, nice to see your tutorial! This is selfdefiant and I have to say that I was looking around the net trying to find a new way to get do my items. I was amazed when I found out who it is that wrote the tutorial here. I bet never in a million year you would have thought that I, would be reading your tutorial looking for insight. I am though and it is great to see that you have devised a tutorial to help others create a great game of their own. I have done the items the way that you did yours, I am searching for a more dynamic approach for my new game. I will have many items and the order of which the player picks them up will be totally random. I don't really want the items to be all spread about the item screen so I am in search of way to load them in the order of which they gather them. I will give an example, if you have a grid from top left being a,1 - a being the left side going to b heading downward and 1 starting the top moving to 2 heading right. The first item they pick up will land in box a,1 and the next item will go into box a,2. This seemed pretty easy at first but remember that my games save and that can be a real pain! Not only do the items have to be placed correctly when they are picked up, they also have to be replaced when the player closes and re-opens the game. Let me know if you can think of a better way to make the items more dynamic. Glad to see your site too!