Hello all, I am currently programming a 2d side scrolling game similar to megaman zero and contra in XNA. What would be the best way to tackle this project programming wise? I am stuck on level design and collision detection. I need the level to be similar to this. What topics should I google to design this? P.S. I already know c# and have been through many XNA tutorials Thanks!

Quote:Original post by Kohar
Hello all, I am currently programming a 2d side scrolling game similar to megaman zero and contra in XNA. What would be the best way to tackle this project programming wise?

The first thing I'd suggest you look at is XNA Starter Kit: Platformer if you haven't already. It discusses things like collision detection and level scrolling.

The best to tackle it is to set an exact goal, identify the problems, break these problems into smaller problems, and then make the game.

Quote:Original post by Kohar
I am stuck on level design and collision detection. I need the level to be similar to this.

Level design? Like how it looks, the art style, the layout, where enemies and items are placed? If so, this can't really be answered. You'll need to find a team member that is good at game/level design. Or are you talking about level design tools?

There are two basic collision detection processes going on in a platformer/side scroller type game:
1. Collisions with the environment (like a platform/ground).
2. Collisions with enemies/items/powerups/etc.

For #1, a lot of platform games have a tile grid where each tile could be something like 32x32 pixel^2. Collisions are processed between the player and the tiles. If the tiles are stored in something like a 2D array, you'd just find which tile/tiles the player is interacting with and process collisions accordingly. For more advanced things, like depicted in the video you linked, you may need to look into pixel-perfect collision detection for things like smooth rolling hills.

For #2, this is usually more difficult. If you want more advanced techniques google quadtree or sort and sweep algorithm. But, for a first step maybe you should try something simple like a brute force circle-circle collision detection. For circle-circle, each 'physical' object has a collision circle associated with it. This circle could have its center on the center of the sprite and its radius could encompass the sprite. That way, in this simple collision detection scheme, to detect collisions between to objects you could check if the origins of the two objects' collision circles are closer than the sum of their radii.

Quote:Original post by signal_
For more advanced things, like depicted in the video you linked, you may need to look into pixel-perfect collision detection for things like smooth rolling hills.

For this I am thinking of having a image of the level that is everything the player can collide with. I will then compute the players next movement position based on velocity and check to see if the players sprite rectangle collides with any non transparent pixels in the level. The problem here is the per-pixel collision algorithm I have only returns true or false. So if a player is running up a hill it will just detect a collision in front of him and not move the player up. What is a good way of resolving this?

It seems to me that this is nothing more than a modified tile-engine. If you look closely you can see that the curves are nothing more than contorted sand tiles.

bump for answers, I've also wondered how they do this in games like the gba metroids and such.

Quote:
The problem here is the per-pixel collision algorithm I have only returns true or false. So if a player is running up a hill it will just detect a collision in front of him and not move the player up. What is a good way of resolving this?

In addition to detecting the collision, you must also process the correct response. Consider the simple case of two penetrating squares. If the physics of the program determines that suddenly in some frame two squares are interpenetrating you must rectify this. For this to occur you must calculate how much one square penetrates the other. For example, let's say one square is the ground and thus it cannot move. The other square, maybe representing the collision box of the player, penetrates the ground by say 7 pixels.

The player collision box and also the player itself must then be moved up by 7 pixels in the same frame, before the rendering, so that it looks like the two objects do not interpenetrate and thus the physics is believable.

So the moral of the story is that not only do you need to detect the collision, you must detect the magnitude of the collision, that is how much the dynamic physical object (player) penetrates the static physical object (ground). Then you must move the dynamic object backwards that corresponding magnitude in the direction of the dynamic object's initial incidence.