The architecture

How it's been developed?

When I've started this project the main goal was to make it easy for anyone, so I've choose a language which by now is I think the base of the web: Javascript.
This way almost any developer in the world could go and implement Reldens, and this place the project in a huge market.
Another benefit of doing it with JavaScript is that you don't need to learn anything else for the server because that's where NodeJS comes in.
By now the project has been fully refactored 4 times that's why the big mayor version coming is v4, but to be honest it was just me messing with SemVer at the beginning and then didn't wanted to just restart the version when it was getting a serious project.

Other things that made me choose the language? That's easier: all the other platforms, frameworks, modules, plugins and so in which I'm basing Reldens.
In the current stage I'm using Colyseus to handle the communications and Phaser for the client, so I'm not rewriting the wheel, I'm delegating all I could to just focus on the Platform part which is basically make it dynamic, easy to administrate, and full of features to be able to customize it all you may need.

With that in mind then the next was how to build the client, and for now I'm using Parcel since it basically worked without need much else.

And for last, everything has to be saved somewhere... so MySQL to handle that.

What about the structure?

Well... let's start from the base: the most common practice I've saw is to fully split the server from the client in different modules, I didn't went that way (or at least not for now). This is why I call Reldens as a Platform, Reldens itself contemplates everything: the server, the admin panel and the client, so a package in Reldens would define what ever it requires. For example: a package to change something specific in the UI (on the client side) could also required some configurations available in the admin, and some events observers to apply those changes in the client, so the package must have all of it. Another example a more complex module could require to create it's own room and that way interact with the 3 areas (server, admin and client).
The main point is that each package in Reldens is basically a fully working feature.

That said, at the same time Reldens has it's own Framework which is event-driven based, and all the modules I'm creating and publishing from now on are going to be fully agnostic to later been implemented as packages in the platform.

A good example of ALL OF THIS is the Items-System, which is an agnostic module implemented in the Reldens Inventory Package.

The not so good parts?

The first bad, obviously this is quite experimental, I didn't saw this before, and I know it can be a bit confusing, but I'm still positive that is not that hard to follow (since each package must and will always have an specific structure), and the events are really easy to follow.

The second one, is that I've started to doing it quite long after the project started, so for now I only have one module fully applied this way.

The good part?

This is just starting and the idea is to get everything refactored, decoupled and agnostic.

In the same way I plan to implement everything under the assumption that at some point we should be even able to change anything, from the current communications handler to the client, so let's say you would like to use another server instead of Colyseus or another client instead of Phaser, you would be able to do it.