Knights of Arena: Remake de Knights of Legend (Partie I)

Point de vue Graphisme.. Ca commence déjà mal

Depuis que le CRPGAddict a commencé à jouer à Knights of Legend (KoL) l'envie m'a repris de coder une version flash. Parce que ce jeu de 1989, que j'ai découvert il y a quelques années (donc sans aucune nostalgie) est le meilleur RPG existant.




Je compares à Baldur's gate, Temple of Elemental evil, Ultima, Wizardry, Fallout.. Non, en fait, ça doit être Fallout 2 le meilleur cRPG. Mais KoL est bien classé.

Pour deux simples raisons: Il n'a jamais été finis (certains éléments sont inaccessibles dans le jeu, bien qu'on puisse le gagner sans souci); Il a une interface utilisateur horrible ( comptez 5 clics pour faire la moindre action)
Avec des défauts aussi gros, le fait qu'il soit agréable à jouer (pas trop longtemps tout de même) est un exploit. Si vous aimez les jeux de rôle tactique en tour par tour, multi party avec un système de combat original: Essayez KoL vous serez pas déçu... Ou attendez que je finisses ma version flash, mais ca peut ne jamais arriver.

Objectif final:

Knight of Arena, comme son nom l'indique, consistera à construire une équipe d'aventurier , de les équiper dans les magasins, puis d'affronter des monstres dans une Arène.
La façon générale de jouer (hormis les combats) sera proche de Runestone Arena. L'approche permet d'éviter tout la lourdeur que nécessiterai une quête, des NPCs, ou même simplement une intrigue (Celle de KoL n'est pas particulièrement mémorable de toute façon).
J'imagine que je mettrais plusieurs villes différentes, avec des magasins différents pour rejouer la notion de "préjudice" (NPC refusant de parler à certaines races ou classes de personnage) . Comme dans l'original.
J'imagine aussi que l'accès aux nouvelles villes sera payant (en or du jeu) pour donner un sens de progression.
Et chaque nouveau lieu aura des magasins mieux fournit, l'accès à de nouveaux sort, et des monstres plus puissant en arène.
Peut être aussi, ajouter un aspect unique d'interaction des personnages dans l'équipe. Ca serait la seule innovation par rapport à l'original.
Mais ca me parait nécessaire pour faire fonctionner le système de "préjudice": Dans KoL, si un PNJ refuse de vendre à un nain, le joueur donne l'argent du nain à l'elfe, l'elfe, contre lequel le PNJ n'a rien, achète l'objet, et l'elfe donne l'objet au nain. Tout n'aura servit qu'a ralentir inutilement le joueur.
Avec une sorte de système d'Amitié je comptes bloquer toutes interactions entres les personnages: L'elfe ne veux rien donner au nain. Mais au fur et à mesure qu'ils combattent ensemble, ou en fonction du charisme d'un personnage, les autres seront prêt à lui rendre service. Outre que ca résout le "préjudice" ca me donne aussi une utilité pour la statistique de "Charisme" négligée dans KoL, comme dans tous les cRPG (sauf Fallout).


Tout ça c'est dans un monde idéal. Parce que rien que de coder le coeur du jeu: Le système de combat risque de s'avérer délicat.

Comme pour les humains et les Elfes, j'avais mis le nain à coté du Kelder au début. Ca donnait trop l'impression d'un couple pervers. Chacun sur une ligne fait moins étrange.

Pour que je codes un jeu, il faut que j'ai envie de découvrir quelque chose. Le premier jeu que j'ai codé, c'était pour voir comment simuler, avec des règles simples, un comportement boursier, qui aurait les même caractéristiques statistiques qu'un vrai marché.
Mon jeu sur Gaymard avait dans le même ordre d'idée l'objectif de simuler simplement un marché immobilier crédible.
Et mon Décivilisation au début n'était rien d'autre que de voir si je pouvait coder des Sprites se déplaçant sur un monde dynamique et généré aléatoirement.
Pour KoA je n'ai pas d'objectifs aussi passionnant (pour moi); ce qui risque de ralentir rapidement mon intérêt pour le projet. Mais peut être qu'en documentant ma tentative ici, je pourrais, au pire, inciter quelqu'un de moins incapable que moi, à faire un remake solide de KoL. Parce que le jeu le mérite.

C'est pas complétement exacte , j'ai un objectif personnel pour refaire le jeu....

Création de personnage

Comme on le voit sur les screens précédents j'ai commencé le code par la première étape de tout cRPG: La création de personnage.
Ca été fait en 1 journée, dont la plus grande partie a été de trouver des images.
Je me rend compte que pour programmer un cRPG le gros problème, c'est qu'il faut des centaines d'images. Comme tout est question de choix (races, sexe, lieux où l'on va, armures, armes à acheter, monstres à affronter); Il faut représenter tout ces différents éléments par le plus de graphisme possible.

Mais depuis 1 ou 2 semaine je réfléchis à un résoudre un seul problème: Comment le programmeur original s'y est prit pour générer , au hasard, les caractéristiques de la trentaine de classes disponibles.

Et c'est un peu ca mon "objectif" personnel qui me motive à coder ce jeu: Comment il fonctionne concrètement. Quels sont les chances de toucher? Les dégâts? Comment influe la force du personnage? Parce que si certaines valeurs sont renseignées, beaucoup sont mystérieuses, voire mal renseignée.

Le manuel donner les caractéristiques moyenne de chaque classe. Un simple tirage en jeu, permet de se rendre compte que ces moyennes sont fausses. Genre complétement fausses.

Le manuel stipule que 66  dans une caractéristique représente 2 chance 3, et que les héros étant exceptionnel ils ont autour de 66 (plutôt que 50 pour la "vrai" moyenne de la population).
Le jeu précise que pour la caractéristique de taille (plus importante dans ce jeu que partout ailleurs) 66 représente 6 pieds, 6 pouces. Ce qui fait tout de même pas loin de 2 mètres de haut.

Quand on crée un personnage, depuis Donjon & Dragon ça consiste à jeter un certain nombre de dés. L'avantage : C'est facile à programmer.
Les chiffres empiriques de KoL donne des variations de 6 à 13 points d'écart. Par exemple le Barbare aura entre 80 et 93 en force, et entre 60 et 66 en taille.
On peut supposer que le barbare a un bonus en force, que le "chasseur" un bonus en "rapidité" , etc... Sauf qu'avec 30 classes ca devient vite problématique. Je ne parles pas seulement de retrouver les bonus/malus de chaque classes, je parles de comment ca été codé à l'époque.
Pour le faire, je peux obtenir des valeurs empiriques raisonnables, puis juste déterminer le nombre de dés, et leurs nombres de faces (1 dé 6 faces, 5 dés 3 faces, etc)  pour chaque caractéristique et chaque classes. Disons 3d4 pour la force du barbare, 2d3 pour sa taille, 2d6 pour la force du "chasseur" , etc.

Sauf que quand le jeu est sorti j'imagine mal que les programmeur se soit embêté à coder un système aussi peu réutilisable. Quand on doit coder en hexadécimal et que les disquettes n'ont de la place que pour 512 Ko on ne rajoute pas des données inutiles: mettre des dés individuels pour chaque caractéristique (7 en tout) de chaque classe différente (35 en tout) donne 245 données en plus a ajouter (pour le nombre de dés) et encore 245 pour les faces du dés.
Un système qui jetterai 3d4 pour toutes les classes/stats, et donnerai des bonus/malus individuel  réduit les donnés à 245 : Par exemple le barbare a +1 en force,  etc... Le problème c'est que l'écart maximum/minimum de stat est différent pour chaque stats/classe. Donc la moyenne change, mais SURTOUT la variation autour de cette moyenne. Et je ne vois pas de façon simple d'avoir codé ca.

J'ai cru avoir trouvé à un moment. Si on décide que le barbare a 20% de plus de force. Avec 1 seul chiffre (20%) je peux varier la moyenne (augmentant de 20%) et aussi la variation. Sauf que dans plein de cas la moyenne augmente alors que la variation diminue. Donc ce n'est pas le bon système.
Une façon de résoudre cela,  c'est d'ajouter d'autres influences. La race et le sexe. Mais il faudrait jouer encore sur la variation indépendamment de la moyenne ce qui augmente aussi les données à stocker dans le programme.

Bref, en 2 semaine, malgré mes calculs répété, je n'ai pas trouvé de constantes, ni de règles en testant plein de possibilité sur la façon dont sont généré les caractéristiques de chaque classes.
De dépit je vais sans doute appliquer la méthode brute, mais , même ça , ça va être délicat.