Level transitioning: GREAT SUCCESS!

Hurray! After putting in a fair amount of work yesterday and today, I've gotten the level transitioning to work. Now--shock and awe--when you get to the end of one level, you can move on to the next! WTF!! The future is here!!! (The next level here is exactly the same except with gray bricks instead of red ones, but it is an actual separate file.)

The only thing I really need to do is make the transition prettier (since now all it does is just stop and immediately load the next level). I'll need to flesh this out a little more over the next couple of days, but I'm pretty happy with what I've got going on right now.

I'm gonna spend the bulk of my time in the following week designing some new levels and some new blocks and enemies. I'd like to get a solid four levels together just to mess around with and show off to people. That'd be nice.

On an unrelated note, I finished Braid today and it was absolutely perfect. If you haven't bought it yet, buy it NOW. It'll be the best gaming purchase you could possibly make.

Video:
ExtinctaLevels (720p, 14.4mb download)

Extinctathon: enemy types and collision bugs

Now that the level loading is about halfway where I want it to be (it's independently loading lists of Blocks and Species), I need to do some serious work on the collision detection algorithms. I'll go into more detail in future posts, but here are the basic problems.

• I need to implement per-pixel collision detection. This is most noticeablely an issue with the Snakeocat at the end, which, by virtue of the size of its bounding box, floats in the air a good deal more than the other enemies
  
• I need to do a much better job of processing collisions with enemies once they occur. The player dies in a handful of situations where he shouldn't. Right now, the player dies if he collides with the bottom 3/4 of the enemy. If the player is falling too fast, or the enemy is rising too fast, even when the player hits the enemy from above he dies. What needs to be done is to extract the player from the enemy and then determine if the player was on top, to the side, or underneath.
• Similar fixes need to be done with regards to collisions with blocks. There is a rare bug when the player is between two blocks spaced exactly the width of the player apart that can cause some unusual behavior.
  
• I need to optimize the hell out of it. I deployed to my XBox for the first time this weekend, and anything more than 6 enemies on screen KILLS the performance. We're talking 1 or 2 frames per second. My basic algorithm is as naive as it gets (literally everything is tested with everything, an O(n^2) algorithm), and I need to fix it as soon as possible. It does fine with a couple hundred enemies on my computer, but, of course, that's a lot faster (with certain kinds of operations).
• In addition to optimizing the broad phase of the collision detection, i.e. deciding what should be tested against what, I need to do some serious optimizations on the collision detection itself. I have not yet decided how best to handle this.
• And, finally, I need to make it so that when enemies die by falling off the screen they don't give you points.

That's it for now. I was kind of lazy today and ended up just making a new enemy (the af0rementioned Snakeocat). I'll get to work on the serious stuff tomorrow.

Extinctathon: tiny updatelet

The whole Species content pipeline thing is done (enemy loading and saving, in lay speak), and now I'm going to be updating the Block class to make it more extensible and more geared towards classification via a BlockType enumeration, a method which I've found incredibly helpful with the Species class. I'd like to have more done at this point, but I just picked up Ninja Gaiden II -and- Lost Odyssey, AND I'm at work two days more than what's normal this week. Hopefully I'll catch up on Sunday.

In other, non-Extinctathon news, a friend has passed along some very sciencey Fortran code that models the flight of a frisbee given some initial conditions. Somewhere along the line I'll be turning this into an XNA frisbee simulator, but I really want to keep working at Extinctathon for the time being.

Extinctathon! Current short-term goals

I've got some time today and hopefully more during the week, so I've got a couple of big goals to work towards. The main one is to get the level loading and saving working (level meaning the list of blocks, list of enemies, start point, end point, and a few other bits of info). I was having some trouble, conceptually, with this, but Shawn Hargreaves came to my rescue and explained what all I needed to do. Before I do this, however, I need to make a big change.

Yes, you guessed it....SPRITE SHEETS.

Right now I'm loading 20 different textures and switching between them multiple times per call to Draw(). This is very GPU intensive, so I've heard, and it's much better to load them all into a single image and then draw specific portions of that image onto the screen. The reason I have to do this BEFORE I do the level saving and loading mechanism is that it will replace the lists of sprites that make up the animations of the various characters with lists of rectangles describing where these sprites can be found on the master sheet. This will be a pretty big overhaul, and I forsee spending my whole day (well, up until noon) working on it. Fun.

UPDATE:
I have the sprite sheets working, using the incredibly helpful projects here. I spent most of the morning just adjusting all the draw and bounds-checking calls to work with the new system. I'd say I'm about 20% done with the Level content pipeline system. It's going to take a good deal of work, but I think I can do it. Once that is done, I can work on making a few more enemies, Block types, and a system for implementing power-ups. Once that is done, I can get to work on some serious level editing--after a few much-needed improvements to the level editor, that is. And I still need to get the menus working, either by adapting the examples found here or by rolling my own in some fashion that won't make the code completely unreadable. Either way that seems like a big ordeal.