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

Re:How we built an auto-scalable Minecraft server for 1000+ ... by Jaxkr on Saturday September 04, 2021 @05:34PM (#28419480)

Thanks for your question! Redstone is still WIP but will follow:

1. An optimistic execution strategy (the servers can run their own redstone)

2. A locking system allowing only one server to have redstone current in a given chunk at once.

3. A rollback-based system to repair race conditions caused by (1)'s optimism.

Hostile mobs are ALSO still WIP and:

1. Are only synced if two players are near each-other on two different servers.

2. Have their aggression entirely managed by a WorldQL script which sends messages to the appropriate servers instructing them to call LivingEntity.setTarget on the correct player.

Was hoping nail those both down before I shared it here, so please forgive me! Thanks for your interest and stay tuned.

[ Parent | on HN ]

Re:How we built an auto-scalable Minecraft server for 1000+ ... by L3viathan on Saturday September 04, 2021 @07:36PM (#28420406)

Re (2): Wouldn't that cause wonky redstone behavior on chunk borders?

[ Parent | on HN ]

Re:How we built an auto-scalable Minecraft server for 1000+ ... by the_gipsy on Sunday September 05, 2021 @04:35AM (#28422520)

I think it’s almost impossible not to break redstone.

Perhaps two chunks/servers could communicate fast and precise enough for redstone.

But Imagine the corner of a chunk receiving updates from two different servers.

[ Parent | on HN ]