Alright, yes, I've been meaning to start up the post-mortem train.

The initial concept for 600+ Vector Silhouettes of Anime Girls came about because I was excited about the newly-working text-to-speech abilities of Construct. A Google Image Search for "klip art" turned up the image which inspired the game's title.

WHAT WENT RIGHT:
Very little. Not only was the game completely uninteresting from the player's point of view (Eject a disk! Put it back in! Win?), but I didn't even get the tech part of this tech demo to work properly. You could spawn a bunch of disks and then pick them all up at once, for example.

For lack of any better ideas, the game became an exercise in "How can I make click-and-drag work in Construct"? It turns out the answer is, "It's not quite as cumbersome as it would be in Klik & Play, but it's still pretty tedious." I did get a chance to use Construct's "Family" concept, which worked out alright, but I'd really like to be able to define my own events, so that I'd be able to say "When disk is dropped on drive". Instead I had to say something like "When blue's instance variable id is equal to 2 and red's instance variable id is equal to 1" underneath an event that says "When the mouse button is released and blue is overtop of cursor and blue is overtop of red." Too many degrees of freedom.

Nevertheless, I did actually manage to implement click-and-drag, which I wouldn't have bothered to try in Klik & Play. So I guess there's that.

WHAT WENT WRONG:
The big one is that I had no idea how the player was going to play the game before I sat down to make it. I think that this has been the problem with all of my non-Klik games thus far.

Specifically, when making a game in Klik & Play, the first thing I do when I create an object is define its movement -- how it will navigate the game space. It's pretty much the first question K&P asks you -- when you right-click an object, it's at the top of the list. In Construct, the same functionality is buried in a funny property sheet on the side of the screen, in a tiny, usually-hidden box called "Behaviour". Instead of answering the question quickly using the powerful built-in movements, what I naturally gravitated towards doing was building an interaction model entirely in the event sheet, with only a vague understanding of what I wanted to accomplish. Thus I ended up spending most of my time building navigation and very little time building verbs to apply and nouns to apply them to.

Defining how the player navigates the game space is maybe even more fundamental than defining their verbs, as it defines how the player selects nouns to apply verbs to. I think the player's navigation options inform the player's interaction options. I can imagine a game in which the player does not actually affect the world, but the closest thing I can really think of with verbs and no navigation -- no player choice -- is some variant of Pushing The Button Will Destroy The World In An Explosion. Maybe you could have a bunch of different verbs that always applied to the same noun. In any case, thinking of these as seperate questions that have conversations with each other gives me lots of good ideas to explore.

WHAT ELSE:
Not having built-in klip art totally breaks my flow. I really hope I can figure out a way to work around this -- build some sort of standard asset pack, perhaps -- but I think if I just make sure I work out what I want my game to be beforehand, it shouldn't be a huge drag. Certainly I have done successful KotMKs before that have been light on or devoid of klip art.

Also, I was about a half hour late showing up, and so I kind of over-rushed myself.

I think that's about it.

I think I might like to do a post-mortem of fragment next, because I'm really proud of how it turned out. And nobody ever commented on it ;_;

I'd also like to see other people do post-mortems of their work! GET TO IT, GUYS AND/OR GALS.

The basic idea for YAAI came from a friend of mine, who I finally showed the game to this evening. I liked the idea of a stealth game crossed with a platformer, while keeping the two element separated. Gameplay shifts and intersecting goals interest me. Also, I wanted to make the game as disturbing as possible, given the sometimes creepy knp art. Sadly, I did not remember to make the monsters end the game, thereby forcing you to use the gun to harm innocent bystanders to avoid detection by the police. The actual event in the file tests against the wrong player instance, so the guy on the top screen remains safe from the monsters on the bottom screen (which ends up being a bit of an interesting symbolic meaning, I guess)

What went right:
The game was disturbing.
The stealth elements (not being noticed jumping over obstacles that aren't there) were well recieved.

What went wrong:
Without the monster being dangerous, the player was never fordced into comitting a crime to escape imaginary threats.

As a side note, I showed the "pac man is hungry" game to a group of friends this evening, and they all enjoyed it immensely.