7

In order to get a server list, you will need a central matchmaking server to which all game-servers connect and announce that they are online and to which all game-clients connect to obtain the list of currently online servers. How many servers are you going to have? For comparison, I remember that during the high-times of the original Counter Strike, the ...


5

For peer-to-peer communication between web browsers, WebRTC is likely the best option available. But keep in mind that it is not universally supported yet. Also keep in mind that while you might save traffic on the server this way, the perceived performance for your clients might be far worse, because consumer-grade internet connections will likely have far ...


4

You can do this by making the secret starting state verifiable and guesses difficult: Have all players generate a new private/public key pair, send the public keys Let them shuffle their own decks Choose and/or exchange salts (see below) Generate signatures for the information you want to check: Either a player's full deck if that can become known after ...


4

3G is optimized for stuff like streaming video. It's terrible with regard to latency when talking about small bits of data. There's a reason multiplayer mobile games over 3G with split-second timing don't exist.


4

Why shuffle the deck in the first place? All clients know which cards were already played and which cards are still in the deck. What they don't know is the order in which they come. So instead of fixing the order at the beginning of the game, why not determine it during the game? Keep the deck as a sorted array and whenever a new card is needed, pick a ...


3

For some games it is possible. Take chess, for example. Can you cheat at online chess without the opponent noticing? Cheating at chess is hard, because the game: has no hidden information is deterministic (no randomness involved) is only about making the right decisions. Reflexes or precision don't matter. When your opponent says they just moved their king ...


2

The key to large-scale synchronization is determinism. Basically, if you can plug X into a function and get the same Y on all computers, you can send X instead of Y. For example the de facto RTS game sends commands rather than health, positions, rotations, etc. since syncing 500+ positions can use up quite a bit of bandwidth. For example, the command "...


2

You have multiple problems with your current implementation. First of all, the biggest problem with peer-to-peer (or P2P for short) networking is, that it isn't designed for games. Due to it's nature, nobody has authority over the data being sent and received. If one of the players decides to cheat (always assume this), then there's nothing you can do ...


2

First of all you need a way of detecting such issues and separate them from simple packet loss. Once you know you really have this happening and really need to work around this, there are several solutions you could try: Simplest solution, just drop the player Allow to re-route messages/packets via different peer (i.e. assign a peer who will send out not ...


1

Do the host "decides" the enemies state? This is one way to do it. Which I recommend, but there might be games which work with other methods. Basically I'm asking whats the best way to handle a 4 player p2p game with many enemies on screen. There is no best way.The simplest way to do it would be to have one host control everything about the game, and ...


1

I've found a solution to this problem. Note: this will be a relatively long answer. One thing that I did implement was the use of udp for some of my data transfers that are not as critical as others. For example, since I'm sending movement data about 10 times a second, I figured its ok if 1 or 2 of the 10 get lost once in a while. Now to the actual ...


1

As you already guessed, you can't trust any server or client you do not have under your control. So you can't send processed results. You have to send requests to the server, indicating the actions that lead up to these results, and verify these requests against the master server's knowledge of the rules of your particular game. Even then, someone could ...


1

I think your algorithm is pretty close to one I wrote in this answer to a similar question, but I'm concerned that this line in your algorithm isn't doing what you'd like: b: receives message. If a.localTime + dTime(b-a) is very close to new b.localTime, send accept message. You should be figuring out roughly how long the packets are taking to get from a ...


1

For simple matchmaking only, you can create an ASP.Net or PHP website that the players login to (via your game app) and push a notification when they create a server. The problem is securing the server to make sure only your players are accessing critical services like advertising a host or requesting the available host list. There are also services like ...


1

First, I haven't found any indication that another game does this. Having said that, I'd love to try it, or find examples of it, and was looking for examples when I came across this question (hence the (somewhat) necro - but an answer hasn't been accepted, so I might as well give one). I believe such a method would be useful, though its value would vary by ...


1

I'm not aware of this ever being used, and I suspect it's because it has very limited benefit for greatly increased complexity and bandwidth use. It might make an interesting experiment, but it seems impractical. Consider that to support such a scheme, and assuming that most traffic is generated from player actions, you would need to double the downstream ...


1

You don't need to correct the errors on the client right away. If you interpolate the current client info with the incoming server info, the client info will converge to the server info in the next few frames. Since you are expecting the server info arrival to be less granular than the client update, when some info arrive at the client it will have enough ...


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