Given a client server setup. Has anyone ever found a packet that could be sent that didn''t need an ACK to it? I use the word "need" loosely to mean that the program will still function just fine if the packet gets lost but the other side will either expect a response or send a newly updated packet. For instance, people mention that issuing a move request to a server doesn''t have to be guaranteed to be delivered. But in reality, how is this so? Obviously if one move request is missed the client will still wait for a response stating if the move is legal or not. Unless you commit the NO NO of letting the client simply TELL the server what it''s doing. Now with moving, I issue a request and as the player, if I don''t see my character moving I do the most rational thing, I press the UP ARROW even harder But in reality, should the game resend that packet if it doesn''t get the OK from the server? Another option would be just to send the packets to the server and go ahead with performing the move on the client like normal and have the server simply send out absolute state packets X times a second. These would have to be sent for all creature, other players, anything dynamic in the game anyway so one more character in the mix shouldn''t hurt. So I''m thinking that the server will simply recieve input requests and in return it will send an absolute packet (probably a delta to the last absolute) and the client will adjust to that position if necessary. This could cause a lot of popping though. Ahh heck. Any good books out there specifically targeted at this? The Unix Network Programming book is good an all but only for the actual sockets work. It''s useless as far as game logic. Any good game programming specific books that have some of this info in them? I''m thinking maybe one of the Gems books? Someone really should work up some nice tutorials on this art as it really is turning into something a lot of people (me) are gaining big interest in and finding it very hard to find quality info. You all on this board are great. My hats off to all of you for your help. Webby

>This could cause a lot of popping though.

It would only cause popping if you immediately adjusted the position of the player to where the server says the player ought to be. Instead of doing that, adjust them over the course of a few frames (i.e. suppose they are off by 10 units in the Y direction, simply add an extra Y unit to their movement vector until they''re synched to where they should be). That requires a bit of calculating, but nothing overly complex. This may still cause artifacts (speeding up, gliding, etc), but it''s much better than popping.

In any event, the server can only send out absolute values if (and only if) it has all the proper keystroke information, and in the proper order! We know that UDP doesn''t guarantee this, so this becomes somewhat complex.

I *think* I have generated a workable solution, at least on paper It''s not due to be implemented in my game just yet, but I''ve been giving it a fair amount of thought. It''s off topic to this thread, though. I wouldn''t mind getting feedback/advice on it, maybe I''ll post it in pseudo code or outline form soon.

Anyway, as to your question: So far, I haven''t yet found a packet type that didn''t need some sort of response/acknowledgement, other than ACK packets themselves The only kind I could think of is (as you say) if the client is sending out absolute positional values. Then it wouldn''t matter if one got lost, you could pick it up from the next one. Actually, on the same note an absolute position value from server to client would fall into that same catagory.

So there''s one

quote:

---

The Unix Network Programming book is good an all but only for the actual sockets work. It's useless as far as game logic.

---

Hey Will,

I strongly recommend that you decouple your network code from your game logic. Write a generic network library, independent of your game. Then your game uses the library like it would any other library. The application simply tells the library to send a packet 'reliably'. All the acks are taken care of by the network library. If you decide you don't need a particular message to be reliable, just change the flag (reliable/unreliable/ordered etc) to your send method at the application level.

There are no good books specifically on game network programming. There are some direct play books out there that can give you some idea of the types of messages you need to send, but I haven't found a book yet that covers in any clarity network game programming in its entirety.

In answer to this specific question, you will never send location update messages as reliable, so no need for an ack. Send them using an 'ordered' protocol instead. Basically it's a thin layer of reliability that drops any packets older than those already received. When processing updates you want to ensure you are only processing the newest data available, you don't want players moving backward in time. There are actually very few message types you should use with an ack - connect, login, logout, add player, remove player, chat, and player events (start move, stop move, rotate, shoot etc). Data from the server should be about 90+% unreliable, depending on the type of game.

[edited by - fingh on July 14, 2003 12:41:21 PM]

Thanks fingh. As far as abstracting the library away from the game, I wouldn''t have it any other way.
Right now I''m just trying to figure out the basics of it (lots of connections handled very well MMORPG style). When i actually write the code I''ll be doing the networking portion for the client and the server (separate). By that time my friend should have a rudimentary 2D engine done. At that point I''m going to spend a LOOOOONG time just implementing the battle system, basic questing engine, database works, etc. Graphics and sound engines will be completely last as there is no telling when of if this will ever get done. I''m mostly interested in the networking aspect as far as engines go. My second love is the meat of the game so we are trying to get to a point where we can begin working on the actually content for kicks.

At the very least I will be developing what I hope to be a very nice networking library and might be able to produce some nice tuts for the board here. It''s obvious that this is one aspect of game development that needs some attention

Thanks for all the input.
Webby

I think you''ll find that this stuff isn''t too difficult, it''s rather what you do to produce the network traffic that is far more difficult and critical.

Experiment with a few I/O models and fine-tune your data structures, then you''ll be well on your way to forgetting about most of the network programming aspects until you find reason to fine-tune it further ( data structure changes, adding other inter-server I/O models, etc ).

None of this should really require reinventing the wheel, so-to-speak.


.zfod

I would suggest only sending the input over the network and thus simulating the same game on each client. when you got this kind of system up and running, you can almost forget you are writing a network game

Sure thats certainly possible, but then every movement packet would have to be sent guaranteed, because if you drop just one packet it will throw that system completely outta sync.


-=[ Megahertz ]=-

Typically the system which extrapolates position for each character in your game every frame when your networking updates are only coming in each 1 second or so is called the Dead Reckoning (DR) system.

The way we solved the unreliability issue was to have a sequence number on each DR packet, and to reject old packets for each entity (note this solves out of order delivery as well as failures, duplicates on resend, etc.).

The other thing is that in each DR message, we send the up to date (correct) position, rotation, velocity and angular velocity. This means that a character's position and DR info can be totally updated and corrected in one packet. It still is only like 48 bytes, iirc.

Regarding move validation, you should treat that as cheat detection rather than synchronous validation of each step. This will allow you to use a separate thread or even a separate process for it, and will mean that slow ping times will never result in jerkiness in client rendering.

Planeshift has implemented (and heavily tested) all these concepts and the code is GPL'd on sf.net if you want to take a look at it.

(btw, these DR updates are our only non-guaranteed msg type right now, although if we implement voice chat in the game, it will probably be that way as well.)

Hope this helps you,


Vengeance
Server Team Leader
Planeshift MMORPG
www.planeshift.it

[edited by - Vengeance on August 2, 2003 2:59:56 PM]

I'm also looking for more articles/tutorials on game network programming. There only good one i've found is a chapter in the book Game Programming Gems.

Good (it seems) network library in C++:
http://www.rakkarsoft.com

My own dabbling in C#:
http://www.lidgren.net/code/nEngine

[edited by - fenghus on August 4, 2003 11:16:25 AM]