Hello. I've been browsing quite a bit for now in order to find an answer to this, but to no avail. My issue is, how can I make efficient character movement in online games? Let me explain: I'm developing a very simple top-view 2D online game, where players shoot each other for points. Essentially, there are only two types of objects, players and shots, and they are processed from the server and relayed to each connected user for display only. The question is, how can I make an efficient movement function so that lag is minimized, and there is fairly good security? I've considered the approach of moving players in the client, and then telling the server their position, thus calculating the rest with a bit of dead reckoning... but that means anybody can change the movement value and hack their speed. Therefore, what would be a good approach to this? please keep in mind that all players have the same speed, as well as shots. Players also move fairly slow compared to teir shots. If there's an article that focuses on this aspect (especially 2D), a link would be very appreciated. As you might see, I'm fairly new to game development, especially networking. If there's anything I might have passed up, please excuse me for being such a newb. :P Thanks.

Never trust any data that comes from a client. The clients request that they move to somewhere, the server then tells the clients where everyone is each network tick.

You can use dead reckoning (Google will have millions of results) to determine who's where and whether shots have hit their targets.

I know that clients must not be trusted; however, the question is more like... what's the correct approach to processing player position and input?

So far, I have determined that clients will only receive data for displaying (characters, shots, HUDs...); everything will be processed on the server. But then, how can I make it so that players 'laglessly' move throughout the map?

For instance, would this be a correct approach?

-User presses keypad
-Client sends 'key pressed' command to server
-Server begins to move character
-Server relays display data

-User releases key
-Client sends 'key released' command to server
-Server stops character
-Server relays display data

I'm fairly certain this would work, but I'm worried about the lag this algorithm could generate. So, what I'm asking is, what's the most ideal way of implementing such a system?

well, there are 2 ways to have lag less character movement.

The first way, is if your character moves 1 tile at a time.

IE you have a grid of 32x32 tiles, when the character moves, the client sends a packet to the server letting it know that its moving. When the client moves, it moves and sends a packet to the server.

The server then checks if the client is aloud to move there, then it sends a new packet back letting the client know that it can move there or it cant.

The client should never be able to move more then one tile from his original pos on the client, until the server sends back the okay.



The other way, You would essentially use a UDP connection with the server and client, as the client moves it streams where its moving to the server, then the server streams back if its okay to move there or not. This is unreliable but it is the only way to make it lag less. You would still need a main TCP connection however to insure that the important data for the game is sent and received.

Hey,

I'm working on a project with very similar requirements (it's 2D, players move and shoot), although it may be a bit more complicated/advanced than what you're describing. If you want, send me a private message with your MSN id and I'll add you, and tell you more about how I'm doing the movement.

The main idea behind it is the client sends 'commands' (what buttons are pressed, how much the mouse has moved, etc.) that the server executes and sends back updates with new positions. The client, meanwhile, locally predicts what the server would send it, and uses those predicted values to display the local client. As long as the client is not cheating, his local predictions will almost always match what the server tells it anyway.

Meanwhile, I can suggest you take a look at some of the articles about Half-Life networking model. It is what my approach is mostly based on (with some tweaks), and I find it to be very good in many ways (security, responsiveness and ability to cope with dropped packets).

Article 1
Article 2

If you can understand what they talk about, it should give you a pretty good idea of how you can get started. Be wary though, it's not an easy system to implement, and might be a little (a lot?) too complicated for your needs. However, if you're looking for the best possible approach, I'd say it doesn't get much better than that (it's a subjective call, but still). On the other hand, there are much simpler ways to achieve similar effects if you'd rather not complicate things as much, but I can't give you much advice there...

Anyway, good luck.

Quote:Original post by hplus0603
The Forum FAQ actually contains several links to articles that talk about this problem, and various solutions. I suggest you read it. If you feel that it's too complicated, then try again, perhaps reading slower, because distributed simulation is complicated.

Good advice.

If all of your players have the same speed the easiest way to do it is to send 2 pieces of information in each packet.
1. Moving? Yes or No (1 or 0)
2. direction (0-360)

Then the server takes the packet and applies the speed and direction to the current x,y coordinates to find the new location. Then send this back to the client and all the other players in range. You can let the client move the player locally to avoid the overhead, but that would only work if you are moving on little squares and you can only move a fixed amount. If you want any sort of acceleration your best bet is to store movement on the server and send it back to the client. You can use dead reckoning on the client to smooth things out.
Just make sure the client can't tell the server where to move the player.