Games on Locutus?

[AshtonSnapp]

TL;DR: Is Locutus going to be fast enough to handle the needs real-time multiplayer games, and how would different multiplayer paradigms need to be adapted in order to work?

To start, I like the concepts behind Locutus. I recently learned about the project through the FUTO interview with Ian Clarke, and I'm interested - although I'm not used to programming network related things that much, so I'm not sure how much I would be able to contribute directly.

One thing that came to mind for me is video games. I play a lot of them, and I've looked into making my own a couple of times. And I've been wondering whether it would be possible to build a multiplayer game on top of Locutus.

For multiplayer games on Locutus, there's a few things to consider. First is latency. Ian Clarke said in the FUTO interview that Locutus is going to hopefully have less than 1 second latency, so that should be fine if that goal is achieved. Probably. There's also the matter of stability - you don't want to be disconnected mid-match.

There's also the matter of how to adapt the different multiplayer paradigms that have developed over time. I'll categorize them as follows:

• Transient games, where the multiplayer game environment is instantiated at the start of a session and destroyed at the end. Think matchmaking and lobby systems.
• Persistent games, where the game environment is created once and continues to exist even when nobody is playing the game, with any player-made changes persisting. Think MMOs, or Minecraft servers.
• There's also games that are nominally single-player, but have some multiplayer component, such as an auction house where players can trade in-game goods.

Besides the last one, which to me at least has an obvious implementation, how would these general categories of multiplayer be adapted to work under Locutus?

(To anyone who read this, thank you for your time)

[iduartgomez]

Very late reply but better later than never...

About multiplayer paradigms, I don't see a problem regarding this since it should be able to handle persistent states as well as ephemeral ones. This all comes to how the core logic would be implemented between states.

Re. latency, this one is harder... For certain games, 1 sec updates would be just fine, but for others you would like at least 100ms latencies or even less (hopefully), this will be tougher to achieve, P2P protocols and multiplayer games are known to have their own share of problems regarding this, and this is with much more simple protocols that don't have to worry about thousands (or more) of nodes being connected. The physics of this are hard to beat.

That said, there could be certain optimizations with smart contract design that could lead to better locality, exploiting the small world effect, so we could potentially achieve latencies on par with games which use P2P without centralized servers and hopefully we can make the core node logic lean enough to add a very minimal overhead.

[AshtonSnapp]

Very late reply but better later than never...

I agree.

About multiplayer paradigms, I don't see a problem regarding this since it should be able to handle persistent states as well as ephemeral ones. This all comes to how the core logic would be implemented between states.

I figured it would be able to work, it just isn't immediately clear to me how it would work. Although, I could probably get a better answer to that question by trying to hack something together myself using Bevy or something - even though I am absolutely not an experienced game developer, let alone an experienced multiplayer game developer.

Re. latency, this one is harder... For certain games, 1 sec updates would be just fine, but for others you would like at least 100ms latencies or even less (hopefully), this will be tougher to achieve, P2P protocols and multiplayer games are known to have their own share of problems regarding this, and this is with much more simple protocols that don't have to worry about thousands (or more) of nodes being connected. The physics of this are hard to beat.

I see your point with this. As an example I've been playing Minecraft since 2012, I know I can play online with roughly 600ms ping (satellite internet sucks), but once it goes over 1 second (1000ms) of ping it is prone to disconnect. And even below 1000ms, I'm often left with a disadvantage if I end up in a combat scenario. A real-time, hyper-competitive game would probably be absolutely painful.

That said, there could be certain optimizations with smart contract design that could lead to better locality, exploiting the small world effect, so we could potentially achieve latencies on par with games which use P2P without centralized servers and hopefully we can make the core node logic lean enough to add a very minimal overhead.

I would like to see those optimizations being implemented once they are discovered. Multiplayer games on Locutus would probably be great since you wouldn't have to worry about paying for servers to keep your game running.

[iduartgomez]

Yes, I think we could achieve relatively decent .

Also is important to notice, that Locutus can be used to bridge/discover two (or more) peers, but once this connection is discovered, there is nothing stopping you from opening a direct connection between those 2 peers.

Then the application itself could handle directly some of the traffic between the peers, in a typical game this would be mostly ephemeral real-time information that does not need to be stored (like the position of the player in a map), and just handle the data that needs to be persisted to the node (things like the inventory of a player). Summarizing it shortly: just use Locutus were you would be using a database, and handle the rest of the traffic in the application, and that is likely going to yield similar results (ofc for massive games would need to see how to solve some scalability issues for the "database" part, but I think there are potential workarounds).

I definitively see ways in which you could build multiplayer games with Locutus fine, without an extraordinary additional amount of complexity to how current games using P2P work.

[iduartgomez]

Answered