Netplay - Ideas, Thoughts and Considerations

[0lhi]

The open nature of TheXTech allows it to evolve at a more rapid pace than it's competitors. One of the more exciting possibilities that has been considered is Netplay support - the ability to have multiplayer games via the Internet!

The current idea is to implement a server software that syncs cycle counting between clients. It will lead to some lag on very old PCs or low internet bandwidth, but it will keep the games synchronized.

"physics cycles were computed accurate even they run on different processors (ARM / X86 / PowerPC), together with controls we can count number of cycles and let the server side to tell all clients they can run the next cycle"

• Wohlstand, 2021-04

It would be similar to how common Emulator Netplays work. However, there are many ways to implement such a feature, each of them with their own benefits and limitations.

This discussion is meant to offer a place where players can share their input, so that the best solution for all use-cases will be found.

I think, the two most important first steps to take are dealing with #46 and #132.

#46 talks about suggestions to improve the Screensplit for Multiplayer. I was first thinking about a 2-Window setup, but a single Window with two 800x600 could work as well, at least for 2-Player.

#132 In order to make sure that games stay synchronized, the Clients need to verify that the episode is identical. This can be done by putting them inside a container (like an image or archive) and comparing the Hash-Values.

Another thing that has to be verified is that the TheXTech versions are the same. There are two way to do this:

Complex: Have a value that identifies every auto/manual build.

Simple: Have autobuilds be labelled as development versions (for example 1.3.5-DEVEL) and allow only release versions for Netplay.

How to enter Netplay?

One possibility to do so would be via the #40 Planned Launcher. It could establish a connection to the server, have the Players be assigned by order of arrival, and select an image or archive of an episode, which, during the Netplay, would be the only episode accessible from the menu. Player 1 would select the sav(x) file, which would be saved for both players as GAME.wld-save-net1.savx.

4-Player-Mode?

Before making any concrete steps, it should be discussed whether there is interest in having more than two players. NSMB Wii and U, as well as Mario Maker, allow to have four players, which people seem to enjoy. There is also the Battle Mode, which is somewhat reminiscent of Super Mario War, but with a bigger Playfield.

Compensation for Input Delay?

Netplays cause Input Delay. However, not all games are equally affected by this. A 2-frame-delay could ruin one game, while a 5-frame-delay is barely noticable on another. It comes down to how precise your inputs must be. Whether it'll turn out to be an issue for SMBX remains to be seen.

If it does, however, there are ways to relieve this. One such way is the so-called "Coyote Jump", that is commonplace in many modern Platformers such as the N. Sane Trilogy and Battle for Bikini Bottom (3:21).

Enjl has also brought it to SMBX2:

Other ways to compensate could be a mid-air spin for Mario, or giving Yoshi his flutter.

In Summary

Netplay is a promising, but ambitious prospect. I have shared some of my thoughts on this, and am eager to hear yours!

[Wohlstand]

Complex: Have a value that identifies every auto/manual build.

Inside of CMake builds I already do pick up the current Git HASH, which is already used inside of the game as a macro that gets printed in the crash log mainly, but also can be used anywhere also. The git hash is the best way to confirm builds are the same.

[Wohlstand]

Compensation for Input Delay?

If I will use the server-synced cycle counting, the input delay I guess will not be a problem, the main problem if one of the clients gets lagged (or has a bad network), all clients will lag together with the slowest of them.

What the idea would go:

// Initially, the server will send the same random seed to all clients:
Server ->> random seed
loop:
{
    // every client sends the controls state and will wait when serve will reply
    Client -> send own controls
    Server --- wait when all clients report their controls
    // server tells what controls all clients have
    Server ->> control states of all clients
    // server allows all clients to run the cycle
    Server ->> to all:do Cycle
}

I may guess the only reason to have the input delay is having to use the prediction-based model (where you do skip some frames until to report everything state to the server, etc.). SMBX looks like the cycle-sensitive game and I must run the every-frame synchronization, and the data size got send would be (approximately, will need to check some later):

• ~52 bytes per every controls structure (may different) (player will send one own structure, the server will send back the number of structures equal to player's count)
• 4~8 bytes for random seed
• 4~10 bytes of meta-data, but may be different, etc.

I still to have run some other checks on both fast and slow networks (for example, run a game on my phone with H+ active, and play with the game on my computer, so, the slow network is here 🦊 )

The only reason for the input delay I know is the wireless controllers and there is a hardware-side delay, the game itself gets input commands later than they got triggered on the device.

[0lhi]

but also can be used anywhere also.

Oh, nice! How long is it? Ideally, it would be inside the Title Bar, and inside the launcher. Maybe on the game menu in some corner, too.

[0lhi]

the main problem if one of the clients gets lagged (or has a bad network), all clients will lag together with the slowest of them.

Yeah, that's to be expected. With a Framerate of 64.015, a ping of 30ms would lead to a One-Frame-Delay. 35ms to a Two-Frame-Delay. Depending on server location and the type of connection (some can only play on wireless, which will be the default for Android), those things can add up.

[0lhi]

From the m64p FAQ:

Will playing with someone with a high ping cause input latency?

m64p netplay manages input latency differently than legacy N64 netplay technologies. If someone has a high ping, only their input latency will be affected, it will not affect the latency of the other players.

That sounds pretty interesting! I have tried Netplay with three Emulators before: Mednafen, Dolphin, and m64p. Out of the three, the N64 Emu felt by far by the most smooth and responsive! Their latency management may be something worth looking at.

m64p Client • m64p Server

[ChristianSilvermoon]

Admittedly if doing netplay, an option to not split the screen at all and just let the other player go off screen if you don't care about or don't want to see what the other player is up to (a great enhancement for Battle Mode, for example)

My only other idea to contribute at the moment is that the Super Mario 64 PC Port's Co-Op mod appears to be able to use Discord for setting up games (Not sure how that works at all), but having a simple system like that could help make multiplayer more user-friendly to setup for platforms with access to a Discord client. If that were somehow implemented I'd want to see it be optional though, as not everyone wants to or can do things through Discord.

EDIT: Not splitting the screen would also open up the opportunity for special episodes where players need to communicate things each other sees to the other to progress.

[0lhi]

The PC SM64 appears to use a peer-to-peer connection. I don't know how Discord can help with that, but, things that apply there may not necessary apply to a server based solution.

A more comparable software would be the m64p Emulator. If the Netplay Setup is done like here, I don't think user-friendliness is a concern.

It also has some Discord integration, though it seems like it's just a bot that reports when a new Netplay Room was opened? That could be done for sure, and would be easy to integrate on other Messengers as well.

[ChristianSilvermoon]

Assuming it would be possible to self-host said server? That seems like a good idea

If possible an integrated multiplayer server within the game itself would be outright fantastic. Possibly enabled (or disabled) at compile time with a build flag (so that the functionality could be stripped out easily for platforms where it's not ideal)

Or... It would be neat if it could work in a way like Minecraft can find LAN games on its own. to make joining another player on the same network extremely simple

[Wohlstand]

The self-host server will be the first and main option, mainly to host the public server for worldwide netplay I'll need to choose the specific place. Hedgewars does the same: it's mainly the standalone game, and it has the local netplay with a self-hosted server and the ability of a worldwide netplay on the official public server.

[M0REKZ]

4-Player-Mode?

Before making any concrete steps, it should be discussed whether there is interest in having more than two players. NSMB Wii and >U, as well as Mario Maker, allow to have four players, which people seem to enjoy. There is also the Battle Mode, which is >somewhat reminiscent of Super Mario War, but with a bigger Playfield.

I say that it be done as a more configurable option, for example, what about someone who wants to play with 5 people? or especially in battle mode, there is going to be the one who wants to play with 8 people at the same time, so that's what I say: make it more configurable by the one who hosts the server