Jump to content
  • Advertisement
Sign in to follow this  
proveren

Mario64-like engine question

This topic is 4841 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

Hello, I am currently trying to create a Super Mario 64 like game engine. I am fully aware of the fact that the game uses a scene graph for rendering purposes. However, I cannot quite say what technique the game uses for collision detection. As you might have noticed, the worlds of this game are created from irregularly scattered triangles with different sizes and slopes. A vertex could share 1 to many triangles. Also, there is a smooth transition when mario walks from one triangle to another, when they share an edge. I am asking this question because I don't think the game uses octrees for collision detection and I don't want to pass every single triangle from the scene (excluding non-linked landscape objects not passed by the scene graph as potential collisions). Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
As far as I can tell, the game uses a tweaked out version of this method. I say tweaked out because there must be a huge list of special conditions for events like grabbing onto a wall or pole swinging. And keep in mind, the animation is often what makes it seem so believable.

I will though give them props for their work. Even in a modern game, that coldet and animation is simply impeccable.

Share this post


Link to post
Share on other sites
Thanks for the reply, I will read that document a little bit later.
What came to my mind was the following (explaining the smooth transition when walking from triangle to triangle):
Once a level is created, every triangle of a "flat" area has a pointer to the triangle shared with each of its edges. The pointer points to null when there is no trangle, or the plane of such a triangle has a degree above %90(walls or ends of cliffs for exapmle). Also, all edges are kept as 2D (x and y only coordinates), so when our plumber leaves a triangle walking, a line per line collision detection is made (1st line is distance walked, again x and y only, second with the edge intersected). When the next triangle is found, the z value of mario is determined by that triangles plane equation.
My explanation is not so well, but hope you get my point.

Share this post


Link to post
Share on other sites
I get what you are saying but it has some flaws. For example, how would you handle jumping? You want your collision detection system to be as simple as possible. I have found that the more complex you make your system, the more you will be prone to errors and hacks to get it working

Read the paper and it should all come together. Walking from one triangle to another becomes no problem with that method.

Share this post


Link to post
Share on other sites
I read the document, and I must say that I learned some things from it. The main one is that I shouldn't be concerned with the collision detection, but the collision response. I will use that collision detection routine, I am not afraid that it will be slow, because in Mario64, there aren't so many triangles in the levels(they are some but big ones), and frankly speaking, the only object that goes through the routine is Mario, all the other objects are limited in their movement, so they don't need thorough checking. Ofcourse, I would use some octree subdividing.
Thanks for the link, I would work on the collision response routine now, since the one provided in the paper is not exactly what I want. I still can't think of an efficient way to determine when the hero should grab an edge.

Share this post


Link to post
Share on other sites
Quote:
Original post by zlatko_bre_1985
It may look noobish but ill say it:
Why u dont create a GrabbableEdge object ???



Amen to that... :)

Thats a really simple solution that should work extremely well too..


Share this post


Link to post
Share on other sites
Hm, easy said.
First of all, if the degree of a "cliff" angle is 90 or close, collision with a face will be detected in 99% of the case rather than with an edge. Second of all this "grabable" object, be it an edge or not, would have to be created when loading the level and thus would be static, however, in mario there are some objects like rotating cubes who have grabable edges at some state of their rotation, but at other times, they can't be grabbed.

Share this post


Link to post
Share on other sites
why not simple Id tag every grabbable object...?


if (CollisionOccurs)
if (TriangleTag==LEDGE)
DoHangingMarioStuff();
else
DoNormalCollisionStuff();


You could of course tag the whole object as grabbable instead of a specific triangle... and for moving object, simple reposition the grabbable object according to the elevator etc..?

Can't really see why it wouldn't work...

Share this post


Link to post
Share on other sites
Quote:
Original post by Rasmadrak


if (CollisionOccurs)
if (TriangleTag==LEDGE)
DoHangingMarioStuff();
else
DoNormalCollisionStuff();



Yes, I have to agree that more or less, everything comes down to this piece of code. I would remove the high possibility of colliding with a face, rather than an edge by first performing an edgetest with an extended ellipsoid radius. :) And by the way,we all know that mario64 collision detection is crappy at some cases, and that there aren't very fast moving object who could present difficulty to a simple approach to collision detection and response.
Thanks to all who replied.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!