Je comprends parfaitement ce qu'est un commutateur BUD et à quoi il sert. Mais que se passe-t-il dans le jeu lorsque qu'un commutateur BUD fonctionne? Qu'est-ce qui lui permet de fonctionner et à quoi pense le jeu?
Voici une explication plus détaillée (bien qu'elle soit encore un peu simplifiée) :
Le monde de Minecraft change constamment et le jeu doit constamment calculer le nouvel état du monde. Cela se produit 20 fois par seconde et est appelé un tick. Dans la plupart des ticks de jeu, il y a pas mal de changements d'entités - mouvements et comportements des mobs, mouvements de projectiles et d'objets abandonnés, etc.
Dans le code du jeu, chaque bloc a un certain comportement associé à lui - les portes s'ouvrent ou se ferment, les pistons bougent, l'eau s'écoule, etc. Le jeu doit exécuter ce comportement pour calculer le nouvel état des blocs. Dans des paramètres typiques, il y a des dizaines de millions de blocs autour du joueur, mais les changements de blocs sont relativement rares. En un seul tick, il y a à peine des changements de blocs. C'est pourquoi il n'a pas de sens d'exécuter (calculer) le comportement pour tous les blocs tout le temps, mais il est beaucoup plus raisonnable de le faire seulement pour les blocs modifiés. Cela signifie que le jeu doit suivre quels blocs changent.
Heureusement, suivre les changements est facile - les changements sont généralement transmis d'un bloc à ses voisins. Ainsi, si un bloc change - par exemple lorsque le joueur place un bloc ou bascule un levier, les six blocs adjacents sont planifiés pour la mise à jour. Lorsque leur changement est calculé, ils planifient à leur tour tous leurs blocs adjacents pour une mise à jour, etc. Le processus s'arrête si un bloc 'passif' est atteint, comme l'air ou la plupart des blocs solides.
Par exemple, considérez ce qui se passe si le joueur casse la base d'un roseau : le bloc est retiré (remplacé par de l'air) et un objet de roseau est créé à sa place. Il notifie ensuite les six blocs adjacents pour se mettre à jour. Le roseau du milieu 'réalise' qu'il n'est pas soutenu et se supprime tout en créant un deuxième objet de roseau. L'eau adjacente 'réalise' qu'elle peut s'écouler dans l'espace libre où se trouvait le bas du roseau et y place de l'eau qui s'écoule. Enfin, le roseau du haut se met à jour, programmé par le deuxième roseau - il 'réalise' qu'il n'est pas soutenu et se supprime tout en créant un troisième objet de roseau. Le reste des blocs adjacents sont de l'air ou du sol, et ils ne changent pas, donc ils ne notifient plus aucun bloc adjacent de se mettre à jour.
Lorsqu'une lampe de redstone est programmée pour une mise à jour, elle vérifie si l'un des blocs environnants est alimenté et s'allume (ou s'éteint si ce n'est pas le cas). Lorsque le joueur place un bloc de redstone à côté d'elle, le bloc de redstone programme des mises à jour pour tous les blocs adjacents y compris la lampe. La lampe 'réalise' alors qu'elle est alimentée et s'allume.
C'est aussi ainsi que le signal de redstone 'voyage' - chaque morceau de poussière de redstone notifie les blocs adjacents et les morceaux de poussière adjacents mettent à jour leur niveau de puissance et notifient les blocs adjacents, etc.
Lorsqu'un piston est programmé pour une mise à jour, il vérifie si l'un des blocs adjacents est alimenté. Cependant, pour une raison quelconque, il vérifie également si l'un des blocs adjacents du bloc au-dessus de lui est alimenté. En image, il vérifie si l'un des blocs de verre est alimenté :
C'est pourquoi il est possible de construire ce BUD simple non réinitialisable :
Lorsque vous placez le bloc de redstone, il notifie l'herbe en dessous et l'air autour de lui de se mettre à jour, et ils ne font rien. Le bloc de redstone n'envoie pas de notification au piston pour se mettre à jour, car il n'est pas adjacent au bloc de redstone, donc le piston reste rétracté. Si après cela, le piston reçoit n'importe quelle notification pour se mettre à jour d'une autre manière (par exemple en plaçant un bloc à côté du piston ou en faisant pousser une culture à côté du piston), le piston 'réalise' qu'il est alimenté (car il vérifiera à l'endroit en diagonale au-dessus de l'endroit où se trouve le bloc de redstone) et il s'étendra.
Les distributeurs et les déclencheurs ont le même schéma étrange de vérification s'ils sont alimentés, donc ils peuvent également être utilisés comme BUDs.
Les mises à jour de blocs sont généralement déclenchées par une action de joueur ou de mob, mais il y a aussi une autre source de mises à jour - le jeu planifie un type spécial de mise à jour (différent de la mise à jour normale) pour des blocs choisis au hasard à chaque tick. Certains blocs réagissent à ces mises à jour aléatoires - par exemple, les cultures peuvent décider de pousser lors de cette mise à jour aléatoire. S'ils décident de pousser, ils programment ensuite des mises à jour régulières pour leurs blocs adjacents. Un autre exemple est que l'eau peut choisir de se transformer en glace si elle se trouve dans une biome froide ou haut au-dessus du sol.
La plupart des commutateurs BUD fonctionnent sur le fait que vous pouvez alimenter un piston avec une quasi-connectivité. Cela lui permet d'être alimenté sans que le piston le remarque. Lorsque vous changez un bloc à côté du piston, il vérifie s'il est alimenté et remarque qu'il l'est. Il envoie ensuite un signal et se réinitialise.
AlleGamers est une communauté de gamers qui cherche à élargir la connaissance des jeux vidéo.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
