Advice on Game

I'm going to dive into making a 3d fightining game. I think i'm going about it right, but I do have a few questions if someone wouldn't mind answering. Mainly about collisions. I'm hoping for 60 fps or so, might go down to 30 min I hope, I also expect once I finish a good 2 player split screen, to enable it for network play.

1. I plan on rendering 6 frames of animation before it readkeys,etc. Without a timer, should I use a timer, or set the fps/animation time?

2. I plan on using punch,kick, and a weapon for combat. I plan on handling the weapon collision with linepick, and using sphere to polygon collision, or should I use linepick for the punch/kick and/or create a sep childmesh to determine those collisions?

3. Since I wish to run 6 frames of animation before should I check collisions every frame and handle them every framer, or every frame, but handle them after all six frames, or just once at the end of each 6 frames?

4. I don't want to use terrains, so I'm going to use meshes instead. When walking should I always attempt to move the mesh downwards to make sure he's not floating. Or should make a type ground, with x/y/z/hieght, and check the players coordinates and adjust if neccesary?

I think that should do me. The only other things I'd be curious to know if anyones got is how much % of udp is usually lost? And if anyone has an animated mesh I could use for a start, there was a ninja somewhere, but I didn't find it.

First problem. ALWAYS create a network game from the beginning. Dont' try to convert a working game into a network game.

I don't understand the question. Check out my programming tutorial if you wish to use frame-limiting (delta time).

Don't understand this question either, but keep in mind that Blitz collisions (using the Collisions command) only work 1 way (moving entity checked against a stationary entity). If both of your entitys are moving, then you will probably have to use linepicks. Note too, however, that linepicks are processor intensive and you will be limited on how many you can use.

For number 3, just do it however you want. Why 6 frames anyways? What's so special about every 6 frames? (1/10th of a second?) If you use my frame-limiting code, it would probably be easier to just check collisions every frame.

It's probably easiest to just use Blitz Collisions from the player to the ground mesh and apply gravity every frame (based on time between frames).

2. Picking won't work with an animated mesh, I would consider using several custom collision spheres (possibly at/between bone positions) for each limb/bodypart and testing the distance between them using EntityDistance().

Ninja/Zombie/Dwarf here:
http://www.psionic3d.co.uk/cgi-bin/imageFolio.cgi?direct=Free%20Stuff/3D%20Models

thanks for the link beaker. And the other info guys.

Sorry, WOW! i wrote this really bad, I was really really tired, guess I should've waited to morning.

I guess I never thought about collision only working 1 way if their both moving. Six frames isn't a neccisity it was just what i picked, thus 10 updates per second.

Going to have to see how bad linepicking with an animated mesh is too. Never done linepicks so.

Collision always works one way... ie the first entity (type) in the Collisions command will react to the second, namely by either stopping dead or sliding. The problem when both objects are in motion is that the collision check can fail and things fall through one another - you can get around this, though, with multiple Updateworld's.

For collision between the fighters Beaker's method makes a lot of sense - I don't think Entitydistance even needs an Updateworld to function correctly (and even if it did, you could do the calculation manually) which totally avoids one layer of complexity.

Where collisions between the fighters and the arena are concerned, conversely, the built-in system is highly appropriate. Don't be afraid to mix-'n'-match collision methods - they each have their particular strengths.