Anyone who have any good resourses? I've searched all around but I can't find any real good information. Most I find has to do with MMORPGS, I need for action games. And I'll like to understand the concept before I code it all. //Wave~

Try searching for "client side prediction" and "server side prediction" instead. You might get better results.

Wave,

I was responding in a post last week regarding prediction both on client and server as Squirm has mentioned, so you might want to take a look at this:

http://www.gamedev.net/community/forums/topic.asp?topic_id=251930

Keep in mind I am fairly new to the whole concept but this will give you a general idea of what is involved in both client-side and server-side prediction. As well, there are a large number of articles regarding this topic online so you should have plenty to build from ^_^.

Permafried-

I have actually read that thread(and all links provided). Some days ago I asked about the layout of the program. I got the answer that sending keypresses are suiside! And I got response that sending vectors is the way to go. That contradicts your tactic, please explain the benifits. Still I don't kown how to solve the smooth out (qubicSplines or beizercurve or whatever).

Example:
1. p1 gets a msg from p2, in this message p2 sends his Location Vector and Force Vector.
2.p1 takes the location and increases it with Speedvector * Latencytime / 2. If p2 is heading straith forward his possition should be almost exact seen from p1. right?

What if p2 did not move like predicted? what am I supposed to do with the next update that proves to be wrong.

I have a function that draws a Beziercurve, it has the parameters (time,x1,y1,x2,y2,x3,y3) //time from 0.0 to 1.0 and returns the X and Y on that curve at given time. Can I use it?

Hey,

The reason behind me sending out key presses at such a huge interval is because I'm sending them out as unreliable, basically I toss it out and if it gets there it gets there, if it doesn't it doesn't that way if say 3/85 get lost I'm really not that concered. As far as sending key presses goes I do the following:

static const char BUTTON_FWRD = 0x00000001;
static const char BUTTON_BACK = 0x00000010;
static const char BUTTON_RGHT = 0x00000100;
etc.

As I'm sure you can see with the pattern you manage to pack 8 key presses into a single byte using:

char byte;if( walking ){ byte |= BUTTON_FWRD;}if( backward ){ byte |= BUTTON_BACK;}

In this way I can extract them on the server side using a bitwise &= and comparing vs the buttons defined above. I also send along with that the client's current view angles (for spawning weapon fire via the cross-product).

Really the advantages here are not only is my packet size incredibly small, but if I lose one here and there it's really not gonna break the game....if mass packet loss is a problem with the connection than no matter how you send the data there's going to be problems. As well, I feel having the client keep track of where they are kinda defeats the purpose of the server in general since it makes your program much easier to hack, especially if the server really has no way of validating that this information is invalid.

Quote:

What if p2 did not move like predicted? what am I supposed to do with the next update that proves to be wrong.

The one major thing that I left out of the previous post was gamestate updates, especially since it was getting way too long as it was. Basically I send out a gamestate update every 200ms or so which says "I don't care where you think the stuff is this is where you're going to put it at time X." Just imagine if you predict wrong 2 frames out of 85 though how much can you really be off unless you're moving your player a disgustingly large amount every frame....this is something you should sit down and figure out mathematically how often you should force a position change and how far off you can afford to be based on mondel sizes, etc.

As far as your final question goes, this kind of math is really not my strong suit and I'm not even going to attempt to pretend I know....hopefully someone else can help you with this because I'd hate to mislead you on it ^_^.

Permafried-

I would send the full state every so often (every 5 seconds?) and send input (keypresses, whatever) in between. That way, if you lose a packet, you'll only be out of sync for 5 seconds, but you'll get most of the transmission savings of sending only input.

If the server collates packets (it should) then you can send the full state for a single player, and deltas for the others, in each network "tick" packet. Then cycle through the players (and other entities that need simulation) for each new packet. That way, you keep network usage pretty stable, but will scale gracefully between a few players / very high accuracy, and many players / slightly lower accuracy.

All of these methods will have full accuracy if there's no packet loss, of course.

Your right, keypresses seems to be the way to go, the dude that said "keypresses are suiside" couldn't have been serious. I've even heard that UT2004 uses this techique!

And for the calculations, I don't know hoe to read it.
Udp header 28bytes
2bytes for msgType and msgFrom
then 1 byte of keypresses for 8keys.

31 bytes sent at:
Medium 6 times/sec <-- I made a program to check this
High medium 11 times/sec <--- It is quite accurate
Absolute max 30 times/sec <--- Insane turn back N forth

Each sec, that is:
medium 186 bytes/sec
high at 341 bytes/sec
maximum 930 bytes/sec

How much is it possible to send/recieve in total?
Because if I have 8players, it's
an average of 1488 bytes/sec/player.
With tops of 2728bytes/sec/player.

Is this much? If a client has a avg internet download of ~200kb/s he should do ok, is all this correct?

All my keypresses are keys that is held down, that means you hold your fire key to fire, but most people still prefer to click it. What if the shots get of of sync (shots travel quite fast), then they'll hit different stuff on different clients and this fault will continue to grow almost forever. Do I need some timestamp for the shots? I'll rather delay the shot so it is instantainious fired on all client but I don't know how.

And I use a client to client system, everyone connects to everyone. How much do I save ( if any ) in speed to have a host-client system instead?

Thanks for the support so far!
//Wave~

hplus0603 you said:
"If the server collates packets (it should) then you can send the full state for a single player, and deltas for the others, in each network "tick" packet." (forum comment/code codes?)

collates? I guess it don't then ;)
And what is a network tick packet, is that what I call keep_alive_ping, you think?
And 5sec in an action game, seems like the tanks is going to get from one side of the map to the other side in that time ;) but I don't know. (no scroll 2d map)

If you don't have the time to explain please give some links and I'll do the research myself,
//Wave~

wave: Firstly, sending a packet that only contains one byte of actual data is bad. You will need to batch data into one packet before transmission (and use compression).

Secondly, For synchronisation issues, every now and then you need to transmit a "state" packet that contains the actual state and positions of game objects, you cannot rely on deltas alone because all connected machines will be running at different frames, including physics frames. No matter what all the clients will eventually drift out of synch by just using delta packets. To fix this, every now and then you transmit a packet that contains the absolute value of the object (eg: the actual player position). Use a server-client approach, have the server handle all the game logic and what not, the game state the server is in is the proper game state for all clients. Over a period of time the server sends out the absolute states for objects, if a clients object is wrong, it is set to this state, do not have the client tell the server what absolute state to set the object because that can allow hacks and cheats client side. (eg if the client can send an absolute position that is on the other side of the map then he can hack teleport himself).
You may have noticed how the server game status is the absolute state, when you play a game and the server lags out for 1 or 2 secs and your player is teleported back to where he was standing.

> keypresses seems to be the way to go

You should translate key strokes into formal commands for the wire. Keyboards across the globe tend not to be the same (AZERTY vs QWERTY). Also, you may want to have a remappable keyboard feature on the client app at some point in time. Tying a network protocol on a specific keyboard layout is akin to painting oneself in a corner.

-cb