Calendar

Everything posted by HaedHutner

Right, so a few people said they liked the content in the last ( and first ever ) Boring Dev Log, so I suppose I should make a franchise out of it. To start off with, how about a sequel?
AtherysTowns
Today, I'm going to go over the pains I've been having with the AtherysTowns plugin, specifically focusing on the permission system, as that has been the most painful part of it, causing me to rewrite the plugin from scratch.
Again, to preface this, I doubt many would get any enjoyment out of this thread. And this one in particular is more of a rant on my part, getting something off my chest about permission management in general ( not just in minecraft ).
Permission Management Is Hard
It just is. It's frustratingly hard. That's not to say that permission handling models don't exist out there, they do, but they're mostly intended for enterprise-level applications. Things like Access Control Lists ( ACLs ), Attribute Based Access Control ( ABAC ), which is itself an improvement of the Role-based Access Control ( RBAC ) approach, which can itself be used to implement Lattice-based access control ( LBAC ).
Did you understand any of that? Yeah, neither did I. Security in general is a very broad subject, requiring a lot of specialization in order to be considered an "expert" on it. I am certainly not one such person. And if you came to me and told me "Hey, maybe find an Informational Security Expert to help you out with the permission part of this minecraft plugin", I would have probably ignored you because that's too much effort for a bloody minecraft plugin.
Yet, here we are, after having written and rewritten the permission system of AtherysTowns a good dozen times, I slightly regret not having done my research better. Now that that's off my chest, let's get into the boring parts...
So How Will Permissions Work in AtherysTowns?
Before we get into the details, let's establish a few basic concepts.
Broadly speaking, we have 2 types of objects in our plugin. We have actors ( those who can execute actions ), and subjects ( objects which are acted upon by an actor ).
We also have 4 types of entities in the plugin, which is the Nation, the Town, the Plot and the Resident ( which represents a player ). A Nation contains many towns, a Town contains many Plots and Residents. There are other things which are part of these entities as well, but those are just noise for the purposes of the permission plugin and don't matter.
So then, here's the first important question: Which of these are Actors, and which of these are Subjects? The answer seems simple at a glance: Residents are actors, and all others are subjects, right? Well, yes and no. If we say that only Residents are Actors, then we have to deal with certain limitations.
Imagine the following:
How does the mayor go about doing this? If we accept that only Residents are actors, they would have to manually permit all residents from Town B to build upon Plot C. Fine, say they do that. What if one of those residents leaves their town?
The plugin wouldn't be able tell if the resident was added because they were part of a town ( Town B in this case ), or because they were explicitly permitted, independent of any town, to change the plot.
The way to fix this, is to have a way for the mayor of Town A to permit Town B ( as an object ) to modify Plot C. But because we've already said only Residents are Actors, we can't do that.
There are a few possible solutions to this. What I've done is I've just said "Ok, so not only Residents are Actors, but also any entities which contain residents".
What this results in is the following:
Plots are Subjects
Residents are Actors
Towns are Actors AND Subjects
Nations are Actors AND Subjects
To explain it more broadly, any entity which represents a part of the world is a Subject. Any entity which represents a player ( or a group of players ) is an Actor. Any entity which represents both is both a Subject, and an Actor.
Let's go back to our initial case:
Now, because of our rework, we've made it so the mayor can permit Town B ( instead of each of Town B's residents independently ) to build upon Plot C. If a resident leaves Town B, then by definition they are no longer a part of Town B, and would therefore have no permission to change Plot C anymore.
This system, as you can guess I hope, also extends to Nations. You can imagine I'm sure many different situations where this would come in useful.

The locks plugin is currently planned to be a completely separate from the Towns plugin ( and in fact, I have no intention of developing such, instead opting for a plugin from Sponge's Ore repository ), thus you are correct that it is (un)intentionally being ignored within this permission system. This is a problem that can be fixed later on, and I consider it of lower priority than many other things. For right now these are considered open questions and we can resolve them later on in the development process. Who knows, in a Boring Dev Log down the line I might mention it

Alright, so this is something that will not appeal to most people. In fact, I would say hardly anyone would get much out of reading this. Unless you're interested in the nitty gritty technical details of programming and plugin development, you can skip this one.
Introduction
The entire point of the boring dev logs is to give you an insight into how we're going about developing A'therys plugins.
Since we've decided to go modded, we have to run a Forge Server. However, this brings with it some unfortunate implications, including having to use Forge to create... well, anything, really. I, for one, do not want to be making mods when the functionality is best described as a server-side plugin, thus I don't see the point in using Forge for any of our gameplay mechanics.
Luckily, we have Sponge ( Found at https://www.spongepowered.org/ ). It offers a higher-level abstraction atop Forge which makes it so much easier to work with. Of course, this comes with limitations, but so far I will say that I have not felt limited by Sponge in 99% of cases, and it's only in some corner cases where Sponge has proven to be lacking. But even then, I've managed to find workarounds which have worked just fine.
Great, so we have our starting point then, right? Well, not quite. Sponge offers a beautiful abstraction, but for our needs we need more than just a plugin framework. The elephant in the room is Persistence, with Sponge not offering any high-level solution for this. But there are other, smaller things which could improve the speed with which we develop our plugins. Thus, something I've nicknamed the "A'therys Framework" is born out of these needs.
This first Boring Dev Log is going to cover what the A'therys Framework is, and why it's necessary.
AtherysCore
In actuality, the A'therys Framework is represented by a single plugin: AtherysCore ( Found here: https://github.com/Atherys-Horizons/AtherysCore ). Core provides all the tools and utilities we need to make A'therys plugins better, faster and stronger. And that's all it does. It has no functionality in it. For all intents and purposes, it is nothing more than a library built atop Sponge.
Annotation-Based Command API
In Sponge, the way you'd traditionally go about creating a command is described here ( https://docs.spongepowered.org/stable/en/plugin/commands/index.html ), and it's a process that often times requires several classes ( not just the one it's described in ), plus more code relating to the command that's placed in the plugin main class. Overall, it creates a very disjointed feeling to command creation, with code being split up in several places. This makes it not only harder to read, but also harder to maintain.
The Annotation-Based Command API is described here ( https://github.com/Atherys-Horizons/AtherysCore/wiki/The-Command-API ) and it's quite a simple abstraction atop Sponge's commands, yet it makes it so much easier to work with.
Gson Utilities
Gson is a library that Minecraft ( and therefore Bukkit/Spigot and Sponge also ) uses to parse json into meaningful objects that it can use. Specifically, any time you describe something in JSON that has to be read by the game ( see: data packs in the latest updates ), Gson will be used. It's a great library written by Google and it works well for 90% of cases. The problem is the other 10%.
More specifically, Gson has issues with polymorphic structures and inheritance. If you have a ClassA interface/abstract class, which is inherited by ClassB and ClassC, you have to describe that relationship explicitly to Gson otherwise it's not going to be happy. It will try to instantiate abstract classes during deserialization, which obviously results in errors. The fix for this, as provided by Gson, is a class lovingly named the RuntimeTypeAdapterFactory. I shorten this to RTAF.
In the RTAF, you provide the abstract class, and link it to several possible implementations. Gson will then embed the implementation type into the serialized data, so it knows for the future which implementation to use for the json it's deserializing. Overall, this is a swell strategy, but it results in some boilerplate which is not very pleasant to look at.
The result therefore is the TypeAdapterFactoryRegistry class ( https://github.com/Atherys-Horizons/AtherysCore/wiki/TypeAdapterFactoryRegistry ), which will store multiple RTAFs and create Gson instances using them. The result is much more organized code, and less boilerplate.
Interaction/Attachment Service
This is something @Rynelf wrote to solve yet another issue with commands. Sometimes, a command needs to be more interactive. For example, you might need to write a command, and hit a block or an entity in order to achieve something.
The details of it are pretty straightforward and you can read the code here ( https://github.com/Atherys-Horizons/AtherysCore/tree/hibernate/src/main/java/com/atherys/core/interaction ), so I won't go into too much detail.
PluginConfig
Plugin configuration in Spigot was a pain in my opinion. And in Sponge, despite best efforts, it's still not the easiest thing in the world to set up a configuration file. That's why the PluginConfig class exists. It offers an abstraction atop Sponge's Configurate library, which is really nothing but the boilerplate required to setup an ObjectMapper and a ConfigurationLoader.
Question API
Another simple addition is the Question API which allows one to easily create text-based question-and-answer forms. Underneath it uses Sponge's Text API to create a question under the form of "Question? [Answer1] [Answer2] ... [AnswerN]". The player can then click on any of the answer buttons to execute some code.
Sound Utilities
Makes it easier to create and send sounds to a player.
Alright, and now we come to the big daddy of them all...
Persistence( JPA/Hibernate )
Persistence means storage, essentially. For example, you create a town, and you want that town to still be there after the server restarts. Might seem simple enough from a user perspective, but it falls under the massive field of persistence. And for this, we've gone several different directions in the past, gone through multiple iterations of each, until we've finally arrived to where we are today: JPA and Hibernate.
Originally, the Core plugin didn't offer any persistence abstractions. Each plugin was responsible for handling it's own, which proved to be inefficient at best. The first abstraction was based off of the NoSQL database MongoDB, which has been proven to be robust and high-performance. Over the course of 5-6 months, in became clear that the simple abstraction atop Mongo simply wasn't enough, and we'd need something better: an ORM.
An ORM stands for an Object-Relational Mapper, and what it does is translate memory data structures into database data, without the programmer having to do much for it. And in the beginning, we used Morphia, which is an ORM for MongoDB. We ran with this for a good 3-4 months, until it became clear that MongoDB in and of itself was simply not a good solution to our needs.
With that revelation, I decided to finally just go for the big one: Hibernate and JPA ( short of Java Persistence API ). It will take any Java object, and store it into an SQL database almost as if by magic, with minimal effort on the programmer's part. The only thing that I did was write a simple 80-line abstraction atop JPA which gives access to basic JPA functionality, such as CRUD operations, criteria and other such ( including JPQL queries ). What I intentionally missed out on were native queries which, while fast, lock the implementation of the database to a single driver ( such as Postgre or MySQL ).
And speaking of drivers, the default database I've chosen to go for is PostgreSQL. It's much faster than MySQL, though still an SQL database, and even offers additional potentially useful features such as JSON support, partitioning, and others.
Conclusion
To conclude this long boring dev log, I would like to say that you can still find all of the source code for our plugins at https://github.com/Atherys-Horizons. And specifically the AtherysCore plugin at https://github.com/Atherys-Horizons/AtherysCore. I don't know if I'm going to make a second one of these. It depends a lot on the time I might have or would want to spend on writing long threads like these, as opposed to writing code. So, we'll see. Take care for now!

So far I have no intention of making armor and weapons which give you special abilities. It's all about modifying stats at the moment.
As for more updates, I've known this is a problem for a while now ( and @Rynelf has tried to fix it with his Dev Log ), but I just never considered it that important to give updates that often. Fact is that very little changes in terms of our overall design strategy for Horizons, and Sellt's diaries touch on that part of our development plenty. The rest is just boring technical details.

The Combat plugin has gone through several iterations at this point. Some of which testable, others not. It's been a genuine process of trial and error, trying to figure out how to code a plugin flexible enough to account for the oh so many different playstyles we've seen over the years. I don't like promising anything, because I'm of the opinion that no matter how far into a project you are, you can always scrap the whole thing and start from scratch if you start noticing flaws in the fundamental mindset of your design.
So far though, this is what I can hint at:
1. A skil tree-based approach to progression
- Just as it says on the tin, you will be able to make your own path through a skill tree. Nothing and nobody will limit you in which route you will take, and with this there will obviously be some choices which are better than others. But then again, that's always been the case.
2. Skills ( duh )
- I liked Heroes skills. There was nothing wrong with the way they worked on a fundamental level. What I didn't like was the complete and utter reliance on that dreaded macro mod which forced you to bind every single key on your keyboard to a skill. This was only made worse by the fact that you had to twist your hand into all sorts of horrible positions to set off just the right combination of skills, in just the right timing. While the skill system itself will not be limited in any way, shape, or form ( intend for it to provide the same sort of functionality as the Heroes skill system ), I hope that skill designers will take into account the fact that at the end of your skill tree, you do not necessarily need to have a dozen different skills in order to pull off the damage you need. I've always been of the opinion that at the end of the day, one should have no more than 4 or 5 skills which synergize well with each other.
3. Armor and Weapon stats ( I call them attributes, though they're a far cry from the traditional RPG meaning of an attribute )
- There was always a fear in the Heroes era of armor contributing too much to your fighting ability. Yes, the armor you wear and the weapons you use either make you better or worse for your class. That's prevalent in just about any RPG I know of. In fact, it's something of a staple. I want to see this in A'therys, and I hope that these "attributes" might result in players being more selective/careful about the items they use. This is the most experimental feature of the entire plugin, so while I talk about it here, I don't know how deep it will go when the plugin is finished. I hope I can figure out some of the kinks I have with it, because I believe it would be an excellent addition.
I hope this satiates your curiosity. Take what I've written here as a general guide to my thinking and approach to the plugin, rather than concrete facts or features which are going to make it into the final product. They might not, but this is my mindset and I hope it's a good insight.

Greetings, all! Seeing as how the A'therys community has very little to do while A'therys Horizons is in development, we've decided we're going to try and expand our horizons.
We're all here because we're fans of multiplayer gaming. Co-op, team-based, MMOs, whatever, there's something for everyone out there and we'd very much like to incentivize our community to reach out to eachother to get together and enjoy something a bit different. We hope this may encourage you all to build stronger community bonds, and for this purpose we would like to present...
A'therys Community Guilds
What is it?
Many online games have mechanics based around the idea of getting many different people which play the same game together, in a smaller, tighter-knit community. Examples of this are guilds in MMOS like World of Warcraft, or Star Wars: The Old Republic, Clans & Teams in more competitive games like DotA, LoL, Overwatch, Call of Duty, Age of Empires, StarCraft, or other such.
An A'therys Community Guild is an officially sponsored and listed such community in another game.
How do I make one?
It's simple, you may fill out an application ( found here ), and will at some point be contacted by a staff member about your new community guild.
The application includes within it places where you can place proof that you meet all of the below mentioned requirements. If those aren't met, your application will be rejected.
However, if you get approved, your guild will be listed on the Discord in the #guilds channel at the very top, along with how people can contact you in order to join the guild in question. You will also be given the "Community Guild Manager" rank on the discord.
Once approved, you will be solely responsible for your own guild. Oversight may be done at random by A'therys Staff to ensure you continue to meet the requirements. If it is found that you no longer meet them, then your guild will be unlisted.
What are the requirements?
Firstly, in order to create an A'therys Community Guild, it's name must contain "Atherys" somewhere within it. We won't limit your creativity, though keep it respectable. Names which degrade the A'therys name will not be accepted.
Secondly, you must continue to be the person in charge of the guild, as per your application. If guild ownership is to change, you should inform staff about this, so that we may update the communication information properly.
Thirdly, do your best to maintain a respectable atmosphere. We're not going to force rules down your throat, at the end of the day the guild remains yours, but if we receive complaints from community members, then we may unlist your guild.

We've always treated meeting notes as confidential because a lot of things are discussed at meetings, including ideas which are purely hypothetical, needing further research, and which ultimately may not be possible. The community might get the wrong impression with us publishing these notes, as if we're promising something in there.
Really what it just boils down to is, we don't want to be held accountable for what gets said in these meetings.

I have many memories overall from the server, going all the way back to V1. I use to love defending Ilusia with my townies at the time, we'd get raided pretty much daily. But some of the best times I had was when we were building up Dreghorn in V2, working out lore and generally just building a community. I think that's what makes A'therys different to other servers, it's the ability to create and foster several smaller sub-communities in the form of towns and guilds.

1. Classes and skill paths are still under heavy development. We are looking at the ability for players to customize the abilities available to them to an extent where the notion of a "class" sort of disappears. We don't want to lock people into certain pre-determined playstyles, we want them to select what works for them.
2. Yes, and yes.
3. By "internally" I'm going to presume you mean a way to create factions within nations which can then fight it out between eachother. This is a matter of some internal debate, so I won't say anything about it yet.
4. Far. There's no way to answer this question.
5. The guilds of past versions will most likely not appear in this iteration. However, we have considered allowing players to create their own guilds in a very limited way.

I think it’s safe to say the launch of the A’therys Survival server is now well and truly over with. In total, I believe the server crashed a good 4 times, with intermittent connectivity issues in between.
And just like any good A’therys launch, some things went very badly. Unexpectedly so.
I can only imagine how the launch must have seemed from an outside viewer’s perspective. For those of you who have not previously had the honor of attending a launch of an A’therys server, then there are many veterans in our community who will assure you this launch was par the course.
With a player count of 15-20, one would expect a relatively smooth experience. Well, it was anything but, and we’re under no illusions when it comes to that. The server crashed way too often and it was way too laggy.
But why though?
World generation. That’s it, those 2 words sum up the majority reason for why the server crashed. During testing, we naturally were very vigilant of the server’s performance. Though, we never really went above a total player count of 7 staff members. It never occured to us that there would be issues if someone, say, went and explored 11k from the spawn point within the first couple of hours. That’s obviously none of the players’ faults, we advertised it as an unlimited exploration server, so that’s what you expect to get, and damn it, we tried our best to deliver on that.
Well, as it turns out, world generation has an extremely high performance impact ( who would have guessed? ). That’s not something we really considered during our testing. To our detriment, as it turned out.
A’therys Survival Launch as a learning experience
We’ve never really launched a survival server before. Our maps have always been pre-generated, so world generation never really entered into the equation. Now we know what it’s like when it does. And if we had to take one lesson from all of this, it’s that you should always pre-generate your world prior to launch.
And that’s exactly what we’re doing right now, as I write this post. A 10kx10k block area of the map ( 390625 Chunks in total ).
Furthermore, we’re going to have to introduce a world border, effectively limiting the playable area of the map within 100,000,000 block^2. This world border will stop you going any further than 5000 blocks in any direction.
We intend to increase this playable area in the future. By how much, and how often, is still a matter of internal debate. But we hope that for starters, this will be more than enough to satisfy your need for exploration.
Expect the server to be back up as soon as the world is done pre-generating, hopefully this time for good

While a post outlining some of the stuff we've finalized is a good idea, we're not planning on polling the community for any gameplay decisions at this time. We believe gameplay-related discussions should remain wholly within the hands of as few people as possible, so as to create a more consistent experience.

Open-Source?!
Yes, that's right, you heard correctly. Development for A'therys Horizons is from now open-sourced. What does this mean? I'll explain below.
What?
Open-source is actually quite simple to define. Every bit of software you use has program code behind it, also known as source code. The idea of open-source is that anyone is able to view the code responsible for whatever they're interacting with on screen.
That is what we've done as well. As of today, we have published the source code of 2 of our plugins on GitHub.
AtherysCore: https://github.com/Atherys-Horizons/AtherysCore
A number of utilities which are used by other plugins. Without this, out other plugins would be incapable of functioning.
AtherysTowns: https://github.com/Atherys-Horizons/AtherysTowns
A land-management plugin inspired by Towny. I'll be honest, it's a Towny clone. I'm not one to argue with established and proven-to-work solutions, so there's no need to reinvent the wheel.
Why?
One of the issues with developing so much code for such a large project as A'therys Horizons is that it takes time. Getting help for all of this is even harder, especially since we have to build upon Sponge, a platform for server-side plugins which can be utilized with a Forge server. There just isn't that much expertise out there. And while I like to think I'm dedicating as much of my time as possible, it still doesn't seem to be enough.
My hope is that by doing this, we can recruit some extra talent to help us out. No-strings-attached contributions are the way many open-source projects prosper, including the Sponge project itself. There are no more barriers to entry for helping out with A'therys development. Are you interested in helping? There's the repos, you can get to work pretty much instantly.
License?
GNU GPLv3: https://choosealicense.com/licenses/gpl-3.0/
Essentially, you are free to use it however you like, modify it, commercialize it, whatever, but whatever you do to it, the code must be public, and it must be licensed under GNU GPLv3 as well. You should also give us a shoutout.
Only 2 Plugins?
On principle, I refuse to publish code which does not work. Obviously, I haven't only developed 2 plugins thus far. There is a substantial amount of code which is not yet published.
AtherysQuests ( our in-house quest plugin )
AtherysAttributes ( a plugin for attributes )
AtherysCombat ( the plugin responsible for the overall combat experience on A'therys )
AtherysRPG ( a plugin for Skills and overall player progression ) are all still on our private GitLab repos and not published yet.
AtherysEconomy ( A fork of EconomyLite, modified for our own purposes )
AtherysConquest ( A king-of-the-hill mini-game plugin which we had at the end of Evo )
This is because they're not functional yet. Half of them don't even build. There's a lot of code in those repos, but it's not ready to be put out there yet.
As these plugins are made functional, they too will be published on GitHub under the same organization ( https://github.com/Atherys-Horizons )

How many times have we ( staff ) had to go around, deleting old and inactive towns? How many times have new mayors had to create their towns in the middle of bumfuck nowhere because the good spots were already taken? And how many of those times were the good spots taken by towns whose mayors logged on twice a month, just to make sure their town doesn't go poof? And how many times have we had complaints over too many towns having their PvP off?
Too many, that's the answer to all of the above. The tax system solves much of it. Is it perfect? Of course not. But will it work? Yes. At least, we believe so.
Let me reiterate, town mayors cannot automatically tax the residents of the town. There is no system which will pull money out of an individual resident's bank. The tax system is only on the nation level, meaning the nation head regulates taxes on town banks. At the town level, it is up to you ( the mayor, or the residents of the town ) to organize a way to pay the tax. Or not. If not, and you fail to pay your taxes, limitations will be imposed upon the town.
This is more than just a "town" server. Always has been, always will be. For us, towns are just another mechanic we can tweak and change to fit the overall experience of the server.

The way I look at it, this system makes it very clear what you need in order to begin a town, and after you've covered these base requirements ( the minimum player count ), it is up to you to maintain the existence of this town. That is all the system does, no more, no less.
Small private towns that just take up premium real estate for the benefit of a small minority have usually been frowned upon, though never directly punished ( See: Mayors who logged on every 2 weeks so they could sustain their dead towns with people in them who last logged on months ago ). If we, not just as staff but as members of the community, were given the choice between a town with 2-3 active people in it or a town with 20-30 active people in it, clearly we'd prefer the latter.
It all comes down to the fact that land and space is at a premium, no matter what server you're on. If we don't better control the distribution of this precious resource, then it's going to be misused and the people who could really utilize it for something good wouldn't be able to. However, we do understand that prohibitively high requirements would also be a net negative for the server and the community. That is why the exact numbers are variables that can be changed at any point.
On the matter of whether or not your mayor requires you to live in a pre-built house or not, whether they require you to pay rent or not, that's all down to the organization of the town. And, clearly, if the town is so disorganized that it can't even maintain itself ( pay upkeep ), then why should it continue to exist and take up land which might be better utilized by another town which is better organized?
As far as player archetypes are concerned, personally, I'm blind to those. I don't see players as PvPers, RPers or builders or whatever, I see them as players, people looking for an interesting and fulfilling experience. We don't balance numbers based on how many players of a certain archetype we have in our community, we balance them based on how difficult and rewarding of an experience we aim to achieve. Archetypes do not enter into it.

To be clear, upkeeps are charged to the Town banks, and that's where it ends. There is no system which will automatically tax player's banks. It is up to the residents of the town to figure it out for themselves how they would like to finance their town.

Ship building is one of the harder things to get right in minecraft, it's up there with the likes of high-detail organics and terrain. These look quite good, and as someone who has experimented with ship building in the past, your skill makes me envious. Good job!