Comme vous pouvez le voir, cette approche permet de court-circuiter pas mal de lectures du tableau 4.

Vous pensez peut-être qu’on devrait simplement stocker les nouveaux calculs de données après le stockage d’une nouvelle entrée du registre. Sur le papier, ça pourrait marcher, mais cela provoquerait des incohérences dans les données et une dégradation des performances. Par exemple, une dégradation possible des performances serait due à la charge que représenterait pour le système la nécessité de recalculer et stocker les données, souvent à cause du processus de lecture puis d’écriture que cela implique. Nous devons équilibrer les besoins en calculs avec l’impératif d’exécution du jeu avec des performances acceptables pour tous les joueurs et joueuses.

Quant aux incohérences dans les données, prenons par exemple les calculs de fin de jeu. La plateforme et l’infrastructure de nos serveurs prennent en charge les retards d’arrivée des messages. Imaginons qu’un problème temporaire s’est produit entre deux centres de données (A et B) et que le message de gain d’expérience d’une figurine a été envoyé par A mais n’est pas encore arrivé sur B. Considérons le scénario suivant : vous faites une partie juste avant minuit. Vous jouez et vous gagnez le mercredi à 23 h 59. Le processeur de cumul a été configuré pour être exécuté quotidiennement pour toutes les données de la journée en cours. Il serait donc lancé à minuit et calculerait vos valeurs totales d’expérience jusqu’à jeudi à 0 h. Ces données seraient stockées dans le second tableau et les nouvelles lectures d’expérience consulteraient la dernière valeur stockée en ajoutant toutes les données reçues après jeudi à 0 h. Dans le cas d’un retard de message, celui-ci serait reçu mais indiquerait que la partie s’est terminée mercredi à 23 h 59. L’entrée correspondante serait donc écrite avec cet horodatage. Cette entrée se serait donc pas incluse dans le tableau de cumul et une interrogation des données ultérieures ne la renverrait pas non plus. Ces données incomplètes seraient problématiques. Qu’en est-il des messages arrivés avec quelques jours de retard ? Eh bien, nous avons mis en place un système de surveillance et d’alerte qui garantit presque toujours le traitement de ces nouvelles informations dans les temps avant le prochain cumul.

Calcul des niveaux des figurines

Si vous vous penchez à nouveau sur le tableau d’expérience totale, vous remarquerez qu’il n’inclut aucun calcul de niveau. On y trouve uniquement le total de l’expérience accumulée dans le jeu. Séparément, il y a un tableau statique défini par les concepteurs du jeu qui ressemble à celui-ci. Pour commencer, une figurine est au niveau 1 ; lorsqu’elle obtient 1 point d’expérience, elle passe au niveau 2, puis il lui faut 3 points pour atteindre le niveau 3.

La combinaison des deux tableaux nous permet de calculer le niveau actuel d’une figurine au moment de l’exécution du jeu en calculant un total cumulé, ce qui nous donne l’ensemble de données suivant :

Cela donne plus de flexibilité aux concepteurs du jeu en leur permettant de changer la quantité d’expérience nécessaire pour passer au niveau supérieur. S’ils pensent qu’il est trop difficile d’améliorer les figurines de faibles niveaux, ils peuvent diminuer les quantités d’expérience requises. Il en résulterait une petite amélioration du niveau actuel de toutes les figurines et moins d’expérience à obtenir pour les faire passer au niveau supérieur, sans apporter aucune modification aux données des joueurs et joueuses enregistrées dans la base de données. L’inverse est un peu plus douloureux. Si les concepteurs du jeu décident que les passages aux niveaux supérieurs sont trop rapides et augmentent les valeurs, nous n’offrirons pas d’expérience en compensation pour rétablir les niveaux qu’avaient atteint les figurines avant la modification. Cela dit, nous pouvons donner aux concepteurs la possibilité d’octroyer de l’expérience aux figurines pour atténuer le choc.

Autres approches considérées

Avant d’adopter notre solution actuelle, nous avons examiné diverses approches pour le stockage des gains d’expérience et le calcul du niveau résultant des figurines. Certaines impliqueraient plus de temps de pause pour nous permettre de modifier l’expérience des joueurs, tandis que d’autres offriraient une bonne expérience de jeu sans négliger la progression des joueurs.

« Toujours stocker le niveau, l’expérience et les points pour passer au niveau supérieur des figurines »

Et si on utilisait juste un modèle SQL standard et des mises à jour transactionnelles ? Les mises à jour transactionnelles permettent de mettre à jour un ensemble de données dans sa totalité, selon un principe de tout ou rien. Si l’écriture d’une partie échoue, toutes les données retournent à leur valeur d’origine. Elles permettent donc de bénéficier des propriétés « ACID » : atomicité, cohérence, isolation et durabilité.

Avec cette approche, le suivi de l’expérience et du niveau total de chaque figurine se réduirait à une seule ligne, ce qui allégerait énormément les lectures.

Lorsqu’une figurine gagne de l’expérience, la mise à jour lui donne 2 points d’expérience avec 8 points avant de passer au niveau suivant et le niveau 3. Ce type de modification force le système à lire les données, à les recalculer, puis à les écrire dans la base de données. Ce modèle ne permet pas d’exploiter les atouts offerts par Cassandra. Ce n’est pas le seul défaut de cette approche, car pour changer le nombre de points nécessaires pour passer au niveau supérieur, il faudrait mettre le jeu hors ligne pour modifier les données de toutes les figurines pour tous les joueurs et joueuses.

« Stockage en tant que pourcentage »

Nous avons aussi réfléchi à la possibilité de stocker un pourcentage avant le passage au niveau supérieur, comme dans cet exemple :

Ensuite, après une partie, nous ferions quelques calculs rapides. Par exemple, la brute gnolle obtient +3 exp, le pourcentage est +3 / 10, ce qui signifie que nous devons donner 30 % d’un niveau à la brute gnolle, avec le résultat suivant :

Cette approche nous donnerait de la flexibilité pour modifier la courbe de niveaux des figurines sans que cela ne change leur niveau actuel. Cela faciliterait aussi les visualisations dans l’interface utilisateur en nous permettant de remplir simplement 30 % de la barre de progression, sans calcul supplémentaire. Avec ce type de modèle, on se retrouverait toutefois avec des pourcentages minuscules aux niveaux plus élevés. Lorsqu’une figurine obtient 10 xp par partie et doit en avoir 100 000 pour passer au niveau supérieur, cela correspondrait à 0,01 %. Les unités centrales (UC) peuvent gérer les nombres flottants, mais la précision et l’exactitude peuvent être source de bugs si nous ne prenons pas en compte la nature des calculs en nombres à virgule flottante.

En attendant la suite…

Il y avait de nombreuses options à considérer parmi ce que permet la technologie des base de données, ainsi que les outils à fournir et enfin comment tout stocker et calculer. Comme pour tout projet encore en développement, nous pourrions tout changer plus tard si nous trouvons quelque chose de mieux, mais cela semble être un bon point de départ pour ce jeu.

Merci de nous avoir rejoint pour ces notes d’ingénierie informatique !

~ Andy Lim