The Minecraft setup will be available and useable by anyone Wednesday of next week. More documentation and a roadmap will follow shortly after.
While developing this did you come up with any best practice recommendations for individual nodes?
For vanilla, I’d try Paper (a high performance spigot fork) and see if you still have problems. If you’re lagging with 6 people while running Paper, you simply need a better CPU.
You can spin up a 4 core 24GB instance, the CPU is 4 dedicated cores and quite fast.
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.
I run my server on a 32GB Ryzen5 PC with the world on an SSD and it often struggles with just 2 players no matter what options I tweak. Keep dreaming of the day the Java parts get the same performence as the Bedrock parts (but I know it'll likely never happen.)
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.
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".
This is super interesting and I'm excited that someone has finally made real progress on distributed game world software
Could you elaborate on this point? To me "need" seems to strong; it could also be addressed via replication or a distributed model.
Centralized is absolutely the most straight-forward (and may be the most suitable) but I'd love to see some reasoning as to why it's the only appropriate approach.
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.
I made a custom minecraft proxy (similar to bungeecord but A LOT less resource intensive) that starts the real server when someone attempts to connect to it.
200 lines of go for the proxy and about as much for the http front end in django :).
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 requirements are reduced compared to a first person shooter for example.
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 to actually see other players.
There was also a feature where you could party up with a friend on a different realm and you would transparently be playing on their server in the open world (with restrictions like not being able to trade with them).
I haven’t played WoW since Mysts, so I don’t know how it’s changed since, but WoW was definitely more complicated than just sharding and instancing.
In private servers using code you can look at (Mangos) they manage to run 4000+ players on a single gaming-spec machine without much trouble. Its more of a design problem compared to something like minecraft where the simulation is much more detailed. In some research projects for wow private servers people have reached 20.000 simulated players in a given machine.
> Here's a demonstration showcasing 1000 cross-server players, this simulation is functionally identical to real player load. The server TPS never dips below 20 (perfect) and I'm running the whole thing on my laptop.
If it can run on one laptop, why does it need horizontal server scaling? :P
You don't really know where the bottle-necks are until you put 1000 actual players on the same "server".
What do you mean by holy grail? Is it not something that's already accomplished by several games/MMOs?
Unless "spatial MMO" means something specific here.
It's also about he level of trust you are willing to give the clients, you can for example offload all logic to the clients and just have the server broadcast all messages. But then you will have a problem with cheaters that use modified clients.
The same "holy grail" exist in database too, where you want low latency, high throughput/concurrency, and high availability. Where the solution is, just like in "MMO" games, to use "sharding".
1) Battle of B-R5RB in Eve online had 2,670 players on the same shard according to WikiPedia. Their solution to the problem was/is to lower the game physics tick-rate.
That demo is primarily meant to demonstrate the efficiency of the message broker and packet code as if there were 1000 players on different MC servers all forwarding their positions through WorldQL. I’ll make it more clear.
Mojang have not yet added a "transfer packet"[0] which would allow for region-based switching.
For the most part, one would need to re-join the server under a different proxy pool located in their desired region, usually accessible via a subdomain (us.example.com, eu.example.com)
[0]: https://hypixel.net/threads/why-do-we-need-transfer-packets....
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!
After a few years it attempted a re-launch using an approach similar to to the first one mentioned in the article. There were multiple worlds and as you approached the border of one world it would teleport you to another adjacent world. It was cool, but was jarring and suffered from its own complexity issues.
Anyway, this project is super cool. I would have loved to see something like it 10 years ago.
> a victim of its own success due to the large player count. It would often have 250+ players who would build these massive redstone machines
I always thought the redstone restrictions resulted in too many bots.
I’m writing up some formal documentation on it now, I really wanted to have that done before this project was exposed to the scrutinizing Hacker News community, but I can’t control what people share! :)
Stay tuned.
Server boundaries could move based on where the population is via delaunay triangulation (instead of fixed boundaries), and servers could share high-importance information with their immediate bordering neighbours. (This would be recognized as ghost data on the neighbouring servers.) You could even go further and have neighbours share ghost data with their other neighbours at a lower fidelity/frequency.
A virtual distributed actor system could potentially be used to address any potential downtime or resource waste created by unpopulated zones.
I've been playing around with some of these ideas but haven't been able to turn them into an actual implementation, so kudos to you for actually doing it!
This new approach was primarily made because I thought it would be fun and cool :P
[1]: https://www.brailleinstitute.org/wp-content/uploads/2020/11/...
However, once the documentation is complete, someone could hypothetically implement it using https://github.com/magmafoundation/Magma-1.16.x
It would be cute if Azure credits could be paying for a VM that's just running Compact Machines I never visit the inside of anyway, while the places my character actually goes are running near me. For example, once you've built it, who visits the inside of that first Compact Machine in Claustrophobia that's just a self-powering battery full of uranium, water and thermoelectric generators? You'd drown in there anyway if you visit for more than a few seconds. But it still needs simulating.
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.
There is something not quite right. 1.7.10
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?
> We're planning to introduce redstone, hostile mob, and weapon support ASAP.
>redstone, hostile mob, and weapon support
Aren't these the slow things? Is it just player position and map data that's synced through a central DB? I would assume the bulk of the work isn't done yet.
I could see this really changing how users interact with each other.
Was this all on top of a 9 to 5?
