That trailer looks neither challenging nor very original, but it's just barely original enough that it doesn't even have the nostalgia factor of Mega Man 9. I'm surprised to see Sega ripping off Nintendo's IP so blatantly, without actually paying for the Mario license. I don't get it.

EDIT: Parody? I guess... Maybe the instruction text is funny?

YMM: I don't know much about it, but there is some creepy voodoo to minimizing sound latency in Flash. These people are upset about it:
http://www.make-some-noise.info/
I don't think you have the exact same issue that they do, though, so don't give up.

Is that double buffering you've got going on there with the off_screen and on_screen? I think that's unnecessary. Flash will not update the real screen until after you return from the ENTER_FRAME event. (meaning, until the update function returns)

Cast to int.

Code:

aWorld[int(player_x/mapTileWidth)][int(player_y/mapTileHeight)]

...Dude, the competition has been listed over in this thread for a while:
http://forums.tigsource.com/index.php?topic=3972.0
Also, a yellow bulldozer is about to knock down your house to make way for a bypass.

I'm going to the one in San Francisco. I heard about it a while ago from the Ludum Dare mailing list.

...three tracks will be the same song, but with slight differences in mood.  When the game switches modes (from 'during wave' to 'between waves' for example), the music will seamlessly switch tracks to the appropriate track...

I did that in my Snake Ball game:
http://johnnesky.com/index.php?page=snakeball
The music is 3 MP3s, all the same length and looping indefinitely. I start playing all of them at the same time, and then I dynamically control the volume of each to vary the mood depending on how crazy your snake is and how close you are to winning.

(I'm rather pleased with how fun the game is, though it lacks polish because I made it while teaching myself ActionScript 2, much like how you guys are currently learning ActionScript 3)

are there things that will work in Flash 10 but not Flash 9? If so, is it better to make a game in Flash 9 or Flash 10? Does Flash 9 have any limits Flash 10 doesn't?

I just thought of another one: Both Flash 9 and Flash 10 have the option to go to full-screen mode, even if the Flash player is embedded in a webpage. YouTube makes use of fullscreen mode, for example. But Flash 9 completely disables the keyboard when in full-screen mode for security reasons (you can easily deceive the user if you control the entire screen), except for stuff like the Escape key which exits full-screen mode. But in Flash 10 the Tab key, the Space Bar, and all four arrow/directional keys are always available for playing a game, even in full-screen mode.

...I've been using both Flex Builder and straight up MXMLC for over a year and I have honestly never tried changing the compile mode, and I had pretty much forgotten that there was even an option. Strict mode is the default, and it's what I stick with. As far as I can tell, turning it off disables type safety, so it is probably less optimized in the end.

#2

- You say that bitmaps can have siblings; does that imply that shapes cannot have siblings? Are siblings just when you have two children from the same parent?

Sorry, Shapes can have siblings too. Yes, I just meant that they can share a parent.

- How do you control the order in which things are drawn on the screen? For instance, if you want to draw a circle, and then a bitmap in front of that circle, how would you achieve that? In Game Maker, the way drawing works is that all objects (the equivalent of display objects here) have a depth value, and they are drawn in the order of their depth. Is there something like that here? Are children always drawn "over" parents? So the background, for instance, would be the parent of the foreground? Or is there some other method?

Children are always drawn in front of a parent. Children are always drawn from first to last, meaning that the last child you added to a Sprite is drawn in front. So the back-most thing is the Stage, which is the parent of everything, and the front-most thing is the last child of the last child of the last child of.... the Stage. There is no explicit "depth" property, instead you have to rearrange the list of children in a Sprite.

- In the painter tutorial linked to in the first post, there were a few display objects: a TextField (I assume that's a type of display object too), "Main" (which is a Sprite), and coulourButtons (a Shape). Would the "Main" sprite be identical to the Stage, since it's top-level?

The Main class, also known as the document class, is the class that is responsible for starting your Flash program (and it doesn't have to be called Main). It does have to inherit from Sprite or a subclass of Sprite. When the program starts up, Flash will automatically add an instance of your Main class to the Stage, so that any DisplayObjects that you attach as children to the Main object will be visible. Technically, you can remove the Main object from the stage and add your own DisplayObjects directly to the stage. But it's usually nice to have some top-level Sprite other than the Stage, so I recommend keeping Main attached to the Stage.

And yes, TextFields are another subclass of DisplayObject. They are not a subclass of Sprite and thus do not have children. To learn more about the relationship between the display classes, read the documentation.

I have updated my explanation for clarity and added an explanation for the all-important Stage object.

Things I don't understand:
- display object
- timeline
- shape class
- sprite class

If you don't have the commercial Flash authoring tool, then you can usually ignore anything involving a timeline. A timeline is a part of creating animation with the authoring tool. If you're just compiling with Flex, there is no way to make an offical timeline, although you can certainly roll your own.

Every single thing that you can see on the screen in Flash is a DisplayObject. DisplayObject is a super-class that all other visual classes inherit from.

Some important classes that inherit directly from DisplayObject are Shape, Sprite, and Bitmap.

Shape and Sprite both contain a Graphics object. You can use this to programmatically draw vector graphics on the Shape or Sprite. When you draw vector graphics, those graphics stay attached to the Shapes and Sprites until you later choose to clear them. You do not have to redraw the vector graphics every single frame unless they are animating in a way that can't be reproduced with simple translations or rotations. In this respect, Shape and Sprite are identical.

But Sprite is special: it can have other DisplayObjects on top of it. These are referred to as children, and the Sprite that contains them is the parent. A Sprite may have any number of DisplayObject children, and if these are also Sprites, they may also have their own children.  With this, you can form a TREE data structure out of Sprites.  This data structure is referred to as the Display List in Flash documentation, and it is very important. Whenever you move or rotate or scale a Sprite, all of its DisplayObject children are also affected.

A common example of a Display List would be a Sprite representing the window, containing a Sprite representing the camera position, containing a Sprite representing the terrain and a bunch of other Sprites representing entities, and each entity Sprite may have other DisplayObjects such as Bitmaps that are attached to the entities. In this example, you could scroll the window by changing the position of the camera Sprite, or you could move an entity in the world by changing the position of its Sprite, and if the entity is holding a gun Bitmap you don't have to worry about changing the position of the gun Bitmap because it's already attached to the entity as a child DisplayObject.

Bitmaps, Shapes, and other direct subclasses of DisplayObject cannot have children, but they can have siblings, meaning that they can share a Sprite parent. The only reason anyone would use a Shape instead of a Sprite is because Shapes are more optimized.

Bitmaps have a reference to a BitmapData object, which is where the actual array of pixel values belongs. BitmapDatas are not DisplayObjects, and thus cannot be attached to the Display List. That's what Bitmaps are for. Multiple Bitmaps can share the same BitmapData. It is absolutely recommended that you share BitmapData whenever possible. If you create a new BitmapData for each Bitmap, you are likely to run into the trouble that Glaiel-Gamer warned about. Also, you shouldn't be constantly redrawing all of your BitmapData. Draw each BitmapData once, and then reuse them in Bitmaps. Reusing BitmapDatas in Bitmaps is usually much faster than using Shapes or Sprites with programmatic vector art.

BitmapDatas are usually created by importing JPGs or PNGs. However, as Glaiel-Gamer said, it is important to understand how to make programmatic vector art in Sprites or Shapes, because you can use those to easily generate graphics that would be otherwise very hard to draw directly into a BitmapData. Once you have created a Shape or Sprite, you can render it inside a BitmapData using Flash's rendering engine, and from then on you can refer to that pre-rendered BitmapData for the fastest possible rendering method. But of course, premature optimization is the root of all evil.

MovieClips are a subclass of Sprite, and thus they can have children. They also have a timeline, which means they can only be created with the Flash authoring tool. Don't worry about MovieClips aside from keeping in mind that many people use MovieClips for all of their entity Sprites and will refer to their Sprites as MovieClips in tutorials.

You may see references to a Stage in the documentation. This is also important: the Stage is sort of a top-level Sprite, meaning that all of the DisplayObjects on the screen are direct or indirect children of the Stage. When we refer to adding or removing things from the Stage, we mean we are making them visible or invisible. DisplayObjects that are not children of the Stage do not get rendered.

Nah, the free compiler is still very useful. Go ahead and use whatever combination of bitmaps and procedurally drawn vector graphics makes sense for your project.

Figuring out how to optimize graphics in Flash is kinda complicated. If your project is indeed simple, just go for whatever makes sense to you. When you want some more intense graphical effects, come back and we'll explain how to optimize Flash's graphics.

Neither Flash 9 nor Flash 10 have built-in Ogg Vorbis support. However, Flash 10's more flexible sound options allow people to make libraries like this:
http://barelyfocused.net/blog/2008/10/03/flash-vorbis-player/
One downside of using Ogg Vorbis in Flash like this is that it takes some significant time to use AS3 to decode it into raw audio waves from the Ogg Vorbis format. Whether this trade-off is worthwhile is up to you.

EDIT: The source code for that Ogg Vorbis player that I linked to seems to be missing.  Oh well, I'm sure some more googling would reveal something.

are there things that will work in Flash 10 but not Flash 9? If so, is it better to make a game in Flash 9 or Flash 10?

There are a bunch of things that only work in Flash 10. Here are some off the top of my head:

• The Vector datatype in Flash 10. It's basically an array (NOT a position in 2D or 3D space!), with the restriction that it can only hold one datatype inside of it. Meaning, you could have a vector of ints, or a vector of Strings, but not a vector containing both. This is in opposition to the Array datatype that is available in both Flash 9 and Flash 10, which can always contain any number of datatypes. Vectors are more optimized and come with all the benefits of strong typing, but judging from your comments in other threads, rinkuhero, I guess you'll probably want to use Arrays anyway. 
• Some optimized graphics functions. You can pass a complex datastructure representing all of the graphics commands you want to run, instead of calling a function for every atomic operation. (function calls are kinda slow in Flash) Again, this is mostly an optimization issue.
• Some built-in 3D graphics effects. Mostly this just means that you can rotate sprites, or anything else that can be projected onto a flat plane, around the X or Y axis. If you want to use more complicated 3D models, you'll probably need some additional library like PaperVision3D, which is available for both Flash 9 and optimized Flash 10.
• Flash 10 also comes with some additional options for connecting to servers or other clients, but I don't know much about that right now.
• You have the option to generate your own sound/music in Flash 10. In Flash 9, you had to use existing sound files (MP3, WAV), which meant that you couldn't use generated music such as the MOD format, unless you resorted to a bizarre hack. But either way, if you want to play MOD music, you'll want to borrow something like badsector's library.

As for which you should use... well, if you don't need any of the features of Flash 10 immediately, it's fine to stick with Flash 9 for now. You can always upgrade later if you need to, since Flash 10's AS3 is backwards compatible with Flash 9's AS3.

I certainly agree that solving puzzles should take some mental effort, and that they're not as fun when you guess the right solution every time. I think I am mostly just bothered by this:

I can't imagine not being able to figure Zelda 3 out and giving up

Being able to empathize with the people who get frustrated by your game and give up is an important part of being a designer. (As long as they're in your target audience... and you're free to exclude them from your target audience if you decide they're too wimpy.)

Hm. I'd still say that persisting for 15-20 min and then giving up isn't enough persistence (at least for games with puzzles). Sometimes puzzles take weeks to solve. That's the fun of them.

I am definitely not going to spend weeks on a puzzle in a game that hasn't already demonstrated to me that it has a lot of potential. Remember, this is the very beginning of LttP that we're talking about, and I played it before it became legendary. And there weren't even any interesting enemies to fight in the rain. There was just a bunch of space to run around in.

They wouldn't be as fun if you could figure them out without trial and error.

I strongly disagree that trial-and-error is an important part of puzzles. Trial-and-error is sometimes a decent way to let players discover what their abilities are and how various objects behave, but solving puzzles, to me, is about applying that knowledge. The puzzles I like are the ones where I already know the rules, but I don't know the strategy yet.

Well, I can't imagine not being able to figure Zelda 3 out and giving up -- I mean, Zelda 1 I could understand, that flute and pond puzzle was pretty tricky, but Zelda 3? What could stump someone in that game...?

The first time I played Link to the Past, I got stuck in the first scene. I was running around in the rain and nothing I tried accomplished anything and I just found a bunch of dead ends. I gave up.

Later I found out that the bush in one of the dead ends was a trap door, and proceeded to uncover a fantastic adventure game.

The problem with puzzles isn't that you need a certain level of intelligence to solve them. It's that people approach puzzles with widely different assumptions, and their random flailing about for the first few seconds could be the difference between stumbling across a hint, and just getting frustrated and moving on. The problem space in the first scene of LttP was large enough that I felt like I still had plenty of options that were unexplored when I first came to that dead end, so I didn't immediately realize that there must be something important there and I left and explored other places. I persisted for at least 15-20 minutes in the rain with returning to the bush, which I had already mentally classified as a dead end, then put down the controller.

As a designer, when you've got a puzzle that needs to be solved by the player to progress, you have to reduce the problem space so that players who are stumped can figure it out quickly just by experimenting. If you give players too many choices, or you give them the opportunity to go away, some percentage of players will simply pick all the wrong choices or they'll go away and forget about the puzzle before solving it, and then they will be stuck.

You can have your respect when you pry it from my cold dead hands.