Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.



This topic is 6627 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am making a side scrolling platform game similar to Mario. I am using a generic tile-based map system with scrolling capabilities. example for(int x, x < NUM_XTILES; x++) { for(int y, y < NUM_YTILES; y++) { tile = MAP[x,y]; draw tile } } ... something similar to that. Anyways, i was just wondering how to detect for collision with the tiles. How did they do it in the old Mario games? Like, if the character hit a wall tile and needs to stop moving, how would I detect such a thing. Please help me with anything you have. (C source code would be nice!) thanks

Share this post

Link to post
Share on other sites
Hi. I don''t have the time to write out some code for you (leaving work to catch a bus soon) but I''ll give you some ideas and maybe some pseudo-code (which is much better for discussing algorithms by the way).

There are lots of ways of doing collision detection with tiles but I''ll just put down one or two of them. Firstly, you have to remember which tiles are "walkthroughable" (in the words of a friend) and "non-walkthroughable". You can do this by maintaining an array of 1''s and 0''s say that represents all tiles on the screen. Then with some calculations, you can find out if Mario has attempted to walk over an opaque tile. If he has, don''t move him. What you do usually in the game loop is get input, process it and then apply it, and then draw the frame. So during the process phase, do some calculations and see if Mario will collide with something if he moves as the input directs. If he will, do something else (ignore them if he walked into a wall, or make Mario explode if he just walked into a landmine).

There''s lots of ways of storing the collision information. You may even have a special structure that contains the bitmap image and some data about that tile (visible or not, etc.) that is onscreen at the moment. You can just add an "opaque or not" item to the structure.

If you want me to elaborate send me an email. Although, when I post this, it will appear on the top of the "recent discussions" part of the main page so lots of people are likely to respond anyway.

Hope that helped. Vale!


Share this post

Link to post
Share on other sites
I''ve designed a couple of mario-like engines in the past with much success. Firstly you must note that there are four ways you can hit a particular tile. You can hit them from the top, the bottom, the left or the right. This may seem obvious, but it''s important to be able to make the distinction between the four. For instance, in the classic Mario games there are certain tiles that Mario can jump through from beneath, but he can land on top of (you can see a lot of this in Sonic the Hedgehog as well.) I''ve been able to dupicate this behavior be implimenting my tile collision properties as a series of single bit flags stored with in a byte. For each kind of tile I can turn off whether mario bumps into the left side, or he can simply pass through the left. Floor tiles will generally only have top collision, and backgrounds all have no collision set and can simply be skipped in terms of collision.

Now, in terms of the actual code. Firstly, part of what made the Super Mario games so enjoyable to play was the way Mario reacted to his environment. The Mario games were basically all nifty little 2D physics simulations. I coded my mario-clone (using graphics stolen with an emulator and a board create by my little brother the pixel painter/2d game board designer) as a physics simulation and was able to duplicate the gameplay almost perfectly. My gameobject structure (which I used for both mario and the baddies) looked something like this:

typedef struct _GameObject {

float xPos, yPos; // x and y position
float xVel, yVel; // x and y components of velocity
float xForce, yForce; // total force applied in last update

int xBound[4]; // x points of bound box.
int yBound[4]; // y points of bound box.

float mass; // I used 1.0f for everyone.

int curState; // sprite''s current state.
float counter; // counter for misc operations.

// info that represents this objects sprite animations,
// states goes somewhere in the struct.

} GameObject;

(NOTE: Actually, the I stored the bound box along with the state information, so collision of mario ducking was handled differently from him running. All I had to do with specify the ducking state when the downkey was pressed.)

Basically, for every update, each character has forces applied to it, one of them being gravity (actually, just apply a constant acceleration.) The force is then converted to acceleration which is applied to the velocity which is then used to move Mario for that frame. NOW! comes the collision part.

When I add the xVel variable to the xPos I first check to see if the velocity is negative or positive. If it''s negative, Mario is moving to the left, so he can only collide with tiles that have right side collision. The same can be checked if mario''s X velocity is positive. If it''s just zero there''s no way he can be heading for a tile in the horizontal direction. If your in a tile you can then determine what mario''s no X position is by takeing mario''s position and MODing (%) (I personally suggest you using an ANDing technique --only if you have tiles sizes that are powers of 2 (8, 16, 32, 64)) by the tile size, and if are on the right side, then adding to Mario''s position by the tile size. (try this out on paper) The same goes for the verticle plane.

Of course you have to make adjustments for the existance of the bound box, I believe they are fairly obvious.

Once you have something like this in place you''ve pretty much got your basic engine ready and you can make whatever game you want. Of course there are other kinds of tiles (which I haven''t touched yet but kinda know how to handle) including slopes and ramps, which take away that boxy look some games have. (the original megaman series was all vertical and horizontal, but nice art made that acceptable) Sonic the Hedgehog made incredible use of these in their environments and even had loops, which I think alone sold a million copies of that jewel of code.

Well, I''m glad you''ve stayed with me until the end of my exhaustive reply to your question. If you would like to see my mario clone I''d be happy to send it to you. But I must warn you that this was written before I had a good concept of doing timing in windows and that my stupid VSync was at 120fps without my knowledge. Anyways, have a great time discovering your platform game. Adieu!

Daniel "NitroSR" Piron

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!