Multiplayer

Gameplay
1

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.

Microbial Multiplayer

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.

In-game display

2022-10-09_18.10.53.9896
2022-10-09_18.10.53.98961920×1080 94.8 KB

And possibly kill feed at the top of the HUD.

May need more design thoughts.

Open World

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.

Miscellaneous / Technicalities

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)

2022-10-09_18.03.51.5694
2022-10-09_18.03.51.56941920×1001 61.9 KB

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

2022-10-09_18.04.28.7146
2022-10-09_18.04.28.71461920×1001 64.2 KB

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.

2 Likes
2

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.

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.

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.

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.

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.

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…

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.

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.

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.

2 Likes
3

Ah yeah, that’s more closer to what I described. I can also see the benefit of a single map mode for total deathmatch. I suppose these two can be separated as their own gameplay modes.

Yeah, I already envision servers would display their game mode, for example like what’s displayed in the lobby as seen in the screenshot.

I think that’s a pretty common solution in multiplayer games, 30 minutes countdown until either team wins or lose and then match resets. No sensible matches should run beyond an hour anyway.

Well I agree, it’s not really true P2P in the sense that everybody connects to everybody but I see that these terms are usually used interchangeably incorrectly. So like P2P = player hosts and others connect, non-player hosted/dedicated = server in a datacenter somewhere which players connect to. I just put the client/server hybrid in the name for the distinction.

Indeed, a “middle-man” functionality of some kind is one my many points regarding the benefit of a main server.

Agreed, I think that’s also how supertuxkart does it. A sensible option à la FOSS style I guess. Though I seem to read somewhere that VPS services or similar cloud hosting services offer a global coverage. Well not really familiar with the business of how those really works but I assume that comes separately and is in a much higher price I presume.

And to be clear about the terms, am I correct by saying that a master server does not host games and so require separate servers to do that?

I think I’m not clear regarding the returning to lobby part, I meant that it’s exclusive to player hosted or private servers. In dedicated/public servers there will be of course no need for a lobby function at all.

As I’m still trying to understand networking in general, I’m afraid this goes beyond my grasp I’m comfortable with at this point, let alone writing your own custom protocol. Though I have a hunch that it might not be as difficult as it sounds…

1 Like
4

Well I think in programming discussions we should use the terms correctly.

In the game we can have a button called “host game” and in there some text warning that “embedded server performance is worse than dedicated servers” in the screen for setting that up.

Well server hosting companies offer servers in various different locations. So if we had a bunch of money to burn we could have game servers in 5, 10, or even more geographical locations. But I don’t think we really have that much money to burn on multiplayer so the people who’d host the community servers will get to pick where they rent their servers from and they can then pick a balance between distance to them and how cheap the servers are.

Yeah, I think it’s much better for performance and outages (due to high load or something) to have one server just being the master server. As the master server would get hammered quite a bit if each active game server would report to it that it is alive every few minutes and each player would whenever they want a fresh list of servers would ask the master server to send them the full list of servers.

So I think it’s much better to have a separate server that’s powerful enough to take that load as the master server. Our official game server would be hosted separately so that if that gets hit hard by high load it wouldn’t impact players wanting to play on community servers.

That sounds good.

It’s not that difficult. You just need to build an array of bytes that are sent as a packet and then code for understanding those bytes on the other side. The actual hard part is adding packet resending, acks, etc. but I’ve done that once and I could help with writing the master server side of things once the multiplayer is farther along and I’m not so busy.

1 Like
5

If you are looking to implement multiple variations of multiplayer game modes, then I believe that a simplified “quick-play” mode would be an excellent addition. It would grant players an option to compete with their peers without significant commitment of time or energy, as well as being minimally resource intensive for all sides. Though it may be a conflict with Kasterisk’s idea of a similar mode.

Game Rules:

The game would be played in rounds, the number of which could be selected before starting the session. Default would be something like 7. Players will choose their cell color from a list of pre-made colors before starting (Ensures players remain visually distinct and prevents camouflage).

Before each round, including the first, players will enter the cell editor to customize their cell. This works identically to base game editing with the exception of the membrane and behavior tabs being absent, and an optional timer to hurry players if they take too long.
Once all players have confirmed their changes, they will enter the game scattered throughout the arena, and must survive until only one cell remains standing (swimming?) to win the round.

Players will not be able to reproduce during the round, but reproductive compounds will still eventually increase their size and duplicate parts.

Changes made each round are cumulative, so as the session goes on players will become increasingly complex. This cycle will continue until all rounds are over, and the winner will be selected based on total rounds won.

Environment:

I think a sort of petri-dish/lab setting would be perfect for this as it believably confines players to a limited environment, the exact conditions of which can be tweaked before or during a session. Players could choose from a list of preset environments, including separate environments for each round, or customize their own using the variables below.

Different conditions would include

  1. Arena size
  2. Compound/chunk concentration and types
  3. Presence of AI cells
  4. Presence of chunk hazards such as toxins and ice
  5. environmental conditions such as light and temperature
  6. Presence of power-up granting plasmids
  7. Presence of editor cost reducing plasmids

Compounds in the environment will not be renewed, meaning that as the round goes on and players consume the available resources, compounds will become increasingly scarce until starvation becomes a significant issue.
This allows defenseless players the chance to outlast offensive competitors via resource attrition. Specializing to consume compounds such as iron and sulfide also increases the overall ability to outlast others by accessing more resources. Particularly devious players could even specialize in storage to horde compounds away from rivals.

Bonuses:

Bonuses are an excellent method of giving players a leg-up against others either because they are under-performing or simply to shake things up in the arena. In this mode, almost all bonuses will be acquired during play by moving into free-floating plasmids. Bonuses will be temporary, but can easily afford players an opportunity to turn the tide if they are not doing well.

There are three types of bonus;

Loss bonus: When a player loses a round, they are given the opportunity to delete up to two parts on their cell for free. This allows players to undo changes that may have otherwise sealed their loss in all future rounds.

Editor plasmid bonus:
Special plasmids that only take effect in the editor after the round ends. These can grant players with the option to replace one of their present parts with another random one for free. These will typically reward organelles that cost more than 50 MP.

Power-up plasmid bonus:
Power-ups are temporary effects that exist to keep players on their toes. The typical duration is around 10 seconds, with some exceptions. The many forms of power-ups are listed below.

  • Speed-boost: Increases speed by a flat amount. Insignificant for fast cells, incredible for slow ones.
  • Size-boost: Increases cell scale by 25%, potentially turning the tides on engulfment.
  • Agent-boost: Completely fills available agent storage for all agents.
  • Armor-boost: Provides 25% damage resistance.

Synopsis

This game-mode provides a purely competitive setting free of long-term simulations and distractions, allowing players to focus purely on outlasting their peers through multiple means in a manageable amount of time. All the while, it preserves the overall theme of evolution and survival of the fittest!

Unfortunately I fear that the development of such a game-mode may present an intensive amount of effort to produce due to the large amount of mechanical deviation from the base game. It may be much easier development-wise to pursue Kasterisk’s concept for an arena mode.

I won’t be upset if this concept never sees fruition, I just really appreciated the chance to pursue more familiar concepts of game design.

1 Like
6

This is pretty close to what I had in mind for the cell battle arena gamemode.
My idea for how the game rules would be is quite similar but there wouldn’t really be rounds, so players would just get dropped in and after some number of kills or time they’d get editor credits to edit their cell. On top of that there’d just be like a number of kills leaderboard. Really basic stuff, so I appreciate someone thinking through how to make the multiplayer mode more of an actual game. Though, I must say I have a bit of criticism about the round based approach as I still don’t really like that (for example I never really got into CS:GO due to the round based nature but I’ve played plenty of team deathmatch FPS games where you don’t need to wait for a round to end). So I’d personally want to see some other approach to that part of the design. Of course if we end up with multiple game modes that are all fun / enjoyed by different player segments we can have slight variants.

One thing to note is that compound cloud synchronising over the network is going to be the most difficult thing. I don’t think @Kasterisk got there yet, but the sheer volume of data there makes it very hard and I only foresee a strategy game kind of approach, where only the changing actions are broadcast and each client simulates separately, is doable.

So my idea with the cell battle arena was actually to forego compound clouds to make it easier to implement.

Other than the bonuses and balancing, I think an arena mode with just a few changeable parameters is easier than the microbe stage itself (see my point about compound clouds above).

2 Likes
7

I personally have a high preference for round-based play as it gives players an opportunity of down-time to think about their strategies, or get up to do something like get a snack without fear of falling behind.

It is of course, largely a matter of opinion.

1 Like
8

I like that, basically a fleshed out design for the actual arena gamemode that I misattribute to my general microbe stage multiplayer concept. More fast paced and with no slow simulations.

Regarding rounds, I don’t know, I feel like this can be made as an option so people can play either with or without it.

Oh yeah, It’s also one of the thing I dreaded, I can already imagine some poor server getting bogged down simulating not one but multiple compound cloud planes in various places with my gameplay concept…

Well, it’s the ultimate goal but I don’t see why we can’t implement the minimally intesive arena gamemode first as I agree that it could be relatively the most feasible out of all.

2 Likes
9

That’s not even the worse part. If I calculated right the server needs multiple megabytes of bandwidth for each player (and of course each player needs multi megabyte internet connection as well). Because of that things get ridiculous with tens of players so only servers with gigabyte internet could host tens of players.

So in my opinion that is entirely undoable. So we need some really smart scheme to cut down like 95% of the data that exists in compound planes. And doing what strategy games do (only send commands like absorb this amount here, place this cloud blob here) is the only way I came up that might work.

This is why I always thought that the cell battle arena mode should be the first multiplayer thing as it would be much more doable than the full microbe stage.

2 Likes
10

Continuing on polishing out my full microbe stage multiplayer concept.

After thinking about it further, gameplay might actually be combination of PvP and co-op. There’s no stopping people to work together, among others maybe they’ll form a pseudo-multicellular organism of some sort and take on the world. Just like “clans” in some games, or a much pleasant comparison: the emergent gameplay of agar.io where not only you just devour and conquer, there’s a mechanic in place to allow beneficial interaction between players.

I’m a bit on the fence about including AI cells for PvE. Firstly I think they’ll take up a fair amount of processing power on top of the networked players, and secondly they could potentially distract the focus away from the novelty of actually encountering and engaging with others since I predict encounters won’t be as often. Though this means signaling agents and binding agents will be useless (unless there’s a way to make them work here).

And one more important thing that I forget, a boundary in the environment. Without it, people would just go infinitely away from each other. As some games have done, we could add a simple circular boundary and this necessitates a map display in the HUD so players know where they are relative to the world boundary and predicts where others are.

Now, regarding the arena game mode. The game rounds as proposed by Buckly might actually be necessary. You can’t evolve midgame, thus solving the timescale problem and giving a more balanced game which is perfect for the quick-play concept, it just makes sense for the game mode. For no-round based approach that’s basically my original microbial multiplayer game mode.

Also, I’d like to add one more to the list of bonuses.

Starting mid-round bonus: Assuming this game mode allows players to join after game has started, joining players are to be granted extra 50 MP to account for the rounds missed. This bonus will only be valid after the first round.

1 Like