Hello! I''ve got something I can''t figure out... maybe one of you guys could help med out. I''ve been reading alot of articles about network game programming (client/server) and come across this thing that you''re supposed to send "snapshots" from the server, say, 20/s. Now, are these snapshots the only thing the server send (in game), that is, one big packet that contains all the messages generated (example: moveobject, createobject, chat messages)? Thanks to anyone who can clear this thing up! /jaybee

are you thinking snapshots are 100% and you may not realise that although game needs 20 instructions per second it may not need the actual state of play that frequently just elements to improve realism whilst waiting for real state of play to make difinitive version of game at client side. ''snapshots'' or what people call packets can be choice information to show predicted results in games generated by the server. the server meanwhile is working out what is really hapening and overides the whole game once a second. The difference is not invisible but is related to the action in a game being visible. Action generates massive changes in FPS visually therefore gameplay rules at server side is simplified to maintain definitive packet frequency. FPS''s are simpler underneath the graphics and so lag is more like taking candy from a baby. More compicated and grown up versions of games will end up never showing you the real state of play because by the time it is worked out it changes with no time to send complete data. Beware, this may send you off imagining your in it when your really not there at all!!!!

As far as I know, a server snapshot is just a listing of all the positions of all the players in the game, and probably a bunch of other dynamic stuff too (game events, that sort of thing). Its main purpose is so that if a client has experienced packetloss, it just has to wait a few milliseconds to receive the important data that it missed. You''re not sending every command the server has issued/executed since the last snapshot.

And they are not the only info you send. Your server should be sending out all commands or processes it issues/executes that are relevant to the clients. That would be a sort of ''Broadcast'' method. Another way (if youre concerned about cheating) is to only send out data to specific clients that need it, i.e. Player A is standing in a room, and Player B is several rooms away. Since Player A cannot see Player B, no info about Player B is sent. A few minutes later, Player B is about to enter the room where Player A is standing. The server realizes this, and starts to send info to player A about player B (location, armor, health, etc). Not only is this a better architecture (uses less bandwidth), but it would make it very difficult for someone to cheat in your game. As well, under this method, your snapshot would only have to send info on players close to the client.

Having the server keep track of all the positions of players and all the game events seems like a lot of overhead and a bad idea; however, since bandwidth may be at a premium, you should be sacrificing server complexity for less bandwidth usage every chance you get.


Hope that helps.

Well making a client/server game boils down to one thing. How do you syncrhonize executables running on different machines connected by a network, limited by bandwidth and latency, well enough so that 2 or more people can play a game.

You can only exchange a limited amount of data at a time. In addition the game logic could place a time constraint upon that data. It''s a well researched problem. Some people opt for sending absolute state data (ie postion, direction, speed, internal states, etc..) others opt for sending events (move to x,y event, hit player x event, build farm event, etc..), or some use a mix of both. Each has their advantages, and drawbacks. The method you use will be determined by what kind of game you want to make, and the constraints of your network.

Though i''ve noticed a few commonalities in network applciaitons:

-a time syncrhoniozation scheme
-an event syncrhoniozation scheme
-a state syncrhonzation scheme
-a network entity id scheme
-a well designed packet protocol

One form of another you will need these things. The more solid this foundation the larger and more robust you network applciation can be.

Good Luck

-ddn

Thank you all (well, except CorsairK8, of course)... now everything is clear to me again

/jaybee