Hello everybody!
Welcome back to our second Development Blog of 2023! Since our last blog in January we have made a fair bit of progress on our server upgrade which we will be sharing later on in this blog, however we will also be highlighting some of our other recent accomplishments. This blog will talk about our Quabbleball Player Testing that occurred earlier this year, and the subsequent re-introduction of Quabbleball tournaments, as well as our other tournaments. Finally we also released a new Recipe system that was utilised in the Pride Event and recently reworked our minigame dailies.
We recommend you check out our January Development Blog where we highlighted our goals for 2023 and gave an introduction to our 1.16 server upgrade!
January Development Blog
In our first blog of this year we gave a summary of our 2022 achievements as well as highlighted our goals for this year. We also gave an insight into our 1.16 progress that will also be expanded on more in this blog!
For this blog, we’ll be covering these topics:
Our 2023 Achievements So Far
1.16 Progress Update
Introducing Javascript Developers
The Future
Without further ado, let’s get into it!
Our 2023 Achievements So Far
So far, alongside our 1.16 server development, we have also released several new pieces of tech as well as made various tweaks to the day to day runnings of the server. Below we have highlighted a few of our recent achievements this year.
Quabbleball Player Testing
In March we opened up Quabbleball for beta testing. This was a process that involved having the players work directly with the Developers to give real time feedback on Quabbleball in order to help balance the game and make it more enjoyable for players. As a result of this month-long process we were able to release a huge update to the game, add a new Mahounoshiro map and release the on-world Quabbleball practice. These Quabbleball fixes also paved the way for our later Quabbleball tournaments.
Star Battle and Quabbleball Tournaments
Continuing on from last year, we have also partnered up with Arena to host more tournaments. In May we hosted the Star Battle tournaments for the duration of the May the Fourth event, and since Quabbleball’s update in April, we have been hosting monthly Quabbleball tournaments.
Custom Recipe System
A new piece of Potterworld tech was utilised in the Pride event, and those were custom recipes. Minecraft allows us the ability to remove the vanilla recipes from crafting tables and instead create our own. We did just this for our custom recipe system, which allows tech builders to input their own materials, and select an output material. Players can then craft these items in a crafting table. We also went a step further than Minecraft and added support for recipes to have requirements and be locked from players unless they meet these. We also added the ability for commands to be run after items have been crafted. This is a system we are excited to see used more in the future!
New Minigame Daily Activities
Finally, this month we also released a series of new minigame daily activities. We went beyond the simple “Play X game Y times” and added new and more challenging dailies that required you to do more in the game. We hope these new dailies are enjoyed!
Server Upgrade Progress
Since our last development blog, we’ve been chipping away at getting more of our code compatible. We’ve had to overcome a number of problems and learned a few new tricks along the way. At times, we’ve had to make decisions we were not quite happy with, but this does allow us to keep moving forward rather than being stuck at solving a single problem for weeks on end. We’ll be expanding on some of the problems and choices in this section. As you’ll see, it can be a bit on the technical side though!
Not too long after our previous blog, we hit a bit of a road block: we had been developing our Compatibility Layer mentioned in previous blogs for our Core plugin. Even though not yet finished, it was time to do the same for our API. We made several attempts and much time at this, but in the end the solution most fitting our current need was to simply maintain two separate versions of it. This does have the obvious downside of having to do any changes to the API twice. Considering the change rate in it is fairly low it is currently a trade-off we’re willing to make in order to get past this road block.
One new trick we developed while upgrading our code, is creating separate versions of some of our java classes for Minecraft 1.10 and 1.16, but call them exactly the same. Normally this would only lead to errors, but since we’ve put them in separate so-called (maven) modules we can do this. When we then build a new release of our Core plugin, we do that twice: once using the 1.10 module and ignoring the 1.16 one, and vice versa. In a way this is similar to our compatibility layer that we described previously, however this method does allow us to have two different versions without having to change all the code that is just using the code we rewrote. This may not seem like a big deal, but that can easily mean hundreds of places we would otherwise have to each change to go through our compatibility framework.
With all this and much more solved, what’s next? Well, there’s a number of external Minecraft plugins we use that we have to upgrade to 1.16 compatible versions, requiring many changes using our Compat layer and new tricks. Newer Minecraft versions have started being very explicit about which Events can be called in the so-called main thread or in async-threads, so we’re having to revisit many of those to keep them working. When that’s done, we should be able to test if our changed code still works for the 1.10 servers and merge it back into our main codebase. After that, we’ll have to see what other surprises pop up!
Introducing Javascript Developers
We have recently also made a minor restructure to our Developer team format, and that is replacing the position of “Web Developer” with “Javascript Developer”. As Potterworld grew, we came to the realisation that there were more opportunities for us to have Javascript-proficient developers on the team. Initially our Web Developer apps were limited to coding for the Potterworld Admin Panel and the main website, but now under Javascript Developer, applicants can work on the Potterworld backend, public API or Discord Bot as well.
At the moment the focus of our Javascript Developers is to rewrite our Discord Bot. Initially coded in Python, we also decided to move the bot across to Javascript as it is more sustainable in the long term to work off of Javascript and Java Developers, rather than have one Python Developer who can only ever work on one project. This rewrite also gives us the opportunity to upgrade the bot, make new features, and upgrade it to the latest Discord standards.
Our next steps in the Javascript direction, shortly after our bot revamp, would be to look into our public API and to expand on it to add more features that not only we can add to our website and bot, but also players can use in their own projects related to Potterworld.
We look forward to seeing what is in store for our Javascript Developers.
The Future
So what’s in store for the future? Obviously our topmost priority is our 1.16 server upgrade. We’re really happy with the progress we have made thus far, and are currently testing our code on our makeshift 1.16 hub. Our next steps there is to merge our 1.16 compat library into our 1.10 (and live) code to make sure that the compat can serve its initial purpose: to serve as an expansion alongside our existing codebase and allow for simultaneous development.
We will also continue to chip away at our Discord Bot over these next few months too.
Other than that, our focus as always is continued server upkeep.
Conclusion
That brings this blog to a close for today. We will endeavour to deliver another blog closer to the end of this year with another update on our 1.16 upgrade. However, like always, feel free to leave any feedback or questions below and we’ll try to address them! We’ll see you next time.
Welcome back to our second Development Blog of 2023! Since our last blog in January we have made a fair bit of progress on our server upgrade which we will be sharing later on in this blog, however we will also be highlighting some of our other recent accomplishments. This blog will talk about our Quabbleball Player Testing that occurred earlier this year, and the subsequent re-introduction of Quabbleball tournaments, as well as our other tournaments. Finally we also released a new Recipe system that was utilised in the Pride Event and recently reworked our minigame dailies.
We recommend you check out our January Development Blog where we highlighted our goals for 2023 and gave an introduction to our 1.16 server upgrade!
January Development Blog
In our first blog of this year we gave a summary of our 2022 achievements as well as highlighted our goals for this year. We also gave an insight into our 1.16 progress that will also be expanded on more in this blog!
For this blog, we’ll be covering these topics:
Our 2023 Achievements So Far
1.16 Progress Update
Introducing Javascript Developers
The Future
Without further ado, let’s get into it!
Our 2023 Achievements So Far
So far, alongside our 1.16 server development, we have also released several new pieces of tech as well as made various tweaks to the day to day runnings of the server. Below we have highlighted a few of our recent achievements this year.
Quabbleball Player Testing
In March we opened up Quabbleball for beta testing. This was a process that involved having the players work directly with the Developers to give real time feedback on Quabbleball in order to help balance the game and make it more enjoyable for players. As a result of this month-long process we were able to release a huge update to the game, add a new Mahounoshiro map and release the on-world Quabbleball practice. These Quabbleball fixes also paved the way for our later Quabbleball tournaments.
Star Battle and Quabbleball Tournaments
Continuing on from last year, we have also partnered up with Arena to host more tournaments. In May we hosted the Star Battle tournaments for the duration of the May the Fourth event, and since Quabbleball’s update in April, we have been hosting monthly Quabbleball tournaments.
Custom Recipe System
A new piece of Potterworld tech was utilised in the Pride event, and those were custom recipes. Minecraft allows us the ability to remove the vanilla recipes from crafting tables and instead create our own. We did just this for our custom recipe system, which allows tech builders to input their own materials, and select an output material. Players can then craft these items in a crafting table. We also went a step further than Minecraft and added support for recipes to have requirements and be locked from players unless they meet these. We also added the ability for commands to be run after items have been crafted. This is a system we are excited to see used more in the future!
New Minigame Daily Activities
Finally, this month we also released a series of new minigame daily activities. We went beyond the simple “Play X game Y times” and added new and more challenging dailies that required you to do more in the game. We hope these new dailies are enjoyed!
Server Upgrade Progress
Since our last development blog, we’ve been chipping away at getting more of our code compatible. We’ve had to overcome a number of problems and learned a few new tricks along the way. At times, we’ve had to make decisions we were not quite happy with, but this does allow us to keep moving forward rather than being stuck at solving a single problem for weeks on end. We’ll be expanding on some of the problems and choices in this section. As you’ll see, it can be a bit on the technical side though!
Not too long after our previous blog, we hit a bit of a road block: we had been developing our Compatibility Layer mentioned in previous blogs for our Core plugin. Even though not yet finished, it was time to do the same for our API. We made several attempts and much time at this, but in the end the solution most fitting our current need was to simply maintain two separate versions of it. This does have the obvious downside of having to do any changes to the API twice. Considering the change rate in it is fairly low it is currently a trade-off we’re willing to make in order to get past this road block.
One new trick we developed while upgrading our code, is creating separate versions of some of our java classes for Minecraft 1.10 and 1.16, but call them exactly the same. Normally this would only lead to errors, but since we’ve put them in separate so-called (maven) modules we can do this. When we then build a new release of our Core plugin, we do that twice: once using the 1.10 module and ignoring the 1.16 one, and vice versa. In a way this is similar to our compatibility layer that we described previously, however this method does allow us to have two different versions without having to change all the code that is just using the code we rewrote. This may not seem like a big deal, but that can easily mean hundreds of places we would otherwise have to each change to go through our compatibility framework.
With all this and much more solved, what’s next? Well, there’s a number of external Minecraft plugins we use that we have to upgrade to 1.16 compatible versions, requiring many changes using our Compat layer and new tricks. Newer Minecraft versions have started being very explicit about which Events can be called in the so-called main thread or in async-threads, so we’re having to revisit many of those to keep them working. When that’s done, we should be able to test if our changed code still works for the 1.10 servers and merge it back into our main codebase. After that, we’ll have to see what other surprises pop up!
Introducing Javascript Developers
We have recently also made a minor restructure to our Developer team format, and that is replacing the position of “Web Developer” with “Javascript Developer”. As Potterworld grew, we came to the realisation that there were more opportunities for us to have Javascript-proficient developers on the team. Initially our Web Developer apps were limited to coding for the Potterworld Admin Panel and the main website, but now under Javascript Developer, applicants can work on the Potterworld backend, public API or Discord Bot as well.
At the moment the focus of our Javascript Developers is to rewrite our Discord Bot. Initially coded in Python, we also decided to move the bot across to Javascript as it is more sustainable in the long term to work off of Javascript and Java Developers, rather than have one Python Developer who can only ever work on one project. This rewrite also gives us the opportunity to upgrade the bot, make new features, and upgrade it to the latest Discord standards.
Our next steps in the Javascript direction, shortly after our bot revamp, would be to look into our public API and to expand on it to add more features that not only we can add to our website and bot, but also players can use in their own projects related to Potterworld.
We look forward to seeing what is in store for our Javascript Developers.
The Future
So what’s in store for the future? Obviously our topmost priority is our 1.16 server upgrade. We’re really happy with the progress we have made thus far, and are currently testing our code on our makeshift 1.16 hub. Our next steps there is to merge our 1.16 compat library into our 1.10 (and live) code to make sure that the compat can serve its initial purpose: to serve as an expansion alongside our existing codebase and allow for simultaneous development.
We will also continue to chip away at our Discord Bot over these next few months too.
Other than that, our focus as always is continued server upkeep.
Conclusion
That brings this blog to a close for today. We will endeavour to deliver another blog closer to the end of this year with another update on our 1.16 upgrade. However, like always, feel free to leave any feedback or questions below and we’ll try to address them! We’ll see you next time.
