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

The algorithm posted was correct, but in your example you are forgetting about the time it takes for the server packet to get to the client, so: Server time: 1 Client time: 0 Client sends 0 to server ... 150ms to get to server (ping is 300! not 150ms in this case. Ping is round-trip) Server time: 1.15 Client time: 0.15 Server receives packet and sends ...


11

This is really hard to pull off, because real concurrent editing (on the same files) can be rather tricky. I'd focus on some source code versioning system like SVN, Mercurial, or Git. If you're using Visual Studio, the best option would be using their Team Foundation Server or - with the addon being in beta right now - Git. Setting up a Git repository isn'...


10

Transmitting the full game state regularly is usually not feasible, though it does depend a lot on the complexity of you game. For a simple game with a small world model it may work. I've personally had much more success with the following model: Game state stored in a well defined object model in a spatial data structure (e.g. an octree) All changes to ...


10

Problem analysis Real-time communication over a high-latency connection is obviously impossible. You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) ...


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

Dead reckoning may not be the best idea in this case; you should do entity interpolation (effectively rendering the other players in the past, which always gives you real, valid positions). I've written about this with much more detail here. Whether or not seeing players slightly in the past is acceptable or not depends on the details of what you're trying ...


8

Was it necessary for a game developer (in Android, game consoles, online, or in desktop) to display the loading screen to cover unfinished rendered game environment and to prevent from other users thinking that this game is either lagging or freeze. Yes, loading screens are used to hide resource loading and it's somehow a more entertaining way to tell ...


8

There are two approaches to this. Lock Step In Lock Step all clients send there data for frame 1 to the server and then wait. The server collects the frame 1 data from all clients and only processes them once all are received. It then sends the result back to all clients and gives the clients the go-ahead to start working on frame two. Note that with frame ...


6

You have identified the key problems. Your "bounding box" solution to what-to-update seems fine. You may want to make the update box a little wider than the view box, so that actors outside the view are already available if your player starts walking. The usual solutions to jumping are: Some assumptions, e.g. other players keep moving in the same ...


6

The synchronization is usually split into two part: incremental and absolute. Sometimes you must transmit everything, it is large, but if you pack it the right way you can do this once every few seconds. It is good to put everithing in place, correcting the faults of incremental refreshes. To achieve real-time experience, you must transmit some changes ...


6

For example, let's say it's tick 1000 and player 1 sends a message saying that he is going to start attacking player 2 at tick 1002. That's not how it works. What is sent is what player 1's controls do. Click on location, drag to here, pressed key X, whatever. You don't send specific game state like "is attacking". The idea being that, as long as ...


6

There is a great number of text editors which allow several users to simultaneously edit the text. "Simultaneously" in this case means that when you open a document and someone else is/are editing it, you see those someone else's cursors, and what changes they make -- in real time. Obviously, you can make your own changes too, and they will be broadcast to ...


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


5

Usually, a Server is employed, storing the "truth" state that is periodically shared with the Clients. Collisions happen independently in Clients and Servers, with the states of the Clients estimated from the previous states using a process similar to what it's usually called Dead Reckoning. When a Server state reaches a Client, if there are differences, the ...


5

In a multiplayer game, every gameplay-relevant decision should be made by only one system. When multiple systems make a decision, like in your case the trajectory of the ball, and they disagree due to timing issues, the game gets out of sync. When each client calculates the angle only after its own collisions and sends the new trajectory of the ball to the ...


5

You're looking for a source control solution. These are a common part of the industry. Large Open Source projects often have dozens (and in a few cases hundreds or thousands) of individual developers spread over the entire world. Solutions like GitHub, BitBucket, CodePlex, SourceForge, and more offer these services for free (often only if you make your ...


5

Introduction There are pros and cons to each method of synchronization you gave that depend on a couple of factors. First, is your game singleplayer or multiplayer, second, how real-time is your game? If your game is only single player, you may want to consider having a client side only game which would make things simpler. However, assuming you need a ...


4

I'd say 2: as you state, solution 1 would generate too much traffic. There's a chance it works in the beginnings, but then when you'll add other things to send you might have to reduce the input updates frequency and thus you game reactivity. As a rule of thumb, sending deltas instead of complete states is most of the time The Right Thing to do. You're ...


4

I found the following comment on an article on lockstep, that should explain it http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/ StarCraft don’t use peer-to-peer it uses client-server model with lockstep (at least warcraft 3 does so). It has the advantage what theoreticaly laggers will ...


4

I'm assuming you're talking about moving in real time. Trying to interpolate position is probably a lost cause; over a slow connection, your game state could fall further and further behind the actual game state. Unlike the other comment, I would advise against putting much game logic in the server side. When I've implemented these sort of solutions, the ...


4

Ok I don't know about World of Warcraft or their implementation. Taking average network jitter and delays into account you don't get a very accurate reading about time from the server. (That is why NTP is difficult.) If all you want to display is the server time, you just need to send the server's time and add the current round trip time to get a rough but ...


4

The choice to make depends on what your multiplayer architecture is for the game. There are two major architectures for multiplayer games, the first being client based, in which each client is responsible for its own decision making and updating, and the server simply distributes these updates to other players. The other is an authoritative server, and ...


4

The normal answer to work on different files rather than trying to edit the same one. Anything big enough to involve multiple people will also involve multiple files.


4

If you are using Visual Studio, you can download VS Anywhere. You can have many person typing codes simultaneously, and it doesn't lag much. Though it's kinda buggy sometimes. I'm using it with my friends all the time! Here's the link , enjoy :) http://visualstudiogallery.msdn.microsoft.com/99466148-ae68-4bd5-b66b-08bae7423a03


4

It's simple arithmetic and requires no loops or periodic DB updates. The player has a rate of resource gain. This is fixed until some external stimulus happens like the player buying an item to change speed. You need only know the current speed and resource counts for this to work. Take the current time. Take the last time the resource counts were ...


4

To complement Anko's answer, you can change a bit your game design by adding the consequence of the failed obstacle after the failure, for instance, a failed jump results in landing in a puddle of mud which disqualifies the player. This way the other player notices the failure by seeing the other fall in the mud, while the player who fails sees it right away....


4

First, to solve the problem with scheduled events, don't broadcast the events when they happen, but when they're initially scheduled. That is, instead of sending an "increment the energy of tile (x,y)" message every second, just send a single message saying "increment the energy of tile (x,y) once per second until it is full, or until interrupted". Each ...


4

The client side asks the service "Am I allowed to keep playing with you?" every five seconds and the server responds with true or false. You store the date value that represents the last time the player "pinged" the service. Also store a single session key that is randomized and sent to the client upon logging in or at the beginning a game (if no login is ...


3

The phrase that you're looking for is relevancy sets. Each player has their own list of objects that they care about (That are relevant to them.) As objects are removed from this list, a message is sent down to remove it from the client. As objects get added to this list, a creation message is sent down to the object. During the course of game play as an ...


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