• entries
686
1952
• views
387957

# PogoBot!

227 views

The new enemy is coming along nicely. I have completed all of it's graphics and started programming it into the game.

This will be one of the toughest enemys to program. Unlike any other enemy(yet), it has the ability to jump freely like Stompy. This also means more complex collision code needs to be added. Most enemy objects don't even recognize that there is a ground!

I also have to make sure it doesn't do anything stupid, like jump right off a cliff. However, this will be fixed using a set of "invisible walls" for the enemy.

The animation will be pretty cool if I get it working right. Every time the PogoBot hits the floor, it will show a kindof boing animation(bounce, or whatever a pogo stick does when it hits the ground).

I don't know if I'll have it working tomorrow, but I can try.

Im not sure how you code your game, considering that I havent seen any source code, but I do have a somewhat good solution to your colision problem. Atleast this is how colision is handled in my current project. First would be having the map atleast two layers, atleast one layer would run the tiles and one would run colision. The colision layer would be an array, just like the tile part of the map, and would consist of tiles that you could:

A. Walk on
B. Not walk on

Then you would make one generic function that would check to see if your alloud to move by passing to it the x and y of the person your checking. Then the function would take those coordinates and determine where they would be placed after the move on the colision map, if the coords after the move fall on a non walkable tile, dont allow the move.

here is the code for the function:
bool Map::CheckCollision(float x, float y,float boundry,int tile)
{
// Check all 4 corners
if(eventmarking[( ((int)(x-boundry)) / 32 )][( ((int)(y-boundry)) / 32 )] == tile||
eventmarking[( ((int)(x+boundry)) / 32 )][( ((int)(y-boundry)) / 32 )] == tile||
eventmarking[( ((int)(x-boundry)) / 32 )][( ((int)(y+boundry)) / 32 )] == tile||
eventmarking[( ((int)(x+boundry)) / 32 )][( ((int)(y+boundry)) / 32 )] == tile
)
return false;
else
return true;
}
}

//and when ever you want to check if an entity is able to move or not you would use this nice simple snipit of code:

g_map.CheckCollision(newX,newY,g_boulder.boundry,1)



That is sort of like the way I handle collisions now, except that it actually would work better. Right now, I use the same tilemap for rendering, collision, and everything. It probably would be a much better idea to have a seperate map simply containing collision data.

For instance, a 1 for collidable and a 0 for non-collidible.

This would be something good to try for a future tile-based project. However, I don't think I could change Stompy at this point to use it.

Yea, do what works for now. Another great thing about doing it that was is you can use other numbers for events, like tile 24 is a spawn point, if you walk on 81 warp to 34, stuff like that.

I like ShoeString's method, it's what I've used for a long time.

Here's a suggestion I'll make about your 'don't pogo off the edge of a cliff' problem. First, though, I want to say that I think that would be so awesome. lol

However, if you want them to change direction at the edge... changing directions in mid-air could look awkward. I know the player can do the same thing, but the enemy might not look right doing it.

When you're defining your imaginary walls for 'don't jump past here,' perhaps you can make them larger than one tile; make them stretch the length of an enemy's jump; therefore, they won't be able to begin a jump that they can't finish before the edge.

Oh, here's another thought. When a pogo is ready to jump (assuming he doesn't jump all of the time, thought now that I think about it, it sounds like he might) you can check the tile he's going to land at. If he has nowhere to land, don't even bother jumping (and then turning around in mid-air); instead, just turn the other way and jump that way.

The trickier part there would happen if you wanted to account for height differences. It'd obviously be easy to check jumps on a horizontal plane, but what if the pogo is on a high platform and could clear the gap since the other side is a lot lower? If you just use horizontal code (say, 5 tiles is too far to jump), this makeable jump could compute as unmakeable. I'm sure it wouldn't be too hard to figure a way around this, but it'd be slightly tricky.

Well, I just finished it up. It does change direction in mid-air, but it doesn't look too awkward. I just have to work it so it isn't too high in the air when it changes direction.

## Create an account

Register a new account