Impressive work! There's a lot of potential here, but probably within a pretty limited market. Outside of 2b2t and maybe Hypixel, is there really anyone who wants 1000 players on the same world? Is the small market the only reason why a solution like this hasn't been created before, or are there bigger complications that aren't listed or haven't come up yet, or maybe the technology wasn't available? Surely someone like Hausemaster who stands to gain substantial amounts of money from this has looked into it before, right?
How we built an auto-scalable Minecraft server for 1000+ players
21–30 of 145 posts
Re: How we built an auto-scalable Minecraft server for 1000+ players
#22Hi, I made this! Was gonna wait until it was downloadable and the documentation was more complete before posting it on HN. Thanks for sharing it though. The Minecraft setup will be available and useable by anyone Wednesday of next week. More documentation and a roadmap will follow shortly after.
I rent a small Linode to run a minecraft server for my extended family. Sometimes it struggles to keep up with just a half dozen of us, and when I tried swapping from a spigot based system to a forge one so the kids could have mods it was basically unplayable. I can't imagine scaling out to thousands of users, this was some amazing work. While developing this did you come up with any best practice recommendations for…
What were the specs of the server and which Spigot fork did you run?
A month ago I ran a Paper instance from a Digital Ocean instance with about 4 GB of RAM and OpenJ9 JVM and it never dipped below 20 TPS even with a larger render distance. This was on Vanilla 1.17.
Re: How we built an auto-scalable Minecraft server for 1000+ players
#23Interesting timing.
I play with a few friends on a modded 1.7.10 server and we’ve decided to restart with 1.16 due to the lag having become untenable.
We run it on an i7 machine at my house dedicated to it, so it’s not a hardware issue.
Like clockwork the server would freeze for about 5s about every 30s. Using opus our best guess is that it’s unloading chunks and the GC is happening.
We’re going to run 1.16 now which I hope has some performance enhancements and so that we can use more modern Java 16 runtime with its nicer GC systems.
I’m also hoping that Minecraft has at least since moved chunk generation off the main thread since there was no good reason for world exploration slowing down things like it did.
I also built a JavaScript redstone simulator website and I’m curious how you will handle that and other block updates at server boundaries.
Re: How we built an auto-scalable Minecraft server for 1000+ players
#24How did MMOs like Asheron's Call and Wow handle this?
If you look at the developer blogs for EVE Online, you'll have endless reading about massive scale multiplayer servers. Possibly the most technically impressive massively multiplayer experience
Re: How we built an auto-scalable Minecraft server for 1000+ players
#25Earlier quoted context omitted.
This is very impressive work! Do you plan to make WorldQL highly available? It seems like if it died you'd loose the server.
Thank you for your kind words! WorldQL uses Postgres under-the-hood to store permanent information. I was inspired by companies like TimescaleDB which build new functionality on top of Postgres’s rock-solid base. Any high-availability solution for Postgres will also be available for WQL.
Do the clients of WorldQL (the workers) know how to gracefully fail over when WorldQL fails?
Re: How we built an auto-scalable Minecraft server for 1000+ players
#26Earlier quoted context omitted.
For WoW, at a very high level, instancing and sharding. Players are spread across realms. The zones are so large that by nature players will be spread out leading to less interactions. Raids are instanced to just your party. In areas with natural congestion (such as auction houses), things could lag at times. While combat and movement is realtime, it's mostly waiting for timers, so the latency and bandwidth requireme…
With WoW they would obviously run each continent as an independent “instance”, but for Wrath, they clearly had multiple servers handling Northrend. There were places where mobs would not path over which was where the two “instances” would overlap. WoW later introduced a kind of dynamic overlay of the same open world area from two realms where it was not very populated in the area so that players would be more likely…
You're correct, I was referring to vanilla WoW which is all I played. It has definitely evolved since then, thanks for the info!
Re: How we built an auto-scalable Minecraft server for 1000+ players
#27Just to clarify, WorldQL is hosted-only software, right? No on-premise? If I tie my game to WorldQL, do I have any options if WorldQL goes under (other than re-engineering everything)? Not to diminish the impressive work on display here - I've just been wondering this since I saw your r/gamedev post.
Re: How we built an auto-scalable Minecraft server for 1000+ players
#28Hi, I made this! Was gonna wait until it was downloadable and the documentation was more complete before posting it on HN. Thanks for sharing it though. The Minecraft setup will be available and useable by anyone Wednesday of next week. More documentation and a roadmap will follow shortly after.
Is there a specific reason why Minecraft hasn’t been “adapted” from the original game to a robust design that could scale to larger worlds and player populations before your project ?
Pretty much no video game engine scales with cores. There are too many dependent systems. There's no game engine that I'm aware of that effectively uses more than a couple of cores for gameplay simulation.
Distributed physics is a well understood problem with no "solution". Just different trade-offs. This solution is cool, but it's not novel or anything. Minecraft is particularly challenging because the entire world is highly mutable.
There are no general solutions to any of this. Just a bunch of custom one-offs. SpatialOS is trying. My opinion on it is extremely, extremely negative. And I'll leave it at that.
Unity and Unreal both have primarily single-threaded gameplay. Writing multi-threaded gameplay code is extraordinarily difficult. Unity has been working on their DOTS/ECS system for years, but it does not appear to be close to ready for the mainstream.
So I think the short answer is "it's really really hard. Like, radically harder than you are imagining. Even if you think it's hard. The value of that work is likely not worth the cost. If most players WANT to play on small servers with close friends then the mountain range of work to effectively support a 1000 player server is not worth it".
Re: How we built an auto-scalable Minecraft server for 1000+ players
#29How did MMOs like Asheron's Call and Wow handle this?
If you look at the developer blogs for EVE Online, you'll have endless reading about massive scale multiplayer servers. Possibly the most technically impressive massively multiplayer experience
EvE is one of the worst architecture for an MMO, there is almost nothing to do and yet they need to slow down the simulation loop when there are too many players. I mean when you gameserver is based on Python what else can you do?
Re: How we built an auto-scalable Minecraft server for 1000+ players
#30Love the font on this site. Looks like you can find it here: https://brailleinstitute.org/freefont