Cela dépend toujours du domaine. Mais il y a aussi deux situations où vous feriez ce genre de recherches. La situation des Ones est après un coup (un changement dans le champ de jeu fait par le joueur), et l'autre serait si/quand le plateau entier a changé.
Dans Tetris, vous n'avez pas besoin de scanner la totalité de la carte après la chute d'une pièce. Vous devez juste chercher les lignes que la pièce touche. Dans un jeu de match-3 comme Bejeweled, où vous échangez deux pièces adjacentes à la fois, vous devez d'abord lancer une recherche localisée dans chaque direction autour de chaque case qui a changé, pour voir si des pièces se sont déclenchées. Ensuite, s'ils le font, le jeu déversera de nouvelles pièces aléatoires sur le plateau. Maintenant, vous pouvez exécuter la même recherche localisée autour de chaque carré qui a changé, mais cela peut impliquer beaucoup de déclarations if et peut être plus lent à balayer tout le tableau de gauche à droite en bas à droite. Cela dépend de votre implémentation et nécessiterait un profilage. Comme le dit Adrian, un tableau 2D simple suffit. Souvent, cependant, vous pouvez ajouter une "bordure" de pixels autour de ce tableau, afin de simplifier l'aspect recherche de motifs. Sans une bordure, vous devez avoir des instructions if le long des carrés de bord qui indiquent «bien, si vous êtes dans la rangée supérieure, ne cherchez pas (et éloignez le tableau)».Avec une bordure autour de vous, vous pouvez en toute sécurité chercher simplement à travers tout: vous sauver if instructions, en économisant vous branchez, en économisant vous-même des problèmes de pipeline, en recherchant plus rapidement. Pour Jon: ce genre de choses a vraiment de l'importance dans les réglages de haute performance, même sur les machines modernes, si vous faites un algorithme de recherche pour jouer/résoudre le jeu. Si vous l'êtes, vous souhaitez que votre simulation sous-jacente s'exécute le plus rapidement possible afin de rechercher le plus profondément possible dans les cycles les plus courts.