Dans ce septième article de la série sur le jeu « La maison dans la colline », il va être question de tests anti-regression.

Regressions

Mais qu'est-ce qu'une regression ? C'est un fonctionnement qui donnait toute satisfaction et qui, suite à un changement dans le système, se met à ne plus fonctionner comme attendu. Autrement dit, une apparition de bug !

Les bugs n'arrivent jamais de nulle part, il y a toujours une raison. Mais plus un programme est grand, plus il se complexifie et plus le risque de programmer des morceaux qui entrent en conflit apparaît. C'est à peu près inéluctable et le développement d'un logiciel est, normalement, accompagné d'un certain nombre de règles pour éviter au mieux et surtout repérer au plus vite les défauts qui apparaissent.

La vitesse de détection est importante, car il une regression peut ne pas être immédiatement flagrante. Il est possible que quelque chose casse sur une …

Dans ce sixième article de la série sur le jeu « La maison dans la colline », il va être question des structures du jeu, de portage et de « binarisation ».

Les structures

« La maison dans la colline » est un jeu programmé en grande partie en C. L'idée derrière est de pouvoir porter assez facilement sur une autre machine qui n'aurait potentiellement pas le même processeur, c'est aussi une manière de faciliter les itérations. Le jeu manipulant des objets, des pièces pour circuler, un personnage, il est intéressant de pouvoir se reposer sur des structures de données et de les manipuler, de les faire évoluer, sans avoir à adapter un code assembleur en parallèle (même s'il existe des assembleurs qui peuvent faciliter ces opérations).

Les pièces

La première structure que je présente est celle des pièces de la maison et des portes qui les relient. Ces données sont fixes et pourraient se situer …

Dans ce cinquième article, je vais aborder la méthodologie que j'ai appliquée pour le développement de « La maison dans la colline ».

La planification

Dans un premier temps, j'avais jeté sur papier (électronique) la liste des fonctionnalités que je voulais implémenter, en partant de l'idée générale du jeu et en descendant successivement sur ce dont je pensais avoir besoin. Puis j'ai segmenté cette liste en thèmes, comme par exemple « mouvements du personnage » ou bien « gestion de l'inventaire ».

Ces fonctionnalités ont besoin les unes des autres, je suis descendu jusqu'aux briques de bases, comme « afficher quelque chose à l'écran » ou bien « lire une touche du clavier ». Entre toutes ces fonctionnalités, j'ai créé des dépendances : afficher un personnage nécessaire de savoir afficher quelque chose à l'écran. L'animer nécessite de savoir l'afficher. Et ainsi de suite.

Mes dépendances ne sont pas complètes. J'ai celles qui concernent les premières tâches à effectuer, mais c'est tout …

Dans ce quatrième article concernant le développement de « La maison dans la colline », je vais aborder quelques points de programmation. Deux points en particulier : la structure générale du programme, puis les listes d'affichage.

Structure générale

Un jeu vidéo, c'est un programme qui ne s'arrête pas. Enfin si... quand on a fini de jouer. Mais il s'oppose aux programmes en « batch » qui doivent résoudre une fonction à partir de données en entrée. Un jeu vidéo se situe donc dans la classe des applications qui font évoluer un état en fonction des entrées de l'utilisateur.

Ainsi, un tel programme peut se résumer à cette structure :

int main()
{
    while(running())
    {
        read_input();
        update_state();
        display_state();
    }
}

Autrement dit : tant que le logiciel tourne, on lit les entrées, on met à jour les états du jeu, on affiche l'état du jeu (on peut aussi diffuser le son, mais ce jeu n'en n'a pas) et on recommence.

Voilà …

Je l'avais brièvement mentionné il y a presque un an : j'ai eu la chance de pouvoir travailler avec l'association M05.COM à l'analyse et restauration d'un exemplaire de « Micral N ».

Entre deux analyses, j'ai reproduis cet exemplaire en modèle 3D, que je présente ici dans un rendu assez simple.

J'y voyais deux intérêts. Le premier est que c'est pour moi une façon d'étudier l'aspect extérieur d'une machine. Dans le cas de celle-ci, est-ce que j'ai bien vu tous les détails ? Est-ce que j'ai bien vu toutes les LEDs et tous les interrupteurs. L'exercice de modélisation force à se pencher sur les détails.

En comparant les photos, on peut aussi voir les différences entre différents exemplaires. Par exemple, l'exemplaire de l'association a un interrupteur ajouté sur la droite du panneau de contrôle par rapport aux autres exemplaires dont les photos sont disponibles.

Le deuxième intérêt est que cette modélisation pourra …