Before we begin, we would like to say congratulations to Yu4c for winning the hardcore event! This week’s dev diary will be a wrap-up of the hardcore event, and the prospects of running similar events going forward. Let’s dive right in.
Why we ran the event:
This event was specifically created to test new server capabilities, and the potential of running live production servers with these new capabilities. There’s a lot that’s changing both ingame and behind-the-scenes in regard to the reset, and gathering as much data as possible about the capabilities of the resources available to us prior to resetting is very important.
The results from the configuration tested during the hardcore event were mixed. Specifically, what we learned from the tests were not ideal in regards to disk I/O speed and its impact on gameplay. If you noticed any sort of input lag, weird glitches with entities being “frozen”, or stuttering upon logging in, you weren’t alone. Minecraft servers have to load a lot of data for every player on the server, and having a fast disk I/O speed is crucial towards maintaining a great gameplay experience. Unfortunately, the configuration we tested during the event was hitting the disk speed limits with lots of players online.
Technical note (Greetings from Rodney):
As some of you might know, an area of 16x384x16 blocks in Minecraft is called a chunk and chunks are saved in groups of 1024, called regions. In minecraft 1.18 these regions have been spread across 3 different files. One for the actual blocks, one for entities and one for points of interests (beds, villager job blocks etc.). All of these need to be loaded when a player is nearby. In the worst case (the player being on the border of four region files, like it is the case at spawn) this means, that including the player data and statistics, 14 files have to be loaded when a player logs in. This not just requires a fast sequential read/write speed, but also good random I/O speeds.
What worked in this event:
There was a lot that went well during the event. While the length of time spent in hardcore appeared to be a bit of an issue (see the next section) the concept of having a lead-up time where you could die before the actual hardcore period began seemed to work well. This was actually a change made shortly after the server launched, and from the looks of things, was the correct move. Additionally, the “anarchy with an asterisk” worked well when paired with hardcore. Hard mode should be hard, and pairing it with essentially a completely vanilla experience seemed to fit perfectly. In any future hardcore events, this will likely be something brought back. Overall, the concept and functionality of the event worked great, at least from our perspective. That said, we did find some changes that need to be made before running similar events in the future.
What didn’t work well in this event:
If you felt the event was slow towards the end, you’re not alone. An issue that stuck out almost immediately the last few days of the event. Once hardcore had begun and several players died, activity on the server ground to a halt. Most players went to spawn and logged off, in an attempt to stay alive for as long as possible. Not necessarily a bad strategy towards trying to win, but it doesn’t exactly provide an enjoyable experience for everyone, as nobody wants to play on an empty server. If this event is run again, we would probably shrink the amount of time spent in hardcore, and at the very least increase the rate that the world border shrinks.
Moving forward:
As mentioned previously, this event was meant to test new server capabilities - but this doesn’t mean similar events won’t be run until we need to do that again. We’d like to do more events like this in the future, and we would like to hear your thoughts. We’d love to hear your feedback on this event, and any ideas you have for limited time events going forward!
Why we ran the event:
This event was specifically created to test new server capabilities, and the potential of running live production servers with these new capabilities. There’s a lot that’s changing both ingame and behind-the-scenes in regard to the reset, and gathering as much data as possible about the capabilities of the resources available to us prior to resetting is very important.
The results from the configuration tested during the hardcore event were mixed. Specifically, what we learned from the tests were not ideal in regards to disk I/O speed and its impact on gameplay. If you noticed any sort of input lag, weird glitches with entities being “frozen”, or stuttering upon logging in, you weren’t alone. Minecraft servers have to load a lot of data for every player on the server, and having a fast disk I/O speed is crucial towards maintaining a great gameplay experience. Unfortunately, the configuration we tested during the event was hitting the disk speed limits with lots of players online.
Technical note (Greetings from Rodney):
As some of you might know, an area of 16x384x16 blocks in Minecraft is called a chunk and chunks are saved in groups of 1024, called regions. In minecraft 1.18 these regions have been spread across 3 different files. One for the actual blocks, one for entities and one for points of interests (beds, villager job blocks etc.). All of these need to be loaded when a player is nearby. In the worst case (the player being on the border of four region files, like it is the case at spawn) this means, that including the player data and statistics, 14 files have to be loaded when a player logs in. This not just requires a fast sequential read/write speed, but also good random I/O speeds.
What worked in this event:
There was a lot that went well during the event. While the length of time spent in hardcore appeared to be a bit of an issue (see the next section) the concept of having a lead-up time where you could die before the actual hardcore period began seemed to work well. This was actually a change made shortly after the server launched, and from the looks of things, was the correct move. Additionally, the “anarchy with an asterisk” worked well when paired with hardcore. Hard mode should be hard, and pairing it with essentially a completely vanilla experience seemed to fit perfectly. In any future hardcore events, this will likely be something brought back. Overall, the concept and functionality of the event worked great, at least from our perspective. That said, we did find some changes that need to be made before running similar events in the future.
What didn’t work well in this event:
If you felt the event was slow towards the end, you’re not alone. An issue that stuck out almost immediately the last few days of the event. Once hardcore had begun and several players died, activity on the server ground to a halt. Most players went to spawn and logged off, in an attempt to stay alive for as long as possible. Not necessarily a bad strategy towards trying to win, but it doesn’t exactly provide an enjoyable experience for everyone, as nobody wants to play on an empty server. If this event is run again, we would probably shrink the amount of time spent in hardcore, and at the very least increase the rate that the world border shrinks.
Moving forward:
As mentioned previously, this event was meant to test new server capabilities - but this doesn’t mean similar events won’t be run until we need to do that again. We’d like to do more events like this in the future, and we would like to hear your thoughts. We’d love to hear your feedback on this event, and any ideas you have for limited time events going forward!