Créer un jeu sur R…

J’ai d'abord une idée : “Battle Monster”, un duel où les joueurs dévoilent les actions de leurs monstres en même temps. Un intermédiaire entre “tour par tour” et “action simultanée”. C’était pas mal. Il fallait lui donner vie maintenant. Et à l’époque, je commence comme un petit pro. Je mets tout sur papier. Je fais des fiches design. Je dessine des cartes. Je teste même sur un tableau blanc ! Des bons réflexes de gamedev. Dommage que j’oublierai de le faire par la suite… on fait tous des erreurs…

Cependant c’est bien de gribouiller des formes sur mon tableau, mais ça manque de punch, de visuel et de sons. Et puis j’en avais assez de tout calculer de tête. Étape suivante : programmer le jeu. On rentre dans le vif du sujet. Par contre, à ce moment le seul logiciel de programmation que je connaisse, c’est R. Parfait pour faire toutes mes analyses statistiques durant ma thèse, mais on s’arrête là. Du coup, normalement j’ouvre Youtube et je regarde un tuto pour apprendre Unity, Godot ou n'importe quoi.

Et non ! Voilà mon prototype sur R. Ça bouge. Tout se calcule tout seul. J’ai même mis des barres de vie et tout. Mon premier jeu ! On peut dire champagne ?

Comme quoi, avec du temps et de la rigueur, on peut détourner R. Puis, bien que j’ai rajouté quelques règles (comme plusieurs distances de combat, la possibilité d'esquiver des attaques, etc...), bien planifié et avec un diagramme, il n’y a rien d’insurmontable.

En plus, la chance est de mon côté. Grâce à cette idée de coder mon jeu sur un logiciel d’analyse, je peux faire des analyses. Merci Captain Obvious. J’ai donc en cadeau plein de graphes générés sur des milliers de matchs. C’est coloré. C’est beau. Et je peux faire de l’équilibrage sur le niveau de mes monstres et la force de leurs actions. J’adore !

Maintenant j’avoue que dit comme ça, on dirait que tout est facile. Mais j’ai un peu menti… Déjà le jeu ne se présente pas tout à fait comme l’animation au-dessus. Là, c'est moi qui ai compilé les images que mon programme génère. Action par action... Puis l’interface de jeu est la même que pour le code… pas très intuitif… pas très reluisante… Puis entrer l'action de chaque monstre en ligne de code, tour par tour, c’est beaucoup moins fluide que de cliquer sur quelques boutons…

Arrivé à ce stade, j’en suis déjà à 90 heures sur le projet, soit 15 jours de travail. Ok, il y a le temps passé au début à conceptualiser le jeu et ses règles. Mais qu'on se le dise, prototyper un jeu sur R, c'est long, c'est chiant, c'est bugué. Ne faites pas ça.

Mais ça reste un prototype et j’ai validé mes concepts avec. L’intermédiaire “tour par tour” et “action simultanée”, j’aime bien. Pareil pour le fait que les monstres sont soit rapprochés soit éloignés, leurs valeurs d’attaques et de défenses variant en fonction. Au joueur d'anticiper où son adversaire se positionne et d'agir en conséquence, n’oubliant pas de prendre en compte sa propre vitesse ou le ralentissement des monstres.

Aussi, coder les mécaniques de jeu dans ce programme peuvent permettre de générer un grand nombre de données aléatoires. Maintenant, il faut se demander si le temps investi dedans vaut le coup. Tout dépendra du projet, surtout que tous les gameplay ne se prêteront pas à l’exercice.

Ce qui me rassure, c’est que je ne suis pas le seul à avoir tenté l’aventure. D’autres avaient aussi du temps à perdre sur R (R Console Gaming and Fun et Games in R: Fun with Statistical Computing). Pour les curieux, il doit y avoir des ressources pour peaufiner l’interface et aller plus loin.

Vous devinez la suite. J'ai finalement fait mes recherches, suivi des tutos Youtube, et téléchargé Unity. Mon jeu prendra une autre forme. C'est le début d’un long périple d'apprentissage... Mais cette histoire, je la garde pour une autre fois.

La morale de l'histoire ?

Commencez avec des fiches designs, puis faites un prototype simple dans le format qui vous convient le mieux.