For those of you who have not heard, we (I) am doing a complete rewrite of the TridentSDK API and and the Trident server. It became apparent after a pause in development when I was waiting for the server to be implemented in order to release 0.4-alpha, only our second release in almost a year and a half. A forum user, Luke__ pointed out, "don't make the same mistake bukkit did, write it good from the start. Or suffer 2 years of rewriting." This was something that never left my mind. Whenever I'd open up Trident and start to write more code, I pause and think for a moment, "is what I am writing something that will last?" And a month ago, it turns out that it wouldn't last. Luke__ was right, it was messy. Take a look at TridentWorld, for instance. The first 300 lines are either imports, or construction logic. That's not OK. We cannot be building something that looks like that off of an API that was designed for code that used it to look like that. My drive to deliver something that worked was stronger than my foresight into the future to ensure something like this looks clean, readable, and maintainable. We were short on maintainable far in the past, with a significant lack of people to help us develop such a huge project, which further added to my drive to deliver, as a member of a 3 person team working on this project. But at one point or another, the entire thing will collapse, because it is just simply too messy and too difficult to continue supporting and writing code on a platform that was designed that way. The 1.9 update made this apparent. My inability and lack of motivation to update it made this apparent. What I'm talking about is that I can make a choice, and that choice is to erase a year and a half of hard work and start again, or to keep trying to dig myself a deeper hole. I decided that the day that the TridentSDK projects would be torn apart about a month prior to today, that they would no longer last - and I was the reason that they would no longer last. Because everything needed to be rewritten and well thought out as it is written, not after we saw that 30,000 lines of code was a complete waste of time. With the experience that I had gained from contributing to those 30,000 lines of code, there is now another branch on both repositories called "revamp," which I will use to restart from scratch, making sure that none of the code is ever left out of the thinking process that makes the difference between good and well designed code, and bad and neglected code.
Some of the things that I am eager to change in the revamp are:
- Logging. I'd love to have a better designed logging structure that doesn't use the registry in order access loggers.
- Getting rid of central classes. It was Factories, now Registered, and both have been deprecated. No more central classes. Bukkit did this with Bukkit.getEverything but that's something that I want to avoid. All related interfaces are provided in classes that belong to that package, not some arbitrary factory or registry.
- Chunks. Oh boy. This was something that really eluded me for the past year and by creating something from scratch I think that being in control of the whole process rather than a figment of development, "oh, maybe we should figure out how chunks will work with multiple threads???"
- Better maintainability. As Minecraft's data types tend to change from version to version, especially packets, I want to build something that it easy for us to update and change without changing how the API is used. This allows for faster releases after each Minecraft release and minimizes development overhead in the future.
- THINKING. Oftentimes when things weren't going our way, we'd get the code written and push it, making it someone else's problem, leaving it for later, etc... No. We are done with this. Every line of code should be thought out and if anything were to call it to question we should be able to defend the way it is written because when the code was pushed it, everyone will be assured that it went through deep thinking and logical reasoning before we are happy with the end result.
- Memory efficiency. My lack of familiarity with the Minecraft internals made it hard to understand code that played with chunks and metadata, but with what I've learned from developing and working with that code, I can write better and more thoroughly thought out code to implement ChunkSections and improve poorly written protocol interactions.
With that said, despite the setback from coming so far and having to get rid of it, I think that this is something to look forward to and to build forward to because what comes out of this will be vastly better for both the end user and myself and the other developers who work on TridentSDK.