Data Coordination Between Server & Client

Started by
34 comments, last by roadkillguy 12 years, 9 months ago
I see.. do you delta-compress everything? I have a class entity with x, y, z, dx, dy and dz that should be sent in a baseline packet right? There will be a whole bunch of these entities that will need to be coordinated, and I'm not sure if I should store them in a list (Delta checking might take a while given that we need to check for every combination for a duplicate) or if I should just leave the packets always the same size (some entities would be empty data and bandwidth would technically be wasted).

Should I bother delta checking this list? It will probably be changing every time, and there will be a different number nearly every time (Bullets and players are both entities). Terrain modifications would be the same way.

So far I'm seeing it this way (Server Side):

Check for acknowledged packets.
Update inputs.
Update tick. (Simulate)
Send baseline packets. --Based on the difference between the acknowledged packets we've received from the client (Their current gamestate) and the current server side gamestate.

Do I need to be keeping track of all the clients' gamestates? It seems to me to be the only way to delta compress data.
Advertisement

Do I need to be keeping track of all the clients' gamestates? It seems to me to be the only way to delta compress data.


Yes, if you need to delta compress states, then you need to know what the client knows.

However, for bullets, you could just send the event right away, and then count on the client to forward extrapolate on its own. For "injury" events, send those from the server as events as well, but you don't need to send the actual bullet trajectories/positions, because those are just visual indications with no real effect on the game in themselves.
enum Bool { True, False, FileNotFound };

However, for bullets, you could just send the event right away, and then count on the client to forward extrapolate on its own. For "injury" events, send those from the server as events as well, but you don't need to send the actual bullet trajectories/positions, because those are just visual indications with no real effect on the game in themselves.


Should bullets be acknowledged?

So far I have a "packets to be acknowledged" list. When a package should be acknowledged, it is added to this list, and a thread keeps sending the data until we get a packet confirmation back.

[quote name='hplus0603' timestamp='1310944927' post='4836536']
However, for bullets, you could just send the event right away, and then count on the client to forward extrapolate on its own. For "injury" events, send those from the server as events as well, but you don't need to send the actual bullet trajectories/positions, because those are just visual indications with no real effect on the game in themselves.


Should bullets be acknowledged?
[/quote]

I don't know. Should they? How bad would it be if they weren't?
enum Bool { True, False, FileNotFound };
About ENet, I have just compiled it 40 minutes ago, if you don't like Makefiles (I don't), there is a Codeblocks project inside the source package, so it's just a matter of opening the project in C::B and pressing BUILD ;)
OpenGL fanboy.

I don't know. Should they? How bad would it be if they weren't?

I don't think it would be that bad... but you would still need to be able to disregard duplicates given that the server keeps sending them until it gets a reply. (A message could make it and it's confirmation doesn't)

and pressing BUILD[/quote]
See that's why I LIKE makefiles. I know exactly what's going on. In a makefile you can even write tar and publishing commands. I have setup so that when I compile for windows, it prepends every .o with windows-. (Even in subfolders) That way, I don't have to completely recompile when I want to test the windows version.

I guess it's a matter of preference.

This topic is closed to new replies.

Advertisement