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

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

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


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


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

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

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

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

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

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

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

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

Don't make your game state so complex that sending it takes so long that the normal update stream is no longer valid. If your network layer can deal with lag of up to 3s, for instance, you need to be able to send the necessary state in under 3s. There's no specific architecture to this. Since sending the initial state is almost identical to just sending ...


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


3

What you've described is correct and commonplace. Ping times can vary widely though, so to get a more accurate result you can repeat the process a few times and take the average ping time as described on wikipedia.


3

A few things to consider : What happens after your fake loading screen is over in the case some user has a machine slower than yours? (Which will happen) Making a loading screen has never been a rule (i do not know if there is "rules" in video game making) but a good practice to prevent users with slower machines to see objects pop on the screen. If after ...


3

You should make your games logic completely independent from real time and essentially make it a Turn-Based. That way you know exactly the turn on which "tiles energy change happens". In your case, each turn is just 1/50th of a second. That way you have to worry only about player inputs, everything else gets managed by the games logic and completely ...


3

The ball, by pretty much the law of Pong and physics must either be going towards player one, or player two, not both. You could use this to switch interpolation priority between the two players. When the ball is heading towards player one then use player one to synchronise your information, as he is the only one that can affect the outcome of if the ball ...


3

There are 2 approaches to that You make clients synchronized - Lock-Step model: Firstly - read this 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond. It's about RTS, but from your description that applies to your game as well. Every client gets a Tick 0 moment (e.g. server sends message to start in MaxLag - ClientLag ms to all ...


3

You need to have a future command queue that will only be acted upon once all parties will have confirmed reception of the command. This queue will include no-operation null commands if no new command is to be executed. The delay for each command can be dependent on the ping/lag. The simulation on every peer only executes to the point (call it frame ...


3

The first fact that any multiplayer game needs to accept is: "No matter how good your connection is, there will always be some unknown delay between the server and clients." Because of this, contemporary real time networked games "run" the game on the server and the clients are just snapshots that are as accurate as possible, given any network latency. ...


3

When the user presses the button to enter panic mode, generate a sequential ID to tie to that event of wanting to enter panic mode. You then periodically send a message to the robot "Activate Panic Mode" with that sequence ID value you generated. Whenever the robot receives an "Activate Panic Mode" message, have it respond with "Panic Mode Activated" with ...


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