Planning to support web/wasm?

[erlend-sh]

Do you intend to eventually support browser games or is that out of scope?

Naia achieves this by using webrtc-unreliable.

[lemunozm]

Yes! One of the next steps is to give support to Websockets

[erlend-sh]

Cool! Does that extend to your asciiarena demo game as well? AFAIK tui-rs doesn’t run on the web. You’d need to use something like bracket-lib instead.

[lemunozm]

Does that extend to your asciiarena demo game as well?

That's precisely the point 😃 . I want to make a frontend abstraction for asciiarena to support different frontends (because as you say, tui-rs, only works for the terminal). When I finish the game to work fine, I want to make the port to wasm :)

And yes, probably this will be the chosen library. I saw the tutorial book about rltk (the now bracket-lib) and it's awesome!

[lemunozm]

I didn't know that bracket-lib also supports crossterm, I have to look it deeply, but if it fits well, with a simple change of tui by bracket it will remain works in terminal and web (and others). Thanks for the recommendation!

[erlend-sh]

I want to make a frontend abstraction for asciiarena to support different frontends

Nice! We’re already doing that in the bracket-based Shotcaller. We also intend to make it networked, following a closer evaluation of our options in about a month. If by that time you’ve had a chance to write a bit about how message-io compares to the other netcode libraries out there that’d be immensely useful.

The ones I’m aware of are:

• message-io
• naia
• laminar
• turbulence

[lemunozm]

I'm glad to hear that you're valuing using message-io.

I knew about these other libraries but I did not use them (maybe I an wrong in some point), but, from my understanding:

• message-io: Follows an event-message paradigm. You control the messages you want to send from where to where and which transport is used. Also provide both, the network and an event system to manage the message sending and receiving easily in one thread. I think this is a strong point of message-io, the API is the simplest. It is quite simple to use. You leave the complexities about concurrency, encoding, serialization... Your information unit is the message and the endpoints (the identifiers of the remotes).

• naia: Follows a different paradigm where you have a state that wants to share among several "endpoints". You don't want to talk in messages as message-io, your information unit is the state. In a game, it is useful because you have a state that you want to share. But maybe in other parts that could not imply share a state as it is less powerful (login? subscriptions? request-response?). Regarding this, message-io is more general purpose. Shared a state could no be as easy as naia but you can build other things that could be more tedious/difficult in naia. You could have more control in some parts with message-io. Also I think that the underlayer protocol is a vitaminized UDP, although remains unordered and unreliable. Also, It lacks TCP. In some cases, TCP is util even in an RTS game. The important actions as "shot" or "move" of the player that is really small can be safely sent by TCP while the frame information with all the content can be sent by UDP: If you lose a frame is not the end of the world, in16/33ms you will receive a new one again, but if you lost your shot action it can be decisive in the game. A good point for naia is that it uses WebRTC, that is the UDP in the web in the same way WebSocket is the TCP in the web. At this point, message-io does not manage these protocols (but is the intention :D). As a resume, I like the idea behind naia of sharing the state, but the paradigm is quite different from message-io that is more general-purpose and message-oriented.

• laminar: Laminar is like a TCP protocol (reliability, order,...) built on top of UDP, and focused on to fit better than TCP in games contexts. TCP reliability implementation implies some minor lags that could be not fit well in RTS games (has an order packet and waiting for ACKs to notify receiving have a cost). The laminar implementation tries to move this cost to other places that have less impact in a game context, where you can suppose, for example, that if somebody is connected is because he is playing and sending information to it to detects if he is alive is expected. I would imply more traffic in some cases. How is it comparable with message-io? Message io is in the upper layer. In the future, it could incorporate laminar as other transport, and the user could choose among TCP, UDP; and ReliableUDP. As I'm writing this, the more I like the idea! It seems to not be difficult.

• turbulence: I think this is quite similar to laminar, it offers UDP with an upper layer to manage it more TCP-like. Seeing the examples I see the laminar API easier than this. But I say this from a non-user point of view.

[erlend-sh]

Super helpful! 🙏

What we’re doing would probably work fine with a pretty simple tcp layer.

Also very important to note that the most important thing for me right now as a game designer and publisher is to just see the core idea of the game in the most fully realized state possible at minimum cost. All I want from a netcode library at this stage is to let me prototype the online experience of the game as easily as possible. If it doesn’t scale past 50 or even just 2 concurrent players, that’s fine by me. As long as I can play online with one other person, that covers the bare minimum most needed right now.

[lemunozm]

Then, probably message-io (in the current state) fits well for your purposes 😃 . I hope that when you have mature your game, message-io can be also mature with wasm support, laminar, and other cool features!

[lemunozm]

From version v0.7.1 message-io has WebSocket working for normal and secure mode

[entropylost]

@lemunozm Is it possible to use the websocket on the client side (web) as a direct interface to web-sys? It seems like this is just for the server right now.

[lemunozm]

Hi @iMplode-nZ,

if I understand you well, yes. I have to add an example working with wasm but websocket should work in both, client and server sides. Currently there is a ping-pong example that can be configured to use Websocket as client side.

If you refer to use the Websocket found in web-sys to communicate with a websocket server in message-io. I have not tested, but should work also.

[entropylost]

Thanks. Maybe say this in the readme as its rather confusing?

[lemunozm]

Although you can use WebSocket in message-io from the client-side, it will not run it the web since tungstenite-rs do not work with wasm.

Feature tracking to archieve this: #100