35

Most MMOs (or projects using similar architecture) I've worked on or know of use the first method: the game servers work mainly with the RAM on the machines running the server processes, and only periodically serialize the relevant game data to a SQL database for archival (if one is used at all). The problems you note regarding power failure are valid, but ...


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


23

You should prefer to keep your rendering code separate from your game logic, as they are separate concerns. If you separate your rendering code from your client/server code, you get a couple of advantages: Creating a dedicated server will be easier, as any code that renders will be in one place. You can separate your update phase from your render phase, ...


21

While ideal, it is practically improbable to validate every single input against the server, both in terms of computational load and latency in input confirmation for the client. Consequently there are usually a handful of things that aren't validated on the server in many MMOs. In some cases this includes certain classes of character movement, which is why ...


19

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

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


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

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

If it's not a "real time" game in the sense that players don't need to see the immediate result of another player's actions on a game scene then you should be fine with HTTP requests. But Keep in mind the overhead of HTTP. That said using HTTP will not save you from designing your communication protocol with care. But if you are in charge of both the server ...


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


13

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


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

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

My suggestion is to have your game communicate to a web service that you created that itself deals with querying the database. At that point, it's very simple to try different kinds of databases by "switching" web service implementations (your web service interface always stays the same so your game doesn't break) and decide which one is right for you. ...


11

You will probably need to micro-manage the 3G modem to ensure that you don't have delays while it switches power modes. Your simple answer is make sure you send at least one packet larger than 128 bytes every 6-8 seconds. If you can guarantee that all your packets are smaller than 128 bytes make sure you send something once every 6-8 seconds. Avoid, at all ...


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


10

I'm not sure what it is exactly that you want to achieve. But, there's one pattern that is used constantly in game servers, and may help you. Use message queues. To be more specific: when clients send messages to server, do not process them immediately. Rather, parse them and put into a queue for this specific client. Then, in some main loop (maybe even on ...


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


9

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


8

I assume since you're students, you are building this as a class project. Please let me first suggest that you scale back your ambitions. Making games is hard, making good games is harder still. I HIGHLY recommend that you and your team Greatly reduce your design. If you have a short timeframe and have to learn everything as you go, you will run into ...


8

I think what you'll find is that the UDK networking protocol which runs on top of UDP and TCP, is tied up with their proprietary client and server code. So no, if you wish to use the actual UDK networking client, you very likely wouldn't be able to write your own socket or webserver, even if you knew what the packet structure was (and wanted to try to ...


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


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