419 points | by alex_medvedev2 months ago
Given the size of the game, it's not an easy feat to build a Minecraft server in any language. Yet there are seven, in just Rust alone??
I suspect the hard part would be getting total parity with all the undocumented intricacies of mob spawning and AI, and block interactions. But if there are slight differences from Vanilla this isn't necessarily the end of the world for players. Popular server mods like Paper already tamper with some Minecraft "features" in an opinionated way and for the most part players don't notice.
Mob spawning and behavior shouldn't be that difficult, but if you want identical terrain generation you are going to be cursing life.
What would really make a third party server stand out is first class mod support.
Better performance is almost a given. Minecraft's engine has a lot of low hanging fruit that has yet to be picked despite it being theoretically a multi-billion dollar game. Just look at how shockingly CPU hungry hoppers are for example. Mob pathfinding also consumes an inordinate amount of resources and is still kinda lousy.
I get it has lots of computing to do for something like a server with large players, but even a server with a small amount of players that's technical focused can easily bring the game to a crawl.
Its funny how the best way to get great performance from Minecraft is getting a CPU with great single core performance, get lots of memory, and then use fabric mods to optimize the game/server.
I don't see it listed, but is there support for block breaking/placing yet? Presumably this would require light recalculation and a chunk update on the server.
Finally, do you plan to add advanced features like scoreboard, teams, or command block parsing in general? Mojang has at least open-sourced Brigadier for that.
Cool project. Hope to see it mature to the point of making servers easier to run on low-end hardware.
Yep block placing and breaking is already supported, but light currently don't so everything is dark :/, We are working on it. Yep, We want to add all cool features like scoreboards, teams and we already have a API which is similar to use to Brigadier for our Commands.
Thanks, I would love to give players on low-end hardware the possibility to host servers. I think i may test Pumpkin on a raspberry PI or something one day
Mojang made large improvements to the lighting engine in 1.20, bringing it in line with the performance mods Phosphor[1] and Starlight[2]. Despite being deprecated now, they might still offer some useful insight into how to approach such a system in a performant way. You'll need to be mindful of the licenses, but it's likely easier than reverse-engineering Minecraft (even with mappings).
I think Minecraft server re-implementations are pretty neat and I like to see when a new one comes out. There are also specific purpose server impls like MCHPRS for doing fast redstone compilation for technical minecraft.
I know Minecraft servers tend to get extremely resource intensive as the player count creep and people run extremely beefy servers to handle the load and still offer poor TPS.
Wow. Pumpkin's runtime is way better (faster, much less RAM used) than the Java versions. Congrats.
I wonder what the Kotlin-based Minestom is doing differently that causes it to have numbers between Pumpkin and the Java versions.
For comparison's sake, do you have build times for Pumpkin? I'll assume that's where critics may target.
How bad could it be? I cry while async-stripe crate builds.
Compiling from Nothing
*Debug:* 10.35sec *Release:* 38.40sec
Recompilation (pumpkin crate)
*Debug:* 1.82sec *Release:* 28.68sec
I will put them into the benchmarks
The build times on async-stripe are inhumane. I wish the project didn't use so much codegen.
After learning that to make a minecraft mod the process was basically decompile minecraft fight the terrible names provided by the decompiler to make your changes then recompile it, I lost all interest.
> Be a drop-in replacement for vanilla or other servers
It seems to me that unless it's a drop-in replacement its not a Minecraft server? Akin to how say an Uno deck isn't a drop-in replacement for a Hearts deck but still both card games but not both Uno decks.
Or is it just meaning that Pumpkin (besides the network) do things differently than vanilla and so you might not be able to open a vanilla created world using Pumpkin?
The only "complete" reimplementation of Java Minecraft that I'm aware of is Bedrock.
For example, in Java version if you take a circuit and activate it with a button/lever - it would always behave in the same way. In bedrock same setup could have random result. And "random" is something you don't want in a large sophisticated contraption.
I'd guess it's caused by some race-conditions in bedrock implementation, but alas it wasn't fixed in 7 years.
For example there there are tricks that allow you to delete bedrock blocks. Which then lets you either get onto the roof of the nether, or drop below the bottom of the world. Not all of these tricks will then work depending upon the specific minecraft server.
Another example is that in vanilla you can "bomb" people with experience orbs, the sheer number of orbs on the screen will grind their game to a halt since there are too many objects to track and render. Some minecraft servers work around this by grouping up experience orbs into a single bigger orb. That way you have fewer orbs on screen at once.
[1] https://www.youtube.com/watch?v=FLynwXDnETI [2] https://news.ycombinator.com/item?id=41798369
From what I remember , there was one other server as well which also was written in rust but I am not exactly sure
Also , the last time I was at it , it was really really alpha software but it was getting developed at good rate , so I am not sure about its current state (I was there when the author had gone to take his exams IIRC)
Ever since I started playing it in the beta days I've been frustrated with how poorly Minecraft performs relative to what it's showing on the screen. (Not that that stopped me from pouring hundreds of hours into the damn thing.)
most servers leave it enabled because preventing player impersonation is pretty important so people can't just easily grief each other. some piracy servers implemented their own auth on top.
| | released | stars | last_update |
|----------|----------|-------|-------------|
| feather | 19aug | 2,614 | 2 years ago |
| mchprs | 20jun | 1,632 | last month |
| graphite | 22jun | 160 | 2 years ago |
| valence | 22sep | 2,731 | 3 days ago |
| hyperion | 24mar | 361 | today |
| pumpkin | 24jul | 965 | today |
| ferrumc | 24sep | 673 | today |I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!
Usually the hyperbolic superlative for Rust projects is “blazing fast”. Of course, any kind of benchmarks or comparisons with other implementations are completely optional. It is simply enough to “cargo init” and start hammering out code. You don’t even need to consider the characteristics of the algorithms you choose to use! If it’s Rust, it’s “blazing fast”.
It’s bad form to badmouth someone’s earnest work for sure. I wouldn’t do it normally since I think it’s nice that you actually did something. But if you’re going to sit in a glass house and throw stones you should expect some back.
Fortunately, my house is an underground burrow so I can throw stones with impunity. As ugly as it is to do.
Dig a little deeper in the repos and you may eventually find that this is exactly what that started as :^)
> badmouth someone’s earnest work for sure
Was speaking generally. Not meant at OP. I think it’s awesome that they are making a Minecraft server in Rust.
> Talk about pot calling the kettle black
Of course! Anything else would be bad form.
> my house is an underground burrow so I can throw stones with impunity
Sneaky, sneaky ;)
This, at least in my experience, applies greatly to software and hardware.
Well, there is research on this!
https://security.googleblog.com/2024/09/eliminating-memory-s... writes:
> vulnerabilities decay exponentially. They have a half-life. [...] A large-scale study of vulnerability lifetimes² published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code
Where ² goes to https://www.usenix.org/conference/usenixsecurity22/presentat...
A study limitation is that they looked only at security-relevant bugs (vulnerabilities). As someone who writes code, I would tend to think that this also goes for bugs without a direct security impact, but I don't have the data to back that notion up
Java 6 had multi-threading
Iirc part of original Minecraft's performance limitations were high object create/destroy rate leading to lots of garbage collection. With that in mind, picking a non-GCd language isn't completely crazy.
Why pick 6, though?
(I've never written pre Java 6 code)
It was really funny. It felt like a Satire LMAO
E.g. sqlite probably wouldn't be called modern, but everyone loves it so who cares.
Am confused by these two lines. Maybe it is just difference between the 'goal' and the 'current state'.
Goal:
"Compatibility: Supports the latest Minecraft server version and adheres to vanilla game mechanics. "
But NOT:
"Be a drop-in replacement for vanilla or other servers "
Will it be a replacement for Vanilla or not?
Drop-in replacement: refer to the ability of a server operator to simply exchange the current installation/executable of the server (be vanilla, paper, cuberite, etc...) for pumpkin while maintaining data, configuration, scripts and mods installed.
edit: grammar
If it is compatible, then can't I 'drop it in'.
They sound like they are saying the same thing.
It is compatible so clients can connect to the server and be fully operational, and thus, I should be able to drop in this server, and use it as a server?
How can it be compatible if it doesn't maintain data, configuration, etc..
Edit: or is this about Pumpkin files. Pumpkin will maintain it's own files, data, configuration. So it can't just use existing Minecraft data files.
So if it was a new world, Pumpkin would generate new pumpkin formatted files. But couldn't just 'drop it in' on an existing world and use the existing Minecraft data files.
Not sure of long term viability as far as effort, but if it is files, couldn't a converter from MineCraft to Pumpkin file structure, make the server 'drop in'?
* nginx is not a drop in replacement for apache
But from a client perspective, both implement HTTP/1.1.
* podman is not a drop in replacement for docker
But from a client perspective connecting to a service hosted in docker, that connection can still occur over TCP.
On the other hand:
* pkgconf is a drop in replacement for pkg-config
* cronie is a drop in replacement for vixie-cron
This seems too low level example to apply for Minecraft.
Minecraft has a lot going on, back and forth. For something to be 'compatible' it would need to be so detailed an implementation of the server, that it could potentially also be a 'drop in'.
If I were to interpret the statement made here I would assume that not-a-drop-in while being vanilla compliant means things like:
* It won't support server side mods without you re-writing them in rust
* It won't support bukkit plugins without you re-writing them in rust
* It doesn't support the configuration file format that the java server uses
* Maybe it doesn't support the world file format (which would be server side only)
* Maybe it doesn't support the same administrative commands (which you would only see as an administrator)
etc.
So it can definitely be compatible from the client perspective while being woefully incompatible with any prior experience anyone running a minecraft server might have.
This is not compatible with other servers plugins/data/configurations, so just replacing the binary and expecting to continue where you left off is not possible.
Drop-in: You run a server for some time. You decide to switch the software by replacing the executable. Everything works as before.
This is especially true with complicated vanilla Minecraft setups and red stone machines (Java Minecraft red stone has "bugs" that "shouldn't be there" but cannot be removed now since so much depends on it).
By the time you are 'compatible' then you have implemented everything needed to also be a 'drop-in' but data file formats might need a conversion.
So convert from Minecraft data files to Pumpkin data files. Then it could drop in.
Even if they supply a tool, isn't it drop-in.
Otherwise I'd so no software in existence is really drop-in. Most of them have some update that has to happen.
I see it is not a drop in when using other tools, plug ins, 3rd party things.
But what about just a plain vanilla world.
Can Pumpkin read in and use the plain vanilla files? Does it do some kind of conversion and have it's own file structure?
So if I had a simple server, it could be a drop-in.
Or does the world need to be generated new inside Pumpkin? I can't use existing worlds.
Will it ever though? Is this a goal?
I think the Minecraft server is in Java exclusively because Notch was only proficient in that language at the time.
Aren’t mods more or less the primary justification for building a server like this?
Although Rust may in some ways improve performance, is that a better trade for the huge reduction in potential mods?
This is why people struggle with their servers, not because the game was written in java
That's why I struggle with the server: it's written in Java. Other game servers don't seem to have this problem. If the network protocol were all, that'd be great
(I didn't downvote any of your posts in case you now wonder if that was me)
- Feather (Rust, abandoned) https://github.com/feather-rs/feather
- Valence (Rust) https://github.com/valence-rs/valence
- Cuberite (C++) https://github.com/cuberite/cuberite
> A Rust framework for building Minecraft: Java Edition servers.
Through there are currently 3 new rust impl. differentiating themself from Valence. So it's interesting to see how this will develop long term. Like will they be for different use case(1)? Will they merge? Will some die and developers migrate?
(1): There are actually quite a lot of different use cases, i.e. Java Edition is by now mostly about mods so providing different modding capabilities and various "common mods build-in" and similar can be a big target. But so can be wanting to run a mostly vanilla community MC server for quite a bunch of people etc.