où la balle pourra rebondir sur les 3 bords haut, bas et gauche de l'écran,
une raquette pilotée à la souris pourra monter et descendre sur le bord droit de l'écran,
si la balle arrive sur la raquette, la balle rebondit et la partie continue,
sinon, la balle continue son chemin et sort de l'écran : il s'affiche alors un message de "Game over !".
2) Définition d'un cadre graphique de travail.
Nous travaillerons dans le cadre graphique suivant :
une fenêtre « fen » tKinter classique,
un canevas « can », de hauteur « height = 500 », de largeur « width = 725 », couleur à définir,
une balle « bal » de dimension 40 x 40, dont la position sera repérée par des variables x et y, couleur à définir,
une raquette « raq » de dimension 20 x 100, se déplaçant verticalement, dont la hauteur sera repérée par une variable « haut », couleur à définir en cohérence avec le fond et la balle.
3) Fonctionnement général.
a) Nous devrons ici prévoir :
une fonction récursive d'animation de la balle « anim » :
qui la fera avancer de « dx », « dy » toutes les 100 ou 10 ms (valeur à ajuster ultérieurement),
testera si la balle entre en collision avec l'un des 3 bords rebondissant, et inversera dans ce cas le déplacement « dx » ou « dy »,
testera si la balle atteint le bord droit de l'écran, affichant alors le message « Game over ! ».
un binding : pour lier un déplacement de la souris ("<Motion>"), à une fonction gestionnaire « raquette », qui déplacera la raquette en conséquence,
une fonction gestionnaire de collision « collision » :
qui testera à chaque appel si la balle entre en collision avec la raquette,
renverra un booléen « True » ou « False », pour indiquer si la balle est entrée en collision avec la raquette.
b) Représentation de l'algorithme.
On pourra ici réaliser une représentation simplifiée de l'algorithme avec les éléments suivants :
4) Dans la pratique.
Ça commence à se préciser !
Mais il faut hélas reconnaître qu'il est très difficile de réaliser, dès le départ, une analyse parfaitement juste et complète d'un projet :
d'une part, des difficultés techniques apparaîtront toujours au fur et à mesure de l'avancement du projet,
d'autre part, un projet peut toujours être amené à grossir et évoluer, pour y ajouter des fonctionnalités supplémentaires, par exemple.
Le travail d'analyse préliminaire du projet, bien qu'indispensable, demande à l'évidence de l'expérience. Et même doté d'expérience, l'analyse préliminaire sera rarement, voire jamais, parfaitement complète.
C'est pourquoi, dans le projet final, nous devrons savoir restés suffisamment humbles sur :
les ambitions et fonctionnalités du programme,
la phase de travail séparé de son binôme, et prévoirons de fusionner tôt, les morceaux de code respectifs.
En effet : un oubli, ou une erreur, sur la phase d'analyse préliminaire pourrait rendre impossible la fusion des 2 morceaux de codes. Nous obligeant alors, à les ré-écrire intégralement, avant de passer à la fusion.
5) Let's go !
Vous êtes donc libres de faire tout le mini projet à 2, ou de vous essayer au développement collaboratif.
Dans le second cas : l'un code la balle, l'autre la raquette, et la fusion s'opère ensuite.
Quelque soit l'option choisie, imprimez, ou remaniez à votre sauce, le cahier des charges, le cadre de travail graphique, et le fonctionnement général, définis en 1), 2) et 3).
Il faudra s'y tenir, ou alors si des modifications s'avéraient nécessaires en cours de route : commencer par les rédéfinir, en concertation avec votre binôme et l'enseignant, avant d'aller plus loin.
