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.
Most of Minecraft's server load is mediating interactions rather than sending the world at first. The base process of chunk loading gives you a 20x20 chunk (over 26 million blocks), centered on your player, on joining a server. All of this in seconds, usually! Computers are absolutely ridiculous.
After that, modifications are handled by Block Updates and Block Entity Data messages and so on. On the innocuous side, this avoids player desync, and doesn't waste bandwidth on telling you what's happening miles away. On the less innocuous side, I'm suspicious that wiki has a vested interest in client hacks; the server rejects clients' attempts to break blocks or damage players across the map. Point is that the server load cannot easily be reduced by smarter loading/unloading.
Coincidentally, you've stumbled upon one of the main reasons Star Citizen is a giant black hole of money.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link