Вопрос о разработке шахматного движка на основе C ++

У меня есть движок вариантов шахмат, который играет в шахматы самоубийц и шахматы проигравших вместе с обычными шахматами. Со временем я могу добавить в свой движок больше вариантов. Движок полностью реализован на C ++ с правильным использованием ООП. Мой вопрос касается конструкции такого варианта двигателя.

Изначально проект начинался как движок только для самоубийц, но со временем я добавил другие варианты. Для добавления новых вариантов я сначала поэкспериментировал с полиморфизмом в C ++. Например, абстрактный класс MoveGenerator имел два подкласса SuicideMoveGenerator и NormalMoveGenerator , и в зависимости от типа игры, выбранной пользователем, фабрика создавала экземпляр правильного подкласса. Но я обнаружил, что это происходит намного медленнее - очевидно, потому что создание экземпляров классов, содержащих виртуальные функции, и вызов виртуальных функций в тесных циклах совершенно неэффективны.

Но потом мне пришло в голову использовать шаблоны C ++ со специализацией шаблонов для разделения логики для разных вариантов с максимальным повторным использованием кода. Это также казалось очень логичным, потому что динамическое связывание на самом деле не нужно в контексте, поскольку, выбрав тип игры, вы в основном придерживаетесь его до конца игры. Специализация шаблонов C ++ обеспечивает именно это - статический полиморфизм. Параметр шаблона - либо SUICIDE , либо LOSERS , либо NORMAL .

enum GameType { LOSERS, NORMAL, SUICIDE };

Таким образом, как только пользователь выбирает тип игры, создается соответствующий игровой объект, и все, что оттуда вызывается, будет соответствующим образом шаблонизировано. Например, если пользователь выбирает самоубийственные шахматы, допустим: создается экземпляр объекта

ComputerPlayer

, и этот экземпляр в основном связан со всем потоком управления статически. Функции в ComputerPlayer будут работать с MoveGenerator , Board и так далее, тогда как соответствующий НОРМАЛЬНЫЙ будет работать соответствующим образом.

В целом, это позволяет мне создать экземпляр нужного специализированного класса шаблонов в начале и без каких-либо других условий, если где угодно, все работает отлично. Лучше всего то, что нет никакого снижения производительности!

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

Интересно, что обычно делают другие авторы вариантных движков для разделения логики (при хорошем повторном использовании кода) ?? Я нашел программирование шаблонов C ++ вполне подходящим, но если есть что-нибудь получше, я был бы рад принять его. В частности, я проверил движок Fairymax от Dr. HG Muller, но он использует файлы конфигурации для определения правил игры. Я не хочу этого делать, потому что многие из моих вариантов имеют разные расширения и, делая их общими для уровня конфигурационных файлов, движок может не стать сильным. Другой популярный двигатель Sjeng завален if условиями повсюду, и я лично считаю, что это не очень хорошая конструкция.

Любые новые идеи дизайна были бы очень полезны.

5
задан Goutham 12 September 2010 в 03:48
поделиться