J'ai créé mes premiers jeux au collège, vers 11-12 ans, en Basic, sur un écran CGA 320x200 en 4 couleurs. Autant dire que ça ne cassait pas des briques. Mais ça m'a permis de me rendre compte de l'énormité du travail de conception d'un jeu qui soit intéressant, original, et du besoin de création de ressources graphiques si on ne veut pas terminer avec une bataille de gros carrés.
L'algorithmie est donc le cadet des soucis du créateur de jeu, même s'il faut bien admettre que c'est essentiel à un jeu réussi et performant, sur des machines limitées comme les PC de l'époque. Il faut également maitriser un certain nombre de techniques plus ou moins ésotériques pour bien faire comprendre à un PC sous MS/DOS - conçu pour faire du traitement de texte en mode caractères - qu'on veut qu'il se bouge un peu de sa routine de papy et nous montre de quoi il est capable.
Les défis à relever sont nombreux, et cela m'a pris un temps certain rien que de les énumérer, en faire le tour pour chercher une faille exploitable, puis pester contre mon père qui aurait pu travailler chez Amiga plutôt qu'IBM ! Les langages et environnements de l'époque pour développer sur PC étaient parfaitement alignés sur les capacités de base de la machine, et sa fonction première : faire des applis business en 80x25 caractères, 16 couleurs max si tes clients ont les yeux fatigués par les écrans monochromes, saisie au clavier uniquement, une touche après l'autre SVP !
Pas de problème pour gérer des fichiers, ça c'est la base, ou l'affichage et saisie en "mode console" ligne par ligne, qui défilent quand on arrive en bas. Ah, il y a une fonction pour déplacer le curseur à l'écran, donc on peut bien écrire ce qu'on veut où on veut quand on veut, et gérer la saisie d'une touche. Après, débrouille-toi ! Bon ok, c'est suffisant pour faire connaissance pendant une poignée d'années, et se faire la main à l'algorithmie de base.
Mais pour ce qui est de faire des jeux, il n'y avait quasiment rien comme bibliothèque pour aider un peu. Pour être honnête envers Borland, ils ont quand même mis une API dédiée au mode graphique, avec un système de drivers pour chaque mode, et quelques routines de base pour tracer des lignes, points, cercles et rectangles, remplis ou non, et même l'écriture de texte dans quelques polices vectorielles (dont Gothique, amusante au début mais on se lasse vite). Tout cela en principe suffisant pour faire tout ce qui nous passe par la tête, si ce n'était une lenteur inouïe et aucune gestion du scintillement produit lors de la confection d'une interface graphique petit bout par petit bout, sans synchro avec le tube cathodique (oui oui, à l'époque il fallait pour bien faire synchroniser son affichage avec le canon à électron).
Bref, à 15 ans, en 1992, j'avais fait le tour du périmètre restreint qu'est un PC de base, avec les librairies de base de Turbo Pascal, et j'étais capable de générer des exécutables indépendants de l'environnement, et donc de distribuer mes créations à mes proches. La seule de cette époque qui vaille la peine d'être nommée est justement un casse-brique, qui compense les défauts de la plateforme par un contrôle adapté au clavier en "mode business" (chaque appui de touche accélère ou ralenti la raquette, il ne faut pas laisser le doit appuyé dessus pour la faire avancer), une palette de couleurs modifiée plus claquante (toujours que 16), et des effets sonores simples et efficaces en fonction des briques que l'on casse, ce qui créé des mélodies si on a placé avec soin les dites briques lors de la création du niveau. Le gameplay est original, car à 2 joueurs face à face, qui peuvent interférer voire carrément chercher à se nuire (brique d'inversion des touches, l'angoisse...). Comme il y a peu de changements à l'écran à chaque instant, a part 2 balles qui bougent et des briques qui disparaissent, la lenteur du driver graphique ne se ressent pas. En plus de la librairie de base de Turbo Pascal, finalement il n'y a que la gestion de la souris qui est en plus dans ce programme, et dans son expression la plus simple : exploitation du driver DOS dans son fonctionnement par défaut, sans fioritures, si ce n'est le changement de la flèche par un viseur.
Reste que la gestion du clavier est limitée, et l'astuce de l'accélération à chaque appui de touches ne fonctionnera pas pour d'autres types de jeu. La gestion de la souris est basique (on détecte les appuis de boutons et les coordonnées à l'écran par polling, après il y a tous les liens avec l'affichage, les actions possibles, à faire à la main sans gestionnaire d'événement), le temps qui passe ne peut être mesuré qu'avec une résolution de 18,2 Hz , il y a tout à faire concernant les joysticks, la communication, les menus et autres éléments d'IHM élaborés... Et bien sûr on ne va pas rester avec les routines graphiques hyper limitées et lentes.
Il a fallu 4 ans pour petit à petit, au fur et à mesure que je me lançais un nouveau projet, je relève les défis. En alternant des projets de jeux, d'outils, de calculs et graphiques mathématiques, j'ai amélioré en continu mes librairies, peaufiné mes techniques pour être toujours plus performant, simple d'utilisation, réutilisable à volonté dans différents contextes.
Vous pouvez vous faire une idée de cette évolution grâce aux vidéos ci-dessous.