What do you mean by "show you how to do" it? What are you unsure of? What do you have so far? What is your level of experience?

I think you just need an animator.

We need to know a bit more about what you are having problems with. Your question is far too high level, like asking "How do I make an RTS unit system?" Hundreds of pages could be written about how exactly you do that. What do you have? What is causing you problems? Have you started yet on the game and are having problems?

Hah, I programmed the player code for a game like this. Basically, the way I did it is, I laid down a bunch of bezier splines that define where the player can walk. The camera targets the player, and was fixed in a side-scrolling perspective, so even though the spline curves around corners in a 3D world, the gameplay was always 2D.

Now, the trouble with bezier splines is that the input to the bezier function, t, is not equivalent to the arc-length distance along the spline. In other words, if you input 0.5 into the function, you may expect that the function will return the point that is exactly half way along the curve. But you'd be wrong.

So you can't expect to linearly interpolate t from 0 to 1 and get a nice, smooth motion along the spline curve at a constant velocity. Instead, you'll see your character slow down and speed up. Generally, it'll move faster along the parts of the spline curve that are highly curved (as opposed to the straighter parts).

In order to fix this, you have to do something called arc-length reparameterization. The concept is this. You create a second spline curve, called a compensation curve, that is 1D (in the sense that you input a value for t, and it will spit back a scalar for you, as opposed to a 3D position). You put in a t-value that represents the arc-length distance that you want to be on the spline curve (so, if you want to be 25% of the way along the spline, in terms of distance, you put 0.25 into the compensation curve). What you get back is the t-value that you will need to input into your real spline curve in order to get that distance. So, it's a two-step process.

And actually generating that compensation curve can be a tremendous pain in the ass. I used a technique that is similar to what you'll find in this paper:

http://www.saccade.com/writing/graphics/RE-PARAM.PDF

Now, I've heard that there may be some types of curve interpolation, other than bezier interpolation, that doesn't have this arc-length limitation. I was unfortunately stuck with using bezier curves and I had no choice. But maybe someone else can provide a better suggestion, and you can avoid all this arc-length parameterization nonesense.

But needless to say, it's a very difficult process. The player code I wrote took many months to get just right. Here's a few things that can help:

1) You may be tempted to lay down your splines such that they follow the contours of the ground that the player walks on. Don't do this. Instead, make your splines completely flat and level. They can curve around corners in the x/z directions, but should never curve upwards or downwards. If you do it this way, then you essentially have two axes, which is what you want with 2D game play. The x axis is your "spline distance" and your y axis is just the normal world axis.

2) In Klanoa, you'll notice that all of the walls are straight up and down. That is, the y-component of their normals is always 0. Also, the floors that the character walks on, even though they have hills, are never cantered with respect to the player's local z-axis. If you follow these basic rules when creating your own level geometry, you'll have a much easier time. Unfortunately, I had no such guarantees about the level design in my code, which is partly why it took so long.

3) Use a collision strategy that is appropriate for this type of game. The game I was working on used a BSP tree for world collision that was intended for fully-3D games. Therefore, collision resolution was such that, if the player collided with the world, the collision system could resolve the player somewhere off the spline. Ouch. So then, I had to snap the player back onto the spline (and there's no closed solution for finding the closest point on a spline, by the way) and the action of snapping the player back on the spline could potential cause another collision with the world. So, it was a real pain in the ass. If I could do it all over again, and I had my choice of which collision system to use (which I didn't), then I would just do some regular 2D SAT tests. I would probably have the level designers draw out their collision in 2D, and then lay their splines out in 3D. I would write a tool that showed the 3D spline, with the 2D collision wrapped to it. This could then be exported and passed off to the level artists, who would draw the level geometry such that it matched this 2D "slice". In code, all of the collision detection would be 2D, and would occur inside this "spline space".

Anyway, I know this doesn't really help you much, but it should give you an idea of the scope of what you're looking at and what concepts you need to learn.

I have never played Klanoa or Kirby 3D, but have you considered going the Donkey Kong Country route and making sprites out of your 3D characters and animations? Then it would give it the look of 3D with all the ease of 2D sprite work.

Quote:Original post by jackolantern1
I have never played Klanoa or Kirby 3D, but have you considered going the Donkey Kong Country route and making sprites out of your 3D characters and animations? Then it would give it the look of 3D with all the ease of 2D sprite work.

I think he's talking about game mechanics, not artistic style.

CDProp's answer is the most detailed one you're going to get without providing us with more specific information than "movement like New Super Mario Bros" and "refine the movement more". We have no idea how your game looks and behaves. Please tell us which specific area of platforming you're having problems with and we'll do our best to help you out there.