Wednesday, November 5, 2014

Enemy Wall Collisions Working

After much mucking about, I finally have the enemy wall collisions working. My general algorithm that I mentioned before was mostly correct, but it needed a little tweaking. The way it works now is:

  1. Check if there was a wall collision last frame. (which would only occur if the enemy was actually drawn!) If so, reset to the "last drawn" position.
  2. If no collision and enemy shown, copy the current position to the "last" position
  3. Move the enemy
  4. Determine which enemies will be shown this frame. If shown, copy "last" position to "last shown" position
  5. Clear the collision flags
  6. Redraw (and capture changes to the collision flags)

The part that really threw me off was the bold part in step 2. I was copying the current to the "last" position even if the enemy wasn't shown, which, once I worked it out on paper, turned out to let the enemy advance slowly through a wall. But it all works now!

Once that was finished, I also managed to nearly recreate my slime "AI" code from the GBA version, so that was a good test to make sure my design is holding up well. ("AI" is in quotes as the there's no intelligence about it, but that's the best label I have for the bit of code that tells the slime how to move around)

So I think I'm finally done with the very core of the game, and it's time to move to other fun things, like transitioning through rooms, adding sound, allowing for alternate items, etc.




And lest I forget Robo-Ninja, I've cleaned up the cutscene a little, but I'm stuck trying to figure out how to animate, with my limited art skills and free internet art, Dr Squidbrain capturing Prof Treeblot. I need to think of a way that doesn't look stupid, but doesn't really require more frames of animation than I have.

I also started back into level design, which is always a nice diversion when I'm stuck. The past couple of rooms felt a little uninspired, but I'm almost to the point where I can expect the player to have a large set up powerups, so I can start designing new sorts of challenges that require quickly switching between powers. That should be fun.

No comments:

Optimization and C

Starting this next game in C, I've known there will be places where C isn't fast enough, and I'd have to drop to assembly to ...