Bonjour à tous ! Aujourd'hui, ce n'est pas un, ni deux articles qui vous sont proposés, mais trois !

Les Super News de GeorgeV : Le 21 Mai !

Salut, c'est encore GeorgeV. Aujourd'hui j'ai étoffé l'interface de l’IA et je l'ai préparée pour les tests. Comme toujours, c'est provisoire. Nous nous sommes même penchés sur les suggestions du forum pour lui trouver un nom. :) SAIL_Interface Je préfère ne pas trop m'attarder sur le sujet. À une prochaine fois ! Source : [GeorgeV Super News: 21st of May!]

Ce qui s'est passé le 21 Mai, par Kyren

J'ai passé la plus grosse partie de ma journée à finaliser la logique d'apparition des monstres, qui est extrêmement différente de ce qu'elle a pu être dans le passé. Désormais, les monstres apparaissent en tant que partie d'un "profil de spawn", qui définit quels monstres doivent être générés, dans quelles conditions et à quelle densité. Les profils de spawn sont liés au biome, et chaque biome possède un profil de spawn différent. Cela permet une plus grande diversité d'environnements, étant donné qu'un biome spécifique (ainsi que ses sous-biomes, ses différentes couches, etc.) peut désormais posséder non seulement des monstres uniques, mais aussi un nombre d'espèces, de types d'espèces, ainsi qu'une densité et des paramètres uniques, ce qui était très difficile à obtenir avec l'ancien système. Nous faisons tout cela dans le but de rendre chaque biome unique, et pour qu'il nous soit plus facile, par exemple, d'avoir un champ rempli de lapins en plein milieu d'une forêt. Nous allons aussi ajouter une valeur de poids pour chaque monstre, et, de manière plus générale, une génération de monstres plus configurable, pour offrir une plus grande variété et pour rendre l'exploration plus intéressante. L'ancien système faisait juste apparaître un nombre X de "choses" autour de chaque joueur, sans réfléchir, et en définissant la nature de la "chose" en fonction de l'endroit où elle est tombée, ce qui limitait un peu nos possibilités. L'algorithme qui nous permet de faire apparaître les monstres autour de chaque joueur avec une certaine densité s'est révélé plutôt compliqué à créer, et décider de la manière dont il allait fonctionner m'a pris pas mal de temps. En outre, j'ai dû aider Omni à trier et démêler quelques bouts de code qui lui posaient problème, et j'ai passé 2 heures à discuter avec les gens qui venaient installer la fibre dans notre bureau, pour m'informer, de manière à pouvoir configurer notre réseau interne. Source : [May 21, things happened]

22 Mai - Mise au courant par Omni

J'ai passé la journée à régler des bugs et à préparer le terrain à mon prochain projet. Kyren et moi avons fait un peu de nettoyage sur l'interface des objets, de manière à créer une API (NdT : Interface de Programmation) plus petite, plus dynamique et mieux définie pour la gestion des objets. J'ai supprimé les fonctions explicites pour le carburant (NdT : existantes dans les fichiers du jeu), et j'ai retiré le flag "Critical item" (qui était une sorte de hack, de plus nous avons aussi résolu le problème de pertes de pioches). J'ai protégé l'accès direct aux paramètres. J'ai également déplacé la fonction instanceValue (qui vérifiait les paramètres d'une commande et la configurait ensuite) de protégée à publique. J'ai aussi transposé instanceValue en Lua, mais pas les paramètres. Il y a toujours du désordre du côté des objets. Mais je laisse ça à mon prochain carnage de cette partie du code. J'ai passé la seconde moitié de ma journée à corriger un bug de soupassement de la quantité d'argent (NdT : Pour faire simple, la valeur correspondant à l'argent du joueur est si proche de 0 qu'elle en devient négative) que Metadept m'avait montré. Après examen du code, j'ai réalisé que la quantité d'argent amassé par le joueur pouvait, de la même façon, dépasser la valeur maximale. Du coup, j'ai été obligé de créer une méthode de multiplication résistante aux dépassements, ce qui, étonnamment, ne semble pas exister ou même être documenté où que ce soit. En voici une copie pour la postérité : 
template <typename Int>
typename std::enable_if<std::is_integral<Int>::value, Int>::type noOverflowMult(Int a, Int b) {
  if (!a || !b)
    return 0;

  if (b == std::numeric_limits<Int>::min()) {
    if (a > 0) {
      return b;
    } else {
      return std::numeric_limits<Int>::max();
    }
  }

  if (a == std::numeric_limits<Int>::min()) {
    if (b > 0) {
      return a;
    } else {
      return std::numeric_limits<Int>::max();
    }
  }

  Int maxInt;
  if ((a < 0) != (b < 0)) {
    maxInt = std::numeric_limits<Int>::min();
  } else {
    maxInt = std::numeric_limits<Int>::max();
  }

  if (abs(maxInt / a) < abs(b))
    return maxInt;

  return a*b;
}
Après quelques tests, cela semble marcher pour toutes les combinaisons de valeurs possibles. J'ai aussi réglé la valeur maximale de l'argent du joueur à 9.999.999 pixels, ce qui sera bien entendu sujet à des changements, sachant que j'ai juste gardé ma touche 9 enfoncée. J'ai aussi retiré notre fonction "range" custom, car elle ne fonctionnait pas correctement (pour chaque nombre de forme -n+ .5, elle faisait un arrondi dans le mauvais sens). Elle était là car MSVC (NdT : C++) ne l'avait pas à l'époque, mais encore une fois, nous n'allons sans doute pas viser cette plateforme. J'ai aussi commencé à créer un début de suite mathématique, histoire de m'assurer que nos fonctions mathématiques fonctionnent correctement. Source : [May 22 – Omni update]
Pfiou, ça fait beaucoup de blabla technique... je crois que je vais aller me chercher un doliprane... Voilà, c'est tout pour le moment, à une prochaine fois ! -Article rédigé par Silverthedragon