Looks good but the music and the title both imply a faster ship, so yeah. Pretty much what's already been said. Make it go faster.

10 for me, too

Yeah, these are more theoretical than anything. I tend to just do what's convenient but sometimes I get to wondering if I'm just doing it completely differently from everyone else out there. Thanks everyone for weighing in, I'm still noodling around the answers.

Specific to the sound I especially think of games where lots of explosions happen in succession from various dying enemies, but they do so without trampling over other sounds too harshly or silencing themselves to the point of sounding poor. So there's some coordination of the larger sound system with the multiple simultaneous requests of actors to play their individual explosions, and lots of systems seem to do this very gracefully - although whenever I put the code down to do it, it feels both convoluted and hard to maintain. Still trying to theoreticize up something better.

I'm a day late, so here's two.

DAY 1 (Waving 24x24):

DAY 2 (B&W 16x16):

edit : bleh, these are totally lackluster. I might retry these again later.

Pardon my stupidity, these are both just very high-level MVC Architecture questions.

First - where does one normally trigger sounds?

Since sounds could be considered a view, should there be a separate 'SoundView' class that monitors the model and plays sounds at the right time? I'm guessing this is technically the most correct way to do it. Usually though I find it most convenient to trigger sounds in the Model, eg., if the controller calls .beginDeathSequence() on an actor, it might be easiest to just have it play out its death sound right there.

Second - particle or lighting effects attached to actors (ie., contained entities with a graphic, some data like health and speed, and input controls). I won't go into detail about how I do it because it's a mess of conditionals and interpretation by the main View to decide how to render actors and their attached lighting/and or implied particles. I'm sure there's a clean way of getting visual area effects out of actors (especially particles) and handing them off to a system without putting too much silly visual code in the actor itself. I dunno, all my ideas in this area seem to suck.

thoughts?

Woops, sorry.. took down the link to the preliminary archive. Figured it was public since you tweeted it, my bad!

You missed it, but this round's entries are up here: [removed]
though from what I gather there might be very late entries? I dunno

Better PR and BD Staff (HIGH PRIORITY)

This is cool but I think it should maybe have gone in the workshop?

Anyway, I'll post a sprite here later.

Today's bug rating: 

Heh, I enjoy this very much

Some pretty sweet character design, I love that you gave them appropriate proportions for their roles. That and they actually look really ninja AND mutant. This is slick.

The one major benefit of an HTML5 Sprite Editor would be vast and immediate portability.

Pixothello, D-Pixel, etc.. are all Windows only from what I can tell.

Sort of why I abandoned Pixnid. A tool like Pixothello which is targeted at Flash devs would be awesome if it ran in AIR. Which I may do at some point. I'm not a very good OS X/Cocoa dev anyway, too much fussing with Interface Builder and NSWhatsits.

Very cute.

This is awesome, but yeah, Navi needs to not be on the clear pixel blocks - it's the same colour as his sword and kinda visually confusing.

My only complaint is that I've been waiting for this for what seems like forever and it's still not out.

AFAIK all I'm missing is the Profiler and maybe some server-type stuff.

Yeah, the jump between Flash Builder Standard vs. Flash Builder Premium seems much less steep than FDT Pure vs. FDT Max. Again I'm not sure about this and I would love for someone to do a proper comparison of the modern versions.

The only use I can see for a Macintosh mouse is for kiosks that don't really require right-clicking.

Mac mice have right click.

But aren't most macs sold with just 1 button mice?

They look like 1 button, but as st33d said, the magic mouse is sort of a touchscreen thing. Prior to that was the "Mighty mouse" which looked like 1 button with a scroll nib, but in fact was two buttons hidden under a 1 button shell. So depending on which side you applied pressure to you'd get left/right click. This didn't work very well.

The touchpads have nice gestures. in particular two-finger right-click is surprisingly convenient.

I have yet to read the reviews or play the game, but it sounds like Duke Nukem Forever lived up to my expectations completely.

st33d... uh. Suffice to say I haven't had that experience with Flash Builder. Flex Builder 3 was a pain but they've cleaned it up a lot since then imo.

More to the point, I really need a modern, up-to-date feature brawl between Flash Builder and FDT. The old ones aren't even close to accurate anymore, as Flash Builder 4.5 caught up with a lot of the code hinting and refactoring.

Does anyone use both on a regular basis? Flash Builder 4.5 vs FDT 4.0 specifically.

Seems to me a lot of the features that put FDT above Flash Builder also require you to shell out for FDT Max, so while the Pure version is $149 you end up shelling out $699 for FDT Max... I really don't know.

Really? Wow. I did not know that, nor did I think it would be technically feasible for Minecraft. Impressive.