It’s been one and a half years since our last technical blog post about the initial new ride system and a lot has happened since then. So let’s sit down and talk about the progress, innovation, and engineering that has taken place since then.
With that said, this article will go super in-depth about the system we build and how it works, our last article had a main focus on the math behind these systems, and this blog post will go into the design and software side of things.
It’s certainly not for everyone, but you might have some cool Aha! moments after reading.
I want to preface this blog post with a notice about traincarts. It’s served us well ever since the first server opened in June of 2018 and might as well be the reason why this server was able to evolve from a dream into reality. The release of the companion plugin, TCCoasters was the spark that lit what now turned out to be the second wave of Minecraft theme park servers and the team behind it deserves all the credit and respect for their work.
But like in any relationship, personal growth, ambitions, and different philosophies can lead two to grow apart. We’ve hit a point where we need to continue growing and build new amazing rides and park features, without being held back by restrictions from a time long gone.
Mouske had a great explanation in the latest newswire about tick-time and performance implications that the old ride system had. But for those who didn’t tune in;
For those who don’t know, the tick speed is how Minecraft executes time. Movement, interaction, plant growth, and more all rely on this. If the game is running perfectly, it runs at 20 ticks per second. If it’s not, however, this can plummet. If you notice rides freezing on the server, that’s usually because the tick speed has gone down. The old ride system we used was incredibly powerful but had drawbacks. It ran calculations every tick, 20 times a second, for every ride vehicle on the server to keep things running. These thousands of calculations per minute would cause the server to begin slowing down as it caught up on the countless things being asked of it. For reference, everything on the server outside of rides such as commands, player movement, toys, animatronics, and more all took up 20% of the server workload. That ride system alone took the other 80% at any given time. The old system made up approximately 80% of the server’s workload on average.
~Mouskegamer, https://youtu.be/Zx8yQOcUnlk
This means that we have calls to update all in-game elements (toys, rides, commands, and tons more) which all have to be done within 50 milliseconds, going over that threshold by only 1ms will result in lag and show timings desyncing, completely ruining the player experience.
Profilers (which are applications that show which lines of code are the slowest by proportion) show that this 80% overhead comes from a few core elements, these are;
So we set up a plan to completely redesign our stack, and eliminate all of these components.