Étape 1 :
La première grande partie de VHDL qui nous mis en place était la logique de jeu. Dans ce module, nous avons créé au sein de l’entité sorties pour les emplacements de quatre obstacle, le score, vit à gauche et le jeu au cours de l’État. Depuis que nous avons ajouté dans une horloge avec la fréquence de 8Hz. Les constantes que nous avons utilisé pour créer cette fréquence sont nombre entier et représente notre fréquence souhaitée des mises à jour de logique de jeu. Ensuite, nous avons généré une séquence aléatoire pour les obstacles à afficher. Par l’utilisation d’un LFSR, nous étions en mesure de faire face à un générateur de nombres pseudo-aléatoires pour générer les obstacles dans le jeu. Obst_out est la sortie vue et que la sortie est envoyée vers le module pick_a_lane qui décide de l’obstacle qui les quatre voies vont aussi.
La prochaine partie consiste à décider si oui ou non le joueur a été touché par un obstacle ou non. Par l’utilisation de signaux, que nous avons pu garder trace des où les joueurs et les obstacles étaient en permanence. Grâce à cela, nous pouvions aussi garder une trace de combien hits, le joueur a fait avec l’obstacle avant d’atteindre le jeu état survolé. Une autre horloge a été mis en place spécifiquement pour la logique de « jeu » du circuit. Il est beaucoup plus lent que l’horloge d’autre signaux car elle détermine la fréquence à laquelle les objets sur l’écran sont mises à jour et à quelle rapiditè les obstacles se déplacent sur l’écran. Une fois que nous avons eu l’horloge « jeu logique » mis en, nous avons pu créer une réinitialisation globale. Ce reset signal est lié à tous les composants de la logique de « jeu » et lorsque le signal est élevé, il réinitialise tous les éléments du jeu. Ensuite, nous avons instancié le quatre SRs pour les quatre voies. Les entrées d’obst_in au service SRs liées aux indices DJ arbitrairement choisis de nombre binaire de la 32 bits de la LFSR stockée. Les sorties de ces SRs sont liés à l’ourputs du module game_mechanics. Une fois que les quatre SRs ont été instanciés nous mettons dans un LFSR qui sert à générer de nouveaux obstacles dans les quatre voies de façon Pseudo-aléatoire. Puis, un processus est utilisé pour générer notre désiré « pendule » avec une fréquence de 8Hz et l’enable_game_update de signal ne sera élevée 16 fois par seconde. Ensuite, à travers une série d’if/else instructions, un processus a été créé afin de déterminer le mouvement du joueur. Le joueur ne doit se déplacer vers le haut ou vers le bas entre les voies. Elle s’exécute chaque fois qu’un changement dans l’entrée pour lecteur est détecté, parce que c’est lorsque l’utilisateur souhaite déplacer leur personnage. Après que le processus de player_movement a été mis en place, un processus de détection atteinte était nécessaire. Ce processus est responsable de la vérification pour voir si le joueur frappe un obstacle quand l’obstacle entre dans la zone « lecteur ». Avec ce processus de hit_detection, un processus appelé scoring_system a été mis en action à travers un if/else instruction qui incrémente une fois par seconde. Enfin, un processus appelé check_for_game_over est nécessaire pour compléter la logique de jeu. Instructions using if/else et par le procédé de global_reset, nous avons pu vérifier si la lose_state était élevée ou basse. Si lives_left est égal à zéro, puis « Game Over ».
