Thought bubble:
Simple explanation:

1. One player clicks on where he wants to go today.
2. Destination and current position are sent through server to all users within "this_actually_has_a_point_being_sent_to_me" range 4 times.
3. Pathfinding system on client side computers show how player got from point A to point B.
4. Pathfinding system is configured so that results are the same on all computers.
5. Sever only gets destination and location info, as opposed to sending an update of the info every damn second (Like in UO)

Get it?

quote: Original post by ThoughtBubble
But first: No offense Kylotan, but unhackability isn''t necessarrally something to persue. For a consumer MMORPG it needs to be dealth with, and heavily. But in a project, or a local game, or a 20-100 person private networked game, security isn''t nearly so big of an issue. It all depends on if you care if someone cheats. And sometimes the issue isn''t worth the effort.

No offense taken, ThoughtBubble. The original poster said ''MMORPG'' so I just addressed those types of game. It''s not massive if you only have 100 people online, really. Having said that, I think any game with more than about 20 players would need to have some sort of anti-cheating setup because the more players you have, the more anonymous they are and the less likely they are to play ''properly''.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

quote: Original post by black_mage_s
Thought bubble:
Simple explanation:

1. One player clicks on where he wants to go today.
2. Destination and current position are sent through server to all users within "this_actually_has_a_point_being_sent_to_me" range 4 times.
3. Pathfinding system on client side computers show how player got from point A to point B.
4. Pathfinding system is configured so that results are the same on all computers.
5. Sever only gets destination and location info, as opposed to sending an update of the info every damn second (Like in UO)

Get it?

This is a start, but not the complete picture.
Most clients use some kind of ''network prediction''. For instance, if you play any Quake 3 game on a lagged server, you shoot and walk and the client shows it immediately. It also sends it to the server. The server sends back confirmation of shots, and your direction and speed. If it arrives in time, it''s accepted and the client plays on. If it''s too late or lost, the game rolls back. You will see this as suddenly being back in your original position, or shots you already shot being shot again a second later.

What a client should do:
- If the player presses walk, send direction with a walk flag to the server
- The client shows the player walking
- The server updates his position, and sends back direction,speed and current position to all clients
- If the client info is out of sync with the server, either update the position hard (a jump to a previous position) or slow down the walking speed.
- server only needs to send position/speed/coordinates to clients every second, when it''s within limits of the previous update. When a player stops, turns or changes speed (walk/run) then update immediately.

If your game is a 3rd person view with clicking on the map, then the server needs to do the pathfinding. I don''t think you need to have the client handle all the pathfinding.

The way I would do it is that when a player issues a command, such as pressing the Up Arrow to move forward, the server is notified only of that keypress, and the player is moved accordingly. Client-side, the player''s movement is simulated instead of unnecessarily getting his position from the server. Once in a while (once per second, maybe) the server sends the player his position to make sure there are no mistakes.

The server would also send other players the first player''s keypress information, along with his position once in a while to correct mistakes.

If the player does something with the mouse that affects the outside world (clicking to attack an enemy), the server is sent the mouse position and the fact that it was clicked.

This, to me, seems like the best way to do it, if you can get everything synchronized. But I never wrote any type of online program, so I don''t know what packet loss or whatever would do to this system.

~CGameProgrammer( );

I''m writing an online point-and-click RPG. I''m using this ''send destination only'' paradigm of movement communication. Once you overcome the synchronization issues, which aren''t that hard, the only question becomes that of hackability.

In my opinion if the server is coded well, using this method will not expose the game system to greater exploitation. After all, any client can be hacked to show the player regions of the world he is not supposed to see - so the real question is, does this system make for teleportation/etc hacks that will allow the cheater to pick up inaccessible items or otherwise interact with the world in ways he shouldn''t. To avoid this we simply need to have the server confirm whether a client can perform an action. For example, if the client is hacked to teleport the player into an area where the player then tries to pick up an item from that area, the server on recieving a ''picking up item'' packet goes - ''wait a minute, there is no such item where the player is'' and takes appropriate action.

Pros:
Less bandwidth usage in transmitting player location state.
No ''personal movement'' lag.

Cons:
More processing on both client and server.
Potentially more overheads when perform subsequent operations to maintain world integrity (ie. prevent cheating).

Well, Kinslayer, it sounds like you''re sending the server the world position of the mouseclick, which isn''t a very good idea because then it necessitates verification, as you mentioned.

I would just send the server the 2D screen coordinates of the mouse click, and let it figure out where in the world the click corresponds to.

~CGameProgrammer( );

I''m sorry, I don''t understand your point. Can you elaborate?

This system would be possible without it being easy to hack.
simply the client sends the position in the world it wants to move to, the server sends this (and the current position of the client) to all other clients, than the clients system move the player using pathfinding etc.. if the client wants to go elsewhere it simply clicks elsewhere and the same happens.. because the server only receives the end position and holds and calculates the start positions itself it can only be hacked on serverside, if the client is hacked and sais i''m behind that wall instead of infront of it.. the client is the only one to draw that.. the server still sends the position it has calculate everywhere on an update. (also back to the client). so it would basically mean that the client can''t play if he modifies the position he knows. because the server would still send other positions to everyone etc...

Eternal: The point is that the hacked client can send a world coordinate that''s way off-screen that the player couldn''t possibly see. But by sending only the screen coordinate of the mouseclick, no real hacking can be done.

Kinslayer says: ...if the client is hacked to teleport the player into an area where the player then tries to pick up an item from that area, the server on recieving a ''picking up item'' packet goes - ''wait a minute, there is no such item where the player is'' and takes appropriate action.

But the server wouldn''t need to do that if, instead of saying "pick up this item" you say "right-click at (340,156)" and if an item is there on the screen, the player picks it up. That way, no hacking can be done.

~CGameProgrammer( );

maybe it should be said that if i were to use client side prediction, it would have to be done with a point and click movement system