Multiplayer advice

So.. A while back I attempted to make a simple 1v1 multiplayer fighter game. I used the peer to peer method and the scirra signalling server.

It worked as intended and I think I understood the basic concept of sending the game state to the peer from the host. The main problem I encountered when testing was the lag involved, the game would often desync and cause some pretty wacky stuff to happen.

I'm now looking into having a second go at it and I have a couple questions, if someone could enlighten me that would be great.

Firstly, is peer to peer a good method? And what alternatives are there?

Would it be wise to do this sort of thing myself? I have very little experience and I'm wondering wether hiring someone would be better. However, I still need to know what needs to be done.

Basically, what is the best approach?

Any advice would be greatly appreciated, thanks.

It depends on what you're willing to achieve.

For a turn-based online game, having a high latency wouldn't be an issue at all.

For fast paced action it's important to keep synced information as slim as possible.

In the end, peer to peer can be a good choice, depending on design of your game.

I've done several local-tests, and never had any real lag issues.

It's important that you don't make any mistakes with trying to sync information which you've not properly set.

Doing so can cause major lag problems. It will look as if the "internet connection" is terrible.

For a 1vs1 fighter game it would be important to create a proper Host-Side check which calculates "back in time" where exactly the player was staying at the time he punched. That way you can prevent issues that the player sees what actually happens. Otherwise the player might punch the opponent, the host however thinks that the opponent was too far away, with that does not count the hit.

Ashley made some good examples in your examples folder of construct 2. You should also checkout his official tutorials.

If you tech yourself the multiplayer features, i think you should be able to get it done right.

But i can only recommend to read the tutorials entirely through.

Alternatives are not easy and require more knowlegde.

Construct 2 does not offer a Dedicated Host feature. So peer to peer is the only official solution available.

Unless you use a workaround by running the game as HOST on a dedicated server and leave it nonstop running/online.

Thanks for the swift reply. The multiplayer tutorial is what I was used on my previous attempt, maybe it was the case that I didn't sync the information properly.

I'll have another go with the same method. It's been a while and I can't really remember the process behind it, but what did you mean by back in time checks?

I just remember receiving inputs from the peer as the host, and relaying them back to the peer. Probably sending too many bits of info to make it desync.

Anyway, will try again. Cheers for the advice.

Rewinding Time:

https://www.scirra.com/tutorials/892/mu ... ge-8#h2a18

Local Input Prediction:

https://www.scirra.com/tutorials/892/mu ... ge-7#h2a15

I can only recommend reading through the entire tutorial.

But using the Rewinding Time will ensure that the HOST is able to recalculate what the player actually saw, and handle accordingly.

Just think about it in a Shooter Game like Battlefield for instance.

What would you think if you shot someone in the head, but the server didn't recognize it?

That would kill the entire fun.

With rewinding the time, the server can recalculate the actual position of where the enemy was standing from your standpoint when you triggered the shot.

Otherwise the Host will think, the enemy was already behind the wall and you shot into the void.

With local input prediction you can ensure that the players input will be immediatly shown on their screen.

Even though the server did not even get your input as of yet.

As soon as the server recieved your input, it will sync the information back to the player, and in case the prediction was wrong, it will do some small corrections to get you back in place.

Otherwise, if you only let the players move as soon as the server responded, it will feel very very laggy for the players.

For a real-time multiplayer game.

It is KEY, to send really ONLY required information.

AND the information sent must be set as SMALL AS POSSIBLE.

More details at the bottom.

What do we want to sync?

And which ones need to be fast?

- NO client side prediction for deaths

Because if we blow up a player and then realize it was mis-prediction, we would have to bring it back together.

This would look kinda weird!

Basic Information

---------------------------------

High (double, 8 bytes):

a double-precision floating-point number that can store numbers without affecting their precision.

It has about 15-17 significant digits of precision. However it takes 8 bytes to store a single number,

which can end up increasing bandwidth requirements significantly.

In practice this is unlikely to be a necessary choice.

Normal (float, 4 bytes):

a single-precision floating-point number that can store fractional numbers with about 6-9

significant digits of precision. This means some numbers will be rounded to fewer significant digits.

However it is usually far more practical than a double, since it only takes half as many

bytes and digits beyond the first 6 are usually unimportant

(e.g. 0.333333 is close enough to 0.333333333333333 for practical purposes).

Low (int16, 2 bytes):

a signed 16-bit integer that can only store whole numbers in the range -32768 to 32767.

Very low (uint8, 1 byte):

an unsigned 8-bit integer that can only store whole numbers in the range 0 to 255.

To minimise bandwidth, it is important to choose the lowest precision possible that will

not seriously affect gameplay. For example X and Y positions can often use low (int16) precision.

As long as the layout is smaller than 32767x32767 (which is very large), and sub-pixel positions

are not important to gameplay (since this will round off any fractional value), it is perfectly

sufficient and uses four times less bandwidth than a double.

For example:

If your total of all synced data is 32bytes:

2 players = 32 x 2 x 2 = 128 bytes per update x tickrate 60 = 0,06 Mb/s (Required Upload Rate of Host)

4 players = 32 x 4 x 4 = 512 bytes per update x tickrate 60 = 0.25 Mb/s (Required Upload Rate of Host)

Even though the player count increases linearly, the bandwidth requirement increases proportional

to the square.