Ok, this is my first post in this forum, so if I forget to do something please tell me.

Short story: Im developing an indie game, with my own engine. Its a realtime game, the game tick is 60Hz. I currently developed an UDP network prototipe in which each player (supports only 2) sends the player input to the other. It works fine on LAN, and via internet inside my country (have not tested it with other people), however I had to introduce a bit of latency in order to get consistent frametimes.

1. Do you think this will scale up to 8 players, sending packets each other?

2. My engine is monothreaded, I could theorically separate render and game threads, and maybe I can reduce latency this way. What do you think?

3. Is there some p2p library that already support creating and joining games so that I can simplify the network game code? It is already a mess, and it works with only 2 players..

First, I don't think sending 60 packets per second will scale well at all. Most games send fewer packets with more data -- for example, sending 10, 12, 15, or 20 packets per second, containing 6, 5, 4, or 3 ticks' worth of player data per packet. This means that there will be more delay in receiving and playing the data on the other end; this is a necessary evil for networked gameplay.

Second, I don't think 8 player peer-to-peer mesh will work. That means each player has 7 other connections, and if you send 20 packets per second, that's sending 140 AND receiving 140 packets per second. As you may see from the Awesomenauts discussion on this board, that high a packet rate doesn't work well for peer-to-peer games on the internet.

I would recommend moving to a client-server topology. You may run the server on one of the client machines; that's fine, but sending and receiving 20 packets per second (containing a integrated update for 7 other players) is a lot less work, and is how successful games like Quake, Counter-Strike, and friends work.

I don't think multi-threading your engine will cause any significant change in latency.

Thanks!

Starcraft 1 worked ok with 8 players via P2P. Ofc it was an strategy game where the game tick was much lower than 60Hz. But its pretty impressive how responsive it is, there is almost 0 latency, I dont know how they achieved that.

Based on that I choosed the P2P over client-server, and because I think its easier to implement, but looks like I will need to have a look at client-server.

Starcraft 1 worked ok with 8 players via P2P

I think your assumptions don't quite hold true.

First, in Starcraft, there is a host, so the topology is client/server.

Second, Starcraft also uses the lock-step simulation method -- similar to the "1,500 archers on a 28,800 modem" article that's linked from the FAQ. This also means that a tick rate of 5 or 10 Hz sends very little data, because only input commands are sent, and they're only sent to the host. (and then a single packet with data from all players received from the host.)

Third, Starcraft has very much latency. They are just good at hiding it. The "Yes, sir!" acknowledgement animation for each command is there to hide the latency of actually making the units move on every player's machines at the same time.

Starcraft 1 worked ok with 8 players via P2P

I think your assumptions don't quite hold true.

First, in Starcraft, there is a host, so the topology is client/server.

Second, Starcraft also uses the lock-step simulation method -- similar to the "1,500 archers on a 28,800 modem" article that's linked from the FAQ. This also means that a tick rate of 5 or 10 Hz sends very little data, because only input commands are sent, and they're only sent to the host. (and then a single packet with data from all players received from the host.)

Third, Starcraft has very much latency. They are just good at hiding it. The "Yes, sir!" acknowledgement animation for each command is there to hide the latency of actually making the units move on every player's machines at the same time.

There are thirdparty plugins that allows players to set the latency to their needs. I have played a lot with it in the lowest latency mode, and a unit response is almost real time. These plugins are called "lan latency mode" or something like that.

My engine is also "lock-step" based, I only send player inputs in very small packets.

These plugins are called "lan latency mode" or something like that.

Right -- but they cannot provide latency lower than the round-trip between each player and the host.

Also, Starcraft is only P2P in the sense that Blizzard doesn't host the games -- the network topology is still, as far as I know, a "star" between each client and an aggregating host (run by a player.)

The game cannot proceed to time step X until it has the input from all players for step X. The variables you have to play with are "how much in advance do I send commands for time X (D)" and "how often do I send commands. (Hz)" The total latency will be D + 1/Hz + RTT.

I imagine that a library like RakNet would work fine for hosting and joining games, although you will still need some way to find hosted games, which is the value that Blizzard provides for Internet games (and that LAN broadcasts provide on a LAN.)

8 players per match in peer to peer is stretching it but might still work. We use peer to peer for Awesomenauts with 6 players and although it is not perfect, it works well enough: we have been having continuous success with the game on Steam for the past two years so it cannot be all bad... ;)

The big question is how fast your gameplay is. If you only need to send 10 packets per second then 8 players per match should be fine.

Also, you need to think about relaying messages. With 8 players in a match there will in most cases be at least two players who cannot connect directly to each other. In Awesomenauts we solve this by letting them communicate through another player. This increases lag but makes sure everyone can talk to everyone. Having dedicated relay servers is even better but requires that you have such servers running on various continents. Photon offers this service but they don't regularly allow sending directly, so they add the relay server's lag to every player which sucks in its own way.