Ok, I will try to summarize part of what I have learn about Graal Reborn (GR).
Mostly, inside architecture.
I suspect what I will say will be known by most, I am sorry, I came to GR without passing by Graal, and I am old.
So I must have learn very slowly. In fact, this will probably show how much I don’t understand things,
as much as it could help a newbie learn about GR.
First let’s present most components very very very briefly:
-client: written with an old directx version, allows you to play the game
-gserver: that’s the game server. It load levels, and knows about NPC (non-player characters).
-listserver: As the name says, it contains the list of servers, and allows to connect and edit players profiles
-The remote control. As the name says, it allows to control the gserver remotely (from an other computer).
-The NPC server, is optional, and not really used in Graal Reborn yet because developing versions are incomplete.
It is a special client, that execute scripts for the NPCs for all clients, rather than having each client execute them.
In fact, scripts can have a server-side and a client-side. NPC server would execute the server-side part of scripts.
NPC are not only monsters, bar tenders, shop tenders, but can be any visual object that react to others (players or npc).
In fact, GR only allows to attach scripts to npc. And so a lot of NPC are not visible, and are created only to set some
properties of a level, or tell to do things when a player enter the level.
So, let’s summarize again the very big picture.
At the start of the world, the listserver is launched. Normaly, the Graal Reborn forums, give instructions how to
get and setup your listserver account with same name as GR forum, but with a possibly, hopefully different password.
The listserver wait for clients, or gservers to connect to it.
Gserver(s) when launched, connect to the listserver.
And disconnect (or are disconnected by listserver if not responding for too long) before quitting.
Because of that, listservers have a list of running gservers.
Then clients can connect to the unique listserver (the listserver url is hardwired in the client).
Client ask listserver to verify their account (username + password).
BTW, the current clients sent in the clear (not encrypted account info), but our listserver have a “new” feature
to check account information in encrypted format, which our future own client could use.
So, if the listsever is happy with the account (by example it is not globally banned -ban on listserver is global ban-),
then the client will have the possibility to request the list of servers from the listserver.
In fact, our listserver can be compiled with an option that avoid using MySQL server. In this mode, the listserver is
always happy with the username and password whatever the password given. Hopefully, the listserver GR use, is not compiled
with this NO_MYSQL option.
I now believe it keep connected to the listserver (by example, to update player profile).
So, the listserver knows about the list of running gservers, but also of connected clients (players).
The human player choose one of the server he wish to play, and the client open a connection to the corresponding gserver.
From there, the client and the gserver will be connected together by a (TCP?) connection.
So at least these three connections exist for GR:
client <–> listserver
client <–> gserver
gserver <–> listserver
Optional connections are:
remotecontrol <–> gserver
npcServer <–> gserver
If the npcServer <–> gserver connection exist, the gserver will not send the serverside part of the scripts to the clients.
But rather send them to the npcServer to be executed.
Components communicate through packets. Which is basically a special string (CString) that knows how to receive, parse, send, compress and uncompress packets. The first byte of each packet identify the type (command) of the packets, so that in theory up to 255 type of commands may exist.
gserver will receive (in packets) from each client (player), and from the listserver (often refer to simply as SV in the code).
listserver will reseive (in packets) from each gserver and each clients.
gserver can and do send a numbers of (out packets) to each clients (players), and to the listserver.
listserver can and do send a numbers of (out packet) to each gserver and each clients (players).
It make very much sense to expect that for each in packets from a component, there exist an out packet in the other component.
It could possibly make code better if the .h file would refrain to call them in or out packets, and use the same .h file.
Code could call the function stored in inDispatcher[id] … thinking. There is no outDispatcher, because packet are sent when needed, but packets are received “asynchronously”.
I intend to show where to find these in the code, in a future post.