What you are about to read will be an announcement that is long overdue, and will have a great impact on our network for a long time to come. Please read the entire post before replying, since some of the things discussed ahead might be a bit controversial.
The Big Picture
Today we are excited to announce something that will change the way we all play Stratus, forever. A lot of work has already been done in order to pave the way for this plan, such as the Mission Post written by Electroid, but we are only just getting started! Today we are announcing that we will be rewriting all of our plugins as well as our backend. Although this is a huge endeavor that we are undertaking, all other solutions have been discussed at length and we came to the conclusion as a team that this would be the best course of action. This will be a multi-month project and will require a lot of work, however, the results will be worth the effort. While the rest of this post will mostly be focused on the Minecraft side of the rewrite, we plan to make a similar post regarding the website portion of this project in a few weeks.
Why Not Keep PGM?
The OCN codebase has served this community well for a very long time, but has unfortunately become too big to maintain. Features that were added on top of each other to make life easier have come back to haunt us later. What made sense in 2014 unfortunately no longer makes sense in terms of usability and coding style. Documentation for some of the APIs that were meant to make life easier is so sparse that they have ended up making developing harder. In the end, the codebase served its purpose and it is time to move on and close this chapter. For a more detailed and technical explanation of how the code currently inhibits development, click here. The rest of this post will be more focused on the future rather than on the past.
This Sounds Familiar...
Anyone who played on OCN near the end of its existance is probably putting a slab of concrete on their caps lock key right about now and preparing to slam us for Hampton 2.0. Hold off for a bit before doing that since we've seen what poor management can do to a community, and have learned quite a few lessons from that whole disaster. Let me be clear, this is not Hampton 2.0, in any shape or form. What we are working on will have most of the features of the current plugins, and will make it exponentially easier to add new diverse features later down the line. The people leading and working on this project were some of the most vocal opponents to the Hampton project, and are in no way trying to replicate it. Now that we got that huge elephant in the room out of the way, let's move on!
The Biggest Change
While a lot of other things will change with the release of the rewrite (such as the lobby and punishments), the main change will be how maps are configured. The past mindset in PGM is that every module should be as general-purposed as possible (hence why we have so many). Some of these modules contain 100s of features, all in an effort to make the game as customizable as possible. This all seems good on the surface, however, if you dig deeper it creates a big design problem. Everything is designed to work together, which works fine when all of the games are relatively similar (ctw/dtc/tdm/ctf). Problems start to occur though when you start adding game types which are vastly different, such as UHC or an arcade. If you look at some the XMLs for the arcade maps, you'll begin to see how hacky some of them are written just to accomplish simple games. These games work, but the point is that they could work a lot better.
With the redesign we will splitting up each game type into it's own parsing section, and dividing up some modules so that they only work in some games. This is so we can design code for what it is supposed to be used for, and not have to worry as much about making everything possible everywhere like we had to in the past. This allows us to write specific game features that enhance some game types without having to worry about the side effects that they will have on everything else.
We would be lying if we said that there weren't any downsides to this new system. We are working to be as open and honest with the community as possible, and part of that is admitting that this system is not and will not be perfect. One of the immediate drawbacks is that mixed game mode maps will no longer be possible. The only exception is a DTC/DTM map, since they are internally treated essentially the same. Maps which combine other objectives, like a CTF/DTC map will no longer be possible. This effects a small minority of our current maps, and should not pose a big problem. The other large downside is that all current XMLs will have to be re-written, since making them all work as they current are would just be like adding PGM to the rewrite, which is impractical and would add a large amount of time onto the already lengthy project. We will provide more information on how this is going to be done at a later date, so stay tuned.
Our goal is to support at least 3/4 of all of the maps in the repository before we release this update. By support, we mean have most of the map's gameplay features work as they do now. Most of the maps currently in rotations are quite simple, so this shouldn't be a problem. Some maps will actually be easier to code now because of the way we are designing the module structure. There will be a far less need for complex filter chains when we can code features specifically for certain game types. Maps which use more complex modules, or combine them in unusual ways, may not work in the beginning. We are working to streamline some maps, and this unfortunately means that some of the wilder maps will have to be on the back burner (for now).
Will the X Module Still Exist?
As stated above, most maps will work as they do now, but might be XMLed a bit differently. We are removing modules which are rarely used (less than 1/5 of the maps loaded) or working their functionality into simpler solutions which are more efficient. The main feature that will no longer exist will be a lot of the complex filtering functionality. Maps that use filters in this way generally accomplish a very specific goal, and those don't make sense to support for initial release. The thinking behind this is that if enough maps use something (now or in the future), we will code something specifically suited for those map types instead of their authors hacking it in with complex logic.
So, What's Next?
For the time being, nothing will change on the network. We will still have developers dedicated to the current codebase. These developers will mostly be focused on fixing bugs, though, and will not be focusing on as many features. This is not to say that no new features will be released before the rewrite, however, larger features will likely be bundled in with the new code.
As stated in the mission, we will be posting updates on our progress every 2 weeks, and plan to begin releasing preliminary XML documentation quite soon. We are also really excited to hear what you all think about this project, and will work to implement as much feedback as possible. Feedback is welcome, but please keep it as constructive as possible. Feedback like "this is a bad idea" will not help anyone in the end.
In an effort to help clear up any questions that this post doesn't answer, we will be holding a livestream Q&A with the administrators, developers and map developers in the coming days. The session will be held on the official StratusMC Twitch page. The exact date and time will be announced soon. If you have any questions about the rewrite, you can submit them here and we'll try to answer it during the stream. If we have time, we may also answer some questions directly from Twitch chat if they haven't already been asked. Please read all of this thread and any responses before asking questions.
The Stratus Development and Administration Teams