There hasn’t been any multiplayer related thread on this forum so I thought I’ll make a new one here for us to talk about it in a concentrated manner.
For those unaware, I’ve recently made a WIP multiplayer prototype which can be found here on this branch GitHub - Revolutionary-Games/Thrive at multiplayer. And I’d like to preface by saying that multiplayer is not in anyway a priority nor is it in the 0.x.x roadmap, the work being done on it atm is simply a prototype to explore the possibilities of multiplayer, might be fully playable at some point, and might be the game’s multiplayer mode in the future but who knows.
So why multiplayer? Future stages (beyond multicellular and excluding prototypes) will likely not be realized in the foreseeable future. Besides new players, the current gameplay the game has to offer right now might become increasingly monotonous for veteran players. While the upcoming new features and the train of progress steadily continue onwards, people might want something fresh to offer to the game. Here I think a multiplayer mode can fulfill this role, it’s highly interactive and provides extra challenge.
Multiplayer is not an easy task, even more so if we wish to turn all aspects of the game fully multiplayer capable. The main difficulty would be to integrate the current singleplayer theme of multi-million year process of evolution into a seamless and fun experience among two or more players, in aspect both technical and gameplay-wise. Consequently, the only feasible approach to achieve this might be for us to split individual stages into its own multiplayer experience, and since the only proper gameplay right now is microbe stage, that’ll be our focus.
The following gameplay idea for a multiplayer mode is common among devs and fans alike. Here’s my take on it.
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 believe freedom of movement is beneficial to the game flow, we shouldn’t restrict players to just one patch. So, this would allow them to explore various strategies and cell builds to reach dominance, all under the pressure of internal cell processes and a dynamic environment. So yeah dynamic compounds/gasses/etc once that is added into main. The tricky part left would be technical, the server has to concurrently simulate various patches where the players reside.
Score is synonymous with population, predation and lineage longevity. Population is pretty much self-explanatory. Predation is engulfment, toxin and pilus kills. Lineage, now this will indicate how long the player survives in a game session without going extinct. A timer will track the time passed from LUCA (which is the starting point for all players) to the player’s last descendant at the end of game session, the maximum duration of which could be 30 minutes or more. 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.
A scoreboard and chatbox will keep the player informed during the game and keep them competitive.
And possibly kill feed at the top of the HUD.
May need more design thoughts.
The “wonder mode”. Playing field is (maybe) across the galaxy, players spread out in different star systems and build their species from there, a rare chance for co-existence. Continuous stage progression. Development complexity = Thrive². Absolutely impossible to achieve in the current state of the game and dev resources but fun to think about.
The communication protocol used is UDP as this is common for fast-paced realtime games, conveniently provided by Godot’s wrapper for ENet.
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.
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.
As of right now, the current prototype netcode focuses heavily on player hosted client/server model. That is, there’s no concept of multiple game rooms so for an initial playable implementation people might need to setup servers themselves, I’m afraid.
A lobby is basically the players main gathering place for a game instance before starting session, I’ve mostly implemented this in the prototype along with basic lobby management. For player hosted server, only the host can start the session while others can mark themselves as ready, similar to how it works in most games. In dedicated servers, people can join whenever they want. At the end of a game session, players will be returned to the lobby.
Display of a server lobby
(Initial state as the host, start button disabled)
(All players in ready state (not counting the host), game can be started)
Regarding security, is a bit of a pain currently. 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’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).
That concludes my report of the multiplayer branch’s current progress and idea for its respective gameplay. This has been a very fun little project and hopefully continues to be so in the foreseeable future.