Это всегда зависит от домена. Но есть также две ситуации, когда вы выполняете такие поиски. Одна ситуация после хода (изменение игрового поля, сделанного игроком), а другая будет, если / когда вся доска изменилась.
В тетрисе вам не нужно сканировать всю доску после того, как кусок упал. Тебе просто нужно поискать строки, к которым прикоснулся кусок.
В матч-3 играх, таких как Bejeweled, где вы меняете местами две смежные фигуры одновременно, вы сначала запускаете локализованный поиск в каждом направлении вокруг каждого квадрата, который изменился, чтобы увидеть, сработали ли какие-нибудь фигуры. Затем, если они есть, игра сбросит несколько новых случайных фигур на игровое поле. Теперь вы можете запускать один и тот же локализованный поиск вокруг каждого измененного квадрата, но это может включать много операторов if и может на самом деле медленнее просто сканировать всю доску сверху вниз слева направо. Это зависит от вашей реализации и потребует профилирования.
Как говорит Адриан, достаточно простого 2D-массива. Однако часто вы можете добавить «границу» пикселей вокруг этого массива, чтобы упростить аспект поиска шаблонов. Без рамки вы должны иметь if операторов вдоль краевых квадратов, которые говорят: «ну, если вы в верхнем ряду, не ищите (и не уходите от массива)». Имея границы вокруг него, вы можете безопасно просто искать все: сохраняя себя if операторов, сохраняя себя ветвящимися, избавляя себя от проблем конвейера, ища быстрее.
Джону: такие вещи действительно имеют значение в высокопроизводительных настройках, даже на современных машинах, если вы создаете алгоритм поиска для игры / решения игры. Если да, то вы хотите, чтобы ваша базовая симуляция выполнялась как можно быстрее, чтобы искать как можно глубже в наименьшем количестве циклов.