Ce module suppose que vous avez déjà lancé le jeu localement, en suivant les instructions de configuration.
Dans les modules précédents, nous avons :
Ces deux tâches étaient assez autonomes. Essayons quelque chose d'un peu plus compliqué, qui touche plusieurs fichiers.
Les joueurs du jeu rapportent que parfois, l'invite « E » ne fonctionne pas comme prévu. Cela semble se produire lorsqu'on se trouve près des murs :
Afficher la transcription : Recording of the interact-prompt bug near a wall
Dans cet enregistrement, vous pouvez voir que l'invite « E » disparaît même si le joueur est suffisamment proche du coffre et de l'objet.
Essayez de demander à Kiro de résoudre ce problème. Par exemple :
Parfois, lorsque le joueur est plus proche du mur que d'un objet interactif comme un item ou le coffre, l'invite d'interaction n'apparaît pas au-dessus de l'objet interactif.
Kiro devrait être capable d'identifier correctement le problème. La fonction qui trouve quel objet est le plus proche du joueur ne filtre pas les murs; par conséquent, lorsque le joueur est près d'un mur, elle marque le mur comme étant l'objet le plus proche, même si le mur n'est pas réellement interactif.
Chargement de l'image...
Le modèle a proposé de corriger le bogue en introduisant une vérification pour exclure
les objets dont la masse physique est Infinity. Bien que cela
résolve techniquement le problème à court terme, est-ce
la meilleure correction? Que se passe-t-il s'il y a des objets non interactifs qui ont
une masse finie? Ou que se passe-t-il s'il y a des objets qui ont une masse
Infinity mais qui sont tout de même interactifs?
Cette solution de code proposée ajoute une logique déclenchée par une propriété dont la signification sémantique n'est pas directement liée à cette logique. Bien que cette correction fonctionne temporairement, le comportement surchargé finira assurément par causer des ruptures ou des bogues subtils plus tard.
Plutôt que d'essayer de traiter cela comme un problème entièrement autonome
dans le fichier game-object-system.ts, effectuons une refactorisation plus vaste.
Partout où des objets de jeu sont créés, nous devrions probablement
indiquer d'emblée si l'objet créé est destiné à être
interactif.
Essayez une requête comme :
Dans #GameObject, ajoutez une nouvelle propriété obligatoire interactive.
Dans #updatePlayerProximity, filtrez les objets non interactifs.
Tous les appels à #addObject dans le code doivent définir interactive à true ou false
Vos résultats devraient ressembler à quelque chose comme ceci :
Chargement de l'image...
Au lieu d'une seule modification, il y a 22 modifications touchant de nombreux fichiers du projet. Cette refactorisation garantira que l'API des objets de jeu contient une signification sémantique appropriée pour exprimer si un objet est destiné à être interactif.
Le LLM pourra utiliser cette signification sémantique à l'avenir, chaque fois qu'il devra implémenter une fonctionnalité.
Dans ce module, vous avez appris trois concepts clés :
Passons à la prochaine tâche :
La refactorisation intuitive représente 50 % de la programmation intuitive
Corriger un problème complexe touchant plusieurs fichiers