Существуют ли какие-либо повествовательные (или, по крайней мере, не пространственно-временные) целенаправленные движки / структуры? [закрыто]

РЕДАКТИРОВАТЬ (2): Поскольку есть два ответа, и я не принял ни одного из них, я решил, что мотивирую то, что я считаю здесь ответом: либо что-то, настоятельно рекомендующее любой такой подход, было бы невозможно / вовсе не полезно, либо альтернативно, ссылка на исследование (область) или примеры, по меньшей мере, несколько общей такой системы, помимо текстовых приключенческих игр / интерактивной фантастики.

Хотя я не буду притворяться, что провел более глубокое исследование, я заметил, что все игровые движки / фреймворки, на которые я смотрел, казались чем-то вроде прославленного графического движка в том смысле, что они говорят о формах / сущностях в двух направлениях. или трехмерное евклидово пространство с, возможно, некоторой формой модели параллелизма, «заправленной», позволяющей определить некоторую форму логики, прикрепленной к этим «сущностям».

Игровые «правила» и повествование затем пишутся в некотором роде (в отношении движка) поверх этих примитивов.

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

Мне, однако, интересно, какие попытки были предприняты для создания движков / фреймворков, которые принимают такие понятия, как (высокий уровень) описание правил игры / логики или повествования (или, по крайней мере, непространственного аспекта игры) в качестве основного основа?

РЕДАКТИРОВАТЬ (4): Это не означает, что игра не будет включать в себя какие-либо пространственные / графические аспекты, просто вместо того, чтобы иметь пространственные объекты, с которыми вы связываете логику, у вас есть представление о сюжете (или игровом процессе, или «правилах настольной игры»). ), который вы затем описываете графический интерфейс / реализацию.

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

То, что я видел, - это некоторые исследования по моделированию / анализу повествования с использованием модели на основе сети Петри и некоторые интересные подходы в языках для написания интерактивной художественной литературы .

РЕДАКТИРОВАТЬ (1): Я решил добавить игрушечный пример для иллюстрации.

Скажем, мы были заинтересованы в создании приключений в стиле point & click (вспомним игры SCUMM). Можно проанализировать их как основанные на понятии более или менее линейного и дискретного перехода от начальной ситуации к концу.

Сосредоточив внимание на понятии дискретной прогрессии и учитывая некоторую нелинейность, можно выбрать теорию (ограниченных) DAG как основную теорию. Таким образом, определение игры такого типа в ее (относительно этой теории) наиболее абстрактной форме соответствует добавлению дополнительных аксиом к этой теории (либо для того, чтобы теория задала конкретный граф, либо достаточно просто для того, чтобы захватить все, что, по вашему мнению, требуется для захвата игр). "сюжет").

Превращение этого в реальную игру теперь превращается в проблему проектирования интерфейса HCI / интерфейса, заключающуюся в том, чтобы внедрить эту теорию в нечто играбельное (то есть построить модель теории / найти гомо (изо?) Морфизм графов из набора состояний пользовательского интерфейса с переходами в DAG "указав игру").

В приведенном выше гипотетическом сценарии я вижу, по крайней мере, три вещи, которые должны быть доступны в библиотеках. Во-первых, нужны инструменты для преобразования / рассуждения о DAG или графах в целом. Во-вторых, библиотека пользовательского интерфейса, достаточно умная, чтобы помочь в проверке того, что наше представление нашего графа как играбельной игры фактически моделирует граф (таким образом, например, по крайней мере, частично / неформально, доказательство того, что игра не имеет застрявших состояний из-за условия ограниченности) , Наконец, коллекция библиотек более высокого уровня для определения графа может быть предоставлена; такие как библиотека для выражения символов и их взаимодействия и создания (части) графов в терминах таковых.

Зачем сохранять «среднюю» теорию DAG, а не просто низкоуровневую реализацию с некоторыми справочными библиотеками? Ответ - все обычные причины формальной семантики. Учитывая, что мы определились с формальной основой, мы можем проверить некоторые свойства игры, что позволяет рассуждать о таких вещах, как оптимизация в низкоуровневой интерфейсной библиотеке (пока она моделирует DAG, мы можем делать то, что хотим), без необходимости беспокоиться о несопоставимости с описанием высокого уровня (персонажей / диалогов и т. д.), так как эти описания сами должны описывать такие структуры.

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

Короче говоря, я думаю, что альтернативный заголовок к этому вопросу мог бы звучать так: как Дейкстра написал бы компьютерные игры?

Небольшое примечание о повествовании и правилах игры: в интерактивной художественной литературе можно утверждать, что игра - это пересечение графа ветвящегося повествования, но в конечном итоге повествование живет вне игровой механики - вы можете заменить все слова чем-то нечитаемым и все же шаги, чтобы закончить игру (или проиграть, играя в нее) были бы точно такими же. Это, в свою очередь, подразумевает, что повествование не имеет отношения к игровому процессу, за исключением случаев, когда разработчик выбирает один для соответствия другому. В играх повествование по сути является фасадом над механикой, которая может сделать механику более убедительной для игрока, который наслаждается этим повествованием, но это все. Есть некоторые игры (хотя некоторые не называют их играми), где повествование является основной формой развлечения, а игровая механика в основном небрежна,Уважаемая Эстер , но разработчикам не нужен формальный метод для рассказа историй так же, как писателям-фантастам, поэтому я не буду вдаваться в подробности повествования. Вообще говоря, любая игра, которая выглядит как «играбельное повествование», является деревом или графиком игровых событий, которые могут существовать и обсуждаться осмысленно без повествования вообще.

Я заметил, что все игровые движки / фреймворки, на которые я смотрел, казались чем-то вроде прославленного графического движка в том смысле, что они говорят о формах / сущностях в двух или трёхмерном евклидовом пространстве [...]

Да, большинство «игровых движков», очевидно, являются «движками для видеоигр», и их главная ответственность с течением времени заключалась в том, чтобы способствовать разработке программного обеспечения в видеоигре, а не в игре. Возможно, это имеет смысл, потому что именно разработка программного обеспечения является самым новым и самым дорогим и, следовательно, наиболее рискованным аспектом. Для сравнения, игровой дизайн в абстрактном смысле был сделан вручную в течение тысяч лет без помощи инструментов, которые могут до некоторой степени объяснить, почему это продолжает иметь место.

какие попытки были предприняты для создания движков / фреймворков, которые бы использовали такие понятия, как (высокоуровневое) описание правил игры / логики или повествования (или, по крайней мере, непространственного аспекта игры) в качестве своей основной основы?

Насколько я знаю, было несколько серьезных попыток, ни одной успешной.

Сторитрон один. «В отличие от традиционной интерактивной фантастики, Storyworld больше заботится о моделировании действий и реакций актеров, их эмоций и склонностей, а не о географии игрового мира или обыденных объектах, которые его населяют». Это следует из предыдущей работы под названием Erasmatron, которая на самом деле не увенчалась успехом, и Storytron тоже не выглядит успешной. Следующая статья хорошо читается об этом: В погоне за драконом

На менее амбициозном уровне есть много людей, которые придумали простые способы представления простых игр. Одна из многих статей такова: Multigame - язык очень высокого уровня для описания настольных игр (ссылка за логином, но вы можете его найти), но все, что у вас есть в конце, - это читаемый компьютером набор возможных состояния, переходы состояний и условия победы или функции подсчета очков - отлично подходит для отдельных настольных игр, таких как шахматы, или карточных игр, таких как покер, но они не распространяются на игры с большим количеством непрерывных состояний или игры с семантикой, которая более например, симуляторы (например, стрелялки) или спортивные состязания (например, гоночные игры). Такие игры не могут быть адекватно представлены простым деревом игровых состояний.

Один из способов приблизиться к пониманию этих более сложных систем - попытаться классифицировать каждую существующую механику в одну из нескольких базовых форм, а затем выяснить, как можно комбинировать базовые формы для формирования более сложного игрового процесса, при условии, что весь игровой процесс может состоять из этих основных единиц или их комбинаций. У Дана Кука есть статья под названием " Что такое игровая механика ?" и продолжение " Химия игрового дизайна"«которые пытаются задокументировать этот композиционный подход к игровому дизайну. Теоретически, возможно, можно построить декларативную систему поверх этого, но на практике механика составляет лишь небольшую часть игры, и, следовательно, конечный результат будет предположительно ограничен». в рамках презентации, которая не будет достаточно гибкой, чтобы привлечь внимание большинства игроков.

Другие попытки формализовать концепции игрового дизайна часто называют «игровой грамматикой» - одна такая статья называется « Атомы многопользовательской игры », но она ссылается на различные предыдущие работы.

Скажем, мы были заинтересованы в создании приключений в стиле point & click (вспомним игры SCUMM). [...] можно выбрать теорию (ограниченных) ГПДР как основную теорию. [...] Во-первых, нужны инструменты для преобразования / рассуждения о DAG или графах в целом. Во-вторых, библиотека пользовательского интерфейса, достаточно умная, чтобы помочь в проверке того, что наше представление нашего графа как играбельной игры фактически моделирует граф (таким образом, например, по крайней мере, частично / неформально, доказательство того, что игра не имеет застрявших состояний из-за условия ограниченности) , Наконец, коллекция библиотек более высокого уровня для определения графа может быть предоставлена; такие как библиотека для выражения символов и их взаимодействия и создания (части) графов в терминах таковых.

Проблема здесь в том, что компьютер не добавляет много к процессу. Разработчики таких игр часто составляют именно этот график в цифровом или физическом виде, который показывает ход игры. Понятно, может ли игра быть теоретически завершена или нет. Даже кодирование различных правил прохождения приключений типа «укажи и щелкни» тривиально. Самое сложное - заставить его следовать интересному повествованию, установить его в привлекательном мире, создать художественные и звуковые ресурсы для правильного изображения игры и интерфейса, а также различные задачи по разработке программного обеспечения, которые объединяют все это. Направленный граф значимых состояний в игре обычно относительно тривиален; проблема во всем этом. И вот почему нет особого интереса к этому,

Я лично в настоящее время работаю с командой над продуктом под названием Storybricksкоторый пытается создать интересный игровой процесс путем указания различных правил, и эти правила могут указывать начальное состояние человека, его потребности и так далее. Легко взять эти правила и проверить, можно ли удовлетворить потребности человека, и если да, то каким образом, и, следовательно, декларативно создавать задачи, которые должны быть выполнены в игре. Однако это само по себе не создает интересного игрового процесса, потому что, как только вы абстрагируете вещи до уровня «Х нужен Y - извлеките их для них», игроки начинают распознавать паттерн и перестают им наслаждаться. (Например: люди быстро устали от автоматически сгенерированных квестов в Skyrim, потому что они могли видеть, что не было никакого внутреннего значения для процедурно сгенерированной миссии, по сравнению с созданными дизайнером. ) Поэтому наша работа будет заключаться в том, чтобы использовать методы ИИ, чтобы сделать эти ситуации более интересными, и над этим мы все еще работаем. (Storybricks все еще находится на очень ранней альфа-стадии). Но наше исследование показывает, что мало кто пытается что-то подобное, и что это очень сложная проблема.

Другая проблема с декларативным подходом состоит в том, что он не очень удобен в использовании. Ученым это нравится, потому что это легко обрабатывается, например, чтобы доказать, что ситуация разрешима или что набор логических правил согласован. Но в реальном мире ни программисты компьютерных игр, ни конечные пользователи, как правило, не чувствуют себя комфортно с декларативным представлением, которое фокусируется на результатах, как с императивным представлением, которое говорит им, как действовать, чтобы результаты были. В настоящее время все топ-10 языков программирования являются обязательными , и инструкции реального мира также обычно имеют императивную форму, будь то выпечка пирога или изготовление мебели, Отсутствие энтузиазма с обеих сторон означает, что нет коммерческих стимулов для выпуска формальных спецификаций для современных игр, и вряд ли это изменится в ближайшем будущем.

Я долго думал, как ответить, и не совсем уверен, как это выразить.

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

Кажется, что этот акцент делается на графике, потому что должен быть способ определить физическое существование объектов. Это как раз то, где вещи начинают становиться экзистенциальными, потому что мы на самом деле говорим о представлении измерения, но давайте пока просто проигнорируем это. Суть в том, что это то, что на самом деле довольно сложно. Разрешение для представления пространства будет чем-то, что по своей сути занимает много программирования игрового движка. И если дизайнеры хотят делать красивые сцены, им нужно много контролировать то, как все расположено. Итак, вы увидите много вещей о графике.

Итак, это сторона вещей низкого уровня. Кто-то должен глубоко задуматься над всеми этими маленькими техническими проблемами.

Насколько повествование и правила игры идут? Это выходит за рамки того, что должен делать игровой движок. Это та часть, в которую входит группа разработчиков.

Более того, не то, чтобы много мыслей не уделялось тому, как представлять идеи через программирование. Это действительно то , что история информатики является . И именно поэтому игровые движки часто имеют интерфейсы для языков высокого уровня. Проще представлять мысли через них.

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

И снова, есть много вариантов выбора языков как есть. И больше людей, чем просто те, кто в игровой индустрии, разрабатывали их. Обычно имеет смысл использовать один из них.

В заключение вы задали интересный, но очень сложный вопрос. И я не совсем уверен, что это такое, или я действительно ответил на это.

* edit: задним числом я понимаю, что я рассматривал только 3D Game Engine, как будто они были единственными, которые существуют. В некоторых играх человек вообще не действует в физическом пространстве. Хотя в таких случаях я не уверен, что игровой движок внесет большой вклад.

В начале истории компьютерных хобби (то есть 80-х годов) было несколько коммерческих наборов для разработки игр, доступных как для текстовых, так и для спрайтовых игр. Основанные на спрайтах были очень похожи на нынешние «графические движки».

Другой тип включает в себя такие вещи, как парсеры естественного языка. Этот тип, кажется, живет в современных «редакторах уровня». Большинство из них включают поддержку чего-то вроде скриптов Lua или Python. Я также хотел бы отметить, что я не вижу большой активности в редактировании на уровне открытого исходного кода, но это потому, что эти вещи, как правило, очень тесно связаны со спецификой рассматриваемой игры. Я думаю здесь о чем-то вроде конструкторских наборов Elder Scrolls.

Kinect может вернуть парсер обратно. Как фанат старой текстовой приключенческой игры, я очень рад тому, что здесь делает Bethesda. Это наверняка является частной собственностью, но, возможно, какой-то молодой гений ...