Guide : C'est quoi un jeu vidéo ? · Frogger en 7 jours

Tu vas coder un jeu cette semaine, et tu te demandes peut-être : « Mais c'est quoi, au juste, un jeu vidéo ? Comment un écran peut-il réagir à ce que je fais ? » C'est normal. Personne ne t'a montré le fonctionnement de l'intérieur, alors on prend le temps de le faire ici. Rassure-toi : un jeu vidéo repose sur très peu d'idées, et tu les retrouveras chaque jour.

Tu as sûrement déjà joué à Pac-Man, Tetris ou Mario. Pour toi, ce sont des univers et des défis. Pour le programme, ce sont toujours les mêmes briques.

1. Un programme qui tourne en boucle

Un programme classique fait ses calculs puis se termine. Un jeu, lui, ne s'arrête jamais : il recommence la même chose des dizaines de fois par seconde, jusqu'à ce que tu quittes.

Cette répétition s'appelle la boucle de jeu (en anglais game loop) :

while jeu_en_cours:
    for event in pygame.event.get():
        process_events(event)   # 1. qu'est-ce que le joueur a fait ?
    update(dt)                  # 2. le monde change
    draw()                      # 3. on affiche le résultat
    # puis on recommence, environ 60 fois par seconde

Ce n'est pas de la magie : c'est exactement la boucle que tu écriras dès lundi avec pygame.

2. Le plan commun : `init`, `process_events`, `update`, `draw`

Voici le point le plus important de la semaine. Tous les éléments du jeu suivent le même plan, quel que soit leur rôle : la grenouille, une voiture, un radeau, et le jeu lui-même (la classe App). Chaque élément est une classe, et ses méthodes portent toujours les mêmes noms :

__init__(self, ...) : préparer l'élément au départ (position, taille, vitesse, image). Python l'appelle tout seul quand tu crées l'objet, par exemple avec Voiture(0, 300, 120).
process_events(self, event) : réagir à ce que fait le joueur (une touche pressée, un clic). Seuls les éléments concernés l'ont : dans Frogger, c'est la classe App qui reçoit les événements et dit à la grenouille de sauter. Une voiture n'en a pas besoin.
update(self, dt) : faire évoluer l'élément d'un tour à l'autre. La voiture avance, le chrono diminue, la grenouille termine son saut. dt est le temps écoulé depuis le tour précédent : grâce à lui, le jeu va à la même vitesse sur tous les ordinateurs.
draw(self, screen) : dessiner l'élément sur l'écran. Rien d'autre.

Par exemple, une voiture :

class Voiture:
    def __init__(self, x, y, speed):
        self.x = x
        self.y = y
        self.speed = speed  # en pixels par seconde

    def update(self, dt):
        self.x += self.speed * dt  # elle avance un peu à chaque tour

    def draw(self, screen):
        pygame.draw.rect(screen, (200, 60, 60), (self.x, self.y, 40, 20))

Et le jeu, qui orchestre tout le monde :

class App:
    def process_events(self, event):
        if event.type == pygame.KEYDOWN and event.key == pygame.K_UP:
            self.frog.jump(0, -1)  # l'App transmet l'ordre à la grenouille

    def update(self, dt):
        self.frog.update(dt)
        for car in self.cars:
            car.update(dt)

    def draw(self):
        for car in self.cars:
            car.draw(self.screen)
        self.frog.draw(self.screen)

Pourquoi ce plan ? Parce qu'il rend ton code prévisible : devant n'importe quelle classe, tu sais déjà où regarder pour le départ, les actions du joueur, l'évolution à chaque tour et l'affichage. Ton prof, ton IA et toi-même retrouverez un bug beaucoup plus vite.

Ce n'est pas une règle inventée pour ce cours : c'est la structure App que ton prof utilise dans ses cours, et la façon dont la plupart des jeux sont construits. Tu l'écriras toi-même à partir de jeudi.

3. L'état du jeu : la mémoire

L'état du jeu, ce sont toutes les informations qui décrivent la situation à un instant précis : où est la grenouille, où sont les voitures, combien de vies il reste, quel est le score.

Tout dépend de cette mémoire. Si l'état est clair, le reste suit : dessiner, tester une collision, savoir si la partie est perdue. Chaque jour, tu verras cet état grandir : d'abord des variables, puis des listes, puis des objets.

4. Des règles qui décident

Une règle, c'est une question posée à l'état du jeu, suivie d'une conséquence :

la grenouille touche-t-elle une voiture ? Si oui, elle perd une vie.
la grenouille est-elle sur un radeau ? Si non, elle tombe à l'eau.
la grenouille a-t-elle atteint une maison ? Si oui, le joueur marque des points.

Ces règles sont écrites dans update(), et c'est là que tu pourras les modifier pour créer ton propre jeu.

5. Ce que tu vas construire cette semaine

Frogger réunit toutes ces idées dans un petit périmètre :

une grenouille qui se déplace (variables, fonctions, classes) ;
des voitures et des radeaux qui défilent au hasard (listes, boucles, aléatoire) ;
des règles de victoire et de défaite (conditions, états du jeu) ;
un écran de fin, un pseudo et un tableau des meilleurs scores (dictionnaires, fichiers, interface) ;
un code découpé en modules que tu sauras défendre devant ton prof.

Chaque jour ajoute une brique à ce même plateau, toujours avec le même plan __init__ / process_events / update / draw.

À retenir

Un jeu est une boucle qui tourne sans fin.
Chaque élément du jeu suit le même plan : __init__, process_events (seulement s'il réagit au joueur), update(dt), draw(screen).
L'état est la mémoire du jeu ; les règles décident de ce qui se passe.
Tu n'as pas besoin de tout comprendre aujourd'hui : la semaine va te faire construire chacune de ces briques, une à la fois.

Prochaine étape : Comment suivre ce cours, puis lundi, le trottoir.