Well, after recovering from my horrendous blunder of being hasty and posting before looking at the rules, I set out once again to the daunting task of practically recoding the entire game.

The game was extremely laggy and poorly organized, so it was obvious that it needed some reform before we add any more. Without a good system in place, adding stuff to the game is often tedious and can work poorly with what's already there, and is harder to change/fix later.

Also, there's Final Fantasy XI, World of Warcraft, and random fits of laziness/watch cartoons and eat. However, I did accomplish something great today game-wise!

//skip to the next comment if you don't like nerd talk about boring block stories…

As I was painting the blocks for the redone VR_Training level, I realized that it was truly a PITA to paint each individual block by myself. As I designed the level, I had pretty much only put down the corner blocks, then filled in the lines myself.

So then I says, "Why not make an object to do this for me?" and thus, objAutoBlock_horz and objAutoBlock_vert are born. I created logical objects that detect either left-right blocks, or up-down blocks, then fill the space inbetween them!

Then yet another idea hit me. "When there's a crapload of blocks, it lags. Why can't I just stretch a block really long to make a floor?" Well, I tried it. I had it simply stretch the left block's image_xscale to close the gap.

It didn't work though… much to my dismay, the stupid thing would stretch the image properly, but the collision didn't. It would leave a collision gap proportional to the distance covered at the end.

So, I proceeded to reduce the number of blocks required in a different fashion. I created wide and long blocks, basically wall blocks of width/heights 16, 8, 4, and 2. Then I had the AutoBlocks paint using these instead, and it works amazingly well. It cuts down on the block instances a ton, in addition to making level design much quicker. I'm quite happy with the result.

//end nerdy, boring block-talk

I also added more parenting to the gibs/blood system, and re-coded Kamikaze Steave. I coded it in a way that makes the AI states much easier to work with, and the death sequences are easier to do as well. Instead of having special death sequences do a code then destroy, they simply set a variable that acts as a switch in the Destroy event. For example, if (deathtype == "frozen") {//turn into an ice block; exit;}.

So, what does this all mean? It means an OPTIMIZED Legacy of Gib release soon. Yeah, it won't lag nearly as bad. In fact, I already have the new VR_Training level running at 30 fps consistently, while the old one would lag. Who knows, the new release might even have some cool new additions, and a couple fully playable levels… but time will tell =)