Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411665 Posts in 69396 Topics- by 58452 Members - Latest Member: Monkey Nuts

May 16, 2024, 06:27:22 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Grab ledge like mario 64
Pages: [1]
Print
Author Topic: Grab ledge like mario 64  (Read 3704 times)
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« on: December 03, 2009, 08:06:43 PM »

I'm a gamedesigner but i've start to learn some game programming langage (blitz3D). I want to experiment with 3D controls and camera and learn myself how far you can fine tune and expend on them. I've quicly learn that there is a lot of tut to program complicate things, but very little about actual gameplay programming ...

To start I want to reproduce 3 test levels of famous 3D games (mario 64, zelda and sonic) to know to get their basic control. I'm playing and watching extensives hours of those game to get all the subtleties, and try to mess with level editors when available to understand.

Mario 64 (ds) :


Zelda 64 :


Sonic adv2 : http://www.youtube.com/watch?v=DTmxB5j3pxg

I thought first it would be fairly easy to replicate those move and it is fairly not!

I ve start with Mario 64, basic walking, running and jumping was easy, camera wasn't exactly hard ... but i simply don't understand how they did the edge grab.

The things is that everything in mario 64 seems systemic, not tagged or scripted.
This is handy as tagging cost ressource on a project workflow (especially if i want to do one man made personal project).

I have check with the toadstools unofficial mario 64 level editors that there is no tagging. Actually they have tests where they import geometry directly from a modeler into the game and it is instantly useable as a collision mesh with grab enable! No tagging, no preprocessing.

Imported level running in the game: http://www.youtube.com/watch?v=QFK6xvrXRTI
The editing in blender : http://www.youtube.com/watch?v=cjOhe1ar8Xc

Mario 64 grab is especially precise with the satisfaying snap feeling. I want to replicate that without having to resort on tagging or preprocessing.

I wonder if some of you have thought it up?
Have you work on such a system or have any idea about how they have or could done that?

Thank you
Logged

BlueSweatshirt
Level 10
*****

the void


View Profile WWW
« Reply #1 on: December 03, 2009, 11:43:58 PM »

Have a small collision box/line at the top of your player object.

If the vertical speed of your player object is moving downwards, have it check if this collision box/line at the top is intersecting anything. Make sure to give it a bit of a lip from the player's default collision geometry, as that would make the ledge grabbing much more trivial. The bigger the lip you give your collosion box/line, the easier it will be to grab ledges.
Logged

bateleur
Level 10
*****



View Profile
« Reply #2 on: December 04, 2009, 08:36:24 AM »

The things is that everything in mario 64 seems systemic, not tagged or scripted.

Not tagged by hand... but have you considered the possibility of writing a routine which runs through the level geometry identifying and tagging grabbable edges at runtime (after a level is loaded but before play begins)? This would allow a relatively clever detection algorithm without hurting performance too much.
Logged

slembcke
Level 3
***



View Profile WWW
« Reply #3 on: December 04, 2009, 08:50:25 AM »

The first thing that comes to mind is to do a preprocessing step when loading as bateleur suggested. Not sure how much you know about 3D math. Every edge in your model will join two polygons and each of those polygons have a surface normal, a vector pointing outwards from it's surface. If one polygon's surface normal is more or less straight up (the dot product of the normal and the up vector is near 1.0) then it is a floor polygon. If the other polygon's normal is horizontal (the dot project of the normal and the up vector is near zero) then it's a wall polygon. If the edge is between a wall and a floor polygon, then it's an edge you can grab onto.

Looping over all of the edges and testing them like that would be easy, add all the edges to a list or tag them somehow. Depending on how your model is stored, it may be difficult to make a list of all of the edges though.
Logged

Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine.
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #4 on: December 04, 2009, 09:27:44 AM »

Thanks for the input!

If i have understand well you advise something like this:



However i wonder how you don't cover:
How do i identify edge?
How i can discriminate different case? (see image below)
How do i align precisely with the edge?

Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #5 on: December 04, 2009, 09:55:51 AM »

Oh i didn't see the other response, take so many times building those pics...

Thanks!

I use BLITZ3D, maybe i should try something like:

Find objects within range
_____Find triangles within range
_____sort triangle from closest (?)
_____edge test each triangle


function "edge test"
__________get the vertices
__________get other triangles that share vertices
__________compute edge
Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #6 on: February 22, 2010, 02:35:13 PM »

Other than that i only find 3 ways general to do edge grab, and it all depend on the level technical design. Here are the results of my research if you are interest in.

1. Tags

Most game today use Tags, whether preprocess or artist driven. Tags can be handle with raycast or simply contact collision.

Assassin's creed use Tags and lot of raycast, the animation system and the logic them adapt.
It's pretty costly, that's why they have only 3 differents gameplay elements for scenary (bump, ledge and surface if i'm right). But they tag the building blocks rather than the scene. It give the game consistency but you cannot have arbitrary scene (limited by the building blocks).

Some other games handle tags at the level editor once the level is already done. It can lead to read the designer's path Lips Sealed but work better for arbitrary scene.

Preprocessing on the other side works well with arbitrary scene but can lead to "level bugs", and we must check the preprocessor, the level design and the geometry to track an single bug, it can be costly and lead to headaches.

Raycast is cool when you want to anticipate movement for animation or to ease gameplay with "retargeting". Contact leaves everything in the player's hand.


2. Grid

When i was working at elsewhere entertainment on an unreleased game TOTEMS. They used a grid base level building. The unit was "blocks" which is a collision mesh associate with a graphical mesh and a tag. Blocks where size according to the "gameplay step" which was the dimension of the grid (50*50*100 cm). Check for the gdc keynotes of "julien hamaide".

The advantage is that all movement was entirely contextual and it provide the character immediate awareness of his surrounding. All you had to do is to read adjacent cells and check for pattern to match situation.  From a design perspective it's priceless. Because grid have an inherent structure, Grab is has easy as checking the next cells. Essentially this is tagging every point of space. There is two way to check a "context" (ie grab here), information are directly store on the cells (ie grab able) or imply by the context indirectly (grab able if cells right above is empty).

Game like rockman dash and tomb raider use some sort of heightfield grid (ceiling and floor for tomb raider) that allow for quick reading of the environment. 2d game rely a lot on tiles as both gameplay and visual pattern of informations.

The draw back is that it cost a lot of memory and is limited artistically to the structure of the grid. On the other side it's quick and allow for very complex gameplay situation, and essentially you can "paint" design on level without code, especially if there is an interaction editor where you can specify pattern of interaction in a timeline by marking cells to check and which another interaction it trigger.

3. systemic grab
Obviously some graal and very rare. To my knowledge mario 64 and zelda 64 are the only one i'm 100% certain that does that way, thanks to the rom hack scene we can see that import model work in the game directly (ie no tagging).

Basically those kind of game would use sensor to imply situation from the world with arbitrary mesh.

Let's see the mario case:

From the data i have collect, i think mario first check for a vertical collision while in air, Then there is check a for an horizontal surface at a certain point, then it tries to move the model at the intersection of the vertical and the horizontal, then it check one more time for grab, if that fails, it enter 'fail grab' state that repel the character (i believe it's for safety and avoiding bugs like repeatedly trying to grab). Mario "fail grab" at many place, like trying to hang on a fence. But look at the sideview last case, he simply fall and do not attempt to grab.

Other obvious techniques is to get the collided mesh abd go through all the edge of his collision mesh, that can be costly and slow if the collision mesh is complex.

That's all i find so far.

If i try to make a game i will try to use something "local grid" object, on collision convert position to object tiles position, and check pattern. But it would require a little more design than that.

Hope this is interesting.
Logged

Sos
Level 8
***


I make bad games


View Profile WWW
« Reply #7 on: February 23, 2010, 07:12:51 AM »

 - How do i identify edge?

You have to do some preprocessing to maintain FPS. First look for edges (eg. triangles / quads that share 2 verticles).

Then filter this list leaving only pairs, where one surface is horizontal (height values for each vertex are identical, e.g. y1=y2=y3)
then get a dot and cross product from surface normals. Dot product should be around 0.0 (leave some space for error, so let it be .1 to -.1), and cross product Y (vertical) value should be also also around 0.0 (leave some less place for error there). Dot product will make sure that walls are 90 degrees from each other, and cross product will make sure that they are actually a ledge.


- How i can discriminate different case? (see image below)
See above

- How do i align precisely with the edge?

Use some fine tuning. Your best bet is to have your model for grabbing origin inside the hand, and cleverly switch it. with normal model.

PS. The way above will also list cases where the ledge is L shaped (like bottom of a floating box), but i'll leave eliminating that to you.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic