Какую парадигму использовать для написания шахматного движка?

Если бы вы собирались написать движок для игры в шахматы, какую парадигму программирования вы бы использовали (ООП, процедурный и т. Д.) И почему вы бы выбрали это? Под шахматным движком я подразумеваю часть программы, которая оценивает текущую доску и решает следующий ход компьютера.

Я спрашиваю, потому что я думал, что было бы весело написать шахматный движок. Затем мне пришло в голову, что я могу использовать его как проект для изучения функционального программирования. Затем мне пришло в голову, что некоторые проблемы не совсем подходят для функциональной парадигмы. Затем мне пришло в голову, что это может быть хорошим кормом для обсуждения.

Насколько мне известно, оценка - это не распараллеливаемая проблема, но оценка различных цепочек такова, поэтому я бы окончательно написал ее, чтобы использовать несколько ядер и многопоточность.

Работаете ли вы функционально или полуфункционально - дело вкуса. Лично я бы пошел ООП и использовал бы поддержку для функционального программирования и распараллеливания, которая существует, например, в C #

С другой стороны, если бы я написал шахматный движок, я бы попытался создать такой, который действительно мог бы «думать» о шахматах. Используя оценку доски для грубой силы, все возможные комбинации были сделаны до смерти и очень хорошо, но на самом деле не было большого прогресса в создании более размышляющего / нечеткого шахматного движка. Это было бы проблемой! :)

Найдите некоторые игры с действительно сложной позиционной игрой и сильными ходами (они отмечены! Или !!) и используйте их для тренировки и тестирования своего движка.

Я полагаю, это зависит от ваших целей, которые я считаю строго дидактическими. Если бы вы пытались написать конкурентоспособный продукт, вы бы хотели получить максимальную эффективность в оценщиках самого низкого уровня. Здесь много возможностей для параллелизма на битовом уровне. Также много возможностей для хеш-таблиц. Также возможности использовать параллелизм. Тогда на более высоких уровнях вы, вероятно, захотите систему, подходящую для ИИ, что, вероятно, означает язык функционального программирования. Очевидно, что вы не хотите делать все эти вещи, выберите один или два из них и будете довольны тем фактом, что ваш проект не будет конкурировать с лучшими программами.

Я выбрал ООП-парадигму в своем шахматном движке под названием Турок . Первая версия моего шахматного движка была написана скорее процедурно, нежели ООП. Тогда мне было очень сложно улучшить свой шахматный движок из-за длинных блоков кода и плохого дизайна.

Это зависит от того, чего вы хотите достичь при написании шахматного движка. Если вы хотите создать шахматный движок, который слишком силен, так что даже невозможно сделать это на языках ООП из-за медленных поздних привязок. Если вы просто хотите изучать программирование, а также получать удовольствие от написания шахматного движка, так что управляемые языки и ООП станут вашим другом. Я могу предложить вам выбрать C #, потому что с ним также можно написать шахматный движок более процедурным способом.

Я перенес простую шахматную программу как средство изучения языка Forth. Это оказалось очень подходящим для этой очень насущной проблемы, и я многому научился. Открытый стек позволил мне реализовать альфа-бета-поиск уникальным способом, который дал мне лучшее понимание алгоритма.

Можно было бы подумать, что функциональное программирование было бы хорошо для шахматных программ, поскольку основные алгоритмы (поиск, оценка глубины в альфа-бета-версии) рекурсивны и функционально строги. Тем не менее, шахматная программа живет и умирает от эффективности, и ни одна из нынешних культур функциональных языков не преследует этой цели. Лучшие 100 современных движков используют императивные языки (в основном C / C ++, а затем Delphi), чтобы иметь максимальный контроль над использованием памяти, многопоточностью, глобальным состоянием и генерацией кода. Все функциональные языки используют динамическое распределение памяти для основных структур данных, что является смертью для шахматной программы.

Я все еще хотел бы, чтобы кто-то попытался пробиться в топ-100 шахматных движков, используя функциональный язык.