Moment of Truth

The game is reaching a crucial point in its development, and I thought this was worthy of its own post. Basically, everything's running pretty smoothly; there's some mostly trivial collision stuff that I want to add at the end, but the last main obstacle is the barrage of "bubbles" that are supposed to descend from the heavens. As I mentioned two posts ago, Flash doesn't seem to be very good at rendering large numbers of moving sprites. So, I finally decided that it was time to stop re-inventing the wheel and go do some online research. What I came across was this:

Arrow Test

To quote that guy from The Wire, sheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeet. That's a lot of sprites.

Well, actually it's not. The test came from one Mike Grundvig's blog, and it seems to be a clever use of the BitmapData Object type's copyPixel function. A fast way to move non-animated sprites across the screen? Could it be my salvation? Could it be?! Well, I'm certainly going to try it. In the mean time, here's the game as it stands. Steer with the WASD keys, point and click to shoot. you can drop down levels by pressing down (S). Bon appetit.

Log Update #1, 8/3/2010: Today is performance day! Performance, performance, performance! The results aren't immediately noticeable, but I've made the game better at cleaning up stuff that's off-screen, so now it's never updating more than 8 whale objects at a time. I've also been goofing around with bitmaps, so hopefully my bitmap-bubble plan will pan out by the end of the day.

Log Update #2, 8/3/2010: Unmitigated success! Well, so far. I initialized my block of bubbles (which are more akin to cubes of coral now), made it creep down the stage, and there was no noticeable slowing. I didn't explain it so well earlier in this post because I hadn't tried it and I didn't know exactly what I was talking about, so here's a better explanation for anybody interested:

When you make game sprites from Flash's built in drawing engine, to move these sprites in the game it literally has to redraw them in a different position every frame. In an earlier post, I mentioned getting around this by making it into one giant sprite, but this apparently doesn't help because Flash still has to redraw the damn thing every time. I opted out of Flash's vector drawing entirely by just copying everything to a giant bitmap image in memory, and for reasons that are not entirely clear to me, moving this giant bitmap is much easier for Flash than moving a ton of sprite information. Now when the screen scrolls up, I can make a bigger bitmap, copy all the pixels from the old bitmap to its bottom half, and fill out the rest.So, let's get going with that.

Log Update #3, 8/3/2010: Wheeee! Gigantic bitmap resizing is working surprisingly well. Of course, now I have to program collisions with it, which may prove difficult. In other news, look how trippy the game is right now! Sadly, it can't stay that way. :^(

Log Update #4, 8/4/2010: Here's what's on the agenda for today, just so I can stay focused: first I'm going to fix the level-scrolling glitch that I discovered last night, which should be easy, and then I'm going to try one method of collision detection between speared whales and coral cubes. Basically, I use ActionScript's built in hit-test function to see if the whale is intersecting with any part of the bitmap. Then I use another built in function to convert the stage coordinates of the Whale's center to its coordinates relative to the bitmap. At any given time one whale should not be intersecting with more than four sectors of the bitmap, so I'll cycle through them in order of closest to the Whale's center to the farthest, and if any of them are non-empty, the pieces of the collision will react accordingly. The awesome thing about this is that it's insanely efficient; instead of iterating through a giant list of corals and testing collisions on each, I just grab one by its grid coordinates. The problem is that I have to do math. Sigh...

nathan

[EDIT: Game has been moved to next post.]