Aller au contenu

Limitations connues

À propos de cette page

Cette page documente l'état réel du code tel qu'il existe aujourd'hui : fonctions laissées en stub, écarts entre le code et la documentation historique, et bugs potentiels identifiés lors de la relecture du dépôt. L'objectif est d'offrir une référence honnête et précise, pas un réquisitoire : chaque point est décrit comme un état actuel, une limitation connue ou un travail futur, avec le fichier:ligne quand il est connu et l'impact pratique.

Le code reste fonctionnel pour le cas d'usage nominal ; les éléments listés ici concernent des branches non câblées, des incohérences de représentation, ou des fonctionnalités annoncées mais non réalisées de bout en bout.

IA (Python)

L'IA (ai/) est largement implémentée, mais son README la qualifie encore de « squelette ». Plusieurs stubs et incohérences subsistent.

Stubs (provoquent une erreur si atteints)

Fonctions non implémentées

Élément Emplacement Impact
parse_broadcast ai/src/protocol/parser.py:102 Lève NotImplementedError. Les broadcasts entrants message K, text ne sont pas traités de bout en bout : le ralliement par le son n'est pas réalisé.
ForkState (4 méthodes) ai/src/strategy/states/fork.py:27,33,37,41 Toutes les méthodes lèvent NotImplementedError. FORK est enregistré dans la FSM mais aucune transition n'y mène ; y entrer planterait. La stratégie de reproduction (Fork/Connect_nbr) n'est pas implémentée.
tile_index_to_relative_coord ai/src/state/vision.py:20 Stub mort : la géométrie équivalente est implémentée en ligne dans WorldMap.update_from_look. Jamais appelé, donc sans effet runtime.

Voir IA > Stratégie (FSM) et IA > Couche protocole.

Code implémenté mais non câblé

Présent et testé, mais sans appelant

Le paquet team/ complet (crypto.py, protocol.py, decoy.py) est implémenté et couvert par des tests, mais n'est référencé que depuis team/ lui-même : aucun appelant dans le réseau ou la stratégie. Les communications d'équipe chiffrées et les leurres (decoys) ne sont donc pas utilisés à l'exécution. Voir IA > Coordination d'équipe.

Autres éléments implémentés mais inutilisés :

  • pathfinding.bfs_toric — BFS torique complet, aucun appelant.
  • pathfinding.direction_from_sound — mapping K (0–8) vers direction, inutilisé (lié à l'absence de ralliement sonore).
  • Client.flush_output — implémenté mais jamais appelé depuis la boucle principale.
  • CommandQueue._callbacks — stocké par add_callback mais jamais relu (effectivement mort).
  • ConnectNbrResult — type de message jamais produit (car ForkState est un stub).
  • config.DEFAULT_HOST — constante inutilisée.

Bug probable : comparaison d'unités de food

Seuils de food : count vs unités de temps

Les comparaisons de seuil de nourriture confrontent drone.food (un nombre d'unités de food) à FOOD_SURVIVAL_THRESHOLD * LIFE_PER_FOOD (une valeur en unités de temps, p. ex. 5 * 126 = 630). On compare donc un compte (typiquement quelques unités) à une valeur en ticks (centaines), si bien que certaines transitions risquent de ne jamais se déclencher.

Concerné dans : survive, collect, incant_prep, incant (ai/src/strategy/states/). Voir IA > Stratégie (FSM).

Fragilité du handshake

do_handshake suppose une réception groupée

Dans ai/src/network/connection.py (do_handshake, ~:65), le code suppose que CLIENT-NUM et la ligne X Y arrivent dans un seul recv (splitlines()[0] / [1]). En cas de fragmentation TCP, cela peut lever une IndexError. Voir IA > Réseau & file de commandes.

Écarts code / documentation

Le code ne correspond pas toujours aux docstrings/README

  • Boucle d'E/S : main utilise un polling par select avec timeout (select.select([...], [], [], 0.1)), pas le module selectors, contrairement à ce que suggèrent les docstrings et le README. La boucle principale est un while 1 non bloquant, pas une boucle événementielle sans busy-wait.
  • Diagramme FSM du README : le diagramme historique (RALLY basé sur le son, EXPLORE comme état par défaut, boucle FORK) ne correspond pas à l'implémentation : RALLY est basé sur des coordonnées, l'état initial est survive, et FORK est inatteignable.

Voir IA > Boucle de décision et IA > Stratégie (FSM).

Résidus de débogage et configuration

Détails à nettoyer

  • print() de débogage laissés en place : ai/src/strategy/states/collect.py:50 et :95, ai/src/strategy/states/incant_prep.py:77.
  • pyproject.toml : la cible wheel [tool.hatch.build.targets.wheel] référence packages=["src/zappy_ai"], un dossier inexistant. La construction du wheel est donc mal configurée — sans impact car le client est lancé directement (via ./zappy_ai), pas installé.

Serveur (C++)

Mismatch de représentation de la food

La quantité de nourriture n'a pas la même représentation selon le consommateur :

  • l'IA reçoit, dans l'Inventory, la food sous forme units * 126 (server/srcs/commands/CmdInventory.cpp:12) ;
  • le GUI reçoit, via pin, le compte brut d'unités (server/srcs/protocol/GUIProtocol.cpp:100).

De plus, le commentaire de Player.hpp décrit la food comme 1260 ticks, ce qui ne correspond pas au modèle à 10 unités (1 unité consommée tous les 126 ticks). La durée totale est équivalente (10 × 126 = 1260), seule la représentation diffère. Voir Serveur > Joueurs, équipes & œufs.

Événements / commandes du serveur

  • smg : l'événement GUI smg est défini dans GUIProtocol mais aucun site d'appel serveur ne l'émet (semble inutilisé).
  • Connect_nbr : la commande renvoie le nombre d'œufs d'équipe restants (non éclos) plutôt qu'un décompte séparé de slots de connexion libres. L'approximation est raisonnable mais ce n'est pas, à proprement parler, un compteur de slots libres dédié.

Voir Serveur > Commandes & délais.

GUI (C++ / Raylib)

Version de Raylib non figée

La version de Raylib n'est figée nulle part (fichiers de build, docs, binaire). Le build suppose une bibliothèque libraylib installée au niveau système (lien dynamique -lraylib -lGL ...), et un pilote compatible GL / GLSL 330 (le shader recolor.frag cible #version 330). Aucun vendoring, find_package, pkg-config ni FetchContent. La page GUI > Installation de Raylib décrit donc une installation générique (paquet de distribution ou compilation depuis les sources).

Code mort et messages ignorés

  • gui/raylib/Window.* : wrapper fin non compilé (absent des SRCS du Makefile) et non utilisé — code mort / hérité.
  • mct : le handler est un no-op (le serveur développe mct en bct par tuile).
  • sst : non géré par le GUI (pas de handler).
  • Le GUI ne traite que les 21 messages enregistrés dans MessageParser. Les réponses serveur sst / suc / sbp sont ignorées — ce qui est cohérent puisque le GUI n'envoie jamais que GRAPHIC.

Panneau d'info joueur (PlayerCard) stubbé

Le panneau 2D PlayerCard est câblé mais inopérant : _focusedPlayerId (Renderer3D.hpp:53) n'est jamais positionné (reste à -1). La branche « joueur focalisé » ne s'exécute donc jamais, et la carte est toujours dessinée vide, avec le nom codé en dur « Salut » (PlayerCard.cpp:20).

Assets et raccourcis caméra

  • Assets : de nombreux dossiers d'assets présents sur le disque sont inutilisés ; seuls 13 dossiers d'animation plus le shader, la police et les éléments de playerCard sont chargés.
  • Caméra : la table des touches du README est partiellement incohérente avec le code réel d'IsoCamera. Se fier au code et à l'indication affichée en jeu (« W/S height | A/D radius | Q/E orbit »).

Voir GUI > Rendu graphique.

Dérive build / documentation

Deux répertoires d'IA

Deux dossiers d'IA coexistent :

  • ai/ est l'IA vivante (vrai code Python, zappy_ai, tests, docs) ;
  • ia/ est hérité / mort (seulement un script shell et des dossiers vides, aucun .py).

Le Makefile racine référence bien ai/. Le dossier ia/ peut être ignoré.

CI et docs

  • CI : le Jenkinsfile ne construit ni ne teste le GUI : il compile et teste uniquement le serveur (build, cppcheck, doctest, couverture) et exécute la suite pytest de l'IA. Le seul workflow GitHub (.github/workflows/mirror.yml) ne fait qu'un miroir du dépôt.
  • Doc manquante : gui/README.md référence un fichier docs/GUI_protocol.md qui n'existe pas.