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.