Quote:walking/runnning/etc. How is that best done? Is it done with a collision test, and have it colliding with the ground?

First of all, if this is your first time making a platformer, I recommend making it tile-based with no sloped surfaces. This should simplify things significantly, and there are many great platformers made using only orthogonal surfaces. Similarly, use a rectangle as the collision shape for your player.

And then, yes, you want a collision test. With square tiles and a rectangular player you have what is known as "Axis Aligned Bounding Boxes" (AABBs). It should be very easy to google how to do AABB intersection tests.

Then, when you determine your player is intersecting with the world, you need to take an action. There are four cases - hit a ceiling, landed on a floor, blocked to the left, blocked to the right.

When you do your AABB intersection test you should be able to determine how far "in" your player has gone, in that frame, inside the world, for both the X and the Y axis. Use these values to determine which of those four states has occurred (or possible a combination - like hitting a corner) and the appropriate action to take.

The simplest action is to just move the player "out" by the amount they have gone "in", at the end of your update phase, before your draw phase. You will also want to set the player's velocity on that axis to zero.

This method is simple and avoids having to track if the player is "on ground" or "in air" and so on. Although, later you might want to add that kind of sophistication to implement animation, friction, etc.

Finally: doesn't XNA 3.1 come with a platformer sample/starter kit? Take a look at how it does things.

Quote:Can you use XNA's spritefont to draw sprites by putting sprites in as a spritefont?

Yes but this would be stupid. XNA already provides a mechanism for drawing arbitrary sprites - use it.

It sounds like you are looking for "sprite sheets". But this is a performance optimisation - you almost certainly don't need it.

(Alternately it sounds like you might want arbitrary symbols in your text - controller button images, for example. There are plenty of tutorials floating about describing how to do this.)

Quote:If your screen is only 400x400, and your game map (level) is 50000000000000x600, when you move your character on screen, how does that work? Do you keep the the coordinates according to the screen or the map or both? Or only one unless you find a reason to use both?

Keep everything that happens in the game world in "world co-ordinates". So this would include your player, but not your UI.

When it comes time to draw the game world, you want to transform it (specifically you want to translate it) such that the player is in the center of the screen.

Basically you want to subtract the player's position minus half the screen size, from everything you draw. You could do this manually everywhere you draw something. Or you could simply create a translation matrix and pass that into SpriteBatch.Begin().

Quote:Original post by pothb
walking/runnning/etc. How is that best done? Is it done with a collision test, and have it colliding with the ground?

Can you think of an alternative? ;)

Quote:Can you use XNA's spritefont to draw sprites by putting sprites in as a spritefont?

Perhaps, yes - go ahead and give it a try. Though I'd say that's abusing the system - you'll probably run into alignment issues and other cases where a custom system would fit better.

Quote:If your screen is only 400x400, and your game map (level) is 50000000000000x600, when you move your character on screen, how does that work? Do you keep the the coordinates according to the screen or the map or both? Or only one unless you find a reason to use both?

That's a huge map, best split up into multiple sections. Either way, collision detection and movement should use world coordinates. Only when rendering things should you translate these coordinates to screen coordinates. What you see on your screen is just a visualization of the actual data - whether that's full-screen, split-screen, or text output shouldn't affect the underlying data and logic.

Quote:Original post by pothb
As for how else would you do the running and such, I couldn't think of a better way or at least I'd think of as a better way. But I guess you could just have absolute values like always have your sprite running at x,90, then at jumps have him go up 5 and then down 5 again, but I was thinking that is incredibly inefficient and probably extremely hard to deal with if you end up having slope/different heights.

The simplest way is to have velocity and position. For jumps just give it a timer (eg: if intersected the ground last frame, move up at velocity=10 for 2 seconds or until a ceiling is hit).

Once you have that working, you can start expanding on it - introduce acceleration and terminal velocity, for example. Have different air and ground speeds and so on.

Quote:And on the spritefont thing, I was just wondering it about it. Since in a way, it would probably be separated already, and to animate, you would just send it a different letter.

I would strongly recommend against that. The simplest way would be to use an array of textures, and then index into that to perform animation. (Basically the same idea, but you're changing an integer instead of messing about with letters).

Quote:And for the starter kit, I wanted to know how it would be done for any side scroller, rather than just one with preset square type object, like it seems to have. (I haven't actually looked at the code)

Well - any tile-based side-scroller works on the same basic principles I described. Although by the time you're adding non-square blocks you've probably added an "on ground" and "in air" state - each with its own movement code.

Take sloped tiles for example. You'd want to change your collision response mechanism to handle landing on differently sloped tiles, and your ground movement code to go up/down hills how you like.

(The alternative to a tile-based platformer is a vector-based one, allowing arbitrary shapes. I've made one of these after many failed attempts. It's stupidly difficult and I wouldn't recommend it. Also it doesn't really offer many more gameplay opportunities than a tile-based platformer.)