   Bomberman clone network woes
  Hi all,I''m currently involved with a group attempting to implement a multiplayer version of Bomberman. My question is about maintaining the shared state.Right, my approach is to have the current scheme:* Server maintains an _final_ gamestate, i.e. the gamestate that has authority over what happens. If a bomb goes off, it is the server that determines who is killed by the explosion, and it will notify clients "You are dead!"* Clients render the gamestate according the most recent updates they have received from the server. The client gamestate, thus, is nothing but a (fairly) synchronized copy of the server game state.* Clients, however, do have authority to move their own character without first sending this information on a server roundtrip. I.e. when a character wants to move, his gamestate is updated immediately and a packet is sent to the server with contents: "I was at: XXX, YYY, when I started moving LEFT". The server will accept this and update the client''s position accordingly. This means that the second a player presses "left", his character will move left.An alternative approach is:* The server maintains all authority. This implies that a client player only moves once his packet has been sent to the server and the server has told the client''s gamestate to update the player position.* Using this approach, the game state on a client with ping X ms will be an more synchronized version of the game state X ms ago. But now the client has to wait for the server to update his position, i.e. key presses will not result in immediate movement.I can see the advantage to this alternative approach, but naturally the drawback is the sluggish reaction to movement orders.What are people''s experience? Is it wise to delegate some authority to the client even on small scale projects with a limited number of connected clients?  
  Take your first approach, but make the server check what the client has sent. If the client has sent an invalid movement, send a correction packet back. In that case, the player will snap back to the last valid position on the client (but not on the other clients'' screens, since they didn''t receive the invalid position in the first place)Regards,Jörg ;  The server shouldn''t accept this:"I was at: XXX, YYY, when I started moving LEFT"... as the truth. Someone will hack the client and create super speed or teleporting. A better conversation is:Client: "I start moving left" (start moving on screen)Server: "You end up at XXX, YYY" (client thinks: I know ;-) ;  Right, naturally the server wouldn't accept any sudden jumps, but keep the client within a certain area from his last reported position.But is it generally accepted that pure client/server methods - i.e. the client updates his position on the server and the server sends the new position back, which is rendered by the client - is a bad way of doing things in a multiplayer game that needs quick movements? [Edit: added] I was under the impression that this how Quake maintained its shared state. [edited by - sunbeam60 on February 3, 2004 1:37:09 PM];  Well, in any event don''t just accept blind coordinates from a client, thats a given. I''m not roasting you, you seem like you know what you want to do, I''m just saying this for ppl who don''t.Never accept input directly from a client, always check it''s integrity. If you must use an absolute location system (ie: players send their actual x/y/z coordinates), check them by comparing the maxumim distance that can be covered.All in all, just use a state engine or something for moving players. If a key is pressed, bind it to a ''state'', like ''STATE_MOVE_LEFT'' bind to Left arrow. When left arrow is pressed, this state is ''on'', otherwise off. When a state is toggled, send data to let everyone know.Theres tons of ways to do this. ;  The thing that puzzles me a bit about state systems like the one Nullmind describes is that I cannot guarantee that the "state: on" and "state: off" packets arrive with the same time between them as they were sent.Even if the client and server runs a (reasonably) synchronized game time counter, the server might move the client too far away before receiving the "state: off" packet and realizing that the the client actually switched this state to off some time ago (i.e. the "state: off" packet arrived much more delayed than the "state: on" packet). Then the client would have to jump back, which to me seems a bit messy. Is there anything I''m missing here? ;  Hi there,if you like, you can contact me for maybe sharing some experiences.Cheers,Chris.   Let''s kick some ass... Buy BomberFUN online now!visit http://www.bomberfun.comKeep your eyes open on the upcoming Bomberfun Tournament! 