L2J Architecture

This is not a Support area! Discuss about the Server here. Non-Server related discussion goes in Off-Topic Discussion.
Forum rules
READ NOW: L2j Forums Rules of Conduct
LasTshaMAN
Posts: 12
Joined: Wed Nov 04, 2015 10:38 pm

L2J Architecture

Post by LasTshaMAN »

Hello, guys! I've walked through the forum and I didn't find much information about the architectural aspects of L2J project.
I saw several wiki pages on GitHub, technical question here and there, some comments in the code, but being a project of such a scale one would expect to find accompanying diagrams with description of each component of the server, and rationale for different design decisions.

Is there some place I failed to find, or there are no such documents ? I am interested in a top-down approach of understanding the code base. The tutorial on the architecture of the project might look like this:

1) At the highest level we have L2J_Server, L2J_DataPack, ... The whole project is split into these modules because of ...
2) Then for each of those modules follows a complete description of what the given module is about (diagrams with some comments are very welcome during this stage).
3) Next, if we want to talk about L2J_Server module, we need to mention data model and its mapping onto database tables(in case of relational database which is actually your case), we need to say a few words about client side of the application(where it comes from, how the data exchange is made e.t.c.). As I understood from the code, there are a lot of sub-modules united under L2J_Server module each of which has its unique purpose expressed through a set of classes. It would be nice to have a description(better yet a diagram with comments) of each such sub-module.
4) Then, may be, it's time to describe each class in the context of the whole picture we've drawn so far.
5) And only then would it make sense to read each line of the code in detail.

Tell me I am not doomed to reverse engineer the whole architecture of the project from the source code =)
Nik
L2j Veteran
L2j Veteran
Posts: 629
Joined: Fri Apr 18, 2008 9:09 pm

Re: L2J Architecture

Post by Nik »

Yes, you are doomed to read at least 20-30% of the code inside to get an idea of where things are.

First, it is impossible to write some documentation of each class file, because a certain class file may come and go. They are not there forever, because they get reworked.
But basically speaking, L2PcInstance is where mainly stuff about player is handled, L2Character is where stuff about creatures and npcs and others are handled (the main superclass) and L2Object is what it says... basically all objects within the games extend it, from creatures to players to items to doors, etc.
At skills package and stats package you can find how skills and stats are being handled. Keep in mind that here is where targethandlers and effecthandlers come into place from the datapack. They are just unhardcodded from the core for an easier adjustment (a lot of stuff in the datapack is like that. Unhardcodded so you can edit it without the need of using a compiler/compiling/restarting server in some cases.)
xml package is where static XML stuff is loaded from the datapack. Basically all data holders are inside (except sql).
SQL calls on the other hand, they are almost everywhere, not just on specific package.
This is all the basic stuff you will need to know from where to start chewing the code. 90% of the code is linked one way or another with the above classes/packages.

Now, L2J_Server and L2J_DataPack are the only modules you need. There are no other sub-modules other than maybe some libraries that havent been touched in years and just stay there for the sake of their code being exposed.
JythonEngine - outdated since the stone age of l2j where python scripts were used
Netcon - wtf? I see it just now
L2J_CommunityServer - support of this has been dropped
JavaEngine - java runtime compiler for scripts
L2J_GeoAbstraction - I have no idea, something about geodata... is it even used? Is it even finished?...
MMOCore - The network library, this is what handles all packet sending and receiving.
L2J_GeoDriver - again... i dont know...

So, you dont need those. They are already as libraries inside the main projects - Core and Datapack.
Ok, since I've explained you about core, now the datapack is what you should start from if you are totally novice and have no idea from java and whatsoever or just... yeah, its where you should start looking at.
Datapack is made so you don't have to deal with any java code (okay, scripts are on java >.<). Core is just one jar once compiled and datapack is where you can touch with notepad++ and change 50% of the server. All the static data from where core reads the settings of the server. X skill does Y things, X npc has Y stats, X player has Y skills, X npc shows Y html, X quest does Y stuff... etc. Also, since the unhardcodding of many handlers, you can see them as well, handled by MasterHandler.java. This has been done so you can also change the function of how certain effects, skills, targeting, chatting etc, work.
So to sum it up, datapack is the newbie playground which is really, really powerful in terms of changing gameplay and core (aka L2J_Server) is where you shouldnt touch and leave it to the pros. Basically I'm thinking like this... if you wanna do something and you need to edit core for it, you are already codding dirty enough.

And finally "5) And only then would it make sense to read each line of the code in detail." this is very, very false statement. 95% of the cases you dont need to read what the code does because method names are explanatory enough and do what you want them to do. Unless you've stumbled on russian forks where l2j's architecture has been radically changed, and you really, really need to read every single piece of code because stuff there works on hope and magic.
Playing a game where you know how every single mechanism works is quite satisfying.
Its the main perk that a gamer-developer has :D
User avatar
Zealar
L2j Veteran
L2j Veteran
Posts: 1236
Joined: Sun Jul 15, 2007 10:29 am

Re: L2J Architecture

Post by Zealar »

Great explain Nik :+1:
User avatar
Gladicek
Posts: 634
Joined: Wed Jan 19, 2011 6:25 pm
Location: Czech Republic

Re: L2J Architecture

Post by Gladicek »

"datapack is the newbie playground"

I hate you Nik for this! :kappa:
ImageImage
L2J retired
Nik
L2j Veteran
L2j Veteran
Posts: 629
Joined: Fri Apr 18, 2008 9:09 pm

Re: L2J Architecture

Post by Nik »

Gladicek wrote:"datapack is the newbie playground"

I hate you Nik for this! :kappa:
Thats why we love the people playing there with quests and crap :D Working there doesn't mean you don't put as much effort and thought as it is done in core. It only means that some people just don't want to play with fire :D:D:D
But speaking about the subject, it is true that datapack is really for newbies, as well as the whole core. The place where real developers hang is no other than the ancient com.l2jserver.gameserver.ai :kappa:
I'm offering 5 kappas for the first real developer that manages to modernize that place :D:D
Playing a game where you know how every single mechanism works is quite satisfying.
Its the main perk that a gamer-developer has :D
Sdw
L2j Veteran
L2j Veteran
Posts: 855
Joined: Mon May 03, 2010 8:38 am
Location: France

Re: L2J Architecture

Post by Sdw »

5 kappas it is
Sacrifice
Advanced User
Advanced User
Posts: 1026
Joined: Thu Aug 14, 2014 6:31 am

Re: L2J Architecture

Post by Sacrifice »

Nice explanation... ;)
DevOps and Java Developer using Eclipse, Java 21, MySQL 8.0+
User avatar
Gladicek
Posts: 634
Joined: Wed Jan 19, 2011 6:25 pm
Location: Czech Republic

Re: L2J Architecture

Post by Gladicek »

Nik wrote:
Gladicek wrote:"datapack is the newbie playground"

I hate you Nik for this! :kappa:
Thats why we love the people playing there with quests and crap :D Working there doesn't mean you don't put as much effort and thought as it is done in core. It only means that some people just don't want to play with fire :D:D:D
But speaking about the subject, it is true that datapack is really for newbies, as well as the whole core. The place where real developers hang is no other than the ancient com.l2jserver.gameserver.ai :kappa:
I'm offering 5 kappas for the first real developer that manages to modernize that place :D:D

If you wanna touch DP part, then you have to change core aswell. So many missing or totally wrong codes in L2j core. Everytime you change something in core and see how bad it is. You just wanna exit eclipse as fast you can...otherwise your brain will blow up.
ImageImage
L2J retired
Nik
L2j Veteran
L2j Veteran
Posts: 629
Joined: Fri Apr 18, 2008 9:09 pm

Re: L2J Architecture

Post by Nik »

Looks like someone hasn't dealt with russian based packs to see that exiting eclipse isnt enough :D
Playing a game where you know how every single mechanism works is quite satisfying.
Its the main perk that a gamer-developer has :D
User avatar
Gladicek
Posts: 634
Joined: Wed Jan 19, 2011 6:25 pm
Location: Czech Republic

Re: L2J Architecture

Post by Gladicek »

I saw it, made a huge facepalm, made a barrel roll then realised that russians must be drinking vodka while they are making it. No way. :kappa:
ImageImage
L2J retired
User avatar
UnAfraid
L2j Veteran
L2j Veteran
Posts: 4199
Joined: Mon Jul 23, 2007 4:25 pm
Location: Bulgaria
Contact:

Re: L2J Architecture

Post by UnAfraid »

Well.. this is 12+ years old project, on which over 50 different developers have worked on.
Every single one of them had his own style of working, until few years ago there was no code quality reviews, it was all "If it works its fine", "Don't touch it if it works" and etc..

Creating such a map (diagram or whatever) is simply impossible task, the project is divided so much at some places, at some everything's put together, we've reworked like 30% of it for the past 4 years but still that's around 3000 classes, its not simple to describe what each of them is doing.

Maybe you can start with asking questions about what handles "what", how "that" work. It would be easier to explain.
Image
LasTshaMAN
Posts: 12
Joined: Wed Nov 04, 2015 10:38 pm

Re: L2J Architecture

Post by LasTshaMAN »

Thanks, Nik, nice introduction!

UnAfraid, I completely agree that everyone, who changed something in the code, saw the project in his/her own way. I get that such circumstances made a lot of tangles and nets in the code. But I believe, at least some sub-modules do have a distinct shape. There are quite a lot of packages as well as "powerful" classes under the "gameserver" package, each of which, I think, represents a separate concept with some interface and internal structure.
It would be nice to have a 10-sentence description for each of those sub-modules.

But, for starters, I would like to understand the interface that the server provides for the client. Namely, the "login server" and "game server". They seem to be represented by the "loginserver" and "gameserver" packages respectively. I don't understand the way they interact with each other. They both have the "main" functions inside their according leader-classes from which I draw the conclusion that these modules can work in isolation of each other.
There are also some other classes with "main" methods inside, which give "l2jserver" module another "entry points".

Thus, I'd like to know, what happens when "l2jserver" starts ? Both the "login server" and "game server" start ? With whom of these does the client interact and what is the chronological sequence of these interactions since the first client-server interaction up until the moment when the human-player on the client side is able to move his character after he logged on? Do the "login server" and "game server" interact in some way ?
User avatar
UnAfraid
L2j Veteran
L2j Veteran
Posts: 4199
Joined: Mon Jul 23, 2007 4:25 pm
Location: Bulgaria
Contact:

Re: L2J Architecture

Post by UnAfraid »

Login Server is listening for client connections on 2106 port and on 9014 for Game Server connections.
Login Server handles client authentication, username and password validation, as well as game server access, when user is validated and able to proceed to the game server login generates two keys and gives them to client which gives to game server (and it verifies them with login server) and there Login Server ends his job.

They are made in separate packages for complete isolation in fact when you build project it only includes the required packages to each jar (You can see build.gradle)

There are multiple entry points because of some tools, like database installers, game server registration, account manager, etc..

However most important classes are as Nik mentioned L2PcInstance, L2Playable, L2Character, L2Object
L2PcInstance - is the Player server representation it keeps all its data and handles most of player specific operations
L2Playable - is the Player or Pet/Summon representation its fairly short you can see it no need of additional information.
L2Character - thats the main class of all creatures in game starting with players, pets/summons, npcs, monsters, static objects, etc.. all what can move, attack, etc..
L2Object - thats the master class of all childs mentioned above it includes even Items (cause they can be dropped on the ground)

Skill - thats the skill class contains all the data of specific skill and most of its logic (activation for example)
AbstractEffect - thats the effect abstraction class it handles activation, deactivation, over-time logic of each of skill's effects (All implementations are located in Datapack data/scripts/handlers/effecthandlers)
CharEffectList - Thats the buffs container and manager

L2Item - thats the master class of all items it contains mostly data almost no logic within it splits into L2Weapon, L2Armor, L2EtcItem.
The logic behind L2Item is mostly handled with Item Handlers which are located in Datapack data/scripts/handlers/itemhandlers

Quest is the master class of all quests and datapack scripts it has plenty of event listeners that u can work with check com.l2jserver.gameserver.model.events.impl thats all available events
There are multiple ways of using them: Annotations, pre-made methods of AbstractScript, manual listener registration.
In Datapack u can find example of listeners usage at custom/listeners/ListenerTest
Image
User avatar
lozhar
Posts: 21
Joined: Fri Sep 11, 2015 11:16 pm

Re: L2J Architecture

Post by lozhar »

UnAfraid wrote:Login Server is listening for client connections on 2106 port and on 9014 for Game Server connections.
Login Server handles client authentication, username and password validation, as well as game server access, when user is validated and able to proceed to the game server login generates two keys and gives them to client which gives to game server (and it verifies them with login server) and there Login Server ends his job.

They are made in separate packages for complete isolation in fact when you build project it only includes the required packages to each jar (You can see build.gradle)

There are multiple entry points because of some tools, like database installers, game server registration, account manager, etc..

However most important classes are as Nik mentioned L2PcInstance, L2Playable, L2Character, L2Object
L2PcInstance - is the Player server representation it keeps all its data and handles most of player specific operations
L2Playable - is the Player or Pet/Summon representation its fairly short you can see it no need of additional information.
L2Character - thats the main class of all creatures in game starting with players, pets/summons, npcs, monsters, static objects, etc.. all what can move, attack, etc..
L2Object - thats the master class of all childs mentioned above it includes even Items (cause they can be dropped on the ground)

Skill - thats the skill class contains all the data of specific skill and most of its logic (activation for example)
AbstractEffect - thats the effect abstraction class it handles activation, deactivation, over-time logic of each of skill's effects (All implementations are located in Datapack data/scripts/handlers/effecthandlers)
CharEffectList - Thats the buffs container and manager

L2Item - thats the master class of all items it contains mostly data almost no logic within it splits into L2Weapon, L2Armor, L2EtcItem.
The logic behind L2Item is mostly handled with Item Handlers which are located in Datapack data/scripts/handlers/itemhandlers

Quest is the master class of all quests and datapack scripts it has plenty of event listeners that u can work with check com.l2jserver.gameserver.model.events.impl thats all available events
There are multiple ways of using them: Annotations, pre-made methods of AbstractScript, manual listener registration.
In Datapack u can find example of listeners usage at custom/listeners/ListenerTest
Quite an intuitive architecture, i think it's a good one. Considering that lots of developers have been working on it over the course of many many years.
LasTshaMAN
Posts: 12
Joined: Wed Nov 04, 2015 10:38 pm

Re: L2J Architecture

Post by LasTshaMAN »

Login Server is listening for client connections on 2106 port and on 9014 for Game Server connections.
Login Server handles client authentication, username and password validation, as well as game server access, when user is validated and able to proceed to the game server login generates two keys and gives them to client which gives to game server (and it verifies them with login server) and there Login Server ends his job.

They are made in separate packages for complete isolation in fact when you build project it only includes the required packages to each jar (You can see build.gradle)
It took me quite some time to find how things described above are accomplished in the code. But I still don't understand, why the login process was made in such a complex way(may be complex is not the right word, consider repetitive instead).

First, does anybody here know why NCZ0ft made client to authenticate through one socket and proceed with game activities connecting through another socket ? I don't see any good reason for this. Why couldn't they just connect client through one socket with server, making login activity just as a part of the client-server interaction process ?

Second, I don't see any good reason for making repetitive actions. Namely, client performs authentication at login server and then client basically performs authentication again at game server(this game server authentication is the check conducted by game server via communicating with login server). Does something prevent me from making this client, login server, game server triplet just client, server with login part of the communication process ?
Post Reply