О, а можно ссылку на вашу статью? Было бы интересно почитать. Про шахматы по дороге это жиза. Только я с телефона на chess.com играю. А на личесс с ноута в комфортных условиях, поэтому там рейтинг выше)
Изначально я писал шахматную логику "вслепую", было интересно самому реализовать всё, не подсматривая, и по-спотыкаться о подводные камни. Потом уже стал сравнивать)
Мне очень понравилась идея записи состояния игры с личесс. Раньше я там просто играл и не пользовался дополнительным функционалом. Можно зайти в 'инструменты' -> 'редактор доски' и увидеть записи вида:
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Это состояние соответствует начальной расстановке фигур на доске)
При анализе возникает неопределённость. Допустим, мы хотим посмотреть, куда может двигаться ладья. Напишем алгоритм, который ищет поля, чьи id соответствуют движению по вертикали и горизонтали. То есть написать какой-нибудь for, который будет имитировать движение по доске (а в реальности по массиву id) Но рано или поздно мы подходим к краю доски. Следовательно, по этому направлению мы должны остановить "движение". В случае с координатами всё просто - x и y меняются от 0 до 7. Но в случае с одномерным массивом мы не можем просто так понять вышли ли мы за пределы доски. Так как фигура просто телепортируется за на противоположный конец поля (например ладья с поля 7 на поле 8).
Решить эту проблему можно. Например, анализировать не поле 8 на 8, а 12 на 12. То есть создать ''буферную зону" по краям, чьи id будут однозначно говорить, что это поле не игровое. 12 на 12 потому что конь прыгает через два ряда.
Но зачем столько мороки, когда можно анализировать просто координаты?)
Через флаг. Сохраняются и история ходов, и доска конкретной игры, и состояние самой игры. Информация о рокировке сохраняется в состоянии игры, обращаться к истории ходов или доске для этого не нужно. Разумеется, для анализа отдельного хода используется информация и о доске и состоянии игры. История ходов выступает больше как логирование, но и она нужна. Только не для рокировки, а для условий "50 ходов подряд без взятия фигуры" или "трижды повторившаяся позиция".
Со взятием просто. Есть поле "откуда" с ходящей фигурой и поле "куда" с фигурой съедаемой. Подробнее об этом будет в следующих частях, но пока скажу, что у доски к каждому полю привязана конкретная фигура. Соответственно, при взятии, надо удалить у поля ''откуда" фигуру и заменить ею фигуру поля "куда".
Со взятием на проходе и рокировкой таких полей (для которых необходимо произвести изменения) больше. Плюс те ограничения, о которых я писал в этой статье. Поэтому да, рокировка и взятие на проходе требуют дополнительной реализации, нежели просто взятие одной фигурой другой.
Превращение пешки в этом плане проще, так как тут мы снова оперируем только двумя полями "откуда" и "куда". Просто удаляется фигура с "откуда" и создаётся новая в "куда".
О, а можно ссылку на вашу статью? Было бы интересно почитать.
Про шахматы по дороге это жиза. Только я с телефона на chess.com играю. А на личесс с ноута в комфортных условиях, поэтому там рейтинг выше)
Изначально я писал шахматную логику "вслепую", было интересно самому реализовать всё, не подсматривая, и по-спотыкаться о подводные камни. Потом уже стал сравнивать)
Мне очень понравилась идея записи состояния игры с личесс. Раньше я там просто играл и не пользовался дополнительным функционалом. Можно зайти в 'инструменты' -> 'редактор доски' и увидеть записи вида:
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Это состояние соответствует начальной расстановке фигур на доске)
При анализе возникает неопределённость. Допустим, мы хотим посмотреть, куда может двигаться ладья. Напишем алгоритм, который ищет поля, чьи id соответствуют движению по вертикали и горизонтали. То есть написать какой-нибудь for, который будет имитировать движение по доске (а в реальности по массиву id) Но рано или поздно мы подходим к краю доски. Следовательно, по этому направлению мы должны остановить "движение". В случае с координатами всё просто - x и y меняются от 0 до 7. Но в случае с одномерным массивом мы не можем просто так понять вышли ли мы за пределы доски. Так как фигура просто телепортируется за на противоположный конец поля (например ладья с поля 7 на поле 8).
Решить эту проблему можно. Например, анализировать не поле 8 на 8, а 12 на 12. То есть создать ''буферную зону" по краям, чьи id будут однозначно говорить, что это поле не игровое. 12 на 12 потому что конь прыгает через два ряда.
Но зачем столько мороки, когда можно анализировать просто координаты?)
Так и не полюбилась эта игра(
Шахматы мне куда ближе. Но на реализацию го на go я бы глянул хотя бы из любопытства)
Через флаг. Сохраняются и история ходов, и доска конкретной игры, и состояние самой игры. Информация о рокировке сохраняется в состоянии игры, обращаться к истории ходов или доске для этого не нужно. Разумеется, для анализа отдельного хода используется информация и о доске и состоянии игры. История ходов выступает больше как логирование, но и она нужна. Только не для рокировки, а для условий "50 ходов подряд без взятия фигуры" или "трижды повторившаяся позиция".
Спасибо! Постараюсь опубликовать её как можно скорее)
Со взятием просто. Есть поле "откуда" с ходящей фигурой и поле "куда" с фигурой съедаемой. Подробнее об этом будет в следующих частях, но пока скажу, что у доски к каждому полю привязана конкретная фигура. Соответственно, при взятии, надо удалить у поля ''откуда" фигуру и заменить ею фигуру поля "куда".
Со взятием на проходе и рокировкой таких полей (для которых необходимо произвести изменения) больше. Плюс те ограничения, о которых я писал в этой статье. Поэтому да, рокировка и взятие на проходе требуют дополнительной реализации, нежели просто взятие одной фигурой другой.
Превращение пешки в этом плане проще, так как тут мы снова оперируем только двумя полями "откуда" и "куда". Просто удаляется фигура с "откуда" и создаётся новая в "куда".
Спасибо! Рад, что вам понравилось)