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 ...


21

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

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

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 ...


10

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

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

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 ...


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 ...


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

Several points: You should definitely enable error reporting and error logging into a file on the PHP side, otherwise you'll have no evidence of problems. AJAX errors usually cause little visible error to the user. You should check for errors on the Javascript side too PHP error handling is famous for being both bad (e.g. the default action for most ...


6

Can't be done. Haven't you ever been in a 10mx10m TF2 server where you'd just wait for drops? Neither have I! ;) You could implement some sanity-checks on your server, but then you'd have a central server. Can you afford a central server for such checks?


6

I suppose you could have the server send a hash of it's executable to an authentication server, to ensure it hasn't been modified been modified, but that's about it. I wouldn't worry too much about it, if you're going to let players have their own servers let them do whatever they want with the game, they purchased it. You can make it difficult to cheat, ...


6

As far as I'm aware, this is essentially what many console games do. This was even brought across to some PC games, like Call of Duty: Modern Warfare 2. There are, of course, some drawbacks: Any coding effort to "do some checking to stop cheating" would almost have to be more complex than the physics code itself. You can't trust the client, pure and simple....


6

Just read this: http://www.gabrielgambetta.com/?p=22 On every recording record current time/frame On every RPC sent to server attach frame/time Server sends back result with frame/time Now the client knows exactly which frame the server's result is about Commence "player prediction" + rewind & replay


6

In broad terms, there are a few standard architectures for networking systems. In terms of topology, you have: Client-Server: All clients talk to a single server, which may be a dedicated server executable, or may be another copy of the game, just operating in "server mode". (this is the one you mentioned) Promiscuous Peer-to-Peer: Every peer talks ...


6

If you haven't already, I suggest you to read these two deep but understandable articles : https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking and http://fabiensanglard.net/quake3/network.php. These explain why it's advised to use 'fixed interval' packet sending. To be short, it's in fact mainly important for packets sent by the server. ...


6

every action the player takes is deterministic, however, there are events that happen on scheduled intervals I think there's your problem; your game should only have one timeline (for gameplay-affecting things). You say that certain things grow at a rate of X per second; find out how many game steps are in a second and convert that to a rate of X per Y game ...


6

Many MMO's are designed with client-side hit prediction. So if there is a hit on the client, it sends that result to the server that there was a hit. In this case the server is not truly authoritative, and thus cheating is possible. To be honest, if I were designing an MMO, I would make the server fully authoritative, with the client only sending clamped ...


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