Frequently Asked Questions

The main reason is that it's simply the right tool for the job. An ECS excels at managing high numbers of entities with complex interactions, which is exactly what a Minecraft server needs to do. The ECS approach wasn't super popular when Minecraft was first developed and the JVM makes it much harder for the ECS's cache hits to shine since the JVM can get in the way with its own memory management and optimizations, but Rust's lack of a runtime makes it a perfect fit. Even Mojang sees te value in it, since Bedrock Edition uses an ECS architecture as well. In the end, Java is more designed for OOP architectures, and Rust lends itself better to an ECS design, so it just made more sense to go with an ECS for Temper rather than trying to shoehorn an OOP design in there just for the sake of familiarity or tradition.

We use a proper key-value database for storage, called LMDB. It has a lot of upsides like massive performance, memory-mapping, fault tolerance being developed by people way smarter than us. It's not compatible with Minecraft's world format called Anvil sadly, but we figured that utilizing 15 years of software breakthroughs since Minecraft's inception was worth trading out drop-in compatibility for, especially since we have a world importing tool that can import existing worlds.

It's very much on the roadmap, but we want to get it right first try instead of having a half-assed API that needs changing every 3 months. Plugins will be written in Rust and compiled to binary libraries that Temper will be able to run. This allows for high-performance plugins that can comfortably interface with the rest of the Rust ecosystem. This will however come with some downsides; namely plugins being platform dependant so you'll likely have to download a version of each plugin for your server's OS, and the barrier to entry for plugin development being higher since Rust is a more complex language than Java which is used for plugins in other Minecraft servers. We think the performance and ecosystem benefits are worth it though, and we're working on making it as easy as possible to develop plugins in Rust with good documentation, examples and tooling.

Long story short, no. Completely different languages, implementations and architectures make it almost impossible for Java plugins to work with Temper. A compatibility layer would be possible on paper, but it'd be a massive headache to implement, extremely sketchy and having to pass everything to a Java runtime and back would obliterate performance. More complex plugins would also require a deeper compatibility layer and it'd eventually get to the point where reliably running popular plugins like WorldEdit or Dynmap would require us to basically re-implement Paper/Bukkit on top of Temper, at which point there isn't much reason to be doing this project in the first place. When feature-completeness is on the horizon we might revisit, but for now it's very unlikely it'll happen.

I know the software world is saturated with stuff being rewritten in Rust for no good reason, but I promise it's actually the tool for the job here. Other languages have been considered but Rust just ended up coming out on top. Rust is only marginally slower than C/C++ and is much easier to write and maintain, with memory safety guarantees and a modern ecosystem. Golang was ruled out due to not scaling well with the size of the codebase and most interpreted languages like Python and Javascript/Typescript would have been too slow to be a real improvement over the vanilla server. C# was a real consideration at one point, but the lack of support for proper multithreading would have meant we would lose out on a massive performance opportunity. Zig was also considered, but with it being so young and unstable, along with not being as well known or widely used as Rust, it just didn't make sense to go with it over Rust which has a much larger ecosystem and community. In the end, Rust just made the most sense for what we wanted to achieve with Temper, and we're excited to be using it to build a better Minecraft server experience.

If I'm going to be honest, the name sounded cool and I had the think of a reason after. Tempering is the process of hardening metal by heating and cooling it, which could be a metaphor of what we're doing with Minecraft server software; taking something that already exists and making it stronger, faster and more resilient through a lot of hard work and iteration. Honestly, up to interpretation, the domain was cheap, name sounded cool and wasn't used by anything else notable so I just went for it.

I wanted to carry on the proud tradition among Minecraft server projects of forking over management issues and splitting the community in half. In all seriousness, we just didn't agree on how to run the project. There was no major falling out or anything and we are still on good terms, but we had different visions for the project's direction and management style that ultimately led to us parting ways.

We welcome contributions of all kinds, whether it's code, documentation, bug reports or just spreading the word. Hopping in the Discord is a good first step, since you can ask what needs working on we can discuss how to best help you contribute. If you want to dive right into the code, the github usually has some issues open for what needs doing, feel free to pick one up and start working on it, and if you have any questions or need help don't hesitate to ask in the Discord or open an issue on github. If you want to work on something that someone else has already picked up, chuck a comment on the issue or in the Discord to see if you can collaborate with them rather than stepping on their toes.

Yes, but simply providing quantity over quality won't do you any favours. AI can be helpful yes, but you are still expected to understand what you are submitting and be able to explain it if asked. If you just dump a wall of AI generated code that doesn't work or isn't up to our standards, it's not going to get merged and it's just going to waste everyone's time. If you consistently submit poor quality AI generated code without being able to explain or fix it, future PRs from you will likely be ignored. In short, if you wouldn't be able to write the code without an AI, then you probably shouldn't be submitting it with an AI. If you are of the opinion that throwing a wall of unchecked AI slop at the PRs page is the right way for the project to be developed, you should probably go find another vibe-coded project that shares that vision, or start your own.

I am such a kind and generous person that I will take some of that pesky money off your hands. Jokes aside, donating money is in no way expected or required, but if you really do want to support the project financially, there is a buymeacoffee page here. The money goes towards hosting costs, domain registration and other expenses related to running the project, and any excess funds will be put towards future development and improvements. There are some small benefits for donors such as having your name listed on the website and a special role in the Discord, but the main motivation for donating should be just wanting to support the project and help it succeed rather than any specific perks. We appreciate any support we get, whether it's financial or just spreading the word about the project, and we're grateful to have such an amazing community behind us.

The logo was designed by a super cool artist who goes by the name of Star. You can check them out here: https://starcomissions.carrd.co/. I have worked with them previously on some work for another project and they always deliver high quality work very fast with extremely reasonable prices, I'd highly recommend them if you need any art or design work done.

Most likely yes. We are trying to avoid using decompiled code so we don't get sued by Microsoft/Mojang and this ultimately means that some of the game's internal workings won't be easy to replicate. For most things the community has well documented so we can simply consult the wiki or chat to Minecraft experts in the community to figure out how to replicate it, but for some more obscure mechanics we might have to make educated guesses based on testing and observation. Stuff like terrain generation for example will be nearly impossible to perfectly replicate without decompiling the code, but we can get very close with enough testing and iteration. We also want to take this opportunity to fix some of Minecraft's longstanding issues and inconsistencies, so there will likely be some intentional differences as well. Our goal is to make a server software that is compatible with vanilla Minecraft clients and provides a solid foundation for plugins and mods, but that doesn't necessarily mean we have to replicate every single quirk and bug of the vanilla server.

There is a pretty solid chance that we just haven't gotten around to implementing it yet, especially if it's a more obscure or less popular feature, or it requires other unimplemented features to be added first. If it's important to you, come have a chat and we can discuss how it's being handled. It might be further down the roadmap than you'd like, in which case you can either wait for us to get to it, or if you have the skills and motivation to work on it yourself, we would welcome contributions. If it's a bug rather than a missing feature, definitely report it in the Discord or on github so we can get it fixed as soon as possible. We are still in early development and there are bound to be a lot of missing features and bugs, but we are working hard to get them all ironed out and we appreciate the community's patience and help in getting there.