Projet Gameboj

Le but du projet de cette année, nommé Gameboj, est d'écrire un programme simulant la célèbre console de jeu Game Boy, créée en 1989 par Nintendo et visible ci-dessous.

Le Game Boy a été extrêmement populaire et s'est vendu au niveau mondial à presque 120 millions d'exemplaires. Plusieurs versions du Game Boy ont existé, mais celle que nous simulerons ici est la première, dont la caractéristique principale est d'être doté d'un écran monochrome n'offrant que quatre teintes de gris.

Comparées à celles des consoles de jeu modernes, les caractéristiques techniques du Game Boy d'origine font pâle figure, comme la table ci-dessous l'illustre. Y sont comparées certaines caractéristiques techniques du Game Boy et de la Switch, la console portable la plus récente produite par Nintendo. La dernière colonne donne le rapport entre la Switch et le Game Boy, et montre bien l'impressionnante évolution des composants électroniques durant les presque 30 ans qui séparent les deux consoles.

Caractéristique	Game Boy	Switch	S/GB
Nombre de processeurs	1	8	8
Fréquence processeur	4 MiHz	1 GiHz	256
Mémoire vive (RAM)	8 Kio	4 Gio	524 288
Pixels de l'écran	23 040	921 600	40

Cela dit, ces caractéristiques techniques modestes n'empêchent pas le Game Boy de posséder un très grand nombre de jeux d'excellente qualité.

Comme toute console de jeu, le Game Boy est un petit ordinateur, constitué d'un ensemble de composants électroniques interconnectés. Dans le cas du Game Boy, les composants principaux sont :

• le processeur,
• le clavier, comportant un total de huit boutons :
  • quatre boutons de direction (haut, bas, gauche, droite), organisés en une croix directionnelle,
  • deux boutons d'action nommés A et B,
  • deux boutons nommés Select et Start,
• l'écran à cristaux liquides et son contrôleur, un processeur graphique simple,
• un synthétiseur sonore.

Le Game Boy ne contient — à une petite exception près — aucun programme. Dès lors, les jeux sont distribués sous la forme de « cartouches », qui sont des étuis en plastique ne contenant pas grand-chose d'autre qu'une mémoire morte dans laquelle se trouve le programme du jeu ainsi que ses données (graphiques, sons, etc.). Lorsqu'une cartouche est enfilée dans le Game Boy, sa mémoire morte se trouve physiquement connectée au reste du système, et le jeu qu'elle contient est exécuté dès l'allumage de la console.

L'architecture du programme Gameboj suivra, dans les grandes lignes, l'architecture matérielle du Game Boy. Ainsi, chacun des composants mentionnés ci-dessus — exception faite du synthétiseur sonore qui, faute de temps, ne sera pas simulé — sera modélisé par une classe Java.

Un problème qui se pose toujours lorsqu'on désire simuler le comportement d'une entité quelconque est de savoir à quel niveau d'abstraction faire la simulation.

Dans le cas du Game Boy, une possibilité assez extrême serait de simuler chacun des composants au niveau électronique. La simulation obtenue serait très fidèle, mais d'une part extrêmement complexe à mettre en œuvre et d'autre part très lente à exécuter, beaucoup trop pour qu'il soit possible de jouer à un jeu sur le simulateur.

Une autre solution serait de faire une simulation « fonctionnelle », qui ne se charge de simuler fidèlement que les aspects du Game Boy qui sont explicitement décrits dans la documentation officielle de Nintendo. Malheureusement, cette simulation a le problème inverse de la précédente : comme certaines caractéristiques du Game Boy réel ne sont pas décrites dans cette documentation, mais que les programmeurs de certains jeux en ont néanmoins tiré parti, il ne serait pas possible de faire fonctionner ces jeux sur un tel simulateur.

Tout l'art de la simulation consiste donc à choisir où se placer entre ces deux extrêmes. Pour ce projet, nous simulerons le Game Boy à un niveau d'abstraction relativement élevé, donc proche de son comportement officiel et documenté. En conséquence, certains jeux, heureusement minoritaires, ne fonctionneront pas correctement sur notre simulateur.

Le projet se fait par groupes de 2 personnes au maximum. La formation de ces groupes est libre et peut changer au cours du semestre, pour peu que les directives concernant le plagiat soient respectées. En particulier, si deux personnes ayant travaillé en commun se séparent, elles doivent se partager le code et ne peuvent chacune l'emporter en totalité de leur côté.

La mise en œuvre du projet est découpée en 12 étapes hebdomadaires, regroupées en trois parties :

1. la première partie est composée des étapes 1 à 6,
2. la seconde partie est composée des étapes 7 à 11,
3. la troisième partie est composée de l'étape 12, qui est une étape bonus optionnelle et (presque) totalement libre.

Un total de 500 points est attribué durant le semestre, répartis ainsi :

• examen intermédiaire : 75 points,
• examen final : 125 points,
• projet : 300 points.

Les 300 points attribués au projet sont répartis de la manière suivante :

• rendus testés : 90 points (18 points par rendu),
• rendu intermédiaire : 80 points,
• rendu final : 110 points,
• test final : 20 points.

Un rendu testé est un rendu qui est évalué automatiquement au moyen de tests unitaires. Il y a 5 rendus testés au cours du semestre, un pour chacune des étapes 2 à 6. Le nombre de points obtenus à un rendu testé est proportionnel au nombre de tests passés avec succès.

Le rendu intermédiaire, qui concerne les étapes 1 à 6, et le rendu final, qui concerne les étape 7 à 11, sont quant à eux évalués par des correcteurs, et les points attribués en fonction de la qualité du programme. L'efficacité, la concision et l'élégance du code sont pris en compte dans cette évaluation.

Le test final consiste en un test non automatisé (contrairement aux tests unitaires) du bon fonctionnement du projet complet.