I'm not sure how you are getting that out of anything I've said. I think you should read the full sentence in context, and not clip something like that out.

If you're not sure how I'm getting that then perhaps you should reread what I posted before. The fact that the people in question are inspired to make games and that they're inspired to make games like Cave Story both come from the same source. You can't pick and choose between them.

Moving on to a more recent topic of discussion, I'm of two minds about the whole 'dead genre' concept. First, I think that 'genre' is not a useful way to think about games during their production. I don't think it's ever productive to try to work within the confines of a genre, because that's limiting your vocabulary as an artist solely to what's been said before. Conceived of that way, all genres are dead on arrival to start with; though they may be expanded, they're just a way to describe already existing games, and aren't (or at least SHOULDN'T be) a mold for new games.

However, second, I think that the most recognizable attributes of games in whatever genre cannot die. They are too simple and elemental to die. I honestly get rather irritated at the idea that broad areas of game mechanics have been 'played out' and that there's nothing left to do. It's like saying that there's nothing more that can be done with jazz forms because jazz has been around for a century! It's STUPID. Sorry, but that kind of close-minded thinking really annoys me, and I think it works against the kind of innovation it claims to foster.

I think the stache should be a powerup like the mushroom in Mario.

I think it's a bad trend

It's a bad trend that people are being inspired to make games?

That's my point exactly though; it's not a matter of making Cave Story influenced games or making not-Cave Story influenced games. For many people, their status as game creators is inseparable from creating games influenced by Cave Story. I don't think that you actually believe that you'd rather people wouldn't make games than that they make Cave Story derivative games, but my point is that a for many of those people if they weren't making those games, those particular games that Cave Story made them want to make, they wouldn't be making games.

People make the games that interest them. I'd rather play something derivative and heartfelt than 'innovative' and hollow. I tend to agree with the take that Jon Blow had on this in one of his lectures: Innovation is great because it widens the possible field of expression in games, but it's not the end goal. The chances of a very innovative game being truly great are low because it's aiming for an unknown target. If people want to fall back upon established tools and tropes in order to express themselves more perfectly, I wholeheartedly encourage that. If people want to be innovative, likely at the expense of making a quality game, then I encourage that too. These are both necessary if we're going to achieve the goal of making meaningful games.

And he's influential in that his games have inspired a bunch of Cave Story clones, and a resurgence of metroidvania games, yes. But that's an influence I think I'd personally have been better off without.

You'd rather those people didn't make games at all than make games you don't want to play?

I have this problem with books, it's not that I don't enjoy books or anything, but I always get sleepy. Even if I'm enjoying a book and the story is compelling I get sleepy.

This happens to me the first few times I hear particularly complex and interesting music (which is generally the kind I prefer to listen to). I just sort of get absorbed into the patterns and before I know it my head is touching the table.
edit: Same thing happens to me when I'm trying to figure out plotlines in my head sometimes, for much the same reason. THAT'S a pain in the ass because sometimes it makes me forget what I was thinking of.

but I can't seem to get it right when it comes to corners.

What happens?

Hm, it should be easy to tell whether it's a top, bottom, left, or right collision, right? So, assuming that one sprite is static (terrain) and one is mobile (player), why not just set the coordinates of the mobile sprite such that the proper sides align?

For instance, you see by the difference in position in your mobile sprite that it is moving down and to the right; so, as long as we're testing against static objects, we only need to test for down collision and right collision. So you iterate through your collision list, and detect a collision with something beneath your mobile sprite. Let's assume you're working with a coordinate system starting at the upper left corner. So, if you know it's a downwards collision, and you know the position of the thing you're colliding with, and you know the height of your object, then all you need to do is reset the candidate position's y value: Sprite1.y = Sprite2.y - Sprite1.height. Obviously that wouldn't work as well for two mobile sprites, but it should be enough for a prototype.

I hope that helped a little.

(Note: If a sprite is colliding with another on two axes, you should prefer to push back only the one that intrudes more shallowly)

Why does it necessarily have to be physical hotness?
edit: Also, I'm not entirely convinced that if a chick went to this much trouble to make something cool for her bf that no one would say "Wow he must have a gigantic penis."

No couch but I've got an air mattress in the LA area.

Slowly rereading The Wind-Up Bird Chronicle.

I'm starting on Catch 22 now.

Awesome. Best book.

Anyone can work hard, but not everyone has learned how to work effectively.

Or could it be love? If you truly, purely, love something, you'll naturally spend more time doing it

Yeah that was kinda what I was getting at

I tend to think of talent as the ability to give a shit about what you're working on, much as genius is an infinite capacity for taking pains.

I do agree with the article though 

Neat! No idea what else to say. Any plans to release either the binary or the source code?

addChild might add it to the display list, but only if the thingy calling addChild is itself on the display list (Though even if it weren't I think it would still parent it to the sprite which would solve the problem). However, there are still potential problems with removeChild getting called more than once. This leads me to worry that your rain drop objects are still receiving events from somewhere; as long as they're registered with a listener they will not be collected by the garbage collector (unless you specify otherwise).

parent.removeChild(this) only works if your object is on the display list.
That's why earlier I suggested using: if (parent) parent.removeChild(this);

Yeah. That's really odd. The only way I could see getting a null object reference for trying to trace out a variable by itself is if it was trying to call a toString on it (which trace sometimes automatically does). I don't know why changing it to this.y would fix the problem...

Usually it only gives 'trying to access property of a null object reference' if you're trying to use the . operator to access a property/method of an object when that object hasn't been properly initialized. Something like this:

Code:

var doohickey:MyClass; // Oops, forgot ' = new MyClass'
doohickey.doThatThing(); // doohickey is still null!

I don't think I've ever seen that error occur without a . operator involved somewhere. Are you sure that's the line causing the problem?