Aujourd'hui, l'état des lieux du jeu n'est pas particulièrement bon :
- les nouvelles fonctionnalités mettent énormément de temps à arriver et sont également très souvent bugées,
- les bugs mettent des années à être corrigés,
- des fonctionnalités banales mais sympathiques sont manquantes, et certaines sont bloquées dans certains contextes.
Entwell est une petite entreprise et ne semble pas performante, de notre côté, NosTale contient quelques personnes qui ont des connaissances suffisantes en informatique permettant la modification du logiciel client que je vais décrire ci-dessous.
Ils ont une roadmap et semblent vouloir s'y tenir à la lettre.
Nous avons de bonnes suggestions, qui pour la plupart sont tellement "banales" (mais nécessaires !) qu'elles ne sont pas remontés, par espoir de voir une grosse suggestion arriver.
Une proposition visant à résoudre ces problèmes est l'autorisation de modifier le logiciel client.
Premièrement, afin de pouvoir donner son point de vue sur le sujet, il est important de comprendre l'architecture d'un MMORPG. NosTale est constitué de deux principaux logiciels : le logiciel client (celui que vous avez chez vous, qui vous montre la carte, etc) et le logiciel serveur qui vous permet de jouer en réseau et que vos actions soient vérifiées (qu'il ne soit pas possible de taper du 15k en étant aventurier level 1, par exemple).
Il est pour nous, joueur, impossible d'influer sur le code de ce dernier. Il est donc également impossible de pouvoir se créer des stuffs R8+10 ou ce genre de choses.
Par contre, il est possible d'influer sur le premier, le client, mais nous sommes, de ce fait, limités : il est impossible de corriger certains bugs (comme les crashs, par exemple) ou d'ajouter certaines fonctionnalités (supprimer des quêtes secondaires). Mais nous pouvons par exemple retirer le bug des activités familiales, celui des drops, l'impossibilité de ctrl+z en combat (sans casser l'animation) ou ajouter des fonctionnalités (comme la fameuse fiche statistique qui a été refusée, ou un compteur de dégâts, ...). Les possibilités, bien que limitées, du point de vue architecturale, sont énormes et peuvent influer sur tous les domaines : PvE, PvP, raids, drop, ...
Deuxièmement, oui, il est possible de faire des choses "mauvaises" pour le jeu (les no stun/no delay, typiquement), c'est pourquoi il sera impératif que cela soit réglementé, vérifié et analysé par Gameforge avant d'être installé sur le jeu, et pourquoi pas les mettre open-source également, afin de permettre à d'autres personnes de les améliorer.
En acceptant certaines propositions, le jeu ne pourrait que mieux s'en sortir : moins de bugs, plus de fonctionnalités, moins de dépendance à Entwell.
Je précise également qu'une modification du logiciel client ne demande aucune ligne de code par Entwell, les modifications nécessaire pour la mise en marche de ce projet est uniquement une modification des termes de la licence NosTale (entre Gameforge et Entwell), et peut-être des CGU. Elle n'est donc pas censée rentrer dans la roadmap d'Entwell et ne freinera donc aucunement leur rythme effréné.
World of Warcraft a instauré un système d'add-on (il y a plus de dix ans).
Bien qu'évident, il me semble également intéressant d'énoncer la non-exclusivité d'un projet tel que celui-ci :
Display More- AddOns must be free of charge.
- AddOn code must be completely visible.
- AddOns must not negatively impact World of Warcraft realms or other players.
- AddOns may not include advertisements.
- AddOns may not solicit donations.
- AddOns must not contain offensive or objectionable material.
- AddOns must abide by World of Warcraft ToU and EULA.
- Blizzard Entertainment has the right to disable AddOn functionality as it sees fit.
Si la définition d'add-on vous semble floue ou inconnue : https://fr.wikipedia.org/wiki/Plugin
Ensuite voici un exemple sur WoW :
Sans add-on : https://i.imgur.com/mJ8Zg40.jpg
Avec add-ons : https://static1.millenium.org/…ce-de-bajheera-full-2.jpg
On peut voir sur ce second screen un "damage metter" (bas droite), un chat plus détaillé, et d'autres petites modifications, qui ne sont pas natifs au jeu.
En modifiant le logiciel client, on arrive au même résultat.
Dans le cas de WoW, il y a une API qui est mise a disposition pour pouvoir développer des add-ons, ça permet d'encadrer ce avec quoi l'add-on va pouvoir interagir ou non.
Dans le cas de ma suggestion, il n'est pas question de téléchargement de fichier, mais bien de code proposé par la communauté, à Gameforge qui oui ou non l'incorpore dans nos petits exécutables.
Questions / Réponses
Comment développe-t-on un Add-On ?
Dans l'état actuel de la suggestion, c'est-à-dire, sans système de plugin (puisqu'il serait à créer, étant donné qu'on ne souhaite pas qu'Entwell code quoi que ce soit pour cela), ce serait fait en incorporant et/ou en modifiant certains morceaux de codes à des endroits précis. Ça requiert quasi systématiquement de l'assembleur, qui est un langage assez complexe aux premiers abords, c'est pourquoi il n'est pas question de rentrer dans le vif du sujet, sur cette suggestion. Cette question (et celles suivantes) trouveront davantage de réponses si cette suggestion est acceptée.
Quels outils doit-on utiliser ?
- Un IDE qui permet d'inclure du code assembleur (Visual Studio, par exemple)
- Un langage qui permet d'inclure du code assembleur (C, C++ le permettent, je ne connais pas suffisamment les autres pour pouvoir en donner d'autres)
- Un désassembleur (Ghidra, OlyDbg, CheatEngine, X64dbg) : ils permettent de voir le code assembleur de NosTale
- Un débugueur (OlyDbg, CheatEngine, X64dbg) : il permettent de suivre le déroulement des fonctions, de voir la valeur des variables, les vtables et tout un tas de truc qui te permettent de débuger/ajouter des fonctions.
- De la patience (beaucoup)
Quel intérêt cette suggestion peut-elle présenter à la communauté ?
Deux principaux rôles :
- Ajouter/Débloquer/Débuger des fonctionnalités
- Moins dépendre d'Entwell
On peut voir par exemple, très fréquemment sur le Discord, des gens se plaindre des phrases familliales qui bugent, des bugs de drops également. Sachez que ces bugs ci sont "fixables" par les joueurs, à l'aide des outils ci-dessus.
Il y aura une review pour chaque feature, ou ce sera plus "cool" ?
Il ne doit pas y avoir de laxisme dans le traitement des features, chaque feature doit être vue, analysée, disséquer et chaque morceaux obscures, mis en lumière. Il ne doit y avoir aucune façon de mettre du code malicieux.
Il est également important de noter que si Entwell fait un changement dans son code, cela peut affecter notre propre code (l'empêcher de marcher, j'y reviens plus tard) et qu'il est donc également nécessaire de le tester post-modification d'Entwell.
Concernant la conformité, et la transparence du code ; vous souhaitez le prouver comment ?
Il faut différencier les bugs des fonctionnalités, dans ce cas.
La correction de bug signifie très souvent modifier le code d'Entwell, et, rarement, en ajouter.
L'ajout de fonctionnalité, c'est l'inverse, on modifie un peu le code d'Entwell, et on en ajoute beaucoup.
Dans le cas des fonctionnalités, généralement c'est très compréhensible, il n'y a donc pas réellement besoin d'explication sur le code en lui-même, mais bien sur les points communs à la correction de bugs, qui est : que signifie les différentes valeurs dans le code ?
A titre d'exemple, voici le code qui permet le Ctrl+Z en combat (sans casser l'animation)
- DWORD oldProtect; // Stocke la permission (Read/Write/Read&Write)
- BYTE *address = 0x...; // Stocke l'adresse (1)
- VirtualProtect(address, 2, PAGE_EXECUTE_READWRITE, &oldProtect); // Modifie la permission (permet l'écriture, et la lecture, de la ram)
- memset(address, 0x90, 2); // On modifie, à l'adresse (1), 2 (2) octets et on leur met pour valeur 0x90 (3)
- VirtualProtect(address, 2, oldProtect, &oldProtect); // On remet la permission du début : Read only
Le code est court, et peu compréhensible tel quel. (Mais on est effectivement loin de ce qu'a envoyé Evilounet !)
Nous avons trois "variables" :
1) l'adresse : c'est grosso modo l'endroit dans la ram où il y a le code que tu veux modifier
2) le nombre d'octets à modifier, 2 dans notre cas
3) la valeur que tu veux mettre dans ces octets (dans notre cas, 0x90)
Il est nécessaire, pour comprendre ce code, de comprendre comment l'adresse a été récupérée, comment on est arrivé à ce nombre de "2", et à cette valeur de 0x90. Il est également nécessaire de savoir ce que l'on a remplacé, puisqu'il s'agit ici bel et bien d'une modification de code.
Je ne rentre évidemment pas dans les détails ici sur comment ces valeurs ont été trouvées.
En réalité, ce code ci devrait, suite à la validation de Gameforge, ne même plus exister et être intégré directement dans notre exécutable.
Pour les fonctionnalités, la partie "basique" (gestion des fenêtres, etc) ressemblera, pour une partie, à ça également. Mais ce n'est à faire qu'une fois, donc qu'une vérification, et les "joueurs" n'auront même plus besoin d'y toucher, à moins qu'Entwell casse tout.
L'ajout de code se fait généralement uniquement dans un langage "plus appréhendable" que l'assembleur. C'est donc moins cette partie qui posera problème.
Mais comme dit plus haut : chaque morceau de code doit être vérifié, ça ne fait pas exception.
Les fonctionnalités développées par les codeurs se trouveraient sur un repository public ?
Je ne vois pas de mauvais point quant à mettre ce projet en open-source. Au contraire, donc pour moi c'est un gros oui, j'imagine que pour Gameforge, ce sera également un oui.