   Tile-Based Movement
  I'm trying to figure out an approach for a tile-based movement in a network game, using Zoidcom. Instead of constant pixel-by-pixel movement, the players will move one tile at a time, at a constant rate. Boulderdash comes to mind as a convenient example, including the dynamic map.Would it be best to send a stream of input information from the client to the server, which then handles collision checks, etc, and sends updated position and map data back to the client; or give the client ownership over movement of its own sprite object and, after collision detection with its existing map data, sending position information to the server for further global interaction and enforcement of rules?   
  if you're trying to cut down on any form of cheating, its best to never let the clientside make any decisions.If the collision check is done clientside, a little work will make them all come back clear, and the player will start walking through walls.The server more or less runs your game, the client program is just the graphical interface and input collector.   ;  Letting the client move before getting the OK from the server doesn't itself allow for cheating. The server can still deny the movement request and tell the client to revert back to a given location (or if the client keeps track of it's previous location, to just move back). Someone who tries to cheat by forcing the client to allow all movements would just end up getting constantly corrected on their positioning, which would be quite annoying visually, and serve absolutely no benefit. You only have a problem with cheating if the server assumes that the client's movement is OK, which is a horrible idea because even under the assumption that nobody will cheat, the client doesn't have the exact same layout of the world as the server. So if there is character collision detection, due to latency, a client can legitimately assume it can move when it really can not. So having the client move before validation from the server doesn't really result in opening up gateways to cheating, but it does result in position correcting, which in it's most simple form, can result in the character suddenly jumping back to their previous position.What system you choose really depends on what kind of game you have. If it is a slower paced game, there isn't anything wrong with sending a movement request to the server then moving only when you get a response. Although there may be a delay, is that really a problem for your game?Another way you can deal with it is take the approach of moving under the assumption that you can move. When the server invalidates your movement, if possible, you can move to a different tile instead of back to where you were. For example, lets say you move up one tile, but at the same time a NPC moves to the right to the exact same tile. Even if you moved first, the NPC doesn't suffer from the connection latency, so he got to move there before you. Instead of forcing your character back down tile, you can try to move him diagonally to the left or right. If you are lucky, you can get this correction message back to the client before they finish moving, so they can smoothly translate to the new position.   ;  Indeed, that's what it'll all boil down to in the end. Even if the player has control over the object, it'd only be for the sake of hiding any delay between the move and the server's reply; cheating on the client side would be overridden, and at worst the result would be an out of sync client. But I guess that's not important at this stage, and probably makes things needlessly complicated, so I'll just go with the input stream approach.Thanks.Quote:Although there may be a delay, is that really a problem for your game?Actually, I think the main thing I'm concerned about is making sure the input synchronises with the server's timer. It seems like it'd be pretty easy for the timing to be off slightly and cause double moves, but it's probably not as big a deal as I think.Quote:but it does result in position correcting, which in it's most simple form, can result in the character suddenly jumping back to their previous position.Yes, that's another reason not to bother with that idea. It probably works well for games that require smooth movement, like a shooter or racing game, but for this kind of thing it's likely to be uncomfortable.   