How we built an auto-scalable Minecraft server for 1000+ players • Hacker News Board

Re: How we built an auto-scalable Minecraft server for 1000+ players

#41

Post by Uyuxo » Sat, Sep 04, 2021, 11:17 PM UTC

8note wrote: post #37

forrestthewoods wrote: post #28

Earlier quoted context omitted.

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…

Couldn't Minecraft chunks run fairly independently, with some message passing when something needs to move between chunks?

Did you read the article

Re: How we built an auto-scalable Minecraft server for 1000+ players

#42

Post by 7373737373 » Sat, Sep 04, 2021, 11:20 PM UTC

63 wrote: post #21

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 li…

> is there really anyone who wants 1000 players on the same world

Of course! One of the few games that is massively multiplayer all in the same persistent, connected world is Eve Online, and the dynamics that arise from its economy and faction warfare are fascinating!

Re: How we built an auto-scalable Minecraft server for 1000+ players

#43

Post by eropple » Sat, Sep 04, 2021, 11:27 PM UTC

ianhawes wrote: post #22

cdev_gl wrote: post #12

Earlier quoted context omitted.

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.

Have you noticed much difference between a HotSpot-driven JRE and OpenJ9?

I am somewhat irrationally biased against J9 because they made us stick it in everything at IBM, but I'm willing to reconsider for better Minecraft performance.

Re: How we built an auto-scalable Minecraft server for 1000+ players

#44

Post by JCharante » Sat, Sep 04, 2021, 11:30 PM UTC

7373737373 wrote: post #42

63 wrote: post #21

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 li…

> is there really anyone who wants 1000 players on the same world Of course! One of the few games that is massively multiplayer all in the same persistent, connected world is Eve Online, and the dynamics that arise from its economy and faction warfare are fascinating!

also Planetside 2, think Battlefield (the FPS) but way bigger map (around 8kmx8km I think)

Re: How we built an auto-scalable Minecraft server for 1000+ players

#45

Post by kaolabear » Sat, Sep 04, 2021, 11:30 PM UTC

I had the impression that most of the server's cpu time is used for simulating the game's content, not the players themselves. Most of the available cpu time is usually spent on monster AI and monster physics.

I assume that WorldQL is also used to store monsters besides the blocks, otherwise my understanding is that players cannot interact with monsters from other servers. Is it possible to create redstone circuits on different servers that then interact with each other?

Re: How we built an auto-scalable Minecraft server for 1000+ players

#46

Post by JCharante » Sat, Sep 04, 2021, 11:32 PM UTC

bruce343434 wrote: post #35

Thaxll wrote: post #29

Earlier quoted context omitted.

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?

They also call servers not being able to keep up and thus the gameloop slowing down "tidi" (time dilation). Like yeah, that's just what happens when a gameserver can't keep up.

Well no, TIDI had to be added in. It's purposefully slowing down in-game ticks.

Normally your requests would just be dropped if it had to process everything within a 1s tick. Now all reload times etc get slowed down by a huge factor depending on load.

Re: How we built an auto-scalable Minecraft server for 1000+ players

#47

Post by L3viathan » Sat, Sep 04, 2021, 11:33 PM UTC

kaolabear wrote: post #45

I had the impression that most of the server's cpu time is used for simulating the game's content, not the players themselves. Most of the available cpu time is usually spent on monster AI and monster physics. I assume that WorldQL is also used to store monsters besides the blocks, otherwise my understanding is that players cannot interact with monsters from other servers. Is it possible to create redstone circuits o…

Near the end of the article:

> We're planning to introduce redstone, hostile mob, and weapon support ASAP.

Re: How we built an auto-scalable Minecraft server for 1000+ players

#48

Post by devoutsalsa » Sat, Sep 04, 2021, 11:34 PM UTC

kevingadd wrote: post #39

8note wrote: post #37

Earlier quoted context omitted.

Couldn't Minecraft chunks run fairly independently, with some message passing when something needs to move between chunks?

Yes*, but players build complex machinery fairly often that can span chunk boundaries, so that requires synchronous coordination between the chunks for those machines to work right.

When will players learn to parallelize their simulated DOGE coin miners?!

Re: How we built an auto-scalable Minecraft server for 1000+ players

#49

Post by inyorgroove » Sat, Sep 04, 2021, 11:34 PM UTC

Jaxkr wrote: post #6

Hi, 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.

Does this solution handle PvP style play? Interesting project, keep up the great work!

Re: How we built an auto-scalable Minecraft server for 1000+ players

#50

Post by tialaramex » Sat, Sep 04, 2021, 11:36 PM UTC

mysterydip wrote: post #5

crazy_horse wrote: post #4

How did MMOs like Asheron's Call and Wow handle this?

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…

Yeah, WoW's combat is effectively just a MUD, to the extent your position matters it's only very approximate even though the animations look much more precise. The Darkmoon rabbit fight made this extremely obvious, because the mob is tiny (it's just a rabbit, it's a reference to The Killer Rabbit of Caerbannog in Monty Python and the Holy Grail) but it's a public fight with potentially dozens of people trying to attack this rabbit at the same time with huge swords and casting spells and stuff, which looks completely ridiculous, but it's a joke so, it's OK that it's silly.