Wol4ik написал:
Игра Проклятье Вервольфа - мои тезисы. Детализация там может быть сколь угодно большая на вкус автора и игроков. Почему. И из собственного прохождения и из стрима наших уважаемых обзорщиц видно, что нужно досканально все исследовать и догадаться что куда заряжать и что потом где зажегать.
По стриму ничего сказать не могу, так как пока не смотрел, но вообще в "Проклятье вервольфа" всё довольно просто. Подсказки произносит сам герой, да и вся информация даётся на первых двух информационных слоях (первый - описания локаций, второй - описания предметов, упомянутых в описаниях локаций). То есть опускаться дальше (описание предметов, упомянутых в описании предметов, упомянутых в описании локации и т.д.) совсем не нужно, там сделано замыкание на сам предмет. Это как раз к вашей идеи про многослойную детализацию мира. Я, в большинстве случаев, считаю неоправданным заставлять игрока осуществлять рекурсивный осмотр по более чем двум слоям. Это замечательный приём, но его нужно использовать изредка, чтобы не выхолащивать игровую механику. Например, там такое в качестве бонуса есть в отношении отдельных частей тела девушки, но вы почему-то больше заинтересовались гвоздями...
К тому же надо понимать, что вас возможно по молодости развлекает просто чтение многослойных описаний, а у кого-то из ветеранов парсера начнётся паранойя на предмет того, что там и надо искать путь к прохождению игры, если мы копаем, а оно всё копается и копается. Так и доведём старика до инсульта.
Всё-таки надо вовремя остановиться, чтобы человек понял, что окно тут для антуража, а то некоторые могут полтора часа провести перед окном, расшатывая, облизывая и обнюхивая каждую шляпку гвоздя, которые мы туда понавтыкали ради декоративной детализации.
Wol4ik написал:
Совершенно не важна длительность времени проведенного за исследованием, так как ничего не происходит пока мы не пытаемся выйти на улицу. Многократная зарядка и разрядка стволов не вызывает у игры необходимости подгонять нас по сюжету. Я думал над играми, где нельзя просто осмотреть не потеряв при этом возможность сделать вместо осмотреть что-то еще.
В том же "Проклятье вервольфа" интересующая вас ситуация создаётся во время боя с волками (даётся только 5 ходов, при этом, команда "отмена" в этот момент заблокирована, правда я не стал блокировать возможность сохранения). Это просто как пример из знакомой вам игры. Так-то существуют игры, где весь геймплей сопровождается подобными ограничениями. Игрой, до определённой степени даже иронизирующей над этим, являются "Три рубильника".
Также есть очень старый приём с голодом, пришедший к нам ещё из 70-х, который вынуждает игрока потреблять еду после определённого количества ходов, что типа повышает ценность хода, особенно если вдруг оторвался от источника еды.
Однако опять же, строить всё на подобных ограничениях - это путь к тому, что игрок будет просто мухлевать откаткой или сохранениями, так что и цели не добьёмся, и игроку удовольствие испортим.
ASBer написал:
Все объекты могут быть интерактивными или декоративными.
Я бы настолько не упрощал. Объекты могут быть обязательными для взаимодействия или использования, необязательными, а также да, совсем декоративными.
Под декорацией в парсерах обычно понимается особый класс объекта, который просто на все действия отдаёт что-то типа "это не имеет значения". То есть это просто заглушки, чтобы избавиться от фрустрирующих ответов типа "я не знаю слово окно", хотя окно есть в описании локации. В игре, ставшей триггером данного обсуждения, такой декорацией является лунный свет, чтобы его лишний раз не щупали и не двигали.
При этом, необязательный для взаимодействия объект вполне может быть интерактивным. С тем же окном возможно вообще не нужно никак взаимодействовать для прохождения игры, но всегда приятно, когда реакции на "посмотреть в окно", "вылезти в окно", "открыть окно", "разбить окно" и пр. более разнообразны и соответствуют контексту команды, хотя по факту ничего и не дают. Это то самое, что и создаёт глубину мира, которая и лежит в основе особой эстетики парсерных игр.
К слову, некоторые объекты желательны, даже если не упоминаются в описаниях, например, земля или объект самого игрока.
Larson написал:
Определенная детализация в парсере должна быть, она обостряет наше воображение, но описание вещей должно быть таким [b]чтобы игрок понял что вот это здесь не главное а вот на этом следует сосредоточится.
Ваше мнение, конечно, имеет право на существование, но оно противоречит всей традиции парсеров, а также общей эстетики жанра. Идея парсеров как раз в том, что нужные для прохождения команды должны быть продуктов логического анализа игровой ситуации, а не лобовых подсказок в тексте.
Например, игра даёт ключ, цветочек и шапочку из фольги как абсолютно равноценные по способам взаимодействия объекты, и когда вы встречаете запертую дверь, то ваш мозг, а не игра, должны сформулировать идею, что дверь, скорей всего, надо пробовать открыть ключом. По крайней мере, как первую попытку. Второй же попыткой может быть стук в дверь, вообще не имеющий отношения к набору вашего инвентаря. Не стоит требовать от дизайна игры, чтобы до запертой двери она не давала вам никаких других предметов, кроме ключа, потому что для парсеров это немного нелепо, и такая игра будет просто неинтересной.
Если вы хотите выбор из готовых гарантировано рабочих рецептов, то это концепция не парсеров, а CYOA. Для этого концепция CYOA и появилась, и за это мы её и любим. Да и там существует явление псевдовыбора или опцийвариантов-заглушек, которые также нельзя назвать абсолютным злом.
Larson написал:
Для себя я сделал вывод такой: тщательная детализация нужна там, где предметы занимают важное место в сюжете игре, тогда детальность предметов будет катализатором для игрока и не будет его отвлекать.
Если писать парсерные игры по такому рецепту, то мы многое потеряем: альтернативные способы решения пазлов, пасхалки, шутки и пр.
Одной из важных составляющих эстетики парсерных игр является то, что шутки и целые смысловые слои являются необязательными для просмотра и нуждаются в их осознанном поиске или случайном раскрытии со стороны игрока.
По сути, весь необязательный для просмотра слой информации в парсерах обычно больше, чем весь обязательный. Это многим и нравится, особенно если автору есть, что сказать в необязательном слое: шутки, различные отсылки, сюжетные подробности и пр.
В каких-то играх есть вообще специальные дразнящие предметы, чтобы вывести игрока на шутку, и это хорошо и правильно. Я тоже люблю так делать.
А иногда игроков просто троллят. В том же "Проклятье вервольфа" столько барахла в шкафу, чтобы потроллить любителей собирать всё и таскать с собой.
нордик написал:
Мое мнение насчет парсера - это всего лишь технический прием. И парсерные игры положили в основу всего игрового процесса именно этот технический прием - набор возможных слов/команд с объектами в локации.
Техническим приёмом, причём, скорей вынужденным, это было годах в 70-х. С тех пор прошло много лет, и это породило ряд традиций и эстетических особенностей, превратив парсеры в жанр, что является более ёмким понятием.
Когда какой-нибудь Гораций Уолпол писал "Замок Отранто" - это был просто набор специфических образов и сюжетных ходов, но теперь, если вы напишите что-то подобное, - это будет работа в жанре готической литературы и от этого уже не деться. Причём, от вас будут ожидать вполне конкретных вещей, отсутствие которых будет смотреться плохо, так как формирование жанра формирует вокруг него определённые ожидания читателя. Если же попробовать быть чуть-чуть беременным, типа взять только половину жанровых традиций, то часто получается плохо: фанаты жанра разочарованы отсутствием второй половины, а другие - присутствием первой, которая им в этом жанре не нравится, из-за чего они и не являются его фанатами.
Именно так и получится с CYOA с парсерным управлением, что по сути тут некоторые и предлагают.
Да, после формирования жанра его законы можно нарушать, и это может иногда получаться небезынтересно, но вот нарушение законов жанра - это как раз всего лишь технический приём, который определяют именно от противного, лишний раз подтверждая то, что именно жанр первичен, а не представители, нарочито нарушающие его законы и традиции. Когда же нарушения одного жанра превращаются в систему, то просто образуется ещё один жанр. Когда-то менюшные игры так и отпочковались от парсерных, от чего вся interactive fiction только выиграла.
Однако для отпочковывания нужны весомые основания. То, что кто-то не знает конвенциальных договорённостей парсерных игр и поэтому у него не получается в них играть или их писать - это ещё недостаточное основание для пересмотра всего жанра.
нордик написал:
Например - есть комната и в ней разраб заложил 30 объектов с которыми можно взаимодействовать при помощи скажем 10 типов действия. Итого 30х10 = 300 типов результатов взаимодействий в одной локации. И лишь 1-2 цепочки (из допустим 20 действий) ведут к находке ключа и выходу из комнаты и развитию сюжета далее.
Это ничего не значит, так как для игрока точный набор значимых для прохождения действий заранее неизвестен. Более того, значимость здесь не является бинарной категорией, так как, например, осматривание каких-то объектов может быть необязательным, но при этом может содержать информацию, раскрывающую какой-то аспект сюжета, или же просто имеющую развлекательную функцию, типа персонаж в необязательной для захода комнате рассказал байку.
Именно исследование заложенных в игру секретов (пусть даже необязательных для прохождения), а также процесс поиска правильных действий и обуславливают интерес к парсерным играм у их целевой аудитории, а также формируют определённые специфические игровые и сюжетные механики, задающие жанровые рамки.
Антон Ласточкин написал:
Парсерная игра предоставляет не только "приём" для реализации сюжета, но и предоставляет возможность моделирования мира и сложного поведения неигровых персонажей. Вне парсера эта задача решается намного сложнее. Плюс ко всему, идёт автоматическая генерация текста локаций в зависимости от объектов на ней и событий. Такие эффекты создают не просто художественное описание, а мощное погружение в мир и ощущение контроля со стороны игрока. Если сложность головоломок будет постепенно нарастать, то больших проблем не будет и можно сделать систему подсказок. Вы можете создавать локации динамически и прописать правила работы между объектами разных классов. Парсерный движок позволяет реализовывать такие взаимодействия, так как имеет объектно-ориентированную основу.
Я бы перечисленное всё-таки не относил исключительно к парсерам. Живой пример - классический INSTEAD, где есть всё это же, но без прямого текстового ввода в управлении.
На мой взгляд, с точки зрения разработки у парсерных игр никаких особых технических преимуществ нет: генерация описаний, ООП и пр. - всё это доступно и для игр без текстового ввода. У разработки парсеров из специфических особенностей скорей только одни проблемы и мучения, поэтому нужны стальные яйца, чтобы доводить такие игры до ума, и именно по этой причине у нас есть куча недоделанных и сырых парсерных игр, потому что позвякивают при ходьбе меньше половины русскоязычных парсерных авторов. Плюс из них кто на пенсию ушёл, кто засматривается в сторону женских квестов на Salet, кто на форумах флудит вместо написания игр...
Madzi написал:
Изначально речь шла о взаимодействии с объектами сцены - это вполне возможно. Здесь нужно иметь набор стандартных объектов и стандартных действий. Тогда автору придётся описывать только новые действия и новые объекты, если они появляются в игре. Для стандартных объектов со сторны автора никаких дополнительных действий не потребуется, а игрок сможет по-взаимодействовать с окружающим миром, если ему так хочется.
Для справки: при разработке парсерной игры и создании игрового мира у нас есть только 2-3 стандартных объекта: объект игрока, объект локации, в которой он появился, ну и, если платформа предусматривает, то пол в локации. Никаких других "стандартных объектов" при создании парсерной игры обычно нет, а главное они и не очень нужны, потому что всё равно окажутся бесполезными из-за недостаточной гибкости.
Существуют стандартный классы объектов, наследуясь от которых мы можем создавать объекты с нужными характеристиками. Однако так или иначе, но объекты или правила их процедурной генерации надо создавать разработчику.
Стандартные же классы выглядят не как окно, стол, книга, пончик и т.д., а как прозрачный предмет, поверхность для размещения других предметов, предмет для чтения или съедобный предмет. А вот будут ли это окно, стол, книга и пончик, или же телескоп, подоконник, наскальная надпись и таблетка, решает и программирует автор в каждом отдельно взятом случае. При этом всё ещё сложнее, так как ту же книгу взять и унести можно, а наскальную надпись нельзя. Именно поэтому никаких "стандартных объектов" по сути не существует, а существуют лишь комбинируемые и дописываемые по обстоятельствам классы со своими иерархиями наследуемых методов и свойств.
goraph написал:
Мнимая сложность разработки парсеров, это страшилка, которая не соответствует действительности.
Вообще смотря с чем сравнивать. Примитивный парсер написать, конечно, сложнее, чем примитивный CYOA, ну а с усложнением всё, как нестранно, усложняется, причём, нелинейно.
Впрочем, разработка парсеров скорей муторная, чем сложная, и там есть долина смерти, когда игра уже более-менее работает и все основные задумки реализованы, но вот теперь надо идти проверять и дорабатывать реакции всех объектов на существующие действия, а также дописывать некоторые чисто инфраструктурные вещи, типа системы подсчёта очков. На этом этапе многие дают слабину, либо ломаясь и откладывая в стол, либо выпуская совсем сырую игру, например, без слова "конец" после обнаружения отрезанной головы в куске льда.
Тут может помочь только жёсткая самодисциплина и переиспользование кода из предыдущих проектов, поэтому каждый следующий парсер писать проще.
Мифом также является сложность разработки длинных парсерных игр. Вообще-то их писать даже легче, чем несколько маленьких с таким же объёмом кодовой базы. Проблема опять же в терпении и способности работать не только на креативном подъёме и полёте фантазии, но и на понимании необходимости и готовности решать ряд рутинных технических задач.
Oreolek написал:
По-моему, стоит немного напомнить о реалиях программирования парсеров: 80% работы за автора делает стандартная библиотека. Это та штука, которая отвечает "Лимон выглядит как обычно" на вопрос "осмотреть лимон", когда лимон просто лежит на столе и не представляет интереса для осмотра. Лимон можно осмотреть, обнюхать, лизнуть, толкнуть — и стандартная библиотека, как правило, делает так, чтобы это работало и выглядело логично в любой игре. Поэтому прописывать сотни комбинаций не требуется, достаточно просто описать объекты.
Вместе с этим, не стоит впадать в другую крайность и идеализировать стандартную библиотеку и её предопределённые ответы и набор классов. В действительности, существенную часть кодовой базы прилизанной парсерной игры занимает как раз переписывание стандартных реакций, а также написание собственных классов. Иногда до 50% кодовой базы уходит именно на это. Некоторых очевидных вещей там может вообще не быть, как, например, в TADS нет функции завершения игры, кроме как функции смерти главного героя. Может быть тут кроится глубокий смысл, что типа "всё тлен", но иногда игры всё-таки кончаются не только смертью основного персонажа. В итоге я всегда таскаю с собой однажды написанную универсальную функцию endGame().
Плюс реалиями разработки русскоязычных парсерных игр также является параллельный патчинг стандартной библиотеки на очень низких уровнях, так как, по большому счёту, мы там всё ещё живём в эпоху бета-тестинга.
К слову, именно это меня настораживает в ТОМ2, так как редактирование словаря там представляется довольно геморройным процессом на совсем ином уровне абстракции, чем разработка самой игры.
0 
#1
10.10.2017 12:12