Traduction du log de la discussion du 19 Septembre avec Archaego
(Hardcore Ruleset)
Archaego a accordé un peu de son temps à Neverwinter Vault pour répondre à quelques questions concernant les mondes persistants et les scripts qu’il a créé pour NWN - 19 Septembre 2002.
Accès direct à une question :
1/ Peux-tu donner à nos lecteurs quelques informations concernant ton passé et ce que tu fais dans la vie ?
Bonjour à tous, beaucoup me connaissent d’après l’événement HCR (Hardcore Ruleset) :). HCR a débuté comme un petit projet pour gérer les saignements et a simplement évolué depuis. Maintenant ça prend entre 1Mo pour la base et plus de 13Mo avec tous les add-ons, et ça continue d’augmenter. Personnellement je suis dans l’US Navy. J’y suis depuis en gros 16,5 ans et il me reste à peu près 4 ans avant la retraite. Je suis un codeur autodidacte de la vieille époque du TRS-80. Je joue à D&D depuis 25 ans environ (j’en ai 35 maintenant) et je dirige des Donjons Multi-joueurs depuis 10 ans. J’ai été un GM officiel pour Underlight, et conseiller pour UO, AO, et EQ, et je code comme une façon de penser, et non dans un langage en particulier.
Retour aux questions
2/ Commençons par les mondes persistants. Disons que je veuille en débuter un, comment dois-je faire ?
Rien, absolument rien, n’est plus important que les documents Vision. Ils ont depuis peu une mauvaise réputation dans l’industrie, à cause des personnes qui pensent qu’ils sont comme les 10 commandements : gravés dans la pierre. Mais ils doivent être un document de base que vous écrivez avec votre équipe avant même de commencer la construction du monde. Ils doivent couvrir les principaux aspects de votre monde. Ils changeront bien évidemment avec votre expérience et vos désirs, mais si vous ne savez pas où vous allez, il est difficile d’y arriver.
Ensuite vient la construction proprement dite. Ma principale recommandation est de construire en premier lieu toutes les zones, l’éclairage, la musique (le son est vital) et les structures avant d’écrire la moindre ligne de code. Gardez à l’esprit ce dont vous avez besoin et la taille que vous voulez pour votre monde. Mais si vous codez au fure et à mesure, ce qui EST plus facile, vous finirez par dupliquer votre travail, et par avoir du code qui fonctionne différemment selon les zones. Ensuite vous aurez besoin d’établir le standard de codage selon lequel vous voulez que vos codeurs codent. Ensuite, commencez les alpha-tests avec des joueurs dont vous savez qu’ils vous donneront des retombées, et qu’ils n’entendent pas s’amuser.
Retour aux questions
3/ Pour la construction des modules, y a-t-il certaines choses à prendre en considération ? i.e. du fait que c’est un monde persistant.
Oui : le design, et de façon surprenante, les caractéristiques physiques. Vous DEVEZ connaître les limites de votre hardware. BW nous a bloqué avec un code limitant relativement les MPs, le plus gênant étant l'impossibilité de sauver des variables Locales sur les PJs. Ainsi vous devez connaître la taille de module pour laquelle votre serveur principal peut gérer la charge des joueurs. Et à quel point vous considérez votre module comme bon, puis le modifier en conséquence des actions qui s'y produisent.
Ensuite viennent les équilibrages. Il y a deux équilibrages fondamentaux à effectuer avant tout autre dans un MP.
Tout d'abord, le taux de montée de niveau. Je m'explique. Si j'ai un joueur qui joue 2 heures par nuit, 5 jours par semaine (la plupart jouent plus), combien de temps lui faudra-t-il pour atteindre le niveau 20... ou si vous utilisez un système d'xp étendue, quel temps lui faudra-t-il pour atteindre les repères : niveau 5, 10, etc.
Ensuite, l'économie. C'est la chose qui pourrait le plus ruiner un MP. Pendant les alpha/beta-tests, faites la TOMBER BAS, VRAIMENT bas, puis regonflez la au fure et à mesure. Le système standard de distribution des trésors de Biowre détruira à coup sûr l'économie d'un MP. Je recommande fermement à quiconque débute d'utiliser un système comme celui de compétences de commerce d'Ambrosia. Et rendez tous les objets de votre module modifiables ; les joueurs ne sauront peut-être pas comment les crafter, mais s'ils sont tous sur la même table/échelle, c'est beaucoup plus facile à équilibrer. Ensuite prévoyez vos sorties d'argent, ce pour quoi les joueurs auront à dépenser de l'argent.
Retour aux questions
4/ Quelle mesure utilises-tu pour déterminer la charge d'hardware et la distribution des trésors ? Tu as des chiffres ?
Pour la charge en hardware c'est difficile. Actuellement, Daggerford est un module de 50 Mo, mais fonctionnant dans un environnement Linux, il utilise 90% du CPU.
2125 nwn 19 0 129M 129M 3028 R 48.4 17.1 288:33 nwserver
C'est la charge actuelle d'un serveur alpha de base vide. Les nombres signifient qu'il utilise 129 Mo de mémoire. Et il utilise 48,4% du CPU sur un Pentium 800. La bande passante a de l'importance, mais pas autant que le hardware de votre machine.
De même pour les trésors. Vous DEVEZ prendre en compte les sorties d'argent, et les comparer aux entrées d'argent. Je vous recommande si vous le pouvez d'utilisez les pages du guide du MJ qui donnent l'expérience requise pour passer de niveau. C'est un bon début.
Retour aux questions
5/ Quels scripts recommenderais tu d'inclure ?
Hmm, ça c'est plus compliqué. Ca dépend de ceux qui sont disponibles à ce moment... Bien, ça dépend quelquepeu de l'usage. J'adore le DM Helper bien sûr. Des options qui devraient être dans le client mais qui n'y sont pas. HCR est bon, SI et seulement SI, vous désignez votre monde au challenge et recherchez le type de joueurs qui aiment ça. Et PERSONNE ne devrait utiliser la version de cuisine que j'ai publiée encore et encore. Parce que c'est trop, et vous ne pourrez pas concevoir avec tout en tête. Comme pour les autres scripts... ATS (le système de compétences de commerce d'Ambrosia) roxe, écrase tout, bien que si Mojo ne présente pas de nouvelle version bientôt, on doive s'en passer. C'est un système super puissant. D'autre part, le système de sous-races d'ALFA était si insurpassable et unique que je l'ai mis à la place du système de sous-race du HCR ; Shir'le a fait un très bon boulot. Et finalement, vous devez statuer sur la persistance. Vous avez en gros 4 façons viables de le faire :
Premièrement : PWDB, qui écrit une entrée vierge dans votre fichier log que vous couper/coller dans un fichier isolé dans votre module avant de le relancer. Bon, mais sur un très grand monde, le fichier log se lance à peu près 4 fois avant d'abandonner le double.
Deuxièmement : PWUM, qui utilise également un fichier log, est plus dynamique ; il "expire" les entrées, mais requiert que vous utilisiez un client externe.
Troisièmement : PW Itemizer : un petit système sympa qui vous permet de sauver des vriables persistantes de nature INT de 1 à 99 sur les PJs, ce qui est très bon pour les multiserveurs. Mais il nécessite un hakpak de 43 Ko (certains ont les hakpaks en horreur, et moi-même je m'en tient à distance).
Quatrièmement : Save game editing. Très chiant, piégé, a tendance a créer de mauvaises versions (donc faites toujours un backup de votre bonne version d'abord) mais marche, et vous savez que toutes vos variables sont sauvées. Mais Daggerford fait 130 Mo maintenant, et le temps de compilation serait de l'ordre de 2 heures.
Retour aux questions
6/ Quelle méthode utilises-tu pour Daggerford ?
PWDB, mais nous avons simplifié tout ce qui était permanent pour supporter un minimum, mais ca continue à utiliser d'énormes fichiers log de 2 Mo, et semble atteindre le point 4 (#4) puis s'arrête.
Retour aux questions
7/ Quelle a été ton expérience quant au bon fonctionnement des différents systèmes de script entre eux ? Pourrait-ce être le problème ?
Effectivement. Voilà le topo. Je "pense" script, je le regarde et le lit comme un livre. Je ne me préoccupe même pas du langage. Ainsi il m'est facile de voir où j'aurai besoin de couper et coller deux scripts OnEnter ensemble, plus particulièrement s'ils sont bien formatés. Mais pour un débutant, "capturer" les scripts peut être un cauchemar, par exemple l'installation de l'ATS... Ils disent de mettre une initialisation en haut du script oncliententer. Néanmoins si vous faites ça pour le HCR, les objets ATS sont supprimés dès leur création. Ainsi ce qui importe c'est d'être capable de lire les scripts, et ça peut prendre du temps ; vous n'avez pas besoin d'être capable d'écrire du code, mais au moins de lire des Si-Alors et de savoir ce qui se passe.
Retour aux questions
8/ As-tu rencontré des obstacles majeurs dans ton projet Daggerford ? Comment les as-tu surmontés ?
La permanence. C'est un énorme problème. Bioware avait laissé supposer que l'on pourrait un jour stocker des variables locales sur le personnage, ce serait un cadeau des dieux. En attendant, je considère le PW Itemizer ou PWUM pour alléger une partie de la charge de log, voire même les scripts Perl pour supprimer les sections logs au fure et à mesure que le module est joué (cauchemar).
Un autre problème est la TAILLE. JE HAIS les tailles par défaut de ce que Bioware nous a fourni, vous voyez ce que je veux dire si vous avez jamais essayé de faire correspondre un donjon 10x10 et une ancienne carte de modules. Tout est trop gros (bien que j'adore le Camera Hack). Donc Daggerford, un petit village entre Waterdeep et The Last Inn sort avec 50 Mo, est magnifique, et procurera beaucoup de plaisir, mais aussi les problèmes de taille. Je travaille également avec Krynn, et j'ai aidé Proving Grounds et d'autres, et la taille est toujours un problème. NWN était destiné à la conception de modules, pas de mondes.
Retour aux questions
9/ Penses-tu que ça résolve le problème définitivement ? Enregistrer les variables sur les personnages ?
Oui. A 100%. Si je pouvais faire ça, je ferais n'importe quoi avec un peu d'acharnement.
Retour aux questions
10/ Peux-tu nous donner une entrevue de ton nouveau projet de Module Hardcore ?
Le set de script Hardcore Modular doit être considéré comme la seconde génération du populaire Hardcore Ruleset. Pendant la construction du Hardcore Ruleset, beaucoup de personnes ont aimé les options qu'ils voulaient, mais n'ont pas aimé être obligés d'avoir beaucoup de code supplémentaire dont ils n'avaient aucun usage ; HCM résoud ce problème. Ce document sert de base pour les document utilisateur du HCM. Ainsi le HCM rendra les choses modulables. J'ai à peu près terminé la base du HCM, avec aucun add-ons pour l'instant, et dezippé il prend 43 Ko. On l'allègera en mettant un minimum de documentation dans le code, et beaucoup de code extérieur. Ensuite vous choisissez et prenez, comme dans un buffet, les scripts que vous voulez ajouter, ils s'emboiteront parfaitement, ou auront des instructions simples. Ensuite, pour activer ou désactiver une option que vous aurez ajouté, il vous suffira de poser son HCMA (un objet) dans la zone HCMStaging, et elle sera activée. Si pendant le jeu vous y allez et le rammassez, ça la désactive. Je ne peux pas faire plus simple et le faire comme Linux, où le seul code qui est dans votre kernel est celui que vous y avez ajouté.
Retour aux questions
11/ Peut-on intégrer cela facilement dans un module existant ?
Oui, j'ai inclus de crochets dans tous les Evènements Module pour le code existant si ça intéresse certains. Mais c'est petit et ça devrait marcher correctement. (c'est à peu près en 0.2 pour l'instant, et je devrais commencer à tester le premier add-on bientôt)
Retour aux questions
12/ Pour construire un monde persistant, y a-t-il des pratiques à éviter ?
Sans aucun doute. Coder avant la construction. J'adore coder, c'est pour ça que je ne construis pas. Il y a quelques concepteurs talentueux pas très loin, laissons les gens talentueux faire ce pour quoi ils ont du talent. Aussi, AUCUN d'entre nous n'est payé. Enfin, assurez vous que plus d'une personne peut suivre le planning que vous avez décidé.
Retour aux questions
13/ Prévois-tu d'accepter plus de 64 ou 96 joueurs sur Daggerford dans l'avenir ? Ou peut-être de créer des serveurs portails ?
Ca dépend, Krynn accepte plus de 64 joueurs actuellement, mais ils ont un serveur super rapide. DF table sur l'utilisation de plusieurs seveurs supplémentaires. Mais ça n'exclue pas le problème de la persistance.
Retour aux questions
14/ Vérifieras-tu la base du HCM pour qu'il soit sans bug avant de le publier, ou travailleras-tu au moins sur le débugage avant qu'il y ait d'autres add-ons ?
Je ferai de mon mieux. J'ai rencontré beaucoup de bugs de ce style avec HCR. Et on en revient au fait d'être payé. Les usagers finaux, malheureusement, sont des testeurs. Je n'ai pas d'équipe pour tester certaines choses. Je vais cependant entreprendre de faire en sorte que les add-ons soient sans bugs, j'ai beaucoup appris avec HCR sur ce que Aurora peut ou ne peut pas faire.
Retour aux questions
15/ Quelles conventions suggères-tu pour les noms afin de tout garder organisé ?
Voici la convention que j'utilise pour les noms dans HCR :
- Tous les fichiers commençant par hc_i# (où # est un chiffre entre 0 et 9) sont des fichiers inclus, et en tant que tels causeront des erreurs lors de la construction du module. C'est normal.
- Tous les fichiers commençant par hc_i0_ sont les fichiers inclus dans la Base HCM.
- Tous les fichiers commençant par hc_i1_ sont des fichiers Crochets pour l'Utilisateur Final, avec une fonction preEvent et une fonction postEvent qui sont appelées par le Evènement Module (Module Event) lié. C'est ainsi que les utilisateurs peuvent ajouter leurs propres scripts sans avoir à modifier le script HCM. HCM ne modifiera jamais ces fichiers, donc l'usager final ne risque rien à les utiliser (simplement, n'en écrasez jamais un lors de l'import s'il y en a un qui s'est faufilé au milieu). Si la fonction preEvent() fun retourne 0, le reste du script mev_ (voir ci-dessous) ne s'exécutera pas.
- Tous les fichiers commençant par hc_mev_ sont les fichiers Module Event, et chacun est associé à un fichier hc_i1_. Ce sont les scripts soutenant le système.
- Tous les fichiers commençant par hc_hcm_ sont des fichiers génériques qui ne sont associés à rien en particulier, ie hc_hcm_initfeat (configure les options dans le module si jamais il est appelé.)
- Les autres fichiers commencent par hc_ et ensuite le Module Event auquel ils sont associés, ie, les fichiers hc_acq_ seront des scripts associés à l'évènement Acquisition d'Objet.
Le plus important. Vous devez identifier les fichiers inclus par une forme particulière, du fait de leurs erreurs de compilation.
Retour aux questions
16/ Que penses-tu du potentiel pour NWN de devenir le support d'une seconde génération de Donjons Multi-Joueurs (oui, telnet et les anciens DMJs)
C'est ce qu'une tonne d'entre nous essaye désespérément de faire, mais NWN n'est tout simplement pas fait pour ça à l'heure actuelle. Espérons que nous aurons plus de support, mais NWN est désigné pour faire une série de modules en tant que campagne, et non un simple monde où beaucoup de choses se passent. Cependant, NWN est le meilleur outil que nous les M.Duponts avons reçus à l'heure actuelle pour ce genre de tâche. Certaines personnes ont essayé avec des moteurs du type de Quake, mais c'était un cauchemar à faire, et ça n'allait pas non plus.
Retour aux questions
17/ Que penses-tu de l'utilisation du OnHeartBeat ?
J'essaie de la minimiser autant que faire se peut. Il faut regarder l'utilisation du CPU. Mais... Si je me contentais de faire un petit module, j'en ferai énormément usage :) c'est le meilleur moyen que nous avons de voir ce qui se passe avec les joueurs tant que Bioware ne nous donne pas plus d'évènements joueurs.
Retour aux questions
18/ Qu'as-tu le plus envie de voir implémenté par la communauté NWN qui te ferait t'assoir, sourir, et dire "ah... enfin..." ?
Le stockage des variables Locales sur le PJs ou des sauvegardes de parties facilement éditables.
Retour aux questions
19/ Comment HCM limitera deux add-ons qui utilisent le même fichier évènement ?
Les Evènements sont toujours structurés comme ils le sont tous, c'est seulement qu'il utilisent des CONSTANTES (pas des vraies bien sûr) pour déterminer s'il faut exécuter certaines zones de code ou non). Ce n'est pas efficace, mais c'est ce qui était demandé, et ça me fournit un bon défi de codage. Au final, ce sera moins puissant qu'HCR, mais 100x plus flexible.
Retour aux questions
20/ Y a-t-il des scripts (conçus pour les MP) qui sont réputés lourd du point de vue Heartbeat ou causer du lag ?
Le système de spawn. Si vous avez BEAUCOUP de zones, et si vous mettez un SpawnControler dans chaque, ça peut bouffer complètement le CPU, mais DF l'utilise, c'est très flexible.
Retour aux questions
21/ Que penses-tu être le mieux : des scripts de respawn ou réduire le temps-système du CPU ?
Je ne peux pas vraiment répondre à ça, étant donné que je n'ai pas assez creusé les 3 ou 4 moyens disponibles. Le mieux serait d'utiliser des rencontres aléatoires (encounters) préprogrammées, et les faire se répéter aussi souvent qu'avec leur script interne, mais même ainsi, tout dépend de la part d'automatisation que vous voulez dans votre monde. Vous pouvez laisser vos MJs postitionner toutes les rencontres aléatoires, ie selon le nombre de joueurs en ligne, et ainsi n'avoir presque aucune utilisation de CPU, mais alors vous avez besoin de MJs 24h/24 7j/7, ou a moins quelqu'un qui se connecte pour disposer les rencontres aléatoires dans vos zones.
Retour aux questions
22/ Je pense que le début de NWN est plutôt difficile... Certaines personnes ont eu quelques désillusions, et on sent parfois que la communauté est moins active qu'autrefois. Peut-être retrouvera-t-on l'ancien NWN, peut-être sera-ce le mieux ? As-tu certaines attentes des mois et années à venir ?
J'attend que de NWN qu'il laisse rapidement la place... à NWN2 ou autre chose. C'est vraiment le premier produit de ce type... Dongeon Siege et autres du genre ont fait des choses similaires, mais ils sont TRES LOIN en-dessous de NWN. Néanmoins, quelqu'un fera un constructeur de MP qui servira le petit utilisateur. Ceux d'entre nous qui ne peuvent pas s'offrir les gros appareils à 100 000$. Mais, je ne pense PAS que les DMJs NWN qui sont faits disparaitront. Les gens jouent aux DMJs pour le contenu de jeu et les amis qu'ils se font, pas pour leurs graphismes et leurs sons fantaisistes.
Retour aux questions
23/ Selon toi, quels sont les aspects clé du gameplay qui font d'un MP un bon un MP ?
Qu'on aime ou qu'on déteste, EQ a réellement trouvé la formule. Vous avez besoin de joueurs pour être capable d'avoir une variété de choses à faire, et non seulement du hack&slash. Ils ont besoin d'être capable d'avoir une évolution soutenue mais petite, mais ça doit être visible quand on compare à leurs pairs. Et il faut avoir un thème SOLIDE autour duquel concevoir votre monde. Star Wars Galaxies s'apprête à faire du jeu à Everquest comme un fumeur de joint passant à l'héroine.
Retour aux questions
24/ Lorsqu'on utilise le système de respawn, (avec le drapeau PCR), n'économise-t-on pas en fait la puissance CPU en ne faisant pas appaître les PNJs/créatures quand les PJs ne sont pas dans la zone ?
En partie, mais le SpawnControler continue à tourner et à tester tous les HeartBeat. Si vous avez 100 zones (DF en a plus de 400 actuellement à ma connaissance), ça améliore les choses. Dans Daggerford actuellement, du fait du serveur, un HeratBeat de 6 secondes prend environ 25 secondes, et l'horloge du monde arrête totalement d'avancer dans le jeu, ça marche encore, mais ça doit être boosté au démarrage en le mettant en place par l'appel du HeartBeat lui-même.
Retour aux questions
25/ Dans quelle phase est Daggerford ?
En version alpha. Vous pouvez vous proposer pour le tester en écrivant à treystaq@hotmail.com. Au passage, j'aimerais insister sur Raystonn de ce côté, il conçoit les critères D&D3, un peu comme Shaderaven l'a fait, mais Ray les fait un par un, chachun avec leur propre cerveau, et totalement obéissant aux 3E. Connectez vous à la beta de Krynn pour les voir, ils roxent.
Retour aux questions
26/ Combien de temps avant les beta-tests selon toi ?
Hmm, il faudrait demander à HOT notre directeur de projet qui publie des versions corrigeant des bugs tous les jours. Ca se passe très bien pour l'instant et nous avons eu récemment 7 nouvelles personnes qui ont rejoint l'équipe.
Retour aux questions
27/ Tu as dit tout à l'heure que la distribution générique de trésor de Bioware tuerait l'économie d'un MP. Pourrais-tu développer un peu ? Fais tu référence aux scripts de génération de trésor en eux-mêmes ?
Oui, tout ce qui remplit les tonneaux de potions de santé légère est une MAUVAISE chose, hehe, et c'est pire dans des zones plus dangereuses. Les drops de cadavres de §Bioware on été faitts pour un jeu du style diablo. Je ne blâme pas Bioware, ils avaient besoin de vendre leur jeu, et que leur éditeur soit content, mais l'armature D&D3 comme pour un vol de nuit.
Retour aux questions
28/ Dans ce cas, diviser le module en plusieurs modules pourrait être la solution (avec plusieurs serveurs)... à ce point, est-il possible d'envoyer des données locales d'un serveur à l'autre ?
En partie, en empêchant les usagers de joindre les serveurs secondaires autrement que par le serveur principal. Vous mettez un objet sur le joueur avant qu'il quitte le serveur principal. Quiconque se connectant à un serveur secondaire sans cet objet est rejeté. Vous mettez d'autres objets sur le PJ indiquant son état ou les informations que vous avez besoin d'envoyer au serveur ; c'est bricolé, mais c'est ainsi que je ferais. Quand le PJ se connecte au serveur 2, le serveur cherche les objets, marque le PJ qui y est lié, puis les supprime.
Retour aux questions
29/ Pour Daggerford, combien de personnes peux-tu accueillir avec ton P800 Linux ?
On en a vu jusqu'à 30 et je pense plus, mais il y avait alors des crash dans le code dus aux joueurs.
