30

This could be considered an animation problem. If a position correction comes back from the server due to an attempt to move into an invisible object, send back not only the correction but a flag indicating why the correction was needed. Instead of a player popping backwards, he may do a "woah" kind of reeling backwards animation, making it more believably ...


20

Simple answer: cheat or don't be that accurate! If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad. This is caused by your client correcting your position from time to time. Basically, what happens on the two sides: The server will track your movement and send ...


18

Always assume the client is a lying, cheating, bastard. The client is responsible for: Receiving input from the player (and sending commands to the server, which validates) Rendering the known gamestate The client is in no way allowed to calculate the gamestate except as client-side interpolation for smooth animations.


17

From an API design perspective, when deciding whether to make multiple separate communicating programs or just one, the question is: can each program function meaningfully without the others? The answer will vary based on your project and preferences. If they can't, it's not worth thinking about. Clearly they're so heavily linked that they're not really ...


17

You're on the right track. The gist of the client-server networking model is that a server is that it's a central point of knowledge that clients connect to. A game server typically contains an in-memory world representation, a list of connected players, a game loop (with e.g. player control handler, a physics engine & AI). You'll also need a ...


15

1000 player may or may not be a problem. It depends on how often you need to update the database. However there is a simple solution: put the database on its own server. I had a peek at how the database system works a game that people would call an MMO-Lite – which one I will not disclosure – yet I can tell it consistently has more than 1000 players, this ...


14

Strategy games usually send input, while shooters usually send gamedata. However there are exceptions. For example Halo : Reach runs in lockstep in some online game modes, sending only input. There are multiple reasons for this: Shooters have a lot less game data than strategy games It's easier to keep the game in sync It reduces lag as long as the game ...


14

I once found a very neat quote on the net that's very, very true for any online game: The client is in the hands of the enemy. As such, you can't really avoid people doing nasty things to your game client. Due to this, don't trust the client at all, i.e. everything important should at least be verified server side (better: calculated there). If this is ...


14

You can use random seed. Select same 32-bit value in server and client (or server can send it to client at start). Use it as seed for random generator. You can send actual seed from server to client with game state update. If you don't want to send it you must be sure that client and server generates same number of random numbers by this random generator. ...


12

I'll rather delve into the problem you are having with network latency: it's unavoidable. Network programming is a fine art and much more psychologically involved than tricking the eye (as you do with graphics programming); people are very sensitive to their perception of time. What you essentially need to do is do prediction on the client. For example, in ...


12

For a real-time game, you want to minimize latency. Here's two tips for achieving it, with notes about PHP and Node: Use WebSockets. They allow fast two-way communication between the server and the client. Using node.js here has the advantage that you can use the same JavaScript API on both ends of the pipe. There's also the wonderful socket.io module for ...


12

Your goal of synchronizing 50 events per second in real-time sounds to me like it is not realistic. This is why the lock-step approach talked about in the 1500 archers article is, well, talked about! In one sentence: The only way to synchronize too many items in too short time over a too slow network is to NOT synchronize too many items in too short time ...


11

As others have said, the first step is separating logic that's shared from logic that's not. While it's great to draw that line wherever it's clear, your addendum illustrates that sometimes you don't have a clean line to split the code down. So, how do we solve cases where the client and server want to do semantically the same thing (play a sound), but take ...


11

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server? To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a dedicated queuing service. If it ...


11

After searching around, it seems that synchronizing the clocks of 2 or more computers is not a trivial task. A protocol like NTP does a good job but is supposedly slow and too complex to be practical in games. Also, it uses UDP which won't work for me because I'm working with web-sockets, which don't support UDP. I found a method here however, which seems ...


10

Don't optimize prematurely. Keep it simple. Using TCP in this case is OK, and I don't see any problems with your current scheme. UDP is usually used for performance critical scenarios such as in an online action game, because it allows explicit control over individual packets as opposed to working on top of a layer abstraction of streams like TCP. However, ...


10

There is nothing on the client side which can not be faked, everything somebody has physical access to can be manipulated. The IP contains routing information and thus hints on the location. But the player just needs a proxy and whoops... the IP hints at a completely different location than the player actually is. Trust your players, don't give them a ...


10

You can use an IP geolocation service to obtain an approximate location from where the user is connecting. Compare this with the GPS data received and you can weed out some extreme cases (players connecting though proxy, etc). You can even calculate distances between user logins and if they are too high (say, the location moved 1000 kms between two login ...


10

One of the reasons why there are protections is that reading the game state could allow bots to know the state of the game and act accordingly. For instance, grinding in a MMO: if the "bot" knows what mob is around, it can send commands to the game clients to select the mob, hit it until its life is 0, pick up the loot, rinse and repeat. With this, even if ...


9

The problem was a misunderstanding about what client interpolation is for. Only entities that aren't controlled by the player should be interpolated. Player controlled entities always update themselves using the freshest data available from the server, since we want to simulate them as close to real-time as possible. That also makes clear what client ...


8

You should send redundant data, which here means send the position and the velocity. Even if you are out of sync, the fact that you have the position and the velocity allows you to correct the trajectory using an interpolation function. Then using some tricks like delayed animations, accelerations, etc. allows to hide the latency. Edit: I assume that the ...


8

It always frustrates me how many people oversimplify the differences between TCP and UDP as "TCP is reliable but slow, while UDP is fast but unreliable". This is not what TCP and UDP are about. TCP and UDP are two different abstractions over IP, and are used for different things. Both very good in their own fields. TCP is a stream oriented protocol. You ...


8

One of the most common misunderstandings of TCP vs UDP is that TCP's main feature is reliability. The main feature of TCP is that it abstracts a stream of data to send from one socket to another. Reliability, as provided by TCP is a requirement for the abstraction to work, but is not the central idea behind TCP. You might want to consider basing your ...


7

Do not copy the entire game model to the server, you wouldn't like to load all the textures and detailed meshes on your server. Keep it as simple as possible, handle all the important processes like the location, health, any movement but do not load everything. - NEVER TRUST THE CLIENT. There are many books, along with multiple wiki's. Every engine ...


7

Yes. You definitely should. Use Let's Encrypt to get a free SSL certificate (or as many as you want or need). SSL is always good to have: without it, man-in-the-middle attacks will be launched, by the NSA if no-one else. Most multiplayer games (e.g. Minecraft) just use raw packets. There's little reason to encrypt packets after one is authenticated as only ...


7

Both approaches are used with MMORPGs. Keeping everything in memory and periodically check pointing it to disk seems to be the most popular option, at least for older games. It has the advantage of being fairly simple to implement and scaling fairly well, but making it reliable is completely up the to the developer. SQL databases provide ACID properties ...


6

Non player characters don't have 'input', and neither do projectiles. In fact a lot of the time players aren't acting as a result of input but as a result of physics. So, generating artificial inputs for some of these entities is extra work. It also assumes that all clients will handle input in exactly the same way, and this won't be the case if there is ...


6

My guess is that the rng's are generating at different speeds. For instance, if a game is updating at 60 times per second, then theoretically it should be in sync with other games updating at that time. But if a game is updating at a different time, it will either generate future or past numbers generated by the master generator(the server).In other words, ...


Only top voted, non community-wiki answers of a minimum length are eligible