Ground Collision methods?

The most practical I can think of is hard coding all the points on the map I want to make line segments for the boundaries.

You must be joking. Consider a data-driven approach instead, you might find JSON useful.

Separating collision geometry from visible geometry is heavily recommended. It is standard in many AAA games for performance reasons, but it buys a lot of flexibility even in small projects (the infamous "secret room wall").

(1) Is there a way to make meshes physical with other meshes or (2) is that all manually coded with collision boxes and spheres, etc?

(1) Yes, there is, but it's not automatic. In general, meshes are approximated in some way. In general you'll have to figure out yourself whatever a mesh is solid or not. An artist will have to flag the mesh as "nonsolid". In certain systems, this "nonsolid" flag was embedded in material properties.

(2) It is automatically [s]coded[/s] input (by using data-driven systems). Very little things are hardcoded nowadays. If your level is data, your collisions should be data as well (and preferably go together). Do not mix data and hard-coded stuff (hard-coded ~= assumption). It will sink way too much effort in the making. Historically, cubes/boxes/spheres have been used. Now k-DOPs, convex hulls, cones... if everything fails, the whole tri-mesh will be used. Trimeshes are typically quite slow, but sometimes they are necessary.

[quote name='Tiege' timestamp='1318204643' post='4870910']The most practical I can think of is hard coding all the points on the map I want to make line segments for the boundaries.

You must be joking. Consider a data-driven approach instead, you might find JSON useful.

Separating collision geometry from visible geometry is heavily recommended. It is standard in many AAA games for performance reasons, but it buys a lot of flexibility even in small projects (the infamous "secret room wall").

(1) Is there a way to make meshes physical with other meshes or (2) is that all manually coded with collision boxes and spheres, etc?

(1) Yes, there is, but it's not automatic. In general, meshes are approximated in some way. In general you'll have to figure out yourself whatever a mesh is solid or not. An artist will have to flag the mesh as "nonsolid". In certain systems, this "nonsolid" flag was embedded in material properties.

(2) It is automatically [s]coded[/s] input (by using data-driven systems). Very little things are hardcoded nowadays. If your level is data, your collisions should be data as well (and preferably go together). Do not mix data and hard-coded stuff (hard-coded ~= assumption). It will sink way too much effort in the making. Historically, cubes/boxes/spheres have been used. Now k-DOPs, convex hulls, cones... if everything fails, the whole tri-mesh will be used. Trimeshes are typically quite slow, but sometimes they are necessary.
[/quote]

Thanks for the info. I was wondering about visible vs collision geometry because in tutorials where they create bounding boxes/spheres, I just wondered why bother loading an additional model if you have to program that anyway? The only thing that model gives is its max and min vertices to create a box.

But for example think of a map in super smash bros melee. The background is the invisible geometry (im assuming) which has no interaction but gives the game visual. The collision geometry is the ground, the platforms, etc. The stuff the characters can actually stand on. This is basically what i'm trying to create. I would make a bounding box for the platforms but what about the ground when it's slanted and distorted so that it cant possibly be covered correctly by boxes?

Something like this:

Sounds like what you need is a physics simulation, specifically a 2D physics library (or a 3D physics library constrained to 2 dimensions). Bounding boxes are used when they can be (because they are simple and quick), but a good physics library can handle arbitrary convex polygon collisions, impulse, friction, etc.

There are several freely available physics libraries, such as Box2D and Farseer, depending on your needs. Your collision polygons could be created with a program such as Gleed2d.

...(3) I just wondered why bother loading an additional model if you have to program that anyway?
(4) The background is the invisible geometry (im assuming) which has no interaction but gives the game visual.
(5) what about the ground when it's slanted and distorted so that it cant possibly be covered correctly by boxes?

[font="Arial Black"](3)[/font] You don't have to! Tutorials want to keep it easy so they illustrate a very specific point but they often fail in giving you a big picture. The collision model is not a standard model. It is a special model. Typically, all the graphics-only information will be stripped (texcoords, at the very least). It might feature less vertices, or be a very different thing such as a physic API native opaque blob.
But let's keep that easy and start from scratch why should you do more work instead of putting all the numbers in a file so the compiler can mangle them for you in an easy-going array?
The main reason is to allow easy modification of data. Now, if you have 8 levels, perhaps you might manage to just code them all in but you'll always have only a choice between those 8 layouts. Suppose your best friend likes the game so much he wants to design a level for you. What do you do? Perhaps you add another array and recompile everything so you get the choice of 9 collision layouts.
By loading the same information from an external file, you get a basically unlimited amount of choices. Your program will be more flexible, more easily reusable, you keep a gazillion of magic numbers outside your source files and, in case you need to move level 1's platform 105 one unit away, you won't have to wander through the code.

And the cool thing is that you don't have to write the numbers at all! You draw them using the above mentioned GLEE2D.

For example, here is how your example above could be visualized in terms of collision geometry.
[attachment=5752:maptg.gif]
In 2nd frame, I tried to use boxes and triangles. Note there can be some small differences (as stated above) between the graphics model and the collision model. Not only they are typically tolerated but they are often necessary for example to avoid the player getting stuck in small details.
In the 4th frame, an equivalent model is presented. This one will hopefully work better (green quads have been colored for presentation only).

[font="Arial Black"](4)[/font] I have to point out you're using confusing terminology. If the background "gives the game visual" then it is not invisible. I understand you were trying to say "invisible by the point of view of the collision system" but that's just not good. Say nonsolid, or non-collidable. But not "invisible". That's just backwards.

[font="Arial Black"](5)[/font] Just use something else!

As laztrezort noted, you might want to use a collision library. I like Box2D.

Sorry about the confusing terminology. Obviously I have little to no idea what I'm doing haha. Thanks for being patient with me. I like the idea of that convex hull method. How would I go about implementing that in my code? Also once I eventually do have my collision area mapped out then give a bounding box to the character or something how would I detect the intersection between the two?

I have a map made and also kind of the collision mask to go with it. Would it just be simpler to make the collision meshes solid for my collision with the terrain and platforms?

I like the idea of that convex hull method. How would I go about implementing that in my code? Also once I eventually do have my collision area mapped out then give a bounding box to the character or something how would I detect the intersection between the two?

Well, I'll tell you what I would do - use an existing library, such as Box2D

Implementing this all yourself would not be trivial (especially to make it perform well), and probably could not be answered succinctly in a forum thread. But I suppose it would be a good learning exercise, if that is what you are after. Be prepared do do some research and dig into some math - I would start by at least checking out the documentation for Box2D here to see how they set up their library, even though you may only be using a subset of their functionality. Sorry I can't help further, this is not something I've ever tried to implement myself.

Well i don't intend to use others' libraries :\. I don't need things like friction, impulse, etc. Just want my guy to not fall through the floor But thanks for the advice!