Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?
This is your opportunity to ask questions. No question too simple or too silly.
Culture war topics are accepted, and proposals for a better intro post are appreciated.
Jump in the discussion.
No email address required.
Notes -
How difficult would it be to distribute the regions of one large online Minecraft world across different servers, to allow for a player count in the 1000s? I watched some videos on the infamous 2b2t server, and am surprised no one has created a maximal case survival server.
There are projects attempting to handle sharding, with various levels of success. Splitting at a level of dimensions or some similar loading screen isn’t trivial (mostly due to player-level data), but it’s doable without massive modifications. Hypixel runs a particularly minimalistic variant, with the mini game servers not really sharing much excepting bungeecord links and authentication, though the line between ‘server’ and ‘proxy network’ gets very blurry here. Velocity is another proxying setup used here, and one I can recommend.
Splitting or proxying requests in a single dimension or, worse, very near to other players, is much harder. Mammoth seems the most promising in dev option, but it’s a space filled with the graves of promising projects.
Oh this is very cool. I’m confused why there’s not a massive server already running this? The demand would be nuts because 2b2t has a queue time of up to 10 hours. If it had no queue time would surely have a concurrent player base of 1000+ at times. This has a compound effect where the more concurrent players, the more popular it becomes, due to how content is proliferated on YouTube.
What I was considering, just as a fun daydream, is the implementation of good game mechanics to mitigate individual server load bearing. Special “rugged” terrain to deter building in the between zones of servers (super hot desert, super cold mountain, dangerous waters and so on); a “you’re feeling tired, stop and rest” feature while the game loads in the content for a new server, as a replacement to the normal hunger meter; an enormous spawn radius; a “main city” where things can’t be built and activities are limited.
I don’t know much about how MC servers work, but I also wonder if you can have players download on the client-side the blocks of the map within 4000 blocks from their location upon spawning, but only the blocks that the server reasonably predicts are unlikely to be modified/deleted (blocks under water, etc). You can have a player spend a minute downloading this information before each spawn; maybe this is 5min downloading the first time, but because little usually changes day by day it’s only 10 seconds next time. Wouldn’t this significantly cut down on server load because the server then only has to serve the newly modified/deleted blocks and can ignore everything they the player(s) is processing on his own computer?
I’m just really surprised we don’t already have some amazing 3000 concurrent Minecraft survival server.
Bungeecord/Velocity-based servers exist, and to an extent Hypixel is a thousand+ server location, but in turn it's further from what you're probably imagining. More complete solutions take a lot more technical lift, and Mammoth in particular is still very much a work in progress (the issues page lists a variety of bugs related to explosions and gear), and there's a variety of technical limitations.
Similarly, there's a pretty good number of mods or plugins for most environments that can do at least the spawn protection and distributed spawn solutions. They've got tradeoffs -- too large a spawn radius makes it hard to meet up with friends, too large a protected area breaks a number of technical builds and can encourage players to play more soloish than the might otherwise -- but there are mods in turn to try to mitigate those (such as chunk claiming, to-home and to-team teleports, etc).
((You can't go too far, here; MineCraft isn't the most secure, but for the most part it tries to not trust the client, so you're really stuck doing a lot of parallel processing on the server for things being sent to clients. But this actually doesn't end up being that big of a deal: from a mod developer perspective, short of things like Create Contraptions or Structurize Build actions that trigger massive changes and thus full chunk reloads, the update system netstack mentions is generally controlling, and you're usually more worried about stupid issues like pathfinding or lighting updates or just entity cramming. And the cost difference between transmitting a chunk and a part of a chunk aren't as big as you'd expect.))
It also only solves part of the problem. A lot of the issues with Minecraft scaling have less to do with distributed world state, and more to do with issues specific to individual server architecture, like packet overhead of keeping player experience of other players consistent. See for example BlanketCon, a (fabric modded) convention that was able to get into the mid-170 simultaneous players that more closely emulated a crowded environment that avoided block updates, and found that much of their performance was being taken up by movement synch. That's solvable -- the BlanketCon post-mortem describes a couple shard-based solutions, and I'm sure an actual game dev like Zorba could list well-established true fixes -- but it's probably just one of a few dozen that you'd need to go through on the way to handle 1000+ users in a small city, rather than 1000+ users who barely see each other.
((Some of these are stupid. Leads and redstone mechanics can be giant TPS problem sources, and there's known fixes for them, but they're not fixed in vanilla.))
The deeper issue is that vanilla MineCraft isn't really built for large-scale deployments, at more than a technical level, and this has lead to little interest in developing megaservers beyond the borderline (Hypixel) or the academic.
Some of the problems of 2b2t are specific to its intended userbase and (lack of) gatekeeping -- you could conceivably decide to stop people who make region-sized lavacasts, then rollback the affected chunks, and even automate doing so. But the broader problem of creating useful and enjoyable communities is hard. It's very easy for a server to have a whole bunch of people individually log in, go through the standard iron-diamond-nether-end progression, and build a couple small 9x9s, and then log out; not only does this not necessarily entertain much, it doesn't really work out that well with a lot of the bottlenecking in vanilla (the Ender Dragon's island is a hard bottleneck, and to a lesser extent so are strongholds, nether fortresses, and end cities; someone else having visited one before you doesn't break your game, but it does end up being really annoying; material values and preferences for certain surface features tend to push people to certain distances from each other that end up getting negated by nether rooftop travel, so on).
Longer-lived communities tend to combine a mix of events, contests, and challenges. But these can be hard to scale well, too.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link