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.

3 Likes
0.6.4 Release Planning
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 ASP.NET Core, an open-source web development framework | .NET 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
11

I found this ancient thread on here, and I found the idea pretty interesting, especially because multiplayer games/gamemodes tends to attract a broader player base. As of today, I’m aware the idea has been overall discarded due to the massive hurdle of multiplayer systems, including the technical difficulties, which would likely divert attention from the more important milestones in the development of the actual game. Still, I found this worth an analysis, so I’m putting my idea of a multiplayer prototype here.

Multiplayer as online arcade gamemode

My idea of multiplayer is to have a fun, fast-paced gamemode. The most appealing prototype would be, just like discussed in this thread, in the microbe (and perhaps multicellular) gamemode.

Basically this.

This would ensure fun lobby gameplays with a basically endless replayability and different meta.

Technical issues

I wanted to reply to this thread particularly to talk about the technical details of this, to add actual useful info, hopefully.

Reading about Godot’s Multiplayer features, they have substantially improved in Godot 4, so that’s especially a good thing.

I believe that using Steam IDs for steam players makes this kinda trivial. There’s a Godot plugin for that, but even if we were to implement it ourselves, it’s not a huge work to make a wrapper. Most indie games use this as a solution if they cannot host their own servers.

I believe the modern ENetMultiplayerPeer implementation in Godot is extremely flexible on this regard. Multiplayer in Godot 4.0: Scene Replication – Godot Engine

I had this concern as well, but clouds are fully deterministic. So, sending “cloud spawned” commands and deltas instead of the whole clouds.

This could be good too, for example eating dots instead of clouds, again like agar.io or similar.

2 Likes
12

In my opinion, any multiplayer we do should just be the full, regular game, which is obviously harder, but a cell arena battler feels too far from the idea of Thrive to me, so it seems more like a minigame based on Thrive. Making a cell arena battler wouldn’t be bad, especially if it’s mostly meant to keep players engaged while the rest of the game is worked on, but if this is low priority anyway and won’t be worked on until the Macroscopic stage is finished, why not just go all the way and make a true multiplayer Thrive? Then, people could have the wonder of evolving their creature and shaping their world alongside their friend or family member.

I know there would be some weirdness keeping things synchronized, but I don’t think anyone playing Thrive with a friend or family member would complain if we added these two restrictions to help. It’s not like it would be a competitive experience, anyway.

  1. The editor isn’t entered until all players choose to enter it, so everyone has to get enough ammonia and phosphate to enter the editor before the next generation starts. Players who click the editor button earlier can either keep playing or they can spectate another player
  2. Each stage transition can’t happen until all players meet the requirements. Players who meet the requirements early get to just keep improving their organism using the tools available to them in their current stage

If I’m wrong and there’s high demand for the cell battler approach, then never mind, but I don’t think it would appeal to the same general audience as the audience Thrive itself appeals to. The Thrive super fans will play it because they just want more to do in Thrive, but I wouldn’t expect the average person who picks up Thrive on Steam to be interested in that. In my opinion, multiplayer in Thrive should be all or nothing.

1 Like
13

Imo, as been discussed in this thread already, most of the features either clash with the gameplay or with a multiplayer system. For example, the current gameplay is entirely built around the idea that Thrive is a single-player game, so things such as the ECS, the clouds and physics are technically borderline impossible to implement for a multiplayer game. As for the gameplay, the following quote kinda summarizes it:

This is actually a good idea imo, because it would quantize the timeline when everybody agrees with it. And maybe have a timer (e.g. a couple minutes) that counts down since the first one decides to enter the editor.

To be fair, having an early simple arcade arena gamemode that works on top of a modified microbe stage would still place the foundations for a future full multiplayer mode like the one you described. In some way, having such a foundation would still be beneficial for the future, if said future does include multiplayer.

No, and on that I agree with you. It’s more like a good complement to the current game for players to test their own evolutionary strategies against others, competitively. After all, the whole concept of Thrive would be unchanged, that is evolving to thrive in a competitive environment. It would just be self-contained in a single stage and shorter lived in terms of gameplay.

1 Like
14

This is a good point, if the arena gamemode is considerably less work than a full multiplayer implementation. I just wonder, once we have the groundwork for multiplayer in place, how much easier is the arena mode compared to full multiplayer? For full multiplayer, you’d only to support up to like 4 players at once to make people happy, which is much fewer than you’d need in an arena, and we wouldn’t have to worry about adding new features to make the arena fun.

The arena definitely could still be easier because there’s probably something I’m missing, I’m just not sure what that is yet. Reading through this thread, it seems like it was started with the assumption that the arena mode is easier, so I wonder if there had been discussions somewhere else about it first.

15

I’m not sure because even though I have some experience with multiplayer programming, I don’t have a well defined plan for Thrive. It really depends a lot on how the arena mode would be implemented, which requires a good amount of game design decisions (e.g. what to use instead of clouds, how will the round system work etc…). I’d expect the base multiplayer systems to take a few weeks to implement, and then maybe a couple months to have a fully working prototype. But again, I’m just speculating here. Without a real plan it’s hard to estimate.

It would be simpler probably because it’s bounded (or toroidal, e.g. you teleport from left to right, top to bottom and viceversa), predictable and consistent. Easier is also avoiding using clouds.
Basically a Thrive microbe stage-lite. Also, for game design reasons, hh quote:

1 Like
16

While maybe fine, I would really hate to lock Thrive multiplayer to be Steam-only.

So I think we need a more flexible account identity system where both Steam and Thrive accounts can exist and join the same games.

We do not use Godot at all for gameplay logic. So I don’t think that’s good. Instead our C++ module should add GitHub - facebookarchive/RakNet: RakNet is a cross platform, open source, C++ networking engine for game programmers. · GitHub as a networking library. I believe that even though that hasn’t been updated for a while it or one of its forks might still be the best one around.

I think that making a cell battle arena will make a future, potential, full game multiplayer mode more likely to happen at all.

May orders of magnitude easier.

In fact Kasterisk made a prototype of the multiplayer battle arena and it kind of already worked. Though it was never completed, and it was before the big ECS refactoring so I doubt it has that many still useful implementations in it.

2 Likes
17

I would also hate that, but a Steam authentication would bypass the uPnP hurdle (using the Steam Datagram Relay), which on some networks is straight-up disabled (I had this very issue with my old provider). So, I see Steam as a “multiplayer without issues” mode, but I’d keep a fallback using a Thrive account or even a guest mode where you can create a one-time server protected by a password, like many games do. But, of course, hosts without uPnP may be locked away from the feature.

I’m fully aware. But Godot’s ENet implementation supports any arbitrary protocol, even streaming our own serialized data which is completely unrelated to Godot’s objects. I think we would be better off using something that’s already in Godot, is stable, and is maintained, rather than RakNet which is unfortunately abandoned (so it’s more code to maintain in case of vulnerabilities, which I think is bad).

I agree with you here.

1 Like
18

We should anyway host our own STUN service and a server list. So I don’t see this is a major problem.

The GitHub - Revolutionary-Games/RevolutionaryWebApp: Web apps with features for Thrive development · GitHub would be the perfect place to put it assuming player counts are reasonable enough to deal with the server load.

1 Like