prologin / prologin2019 Goto Github PK

Imadi 2 laissé dégeu

Gameplay

• Add a maximal weight capacity?
• Error PAS_DE_NAIN is not used anymore in "tirer", it is still use in "miner", but may get a more relevant name?

From haltode's review

• "Granite standard (indépendament de s'il cache des minerais ou non)" :
  du coup il n'est pas nécessairement standard ? -- NOTE: j'ai uniformisé la blague avec le format "nain (standard)"
• Confusion possible entre LIBRE et GRANITE ? De ce que j'ai compris
  LIBRE c'est en réalité du vide, et GRANITE c'est les blocs qu'on peut
  miner. -- NOTE: j'ai uniformisé les précisions
• case_type.erreur_case est un peu redondant, pourquoi pas juste
  case_type.erreur -- NOTE: cohérant avec la convention de Prologin et je pense certains langages pour lesquels l'utilisation des enums est peu verbeuse
• 'pas_accroche' et 'deja_accroche' pas nécessaires vu que ça ne coûte
  rien de s'accrocher/se détacher -- NOTE: les coûts ne sont pas hardcodés et peuvent changer (l'erreur ne coûte rien)
• Il y a un field 'erreur_direction' dans l’énumération 'direction' qui
  est inutile vu qu'il y a déjà une erreur 'direction_invalide' -- NOTE: il ne sert en effet que pour l'implem, foutre des -1 à l'arrache pour un type enum c'est une alternative raisonable ? (alalala ... vivement std::optional)
• Confusion possible entre 'direction' et 'sens' dans le sujet. -- NOTE: j'ai rajouté une précision
• Dans la description de 'obstacle_nain' il ne faudrait pas plutôt
  préciser un nain adverse sur la case ? Vu qu'on a le droit d'avoir
  plusieurs de ses nains sur une même case.
• "Renvoie la liste de toutes les corde dans la mine." -> de toutes les
  positions de corde dans la mine. D'ailleurs c'est le haut de la
  corde j'imagine ? On ne connaît pas sa longueur ?
• Il y a deux 'fct_summary' pour 'info_nain', la deuxième description
  semble être celle à jour.
• "Renvoie la liste de touts les minerais dans la mine." -> de toutes
  les positions. Et pour le coup ça serait mieux de renvoyer les infos
  sur les minerais plutôt que juste les positions. -- NOTE: là tout de suite j'ai la flemme de changer la structure de minerai 😢
• 'cout_de_deplacement' -> renommer en 'cout_deplacement'
  • d'ailleurs ce n'est pas très clair qu'on a plusieurs types de
    déplacement (classique, paroi, corde) qui utilise exactement les
    même fonctions
• Il faut préciser que 'chemin' renvoie uniquement les déplacements
  simples, pas de cordes ou autre. -- NOTE: je pense que la façon dont on gère les déplacement est bonne, et une des plus simples: les nains peuvent se déplacer avec pour seul paramètre une direction, des facteurs extérieurs peuvent influencer le coût de ce déplacement (une corde ou s'il est accroché), la plus grosse subtilité est que le fait d'être accroché ou non annule l'influence de la gravité. Reste à clarifier le sujet papier je suppose :)
• Ça serait mieux de placer la fonction 'chemin' plus haut (en premier
  ?) dans la liste des fonctions, vu son importance pour un candidat.

À discuter

• enlever la notion de "il faut avoir les pieds au sol pour tirer la corde"

General

• Compress "agripper - lacher - ... " sequences to avoid huge histories -- NOTE: cf branche dédiée -- NOTE: capé à 1024 actions par stechec
• Kill dwarf on enemy tavern
• Eliminate all TODOs.
• Embed the API's sources into a namespace to avoid conflict with candidate's code during linkage.
• The code often iterates on a modified object with no specific assumption (eg: results of get_nains_at as a ref)
• ERREUR_CASE seems unused
• Should we keep ERREUR_DIRECTION ?

Need testing

• Kill when walking on enemy tavern
• Gravity on death

Performances

• It could be quicker to save the set of dwarfs on a cell using a vector: even if update will be in linear time, an hashset seems overeact for at most 6 elements and it is slower to iterate.

Not critical (and probably still tedious)

• "nain" is left untranslated even in english parts of the code
• The testing framework use two separate game_state for each player, which make it harder to test interactions

From haltode's review

Actions

• C'est jamais évident d'avoir une action qui en est deux réellement
  (l'action de 'miner' qui permet de miner ET d'attaquer). Par exemple
  je trouve ça bizarre de se prendre une erreur PAS_DE_NAIN pour avoir
  miné une case vide.
• La fonction 'apply_on' de l'action miner devrait avoir une meilleure
  distinction dans le code entre les deux actions possibles (miner et
  attaquer). Par exemple le coup du if (type == LIBRE) qui a un return
  débranchant au lieu d'un else, alors que c'est l'occasion de bien
  distinguer le code qui s'occupe de l'attaque de celui qui s'occupe de
  miner (au début j'ai cru qu'on pouvait attaquer ET miner en même temps
  car j'avais raté le return à la fin de la condition pour le coup).
• Nombres magiques dans les fonctions 'apply_on' des actions.

API

• Répétitions inutiles de la structure d'erreur {{ -1, -1 }, -1, -1, -1,
  false, -1 } dans 'info_nain'.

GameState

• Le coup de 'get_movement_cost' qui peut renvoyer -1 en cas d'erreur je
  trouve ça risqué lorsqu'on voit qu'on modifie des valeurs direct avec
  la valeur de retour. Renvoyer 0 serait plus safe, ou vérifier la
  valeur de retour avant son utilisation.
• Pas fan des fonctions '*_internal' qui ne sont pas utiles du tout (à
  chaque fois c'est deux lignes dont l'appel à la fonction non
  _internal) et non explicites (exemple : 'get_nain_internal' le
  internal ici fait référence à l'id du joueur).
• Le fichier game_state est assez gros, je pense qu'il faudrait extraire
  la plupart des fonctions trop spécifique aux nains dans un fichier à
  part.
• La fonction 'get_cell_ownership' est ambiguë car on dirait qu'il y a
  une notion de territoire.
• Il y a une fonction 'GameState::check_gravity' et
  'Map::check_gravity', ça peut prêter à confusion surtout que les deux
  ont des utilisations très distinctes (une pour les nains et une pour
  les cordes).
• Remplacer la récursivité par une boucle dans 'check_gravity'

Map

• Le 'std::pair<int, std::unordered_set' pour stocker les infos sur
  des nains apparaît souvent, pourquoi pas utiliser une structure
  davantage explicite ? Cela fix aussi le souci du .first .second qui
  ne donne aucunes infos.

• Je comprends pas ça, dans la class Map :

  std::array<std::array<int, TAILLE_MINE>, TAILLE_MINE> rope_;
  std::vector ropes_;
  std::vector ropes_pos_;

  std::array<std::array<int, TAILLE_MINE>, TAILLE_MINE> ore_;
  std::vector ores_;
  std::vector ores_pos_;

  Pourquoi pas avoir des structures pour Rope et Ore qui stockent les
  infos à un seul endroit ?

• Utiliser 3 tableaux 2D de la taille de la carte pour stocker des infos
  sur nains, cordes et minerais semble overkill et un peu étrange/lourd
  dans l'utilisation. NOTE: j'ai essayé d'autres structures pour rivaliser, ça n'a pas été concluant, il doit y avoir en effet moyen de faire quelque chose étant donné le nombre conséquent de copies que fait l'historique.

• Remplacer la récursivité par une boucle dans 'check_gravity'

• "resistance must be a strictly positif int" => positive*

• Les paires sont assez peu explicite dans leur utilisation, je pense
  surtout à la fonction 'get_nains_at' car je vois des
  nains.second.empty() par exemple qui me donne 0 info de ce qu'est le
  nains.second

• Clairement pas fan de retourner un raw pointer sur un nain (ou un
  nullptr si le nain est mort). La structure 'nain' contient très peu de
  choses et puis on peut compter sur le RVO pour ne pas faire de copie
  lors du return. D'autant plus que faire un if (nain == nullptr) est
  beaucoup moins explicite que if (nain.vie <= 0).

• Même remarque sur raw pointer + nullptr pour corde et minerai

Misc.

• La structure 'fall_info' contient un attribut 'goal' en anglais alors
  que le reste des attributs sont en français (il faut aussi changer
  dans le dumper). NOTE: c'est faux, les deux autres attributs sont
  "player_id et nain_id", nain a été mal traduit dans tout le reste du code
  (cf. item dédié then)
• Mix français/anglais 'set_nain_accroche' NOTE: cf. ci-dessus
• Chaque année on utilise clang-format pour avoir une coding style
  consistante, ça serait bien de continuer à utiliser cet outil.

• Handle merging ropes (checking if the above cell is a rope should be enough)
• Find out why dwarves seem to get a position offset (maybe api issue?)