Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Интересно, что факты «location» и «weapon» не понадобились вообще для итогового решения, а оказались в именах переменных.
PS: сколько времени занял подсчет? Меньше секунды или больше?
PS: сколько времени занял подсчет? Меньше секунды или больше?
Таким образом, мы можем сказать, что woman есть и в кабинете, и в ванной, И это не Кристина, а также вычёркиваем остальные варианты для Барбары и Иоланды (кухня, столовая, гостиная, кладовая).
При этом в коде Иоланду вычеркнуть забыли!
Кстати ещё. В на сколько я помню, в институте, когда нам давали пролог, было требование: Условия должны быть записаны именно так, как они звучат в задаче. Тут это правило нарушено. например:
Пользуясь случаем хочу передать привет 609 кафедре МАИ (за давностью лет, забыл… кажется преподаватель Махорин Андрей Олегович) Тогда я не понимал, что от меня требуют… и пытался писать на прологе, как на родных Си. Теперь понял! :)
% % 6. Clue 5: The weapon in the living room was found with either John or George.
% % What weapon was in the living room?
man(Livingroom), \+Livingroom=robert,
Пользуясь случаем хочу передать привет 609 кафедре МАИ (за давностью лет, забыл… кажется преподаватель Махорин Андрей Олегович) Тогда я не понимал, что от меня требуют… и пытался писать на прологе, как на родных Си. Теперь понял! :)
Всегда было интересно, зачем же нужен prolog. Так вот зачем!
Ну да, Пролог это система вывода заключений из фактов и теорем, и прекрасно подходит к задачам, где задано множество фактов, и из них нужно извлечь какое-либо непрямое следствие. ИМХО на Прологе самое то писать SAT-решатели, практически один в один можно перенести условие в код.
Мне кажется сила и великолепие пролога недооценены во всяких РПГ для обсчета внутренней логики сложных квестов. Кроме того в таких играх часто есть дифференциация отношения NPC к игроку в зависимости от его «кармы», персонажа, выполненных квестов, сделанном выборе в той или иной ситуации и прочего. Даже очень крутые игры часто грешат, например, несоразмерностью выдаваемых квестов и уровня персонажа. Так игрок, который заполучил чуть ли не самый мощный артефакт и занимает не последнее место в гильдии покорно идёт освобождать подвал какого-нибудь купца от крыс…
Это лишь вершина айсберга. Думаю с помощью пролога можно было бы сделать квесты гораздо более логичными и гибкими.
Кто-нибудь слышал о применении пролога в геймдеве?
Это лишь вершина айсберга. Думаю с помощью пролога можно было бы сделать квесты гораздо более логичными и гибкими.
Кто-нибудь слышал о применении пролога в геймдеве?
Можно какой-нибудь пример? Я не понял, как особенности пролога помогут писать квесты.
Вот я могу императивно написать что-то типа:
quest.isAvailable = player.level in 10..20 && questsFinished(a, b, c)
quest.reward += Gold(100 + 50 * player.level + 10 * sigmoid(player.karma))
if questA.isFinished && questA.isPlayerChosenSmth
quest.reward += Weapon.random(sword, level=player.level)Что изменится при появлении пролога?
Мне кажется, что примитивность квестов — просто косяк тех, кто их придумывал. В том же ведьмаке практически все квесты можно по-разному пройти c разным результатом и с разным порядком прохождения самих квестов. Мне кажется, такой подход требует большего бюджета на разработку и отладку квестов, но ничего принципиально нового не содержит.
То, что вы написали в примере, легко реализуется и в декларативном и в императивном стиле. Более сложные же квесты способны првевратиться в императивный ад нечитаемого распределённого кода, пронизанного паразитной связностью и багами.
Здесь у вас расчитывается возможность взятия квеста и награда на довольно примитивном уровне.
Я же говорил о сложных многоступенчатых сюжетных квестах. Делая такие квесты уже не обойтись без концепции конечных автоматов, каких-то вариаций сетей Петри и прочего. Но с какого-то момента код квестов становится слишком большим, нежелательная связность слишком высокой, а контекст размазанным по куче мест, отчего ошибки так и норовят создать имбалансные ситуации и петли бесконечной прибыли.
Возможно без императивного описания каикх-то вещей и не обойтись, но декларативный слой, явно описывающий глобальные (в мире или на уровне персонажа) и локальные (на уровне квеста или связанной группы квестов) ограничения определённо сделает более управляемым, понятным и предсказуемым процесс построения и отладки действительно сложных сюжетных квестов.
Контекст правил (предикатов) для логического вывода можно собирать из нескольких частей:
У меня нет готовых рецептов и простых пирмеров для вас. Для простых случаев такая логика не нужна, а сложные в двух словах не изложить… хотя…
Я как-то писал сравнительно несложный квест для ММОРПГ в маленькой но дерзкой студии в коллективе таких же неопытных геймдев-разработчиков как я. Там система квестов задумывалась как относительно изолированная часть, котороую смогли бы наполнять менее квалифицированные и опытные программисты, нежели разработчики ядра. Квестовая система была построена на конечных автоматах и событийной модели.
Так вот, был там один парный квест, который становился доступным когда кто-то в другом городе брал комплиментарный ему квест. Что-то вроде «сопроводить караван» / «перехватить караван». Вариации комплиментарных пар были довольно широки, там можно было сопровождать конкретного NPC или группу, атаковать или защищать локацию и много дургих кейсов.
При этом часть NPC управлялись простыми «рефлексами», а часть логикой квеста.
Легко представить себе сколько исключительных и нештатных ситуаций может породить такая сложная мультиагентная система из двух параллельно работающих конечных автоматов и нескольких десятков юнитов со своими рефлексами и задачами. Но всё становится на порядок интереснее, когда с обеих сторон есть живые люди.
Как-то разумно и внятно учесть вклад и добросовестность выполнения такого квеста — это та ещё задачка. И эта задачка куда понятнее описывается декларативно и логически, чем императивно алгоритмически.
«Фишка» пролога в том, что на этом языке мы описываем не решение задачи, а лишь её условие. Если задача имеет решение, то оно будет логически выведено… рано или поздно.
Кроме того логическими предикатами можно сравнительно несложно описать правила по которым можно вычислить «знает» ли тот или иной NPC о том или ином событии. Например, игрок только что заранее выполнил условие квеста, который только собирается получить. NPC должен всё же дать ему этот квест, если у него не было возможности (даже теоретической) «узнать» о том, что условие выплнено. Грубо говоря нет смысла давать задание убить старосту, если в деревне уже поднялась паника по этому поводу.
Здесь у вас расчитывается возможность взятия квеста и награда на довольно примитивном уровне.
Я же говорил о сложных многоступенчатых сюжетных квестах. Делая такие квесты уже не обойтись без концепции конечных автоматов, каких-то вариаций сетей Петри и прочего. Но с какого-то момента код квестов становится слишком большим, нежелательная связность слишком высокой, а контекст размазанным по куче мест, отчего ошибки так и норовят создать имбалансные ситуации и петли бесконечной прибыли.
Возможно без императивного описания каикх-то вещей и не обойтись, но декларативный слой, явно описывающий глобальные (в мире или на уровне персонажа) и локальные (на уровне квеста или связанной группы квестов) ограничения определённо сделает более управляемым, понятным и предсказуемым процесс построения и отладки действительно сложных сюжетных квестов.
Контекст правил (предикатов) для логического вывода можно собирать из нескольких частей:
- Глобальный контекст мира. Здесь у нас предикаты, описывающие глобальные состояния мира:
- время года, время суток, фаза луны, эпоха...
- правящий дом, соотношение политических сил, влиятельность гильдий...
- глобальные базовые соотношения цен на ресурсы, какие-то коэффициенты...
- Контекст локации (возможно контекст региона можно вынести в еще один отдельный слой):
- Здесь могут быть перекрыты часть предикатов, описанных в глобальном контексте.
- Здесь добавляются предикаты, описывающие или маркирующие саму локацию (наличие рядом кузнеца или трговца, статус, военное положение, общая политическая ангажированность, доступность других локаций, степень этой доступности, характер и уровень опасностей в локации, характер и уровень опасностей на пути в другие локации...)
- Метаданные вроде названия локации во всех спряжениях, числах и падежах...
- и многое, многое дургое
- Контекст персонажа:
- Часть предиктов будет получено от класса персонажа
- Часть предикатов будут перекрывать вышестоящие контексты
- Отдельно может быть описано индивидуальное отношение к классу игрока, к самому игроку и тегам, которыми наделили его выполненные квесты.
- Внутри квеста:
- Предикаты видимости квеста
- Предикаты доступности квеста
- Предикаты для получения каких-то пояснений причин недоступности
- Предикаты, формирующие перечень возможных наград...
У меня нет готовых рецептов и простых пирмеров для вас. Для простых случаев такая логика не нужна, а сложные в двух словах не изложить… хотя…
Я как-то писал сравнительно несложный квест для ММОРПГ в маленькой но дерзкой студии в коллективе таких же неопытных геймдев-разработчиков как я. Там система квестов задумывалась как относительно изолированная часть, котороую смогли бы наполнять менее квалифицированные и опытные программисты, нежели разработчики ядра. Квестовая система была построена на конечных автоматах и событийной модели.
Так вот, был там один парный квест, который становился доступным когда кто-то в другом городе брал комплиментарный ему квест. Что-то вроде «сопроводить караван» / «перехватить караван». Вариации комплиментарных пар были довольно широки, там можно было сопровождать конкретного NPC или группу, атаковать или защищать локацию и много дургих кейсов.
При этом часть NPC управлялись простыми «рефлексами», а часть логикой квеста.
Легко представить себе сколько исключительных и нештатных ситуаций может породить такая сложная мультиагентная система из двух параллельно работающих конечных автоматов и нескольких десятков юнитов со своими рефлексами и задачами. Но всё становится на порядок интереснее, когда с обеих сторон есть живые люди.
Как-то разумно и внятно учесть вклад и добросовестность выполнения такого квеста — это та ещё задачка. И эта задачка куда понятнее описывается декларативно и логически, чем императивно алгоритмически.
«Фишка» пролога в том, что на этом языке мы описываем не решение задачи, а лишь её условие. Если задача имеет решение, то оно будет логически выведено… рано или поздно.
Кроме того логическими предикатами можно сравнительно несложно описать правила по которым можно вычислить «знает» ли тот или иной NPC о том или ином событии. Например, игрок только что заранее выполнил условие квеста, который только собирается получить. NPC должен всё же дать ему этот квест, если у него не было возможности (даже теоретической) «узнать» о том, что условие выплнено. Грубо говоря нет смысла давать задание убить старосту, если в деревне уже поднялась паника по этому поводу.
Версия пролога — огонь. Всегда нравился этот язык.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ищем убийцу на Прологе