Multiplayer

[hhyyrylainen]

@Kasterisk

The ultimate goal of my prototype. Restricted to microbe stage, playing field is under one patch map, gameplay focuses on classic PvP (player vs player). Synchronizing timescales will be hard, so we’ll just ignore that and have players evolve/edit their species asynchronously, i.e. time passes independently of players going into the editor, i.e. asymmetric gameplay. Progression will be the same as in singleplayer, gain the two reproduction compounds, evolve, explore, survive, get better, repeat. The difference would be that this interaction is among players so it’ll be interesting to see how this would play out.

I think we should call this gamemode “microbial multiplayer” as your goal seems to make the microbe stage playable in a multiplayer mode.

What I’d call “cell battle arena” gameplay mode would be just a single map patch where the players are always pretty close to each other, which would much more encourage pvp real time battles. So I’d like to make that distinction clear when talking about potential gamemodes. If we get a server browser it should very clearly display the gamemode the servers are running.

@Kasterisk

So one game session could mean like for example 1 billion years in-game time. To determine the “winning” condition, a player’s lineage timespan is checked and if a tie happens, population and predation count is factored in. The winning player will be presented to others as an “apex species” or something. And if a player goes extinct midgame, they start out from scratch as LUCA.

So you’d solve the problem of players being much further in progress by resetting the game world every 30 or so minutes?

I guess that is a pretty good solution to have like 30 minute matches to prevent new players from joining a server where they can’t survive at all due to other players having played for like 4+ hours or something.

@Kasterisk

The network topology used would be P2P client-server hybrid to allow player host servers. For this (according to my humble research), server host may need to do port forwarding to allow other people to connect to their network. However, if UPnP is enabled and is available to the host’s network, it might be possible for this to be achieved automatically.

In source engine games, hosting a game and playing at the same time is called a “listen” server whereas dedicated servers are then a separate concept (and they are recommended due to performance reasons).

I think what you are describing is actually just a server architecture and not p2p architecture at all as in your model players will act as servers but the server can be automatically started.

If we get a master server that keeps track of other servers, that master server can help players join games by offering NAT punchthrough, which is also a big reason why I think proper multiplayer needs that.

@Kasterisk

That’s just a lot of hassle to setup a server. Therefore I think we need to host dedicated server ourselves with cloud hosting in centralized servers, this will not only make security easier but people could also browse and create game rooms (instances of game session) easily, not to mention latency benefits. HH mentioned about VPS which costs a bit of resource but is possible nonetheless. So, I’m confident this can be achieved, though may need others expertise.

Due to costs, I don’t think we would ever host more than a couple of game servers, so instead like most games with community servers we’d rely on players setting those up. Or if Thrive gets really popular game server hosting companies might start offering one-click hosting options for Thrive.

@Kasterisk

In dedicated servers, people can join whenever they want. At the end of a game session, players will be returned to the lobby.

Unless players get to vote on the next gamemode or something, I don’t really see the point why dedicated servers would even have the lobby screen. Those servers should just automatically start the next “match” once the previous has ended.

@Kasterisk

(All players in ready state (not counting the host), game can be started)

This only really works for games where you know everyone. Public servers can’t use this approach otherwise there’d need to be an admin online at all times to kick the people who don’t know how to ready up…

@Kasterisk

This is still lackluster in the prototype, for example there’s no secure transmission set up. Could’ve used DTLS using Godot’s API but I’m a bit lost on how to distribute x509 certificates in respect to player hosted client/server model. But I feel like this service can be of help in some way: https://letsencrypt.org.

I don’t think we can really use security like this. Because it would be a huge pain for server setups to get a valid HTTPS certificate. And besides that there’s really no benefit to self signed certificates the client can’t verify over a simple encryption like a Diffie-Helman key exchange at the start.

If we get that master server setup, then I think we could have some kind of server name reservation system where a server is given an identity by the master server the first time the server starts. These certificates could then be signed by a certificate held only by the master server.

That would make it so that players could securely join their favourite servers certain that they aren’t getting a MITM attacked. But when joining a new server based on a name in the server browser, they really couldn’t know if someone set up a pretending server or not.

Even that kind of partial security would probably be like multiple times more than what most games do. Then again most games just do matchmaking now and don’t allow community servers at all.

@Kasterisk

I’ve thought about persistent player data, I think it would be nice to have this. We could store players’ score information like lineage longevity etc, this will show up in a leaderboard that people can see. This require players to have game accounts which means a database to manage, further complicated by having to integrate it with Steam, and worst of all necessitates the secure transmission mentioned beforehand and player authentication so that no people will poke around with the data and sensitive information (passwords/usernames).

Yeah, this is one of the trickiest parts. This again could be handled by the master server which players would authenticate to, and then the master server would give authentication tickets the players present to servers they want to join.

This way we’ll have player authentication without the servers being able to steal people’s accounts. But of course we couldn’t have any kind of score validation this way so a “hacked” server could just give everyone infinite score when they first join. So at least initially due to that I wouldn’t add any kind of global leaderboards, only server specific leaderboards.

---

One final thing, I’ll note that if we separate game logic from Godot, we probably need to do our own networking.

Alternative ways to fix the performance

I suddenly realized one more thing regarding this based on the recent bit of prototyping done using Godot networking, which is that if we add multiplayer we cannot use Godot’s inbuilt Node replication mechanisms for that. So instead we need to do entity data updating and local prediction code ourselves, maybe even use all network connectivity outside Godot. For example we could use a RakNet fork like GitHub - SLikeSoft/SLikeNet: SLikeNet™ is an Open Source/Free Software cross-platform network en…

So while the multiplayer is still in the early stages it’s probably easier now to futureproof it, though I won’t definitely say if that alternative game logic way is ever used so I won’t make a hard recommendation for the multiplayer at this point. But I’ll say that the protocol for the master server communication should definitely be done as a custom protocol over UDP so that we can have the master server made with pure C# (and also implement an Error: ASP.net | The ASP.NET Site app for user registration like the ThriveDevCenter is) and not need Godot there.