Much lag

[DalisonCPU]

In online matches, the game has a lot of lag. It takes more than 5 seconds after executing a command. I think you guys should work on some method to reduce this problem a bit, as the game is very good, but this delay makes the matches very boring. I don't know how it's done, but I believe that at every step of the animals, sounds are sent from the server. They should basically be walked by the customer. The server's task would only be to define the destination square.

[sanslash332]

@DalisonCPU can you give more details about your experience? Size of the map, how many units are on the field at the time that are you testing, if you are using a server near you or in the oposite side of the planet.

If you play in a regular map... aprox 20 x 20, with two or three more players, with a limit of a 200 full unit control per user the game is very well to play. If all players habe their 200 units and all of them are fighting, mayve the speed is betwéen 0.8x and up to 1.5x, but is still playable and enjoyable. And, that situation occurs a few times. The regular play speed is on 2.9 to 3.5x.

A, and take in concideration to move a lot of units and play a lot of sounds, the game take a interesting amount of CPU. some lag aren't problem of the servers, is problem of your machine.

[soundmud]

@DalisonCPU

Sorry for the problem.

I should document the multiplayer architecture of SoundRTS, but it's possible to summarize it into one word: (deterministic) lockstep.

Deterministic lockstep – a P2P implementation where only inputs are sent to all other players and synchronized in a “locked step” (i.e., synced for the same simulation tick all at once), and determinism on each client ensures that they all stay at the same state. This system is inexpensive and secure, but with complex determinism. (source: https://blog.unity.com/technology/choosing-the-right-netcode-for-your-game )

Pros:

1. Every player has the same chances, high latency or not.
2. Very small network usage (only the orders are sent).
3. Very small CPU usage for the server (the simulation happens in each client).

Some cons:

1. The game goes at the speed of the slowest client (CPU or network).
2. The simulation must be deterministic or the players won't play the same game.

There are some potential improvements to SoundRTS multiplayer though:

1. The server should tell the "latency" of each player to the other players, especially to the player who organizes the game, so there are less surprises when starting a game with many unknown players.
2. Search for bugs that could worsen the lag. I edited some multiplayer code in 2018 and initially had some concerning feedback about lag (but it's still hard to be sure if the problem was new). 1.2-a9 was published before those changes, so it could be interesting to compare the current version with 1.2-a9.
3. Simplify automatically the simulation by grouping units so the CPU can handle any number of units. I made some experiments this summer and it was interesting but I'm a bit afraid it could open a can of worms, for example with complex units with mana and spells. But at least the game would never slow down and it wouldn't require a rewrite of the game.
4. As a bonus improvement, even with an acceptable lag, the units should react instantly for a better experience. It can be done only by asking the client to predict what will happen next even though the server didn't send the actions of the other players yet. The keyword is: (deterministic) rollback.

Deterministic rollback – an enhancement of deterministic lockstep where clients forward-predict inputs while waiting for updates. This setup is more complex but enables a more responsive game than lockstep. It’s relatively inexpensive and secure, but with very complex determinism and simulation. (source: https://blog.unity.com/technology/choosing-the-right-netcode-for-your-game )

[soundmud]

@sanslash332

Thanks for the stats!

[sanslash332]

@soundmud your welcome!

The improvements sounds good, and really aparentli the better two enansements on that list are

1. see the lag or ping of every player. to check if is one the player that is lagging the others (and give to the host player the option to kick that player)
2. add the deterministick rollback netcode. Sounds very good, and will be awesome for early stages of the game. When the units of the players aren't interacting between them, you dont have to take care about what are ocurring at the other side of the map. The only extrange situation that I can see is when the game is some laggy and your are interacting with other player. For example two soldiers are fighting. the prediction says that the enemy unit will have to death, and because lag, you see that. But the real input was trigger a spell of that unit that when your client receipt the code and update the simulation you see something funny that the oponent unit deaths, but a few milliseconds after your unit desapear because the clients was resynchronised xd.

But well; i Love how this game continues with updates despite all the years that it has. Thanks Soundmud for that.