Кратко -- нужно реализовать (обобщенную) игровую систему для пошаговой коллекционной карточной игры типа www.astralmasters.com.
Играют двое. У каждого есть колода карт, карты в руке и карты на столе. Так же у игрока есть текущее состояние, куда входят параметры типа хит-поинтов и ресурсов, требуемых для помещения карты на стол (мана). Свое состояние имеет и карта (видимо, только лежащая на столе).
Карта может иметь свое правило поведения на произвольное изменение игровой ситуации и может нуждаться в доступе к любой детали информации о состоянии игры. Например, правила могут быть такими: нанести противнику повреждение, когда он берет карту из колоды; изменить свою силу атаки, если у владельца на столе есть больше трех карт заданного типа и т.п. -- см. любую CCG-систему.
Помимо всего прочего, мне не хочется дублировать информацию, содержащуюся в правилах поведения карты для реализации вывода этой информации на экран пользователю -- нужно уметь генерировать ее непосредственно из набора правил.
Какой-то доступ к правилам понадобится и искусственному интеллекту -- как минимум для составления колоды и планирования ходов.
Требуется языковое средство для описания такого набора правил. Нужно учитывать, что остальная часть реализации (например UI) будет написана на C++ -- следовательно, понадобится возможность взаимодействия между C++ и выбранным языком. Возможно, какой-нибудь из существующих языков хорошо подходит для решения подобных задач? Или лучше написать свой domain specific language?
Спасибо,
Tuo_Bellas.
P.S. Наверное, при коммерческой разработке, целесообразнее было бы заставить дизайнеров разработать и отполировать систему на бумажных картах, а потом "быстро и качественно" закодить влоб на С++ все, что у них получилось. Но тут я сам себе и дизайнер и "заказчик" -- мне интересно построить систему, подобную описанной выше. Заодно или освою новый язык, или отточу скилы по дизайну и написанию DSL
Здравствуйте, AndrewVK, Вы писали:
AVK>>>http://www.dcs.ed.ac.uk/home/stg/Psharp/ ?
T_B>>То есть, Пролог, и писать ядро не на C++, а на C#?
AVK>Можно и на C#, но и с интеграцией с анменеджед миром у дотнета все в порядке. Хотя конечно GUI писать на шарпе заметно удобнее.
Ну, GUI-то будет 'with fancy 3D-graphics' -- хотя Managed DirectX тоже вариант...
Про Пролог -- я не совсем в теме... Если не трудно, чем он хорош для решения моей задачи?
Здравствуйте, AndrewVK, Вы писали:
T_B>>Про Пролог -- я не совсем в теме... Если не трудно, чем он хорош для решения моей задачи?
AVK>Ну язык вобщем то специально создавался под решение задач экспертных систем и систем ИИ.
Хм. А можно кратенький пример, как конкретно его можно использовать в моей системе? Или ссылку/цитату... Я с логическими языками дела не имел, поэтому мне пока сложно представить в каком направлении двигаться.
Здравствуйте, Tuo_Bellas, Вы писали:
T_B>Хм. А можно кратенький пример, как конкретно его можно использовать в моей системе? Или ссылку/цитату... Я с логическими языками дела не имел, поэтому мне пока сложно представить в каком направлении двигаться.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Tuo_Bellas, Вы писали:
T_B>>Хм. А можно кратенький пример, как конкретно его можно использовать в моей системе? Или ссылку/цитату... Я с логическими языками дела не имел, поэтому мне пока сложно представить в каком направлении двигаться.
AVK>http://en.wikipedia.org/wiki/Prolog
Просмотрел, книгу Братко тоже пролистал -- пока не торкнуло То есть, общая суть примерно понятна, но конкретный способ применения пока весьма туманнен...
Tuo_Bellas,
> Кратко -- нужно реализовать (обобщенную) игровую систему для пошаговой коллекционной карточной игры типа www.astralmasters.com. <...> > > Помимо всего прочего, мне не хочется дублировать информацию, содержащуюся в правилах поведения карты для реализации вывода этой информации на экран пользователю -- нужно уметь генерировать ее непосредственно из набора правил. > > Какой-то доступ к правилам понадобится и искусственному интеллекту -- как минимум для составления колоды и планирования ходов.
Когда я участвовал в разработке движка правил (модуль был назван Logic) и ИИ для некоторой настольной игры, то мы организовали взаимодействие между модулями Logic, AI и GUI как раз для того, чтоб избежать дублирования реализации правил во всех трех местах. Правила были даны дизайнером игры в готовом виде, но были изрядно сложными для реализации, и не хотелось утраивать усилия. Взаимодействие было основано в виде передачи в объект класса Game модуля Logic действий игроков (Action), а объект класса Game в ответ порождал результирующие события (Event), которые происходили в игре.
Таким образом и AI и GUI могли "прокручивать" игру вперед и назад каждый для своих целей: AI для "беготни" по дереву состояний игры с последующим выбором "лучшего", GUI — для отображения текущего состояния и анимации в ответ на изменения состояни. Также была возможность реализовать анимацию предполагаемых эффектов в ответ на действие, которое начинает делать игрок (т.е., скажем, он еще не "активировал" карточку, но в ответ на проведение над ней мышкой по доске побежала анимация, которая соответствует "активации" карточки).
> Требуется языковое средство для описания такого набора правил. Нужно учитывать, что остальная часть реализации (например UI) будет написана на C++ -- следовательно, понадобится возможность взаимодействия между C++ и выбранным языком.
Я слышал об использовании для скриптования игр Lua. Также в Бусте есть взаимодействие с Python. На моем прошлом месте работы для игровых скриптов мы использовали самописный C++-подобный язык. Были планы выложить его Open Source, но все никак руки не доходят.
> Возможно, какой-нибудь из существующих языков хорошо подходит для решения подобных задач? Или лучше написать свой domain specific language?
В упомянутом выше проекте никакие скриптовые языки не использовались. Оказалось достаточным аккуратно выделить действия и события. Легкость сопровождения при таком подходе подтвердилась в процессе реализации движка правил и модификации его для расширенных вариантов еще одной игры, с достаточно сильно отличающимися правилами.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Кратко -- нужно реализовать (обобщенную) игровую систему для пошаговой коллекционной карточной игры типа www.astralmasters.com. <...>
>> Помимо всего прочего, мне не хочется дублировать информацию, содержащуюся в правилах поведения карты для реализации вывода этой информации на экран пользователю -- нужно уметь генерировать ее непосредственно из набора правил.
>> Какой-то доступ к правилам понадобится и искусственному интеллекту -- как минимум для составления колоды и планирования ходов.
ПК>Когда я участвовал в разработке движка правил (модуль был назван Logic) и ИИ для некоторой настольной игры, то мы организовали взаимодействие между модулями Logic, AI и GUI как раз для того, чтоб избежать дублирования реализации правил во всех трех местах. Правила были даны дизайнером игры в готовом виде, но были изрядно сложными для реализации, и не хотелось утраивать усилия. Взаимодействие было основано в виде передачи в объект класса Game модуля Logic действий игроков (Action), а объект класса Game в ответ порождал результирующие события (Event), которые происходили в игре.
Дело в том, что, как я писал, правила еще не созданы. И создавать правила на бумаге, а потом тупо но time-effective кодить их на C++ -- мне не интересно -- проект некоммерческий.
<...>
>> Требуется языковое средство для описания такого набора правил. Нужно учитывать, что остальная часть реализации (например UI) будет написана на C++ -- следовательно, понадобится возможность взаимодействия между C++ и выбранным языком.
ПК>Я слышал об использовании для скриптования игр Lua. Также в Бусте есть взаимодействие с Python.
А так же есть luabind -- библиотека, очень похожая на Boost.Python, и предназначенная для биндинга скриптов на lua.
ПК>На моем прошлом месте работы для игровых скриптов мы использовали самописный C++-подобный язык. Были планы выложить его Open Source, но все никак руки не доходят.
Делать самописный скриптовый язык общего назначения, а тем более -- C++-подобный -- очень спорное решение. Готовых отлаженных языков пруд пруди, да и больше Lua/Python'а обычно не требуется, тем более, что большинство дизайнеров работало или с тем или с другим. Брать на себя дизайн, реализацию и отладку языка -- это очень большая и труднопрогнозируемая работа. Другое дело, если требуется специализированный для конкретной задачи язык как в моем случае -- тогда готового может не оказаться (впрочем, в моем случае, видимо, оказался -- Prolog).
>> Возможно, какой-нибудь из существующих языков хорошо подходит для решения подобных задач? Или лучше написать свой domain specific language?
ПК>В упомянутом выше проекте никакие скриптовые языки не использовались. Оказалось достаточным аккуратно выделить действия и события. Легкость сопровождения при таком подходе подтвердилась в процессе реализации движка правил и модификации его для расширенных вариантов еще одной игры, с достаточно сильно отличающимися правилами.
Не мог бы ты примерно описать архитектуру такого взамодействия на верхнем уровне?
Здравствуйте, Tuo_Bellas, Вы писали:
T_B>Просмотрел, книгу Братко тоже пролистал -- пока не торкнуло То есть, общая суть примерно понятна, но конкретный способ применения пока весьма туманнен...
Для этого сначала нужно определиться с тем, что, откуда и на основании каких правил будет выводиться. Дальше уже можно записывать на Прологе или на том, на чём удобнее. Вероятно, в твоём случае предикаты будут иметь общий вид типа такого:
action(Conditions, What_to_do) :- ...
А подключить Пролог обычно не сложно.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Tuo_Bellas,
> ПК>Когда я участвовал в разработке движка правил (модуль был назван Logic) и ИИ для некоторой настольной игры, то мы организовали взаимодействие между модулями Logic, AI и GUI как раз для того, чтоб избежать дублирования реализации правил во всех трех местах. Правила были даны дизайнером игры в готовом виде, но были изрядно сложными для реализации, и не хотелось утраивать усилия. Взаимодействие было основано в виде передачи в объект класса Game модуля Logic действий игроков (Action), а объект класса Game в ответ порождал результирующие события (Event), которые происходили в игре.
> Дело в том, что, как я писал, правила еще не созданы. И создавать правила на бумаге, а потом тупо но time-effective кодить их на C++ -- мне не интересно -- проект некоммерческий.
Я понимаю, но, боюсь, в итоге, в том или ином виде, все равно придется выделять набор возможных действий игроков и возможных игровых событий. Т.к. иначе я пока не могу представить, как даже скриптовый язык будет общаться с приложением. В самом деле, не будет же он знать о всех деталях внутреннего устройства приложения? Иначе, вообще, всю игру можно на этом скриптовом языке писать, что вряд ли получится более эффективным (с точки зрения времени разработки), чем использование какого-нибудь полноценного языка, т.к. сложность проекта достаточно быстро превысит пределы, в которых скриптовые языки перестают быть эффективными. Все имхо.
> ПК>На моем прошлом месте работы для игровых скриптов мы использовали самописный C++-подобный язык. Были планы выложить его Open Source, но все никак руки не доходят. > > Делать самописный скриптовый язык общего назначения, а тем более -- C++-подобный -- очень спорное решение.
Я это и не предлагаю. Просто делюсь тем, как было сделано у нас. Язык родился из-за других нужд, которые на тот момент не покрывались другими языками. В общем, это отдельная история.
> Другое дело, если требуется специализированный для конкретной задачи язык как в моем случае -- тогда готового может не оказаться (впрочем, в моем случае, видимо, оказался -- Prolog).
Я далеко не так уж уверен в пользе Пролога в твоем случае. Мы рассматривали Prolog-подобный язык в качестве альтернативы. Обычные скрипты на обычном императивном языке оказались (для нас) более легкими в написании и сопровождении. В играх часто присутствуют многие аспекты поведения, представленные процессами, а не выраженные фактами (пусть даже о переходах в процессе). Имхо, такие вещи проще описать непосредственно в виде скрипта процесса, нежели в виде правил переходов, которые отлаживать будет очень нетривиально.
> ПК>В упомянутом выше проекте никакие скриптовые языки не использовались. Оказалось достаточным аккуратно выделить действия и события. Легкость сопровождения при таком подходе подтвердилась в процессе реализации движка правил и модификации его для расширенных вариантов еще одной игры, с достаточно сильно отличающимися правилами.
> Не мог бы ты примерно описать архитектуру такого взамодействия на верхнем уровне?
Ну, грубо где-то так...
Взаимодействие:
Взаимодействие различных приложений (сервер, клиенты и т.п.) и модулей игры осуществляется с помощью действий ("подключиться к серверу", "создать новую игру", "подключиться к существующей игре" и т.п.), представляющих собой запросы от активных сущностей (пользователь, модули игры и т.п.) на изменение состояния игрового мира, и событий ("игрок подключился к серверу", "создана новая игра" и т.п.), представляющих собой действительное изменение состояния игрового мира.
События делятся на категории, так чтоб различные модули и их компоненты могли обрабатывать только интересную им категорию, игнорируя остальные. При желании категории объединяются в иерархию, позволяя еще более гранулярную подписку на события.
Управление состоянием приложений посредством подобных сообщений (действия + события) позволяет достаточно легко "разрулить" многочисленные нюансы, связанные с организацией работы приложения в потактовом режиме (таймированные итерации главного цикла для обеспечения равномерной отрисовки), позволяет при необходимости сравнительно легко организовать как клиент-серверное, так и клиент-клиентское взаимодействие, относительно легко тестировать как отдельные модули, так и взаимодействие между ними, легко поддерживать запись последовательностей различных событий (история чатов, сохраненные игры и т.п.), относительно легко организовывать undo, управление отдельными аспектами работы клинтского приложения с сервера; на этом же принципе можно организовать воспроизведение игр в обучающем режиме и т.д., и т.п.
Модуль Engine — отвечает за логику работы на уровне приложения: занимается диспетчеризацией сообщений, переводит приложение из состояния в состояние и т.п. Думаю, достаточным будет упомянуть, что модуль помимо прочего принимает от клиентов — "активных сущностей" (AI, GUI и т.п.) их действия-запросы, и передает их туда, где находится сервер (Server) игры (в зависимости от характера игры: клиент-клиент — на машине, которая создала игру (Host), клиент-сервер — на центральном сервере, локальная игра — на локальной машине), а сервер в ответ рассылает клиентам сообщения, описывающие смену состояний игрового мира. На сервере, помимо прочего, для каждой игры содержится экземпляр Logic::Game (см. ниже), с помощью которого поддерживается состояние игры, верифицируется правильность получаемых ходов от клиентов, формируются игровые события и т.п.
Модуль Logic — отвечает за логику игры (правила и т.п.). Сам по себе активных сущностей модуль не содержит, только предоставляя услуги по сопровождению состояния игры другим модулям, содержащим активные сущности:
Есть набор всех возможных действий игроков ("поставить фигуру на доску", "убрать фигуру с доски", "взять карточку из колоды", "активировать такую-то карточку" и т.п.).
Есть набор возможных игровых событий (одна или несколько категорий общего набора событий, управляющих игрой), полностью и однозначно описывающих изменения игрового состояния ("начало игры", "фигура поставлена на доску", "фигура снята с доски", "начислить столько-то очков такому-то игроку", "передать ход такому-то игроку", "засчитать поражение такому-то игроку", "конец игры" и т.п.).
В каждый момент времени для каждого игрока доступен некоторый набор действий. Если игра предполагает строгую очередность хода, то игрок с непустым набором действий всегда один.
В ответ на действия игроков игра переходит в новое состояние, плюс порождаются события, соответствующие разнице между состояниями.
В модуле Logic есть целый ряд классов, представляющих состояние различных аспектов игры (Player, Board etc.). Управляет всем этим хозяйством (полу-)фасад Game, который и используется другими модулями. В экземплярах Game, хранимых у клиентов, эти события используются только для целей клиентов (анимация GUI, анализ игрового состояния AI и т.п.), на сервер эти события от клиентов не отсылаются, только их собственные действия — "ходы" и т.п.
Модуль AI:
Каждый из ботов является "активной сущностью" — клиентом в терминах модуля Engine.
Каждый из ботов создает у себя объект Game, если хочет воспользоваться услугами модуля Logic для поддержания состояния игры и т.п.
Боты передают приходящие игровые события в свой экземпляр Game, дабы та находилась в синхронном с другими модулями и приложениями состоянии.
Когда у игроков, за поведение которых отвечает AI, повявляются доступные игровые действия, бот начинает пытаться применять эти действия к своей копии Game, анализируя последствия и т.п., в итоге выбирает "лучшее" действие, приводящее к максимуму оценочной функции (в общем, обычный выбор лучшего хода путем беготни по дереву состояний). Выбрав ход, бот возвращает игру в начальное состояние (до своих экспериментов), а выбранный "ход" через свой экземпляр Engine::Client передает серверу для обработки. События, произошедшие в итоге его хода, он получит от сервера вместе с событиями, последовавшими в ответ на ходы других игроков, и точно таким же образом переведет игру в состояние, соответствующее игре, хранимой на сервере.
Модуль GUI:
В общем, взаимодействие аналогично модулю AI: принимает события, применяет их к своему экземпляру игры, свои действия отсылает на сервер и т.п.
Разве что GUI вряд ли будет столь же интенсивно модифицировать свой экземпляр игры "вперед", как это делает AI. Возможно, будет пытаться анализировать доступные действия игрока, за которого играет пользователь, чтобы подсветить для пользователя допустимые варианты его ходов, будет анализировать события, порождаемые локальной копией игры, чтобы проиграть анимацию эффектов потенциального хода и т.п.
Зато GUI с большей вероятностью может "прокручивать" игру назад, до текущего состояния, скажем, если игрок хочет проанализировать предыдущий ход игры.
Завязка на действия и события позволяет, фактически, автоматом получить режим воспроизведения записанных игр, подключение к чужим играм для их просмотра и т.п.
В общем, полагаю, схема предполагаемого взаимодействия должна быть более-менее понятна... Можно, разве что, подчеркнуть, что аналогичный обмен действиями и сообщениями предполагается и в случаях другого, неигрового взаимодействия: чат, модификация профилей игроков на сервере и т.п. Скажем, может быть бот, который не играет, но болтает, подключаясь к чужим играм. Это все вполне гладко ложится на схему получения сообщений об изменениях состояния и отправке своих действий, которые потенциально (если сервер разрешит) изменят состояние.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
ПК>Я понимаю, но, боюсь, в итоге, в том или ином виде, все равно придется выделять набор возможных действий игроков и возможных игровых событий. Т.к. иначе я пока не могу представить, как даже скриптовый язык будет общаться с приложением. В самом деле, не будет же он знать о всех деталях внутреннего устройства приложения? Иначе, вообще, всю игру можно на этом скриптовом языке писать, что вряд ли получится более эффективным (с точки зрения времени разработки), чем использование какого-нибудь полноценного языка, т.к. сложность проекта достаточно быстро превысит пределы, в которых скриптовые языки перестают быть эффективными. Все имхо.
Проект такого уровня (карточная игра) вполне может быть реализован полностью на скриптовом языке + библиотека граф. вывода на С++. Особенно если в качестве скрипта использовать какой ни будь полноценный язык например питон или руби.
>> Другое дело, если требуется специализированный для конкретной задачи язык как в моем случае -- тогда готового может не оказаться (впрочем, в моем случае, видимо, оказался -- Prolog).
ПК>Я далеко не так уж уверен в пользе Пролога в твоем случае. Мы рассматривали Prolog-подобный язык в качестве альтернативы. Обычные скрипты на обычном императивном языке оказались (для нас) более легкими в написании и сопровождении. В играх часто присутствуют многие аспекты поведения, представленные процессами, а не выраженные фактами (пусть даже о переходах в процессе). Имхо, такие вещи проще описать непосредственно в виде скрипта процесса, нежели в виде правил переходов, которые отлаживать будет очень нетривиально.
Я тоже думаю что пролог не лучший выбор.
Но для того же питона есть очень интересная штука http://christophe.delord.free.fr/en/pylog/index.html позволяющая прозрачно встраивать в программу на питоне код на прологе(примерно как встроенный ассемблер на си ) и транслировать пролог код в питоновский.
FR,
> Проект такого уровня (карточная игра) вполне может быть реализован полностью на скриптовом языке + библиотека граф. вывода на С++. Особенно если в качестве скрипта использовать какой ни будь полноценный язык например питон или руби.
Я далеко не так уж уверен в эффективности данного подхода (с точки зрения времени разработки), если делать более-менее сложный интерфейс и, тем более, AI.
> Я тоже думаю что пролог не лучший выбор. > Но для того же питона есть очень интересная штука http://christophe.delord.free.fr/en/pylog/index.html позволяющая прозрачно встраивать в программу на питоне код на прологе(примерно как встроенный ассемблер на си ) и транслировать пролог код в питоновский.
У нас тоже Пролог рассматривался не в чистом виде, а в виде подобного же встраиваемого в скриптовый язык диалекта. Тем не менее, (для нас) удобнее оказалось описывать происходящее в играх в терминах процессов, а не правил. Впрочем, настаивать не собираюсь: мы не слишком настойчиво к этому подходили.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, FR, Вы писали:
FR>Проект такого уровня (карточная игра) вполне может быть реализован полностью на скриптовом языке + библиотека граф. вывода на С++. Особенно если в качестве скрипта использовать какой ни будь полноценный язык например питон или руби.
Вот как раз для такого проекта "обычные" скриптовые языки (Питон, Луа, ДжаваСкрипт) вряд ли дадут выигрыш. Эта задача предполагает активные операции с нетривиальными структурами данных (Game etc.). А это является специализацией MLоидов (считая с Erlang и Haskell). Возможно, еще и Lisp — сам не знаю, врать не буду.
Здравствуйте, mihoshi, Вы писали:
M>Здравствуйте, FR, Вы писали:
FR>>Проект такого уровня (карточная игра) вполне может быть реализован полностью на скриптовом языке + библиотека граф. вывода на С++. Особенно если в качестве скрипта использовать какой ни будь полноценный язык например питон или руби.
M>Вот как раз для такого проекта "обычные" скриптовые языки (Питон, Луа, ДжаваСкрипт) вряд ли дадут выигрыш. Эта задача предполагает активные операции с нетривиальными структурами данных (Game etc.). А это является специализацией MLоидов (считая с Erlang и Haskell). Возможно, еще и Lisp — сам не знаю, врать не буду.
Во первых я не вижу в задаче таких уж свержсложных структур.
Во вторых питон в работе со списочноподобными структурами мало уступает функциональным и логическим языкам.
То есть, общая суть примерно понятна, но конкретный способ применения пока весьма туманнен... 
