Files
kimi-game/BENCHMARK_NOTES.md
T
2026-07-21 16:28:15 +02:00

5.8 KiB
Raw Blame History

Benchmark Notes

Choix de conception principaux

  • Pas de communication en temps réel = cœur de gameplay. Le joueur ne contrôle jamais le robot directement : la seule « manette » est la liste de tâches. Toutes les mécaniques (énergie, usure, météo, terrain) servent à rendre la planification intéressante.
  • Monde infini par hachage déterministe plutôt que bruit de Perlin stocké : chaque case est calculée à la volée depuis (graine, x, y), les chunks (16×16) ne servent que de cache mémoire et peuvent être purgés sans perte. Une même graine reproduit exactement le même monde, y compris après sauvegarde/chargement (seules les cases explorées sont stockées).
  • Simulation à pas fixe (1/30 s) avec accumulateur, découplée du framerate ; accélération ×1/×2/×4 par multiplication du dt simulé.
  • Logique / rendu séparés : seul src/ui.lua (et main.lua) touchent love.graphics. Toute la simulation est testable hors LÖVE.
  • A* 4-directions avec coût d'entrée par case (plaine 1, difficile 3, rochers ∞), bâtiments bloquants intégrés à la fonction de coût, et revalidation du chemin à chaque pas (recalcul si le monde a changé).
  • Échec doux : énergie à 0 → robot immobilisé jusqu'à la nuit, dépannage partiel ; jamais de game over brutal. Les journées perdues sont la vraie pression.
  • Prévision météo quasi-exacte mais faillible (85 %) et déterministe : la météo réelle et l'erreur de prévision dérivent toutes deux de la graine.
  • Identification couleur + forme : chaque terrain a un symbole (zigzag, triangle, losange pointé, cercle), chaque bâtiment une silhouette distincte (carré, grille solaire, pile, cercle foré, triangle relais, losange atelier, double anneau balise).

Compromis réalisés

  • Pas de bibliothèque externe (contrainte) : bruit, A*, UI entièrement écrits à la main. L'UI est donc sobre et sans widgets génériques.
  • Déplacement 4-directions uniquement : les diagonales compliqueraient la lisibilité des coûts de terrain et des collisions d'angle.
  • La réserve de minerai par gisement est finie mais généreuse (300/60) pour ne pas imposer de méta-jeu de prospection dans un benchmark.
  • Les cases explorées sont stockées comme un set de chaînes "x,y" — simple et sérialisable directement ; suffisant pour des milliers de cases.
  • L'aide est un overlay texte plutôt qu'un tutoriel interactif.

Fonctionnalités terminées

  • Monde procédural infini déterministe, génération à la demande, purge mémoire.
  • Caméra (clavier + glisser souris), zoom centré sur le curseur, sélection de case avec panneau d'information.
  • 6 types de tâches (explorer, récolter, construire, réparer, recharger) avec états (en attente / en cours / terminée / impossible / interrompue), réorganisation, suppression, estimation de durée, validation des tâches manifestement impossibles.
  • 7 bâtiments fonctionnels avec règles de placement (gisement, distance entre relais, unicité), construction progressive par le robot, intégrité, messages d'erreur explicites au placement.
  • Ressources (énergie, minerai, données) avec effets concrets ; réseau énergétique qui s'effondre à 0.
  • Météo à 3 états + prévision faillible, impacts gameplay réels (consommation, production, vitesse, usure des bâtiments).
  • Objectifs intermédiaires + objectif principal (balise) + victoire signalée + mode bac à sable après victoire.
  • Sauvegarde / chargement complets (graine, jour, exploration, bâtiments, plans, ressources, robot, tâches, objectifs).
  • Menu principal avec graine choisie ou aléatoire, aide en jeu (F1), notification center, pause, accélération.

Fonctionnalités partielles ou absentes

  • Déplacement diagonal : absent (choix assumé).
  • Marqueur visuel de gisement épuisé : absent.
  • Réparation des bâtiments par l'atelier : l'atelier ne répare que le robot ; les bâtiments se réparent via une tâche dédiée du robot.
  • Son : aucun (aucun asset autorisé ; aucun son généré par code).
  • Multiples sauvegardes : un seul slot.

Tests effectués

love . --tests : 49 tests, 0 échec, couvrant :

  • génération déterministe (même graine / graine différente / chunks à la demande) ;
  • météo reproductible et prévision majoritairement exacte ;
  • A* (contournement d'obstacles, cas impossible, évitement des cases chères) ;
  • règles de placement et coûts de construction ;
  • production des bâtiments (solaire, tempête, extracteur, batterie) ;
  • planification (ajout, suppression, réorganisation, validation, sérialisation) ;
  • robot (déplacement, consommation, usure, immobilisation, sérialisation) ;
  • sauvegarde aller-retour complète ;
  • boucle de journée de bout en bout (construction réelle d'un panneau solaire) ;
  • impact du froid sur la consommation.

Vérification manuelle : love . lance le jeu sans erreur (menu, partie, caméra, placement de plan, exécution, sauvegarde F5, rechargement au menu).

Problèmes connus

  • Sous LÖVE 11.4/Linux, aucun problème bloquant observé.
  • Le texte des infobulles de description longues peut dépasser légèrement la largeur du panneau sur les petites fenêtres (960 px).
  • La liste des tâches est tronquée visuellement au-delà de la hauteur disponible (indicateur « … (n autres) »), sans ascenseur.

Pistes d'amélioration prioritaires

  1. Ascenseur sur la liste des tâches et le panneau d'objectifs.
  2. Indicateur visuel de gisement épuisé et de rendement des relais.
  3. File d'attente de réparations automatiques pour l'atelier.
  4. Diagonales optionnelles dans le pathfinding.
  5. Génération audio procédurale (love.sound.newSoundData) pour rester sans asset externe.
  6. Plusieurs slots de sauvegarde et sauvegarde automatique en fin de journée.