Javascript HetwanTS - L’émulateur pour apprendre

Inscrit
14 Mai 2019
Messages
25
Reactions
6
#22
Bonjour à tous, des nouvelles un peu !

Dans un soucis de rapidité le projet a été finalement portée sur du TypeScript converti en JS et exécuté en NodeJS, ça ne change absolument rien a l’architecture imaginée et la manière de le faire, c'est simplement pour être plus rapide pour sortir un serveur de test.

Une fois assez avancé il sera backporté en C# et LES DEUX versions seront partagées à la fin.

L'avantage pour moi de le faire en TypeScript est que je peux faire les outils et facilement les liés les un aux autres. Une aisance que j'ai moins en C#.

Les deux versions seront de la même stabilité globalement, et ça vous donnera une opportunité de voir deux approches différentes en fonction des langages (au niveau du code, pas de l'architecture).

Tant que j'y suis le partage des outils va continuer avec bientôt (d'ici ~ 1 semaine) un éditeur D2O COMPLET qui ressort des fichiers parfait et utilisables directement en jeu après (la table de recherche notamment que l'outil de STUMP ne gérait pas)

Voilà c'est tout ! Non je déconne, changelog time :

- Combats fonctionnels
- Sorts fonctionnels à 90% (manque quelques effets liés aux bombes et aux items ayant des effets en combat)
- Pathfinding (j'avais la flemme avant mdr)
- Début du FM
- Gestion des objets utilisables
- Gestion Zaap/Zaapis
- Patchs et autres notamment pour la stabilité (les fichiers D2O et DLM ne sont désormais plus stockés au démarrage de l'émulateur mais dans un cache spécial en fonction du type, pour exemple la search table est désormais utilisée pour les D2O)

Voilà, A+
Yup, J'ai pas trop compris ton dernier point par rapport au d2o/stabilité pourquoi as-tu besoin de charger les d2o ?
 

Hetarnam

Rédacteur
Inscrit
2 Octobre 2016
Messages
50
Reactions
138
#23
Yup, J'ai pas trop compris ton dernier point par rapport au d2o/stabilité pourquoi as-tu besoin de charger les d2o ?
Je ne les charge pas vraiment, enfin seulement une partie, la search table et je garde une main sur le buffer du fichier pour naviguer et aller chercher les infos dedans, ça me sert à aller cherche le template des items, où alors des PNJ's, pleins d'infos utiles que je peux extraire des D2O au besoin
 
Inscrit
14 Mai 2019
Messages
25
Reactions
6
#24
Je ne les charge pas vraiment, enfin seulement une partie, la search table et je garde une main sur le buffer du fichier pour naviguer et aller chercher les infos dedans, ça me sert à aller cherche le template des items, où alors des PNJ's, pleins d'infos utiles que je peux extraire des D2O au besoin
Tu ne stockes pas ces infos dans la bdd ?
 

Hetarnam

Rédacteur
Inscrit
2 Octobre 2016
Messages
50
Reactions
138
#25
Non sinon c'est pas vraiment modulaire :)

Tu prends juste tes D2O de ton client, et hop tu glisse dans le dossier de lancement, ce qui fait qu'à chaque nouvelle version t'as pas besoin de tout exporter en DB etc, et si tu modifie tes D2O ça sera aussi beaucoup plus simple
 

Hetarnam

Rédacteur
Inscrit
2 Octobre 2016
Messages
50
Reactions
138
#26
Bonjour à tous ! Des petites nouvelles, suite à une longue réflexion et à l'aide de quelqu'un du forum qui se reconnaîtra s'il passe par là (merci encore) il y a un petit revirement de situation :
L'émulateur sera désormais divisé en micro-services.

Ça veut dire quoi d mikro servic ?
En gros chaque micro-service représentera une partie du jeu (Character, Item, Environment, Monster, NPC, etc) qui tourneront chacun séparément.
Il y aura donc 3 parties majeures :
- Login server (C# .NET Core 3.0), qui s'occupera de récupérer les sockets arrivants, traiter les messages (uniquement la partie header) et redirigera une requête HTTP à la partie majeure suivante - le middleman
- Le middleman (Rust), qui s'occupera de récupérer et dispatcher les requêtes HTTP qui seront sous cette forme :
POST /serialize/{gameServerId?}/{messageId} --data {JSONMessageContent} -> dispatcher vers login/game server
POST /deserialize/{messageId} --data {binaryMessageContent} -> dispatcher vers services
Il prendra en argument de lancement un protocole au format JSON qui correspond au protocole de Dofus (un outil et une doc seront fournie pour expliquer comment le générer si vous souhaitez changer la version compatible du client)
- Le(s) game server (C# .NET Core 3.0), qui prendra en charge les game clients

Ensuite il y aura les micro services, qui recevront des requêtes de ce genre :
POST /{gameServerId?}/{messageId} --data {JSONMessageContent}

Les micro services auront aussi le protocole JSON du client, ainsi qu'un autre qui sera le métier.
Les messages métiers seront définis par chacun des micro-services, accessibles séparément d'une éventuelle compilation (en fonction du langage utilisé pour le micro-service)
Il y aura des filtres possibles à spécifier dans la configuration de celui-ci si vous voulez faire vos propre override. Par défaut je fournirait un boilerplate en TypeScript, et un autre en C#.

Ça change quoi du coup ?
Beaucoup de choses. Par exemple si vous ajoutez une fonctionnalité, vous n'avez pas a redémarrer votre serveur au complet, simplement le(s) service(s) impactés.
C'est beaucoup plus flexible également, vous pouvez démarrer plusieurs fois le même service, et grâce à un système de load-balancing le serveur choisira automatiquement le moins occupé de tous pour effectuer les actions.

Tout ça est en développement depuis récemment seulement, ça ne sera pas pour tout de suite mais ça change beaucoup de choses à l'aventure car, incluant ça, je peux vous partager l'émulateur et quelques micro-services au compte-goutte sans pour autant vous donner tout.

Je déclare donc qu'une fois le premier micro-service terminé (Authentication) ainsi que les parties majeures, je releaserait l'émulateur en version 1, et vous aurez la possibilité d'ajouter les micro-services que vous voulez.

Le code déjà fait actuellement sera bien évidement réutilisé pour me faire gagner du temps.

Je fournirais assez de documentation pour que les courageux d'entre vous s'attaquent à faire vos propre services, et créer l'émulateur qui VOUS CONVIENT.

Voilà c'est tout, a+ les gens !
 
Inscrit
21 Juillet 2018
Messages
8
Reactions
1
#27
J'espère qu'un jour je pourrai essayer cet émulateur, il semble excellent!
 
Inscrit
2 Octobre 2016
Messages
50
Reactions
138
#28
Bonjour à tous ! Petit up intermédiaire en prévision d'un gros update, j'ai donc commencé cette nouvelle architecture, c'est un peu long car je travaille sur d'autre chose la journée mais ça avance.

Le projet à donc été migré à 100% en typescript micro-services à l'aide d'une librairie appelée "Moleculer", elle donne un environnement pour faire des services vraiment intéressants et fit parfaitement au projet.

Pour le moment j'ai environ 10 services, assez pour avoir pu établir la connexion game/login, déplacement en jeu, quelques NPC's et autre.

Premier retour sur l’architecture, c'est rapide a développer, très rapide. Ne pas avoir à se re-logger entre chaque update est vraiment un avantage, et ça se ressent sur le temps à effectuer pour chaque fonctionnalité.

Second retour, c'est rapide tout court, niveau performance. Ce projet pourra aussi bien tenir 15 clients, que 10 000 sans aucun soucis, après quelques tests et update, j'ai pu faire tourner 8000 clients qui bougent toutes les secondes et envoient des messages sur le chat, pendant 72h avec seulement une instance de chaque service, avec un délai de transmission interne < 5ms. C'est un coût comparé à une architecture monolithique threadé qui pourrait faire la même chose en 1 ou 2ms par requête, mais au final si on prend en compte la facilité à ajouter des nouvelles fonctionnalités et les tester, c'est largement compensé. Avec 2 instances de chaque service on peut monter à environ 15 000 clients sans lag. Vous faites rapidement le calcul, ça veut dire que chaque instance de service peut handler en moyenne 7000 clients sans broncher, ce qui est vraiment pas mal, prenant en compte que tout ça est en typescript et donc mono-thread pour la plupart des choses (à par le pathfinding des familles, mais je reviendrais là dessus)

Dernier retour, c'est propre. Je veux dire par là que avec la doc auto-générée par TS, les interfaces disponibles pour avoir le protocole de chaque service, ou le protocole Dofus, rendent le tout vraiment simple à prendre en main, en 5 minutes vous pouvez avoir un nouveau service prêt en tourner avec vos nouvelles idées.

Je posterais bientôt quelques screens des tests, du jeu en lui-même et de comment c'est fait, tout ça tout ça.

PS: Je vais aussi vous introduire votre nouvel ami, dofus-io, une librairie TS permettant de manipuler n'importe quelle ressource du jeu, d2i, d2o, dlm etc, ainsi que des fonctions utiles comme le pathfiding et le parser pour les network messages

A plus les gens !
 
Inscrit
20 Decembre 2012
Messages
135
Reactions
0
#29
Bonjour à tous ! Petit up intermédiaire en prévision d'un gros update, j'ai donc commencé cette nouvelle architecture, c'est un peu long car je travaille sur d'autre chose la journée mais ça avance.

Le projet à donc été migré à 100% en typescript micro-services à l'aide d'une librairie appelée "Moleculer", elle donne un environnement pour faire des services vraiment intéressants et fit parfaitement au projet.

Pour le moment j'ai environ 10 services, assez pour avoir pu établir la connexion game/login, déplacement en jeu, quelques NPC's et autre.

Premier retour sur l’architecture, c'est rapide a développer, très rapide. Ne pas avoir à se re-logger entre chaque update est vraiment un avantage, et ça se ressent sur le temps à effectuer pour chaque fonctionnalité.

Second retour, c'est rapide tout court, niveau performance. Ce projet pourra aussi bien tenir 15 clients, que 10 000 sans aucun soucis, après quelques tests et update, j'ai pu faire tourner 8000 clients qui bougent toutes les secondes et envoient des messages sur le chat, pendant 72h avec seulement une instance de chaque service, avec un délai de transmission interne < 5ms. C'est un coût comparé à une architecture monolithique threadé qui pourrait faire la même chose en 1 ou 2ms par requête, mais au final si on prend en compte la facilité à ajouter des nouvelles fonctionnalités et les tester, c'est largement compensé. Avec 2 instances de chaque service on peut monter à environ 15 000 clients sans lag. Vous faites rapidement le calcul, ça veut dire que chaque instance de service peut handler en moyenne 7000 clients sans broncher, ce qui est vraiment pas mal, prenant en compte que tout ça est en typescript et donc mono-thread pour la plupart des choses (à par le pathfinding des familles, mais je reviendrais là dessus)

Dernier retour, c'est propre. Je veux dire par là que avec la doc auto-générée par TS, les interfaces disponibles pour avoir le protocole de chaque service, ou le protocole Dofus, rendent le tout vraiment simple à prendre en main, en 5 minutes vous pouvez avoir un nouveau service prêt en tourner avec vos nouvelles idées.

Je posterais bientôt quelques screens des tests, du jeu en lui-même et de comment c'est fait, tout ça tout ça.

PS: Je vais aussi vous introduire votre nouvel ami, dofus-io, une librairie TS permettant de manipuler n'importe quelle ressource du jeu, d2i, d2o, dlm etc, ainsi que des fonctions utiles comme le pathfiding et le parser pour les network messages

A plus les gens !
Propre !
 
Inscrit
4 Juillet 2017
Messages
1
Reactions
1
#30
I had already given up with the d*(d-word) emulation, but that cheered me up, I will definitely try to help make it grow!
 
Inscrit
2 Octobre 2016
Messages
50
Reactions
138
#31
Hellooow à tous, petit point sur l'architecture et les avancements.

Donc l'architecture complète de l'émulateur sera dans un seul dossier dans lequel vous placerez vos services, et vous pouvez les lancer facilement avec une commande (tout sera expliqué dans la doc ne vous inquiétez pas!)

Vous aurez également quelques autres dossiers:
- dofus-io-{version} -> correspondant à la librairie associé à la version du jeu que vous aurez choisi, elle contiendra tout les éléments pour interagir avec le client (protocole, gestion des fichiers du jeu, signature RSA etc)
- hetwan (c lému ici lol)
- updater (ici le programme magique, vous donnez un invoker en entrée, en sortie vous obtiendrez la librairie dofus-io associé, mais également un invoker patché avec une clef rsa généré automatiquement, il y aussi quelques autre commandes disponibles pour générer le hash de vos hosts (à entrer en config), et quelques autres trucs sympa)
- manager (la vue react qui vous permet de contrôler l'état du serveur, des services, et d'envoyer des actions aux clients)

Vous pourrez avoir plusieurs versions supportés donc en fonction du/des librairies io que vous avez, ce qui rend donc possible le support de plusieurs versions si nécessaire, mais vous devrez faire gérer vos DB pour ne pas avoir de conflit de données de 2 versions différentes)

Pour le moment je travaille majoritairement sur l'updater, actuellement un update de version (sans changer les code des services) prend environ 10 minutes (ça va franchement, ça fait le taff à votre place)

Les services reçoivent des events du type:
- dofus.client.data (raw data du message)
- dofus.client.message (message passé par le serializer automatique, qui vous sort une belle classe du message déjà rempli, magique)

Associé aux events vous avez un contexte qui vous permet de savoir de quel client il s'agit, de quel serveur il provient (game-{id} ou login) et aussi les contextes définis par les autres services, ça vous permet de garder une trace de où votre client est passé et vérifier que les messages que vous recevez sont bien en accord avec l'état du contexte que vous avez (si le client est en combat, c'est pas normal de recevoir un message d'ouverture d'HDV par exemple)

Tout avance à son rythme, c'est un peu long je fais au mieux m'en voulez pas :'(

Je vous enverrais des screens bientôt !

A+
 
Haut Bas