• Register

Smokey the toad is not your average amphibian. With a propane-fueled weed burner in hand, he charges into battle against a relentless force of hostile frogs in a race war that threatens to tear his world apart. It's up to him to emerge victorious and save his kind.

Post news Report RSS Progress Update, September 2016

The collision detection system gets an upgrade. Also, I added a couple interesting maps for testing and catching bugs.

Posted by on

It's been a good couple months of steady progress. I broke away for a few weeks, because you know, life, but I came back and have picked up the pace.

I've added more content, touching up levels. I have a handful of levels that are half-way finished that I've been coming back to. That accounts for much of the time I spent over the last two months.

Recently, I approached something I've been needing to get to. That's the collision system. I was using a rough, grid-based collision system. Basically, if a fireball that is traveling across the map touches the same grid square that the player is on, the player would get hurt, even if the two weren't visibly touching. It works well-enough much of the time. I haven't had any complaints about it. But it's very inaccurate and this is obvious at times.

The squares that touch the toad and sheep are highlighted in white. If a fireball touches one of those squares, it triggers a hit event for the entity.

I made it this way because it was fast. You see, I have an entire separate grid dedicated to collision. Each square on it points to the entity (enemy, player, etc.) or nothing at all. Each time the player moves, it erases the old pointers and adds new ones based on its new position. So when a fireball is traveling across the map, it just needs to check the grid square it's on to see if it has hit anything; if it's not empty that means a hit/damage event should be sent to the entity that the grid square is pointing to. This is loads more efficient that looping through every entity on the screen and doing a proximity check. Instead of N checks every time a fireball moves, only one check is done.

New, more accurate, collision box (in blue over the player), covers the visible area of the toad sprite.

So I've been refactoring my code to do box/rectangle collisions. I don't need exact, pixel-by-pixel, collision checks. An approximate rectangle that covers the visible area of an entity does the trick. Granted, this is more demanding than a simple grid check, and I could easily find myself ending up with hundreds of nested-loops of box-collisions being calculated with each frame, but I found a way to keep it fast. I still do a grid check, and if a fireball is touching the same square that the player is on, a second check will calculate between the two to see if they're touching on a visible level (the box/rectangle check). This keeps it to just one box-check per fireball per frame.

I also created a couple test maps to help with testing. I play my game after about every change I make, running a quick test to make sure everything works. But this method hasn't been enough. It takes too long to play through the whole game. I test in the area I am working on, but sometimes there are unexpected consequences that affect another area of the game. Therefore, what I did was make a test map that has everything in the game (still a work in progress), but is small enough that I can run a quick test through. I don't expect this to catch everything, but it'll hopefully catch many of the bugs that usually slip past me that become a project later down the road to fix. If they're caught upfront, right after the change I make, then I know it's related to the change I just made (so a quicker fix).

Running through my "everything" test map.

I found it surprisingly fun to work on the "everything" map. I know that the better I make it, by fixing all the issues with it, the better the overall experience of the game will be. I also got some cool ideas by throwing everything in one map that I'd like to try incorporating into the game at a later time.

The other map is one that's intended to break my game. Ideally, it shouldn't. My game should be made well enough to gracefully handle any issues, such as too many entities, invalid parameters, and so on. This is meant for me to play through occasionally as a pressure test.

I have some exciting things coming down the road. I'm finally getting around to bosses and things are starting to feel more cohesive. Actually, who am I kidding? This still feels like an incoherent mess at times! There's glimmers of hope here and there. I have confidence that it's going the right direction and it'll all come together in the end. But it's been a long road to get even this far.

Until next time.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: