Yeah my next game does nothing in the enter frame event (all the logic is done on a timer, 60 times a second).

Is there any reason why I wouldn't want to just set the framerate to 120 FPS?  Would this effectively be giving everyone the max framerate their browser/PC can handle?

If you use movieclips it's tied to the framerate not your timer, so unless you feel like taking control of clip playback (a pain in the ass when flash does it for you) then it's extra work

Ah, yes.  So I unintentionally lied: the only thing tied to the framerate is my animations, and if the speed is inconsistent across computers, the animations will be too.  Thanks.

Yeah my next game does nothing in the enter frame event (all the logic is done on a timer, 60 times a second).

Is there any reason why I wouldn't want to just set the framerate to 120 FPS?  Would this effectively be giving everyone the max framerate their browser/PC can handle?

I think he's just messing with the draw parameters of each cube object based on its position relative to the player.  Starting with that basic concept, he just messes with different parameters or combinations of parameters within the draw event of each cube, searching for interesting outcomes.

Or, I could be completely wrong

Yeah flash doesn't use cookies but shared objects (as shown above).  So data stays even if the user deletes their cookies.

It's really annoying that when a key starts repeating (after holding it for a second or so), it triggers a key down event a million times a second.

Though I guess this is because it's easier to work around than imitate this functionality.

• To beat the level, the player only needs to have a very basic grasp of the skill

I just went through some of the audio commentary on Portal, and at one point they talked about something they called "gating". The idea is to have a tutorial level which is almost impossible to solve by blind stumbling around; only if you have really grasped the mechanic will you be able to complete it. That way they could rely on the player having internalized that particular skill from then on and could layer more complex challenges on top of it.

It might be an unusual case because Portal is basically one long tutorial, but I still found the idea interesting.

I would agree that the player shouldn't be able to accidentally solve the tutorials - I was trying to say that they should understand the skill but needn't master it just yet.

This is especially useful when designing the levels after the tutorial levels, in deciding where to start the difficulty curve.  By using "gating" (as the Portal team called it, I usually call these types of levels "gatekeeper levels") in the tutorial stages, you know a minimum skill level for the player coming into World 2 to help you make this decision.

I disagree that all good games must have the design melded with the art and code, even though this is kind of also how I go about making my games.

I would agree that some good games go about it this way, but there's other good ways to design just like there's tons of different ways to visualize and compose music and none are objectively better than the others.

One tutorial level method I like is to provide levels for each of the very basic skills the player needs.  For example, level 1 in a platformer could be about jumping.  Key characteristics of these levels:

• No possibility for failure or no consequences for failure
• To beat the level, the player only needs to have a very basic grasp of the skill
• There is plenty of room to experiment further with the skill and improve beyond "a basic grasp" if the player wants to
• Instructions on how to perform the skill (implicit or explicit).  For example, Braid simply had a sign which said "spacebar" when teaching you how to jump.  It didn't have to tell you what spacebar does, because that is obvious.  If the skill is more complex (a button combination for a special attack maybe), you may need a textbox.

This way there is no explicit "tutorial" on the menu that inevitably everyone will skip, and the tutorial stages would be stupidly easy (and fast) for a veteran of the genre/game, preventing boredom for them.

I'm actually not a fan of gore at all either.  L4D may be quite a gory game, but I still find it all tastefully done.

It's half a parody of terrible zombie B-movies, but at the same time half serious.  It's actually hard to describe and I wish you would give it a shot.

On a semi-related note: I also love TF2's gore, because I've always found it to be satirical of other FPSes.  Maybe that wasn't their intent at all, but the cartoony art style mixed with the ridiculously over-the-top deaths (once, I scored a headshot with the sniper rifle and the target's entire body exploded :D ) is a hilarious mix.

I feel disgusted or sick when the violence isn't tasteful or humorous though - like in Saw or Hostel or even GTA (am I the only one who never kills the hookers?  I just can't bring myself to do it in fact I go out of my way to avoid/save innocent bystanders when I play)

I hate FPSes.  I didn't care much for HL2.

But I love L4D (and TF2, for that matter).

Maybe in 100 years there'll be a "no humanizing" trend in mainstream art, and Pixar movies will star creatures and objects with no human traits and evoke as little emotion as possible. 

Then art lacking humanized objects or creatures will be considered pandering to the unwashed masses and pretentious people on their high horses will huff and puff about how there's no good art with humanized trash compactors nowadays.

I've given up all hope of ever seeing another Majora's Mask-quality Zelda, so they can pump out all the shit they want now and it won't surprise me. 

I realize that Majora's Mask was made at a time when Nintendo was desperate and willing to try anything, and now they've found a formula that sells.

Oh well

Sort of unrelated but: I think a lot of people went into Wall-E intending to like it, but only on the condition that it isn't Wall-E.

It isn't meant to be a realistic (in any sense of the word) story of a robot and I don't see any problem with Pixar giving Wall-E human traits.

I can't imagine this happening to me... I'm so happy right now that the bomb didn't go off.  This kind of thing reminds me that life is precious - I can't imagine the mindfuck had I actually been in the room.

Anyway, if you need or want help, don't cheat yourself out of it because you're busy.  Lots of times people will actually make themselves super busy after a traumatic event to avoid counseling, as a form of repression or denial.  Not saying that's what you're doing, but it's something to be aware of.

[so]

Wow awesome!  Good luck to you with your game development (Snapshot looks great)

Hopefully one day I'll start an adventure like this, though I have to wait to graduate from university first.  Winter also gets me down, I think that's just human.  I'm looking to move somewhere with a shorter winter too, but the states is off-limits because I'd have to live there for X months before they give me a green card or something?  I dunno what the rule is, but I'm not saving up enough money to survive jobless while I wait for them to let me work.  Plus moving to the states is so 90s (excluding Seattle).

[you have to set the child not to handle them]

Okay, advice taken.  I'll write my own hitTest for the player object.

But out of curiosity:

How can I make a MovieClip ignore all children of itself and only check against the hitArea when doing hit tests?

It doesn't work like that. Hits cascade from child to parent, so if you want the parent handling all hits you have to set the child not to handle them.

If for some reason that's massively inconvenient you can hack the behaviour you want by putting a transparent sprite above the other children and adding the handlers to that instead of the parent. (This is basically never necessary, but if you can't see how to do things properly this trick can get you out of trouble.)

All that said, you're likely better off with Glaiel's suggested workaround.

How would I do that?  I'm looking through the docs for a variable similar to mouseEnabled but for collisions, and I can't find one.  Would I have to set the hitArea to an empty Sprite (seems like a sorta round-about way to do it)?

I know there was mouseChildren, which when disabled would make all the sprite's children not register mouse events (which a hitTest version of would be perfect for me in this situation).

[The Anarchist]

The Anarchist
Nothing really matters in a game for you. What matters is the player's mind. Your designs are a way to twist and shake the player's mind like you would dry a rag soaked wet with social expectancies to make it light as a child's mind is. There are no rules by wish you design, except one: ideas are all equals, regardless their differences, and each have the same potential.

Sorry to quote an ancient post, but this is probably the indie-ist fucking thing I have ever read ever.  I love that you wrote that about yourself.

I think I told you this on MSN, but my solution is to just make the moving platformer jump-through-able.  This way it can pass right through the player like thin air.

And I hate moving platforms that kill the player in the majority of cases.  Unless it's a fundamental gameplay mechanic or something (and is obvious to the player), it just ends up being annoying.

Okay, so I have a MovieClip which I've defined hitArea for:

Code:

hitArea = new Sprite();
hitArea.graphics.beginFill( 0x000000 );
hitArea.graphics.drawRect( -8, -8, 8, 8 );
hitArea.graphics.endFill();

Shouldn't this MovieClip now ignore all other children of itself when doing hit tests?  It doesn't seem to be doing this.  How can I make a MovieClip ignore all children of itself and only check against the hitArea when doing hit tests?

Each level in my game is a symbol (a MovieClip), containing the below art, above art, player, and gameplay objects all on separate layers.

So here's what I did to solve the player spawning problem: each level symbol has the playerLayer variable, which tells the game what index to give the player when respawning using addChildAt().  This way I can have multiple art_below layers (for example for parallax BGs).  Not the most elegant solution, but it seems to work so far.