Думаю, каждый кто знаком с двумя разновидностями текстовых игр ответит, что играть легче в меню, а труднее бороться с парсером. Тогда следующий вопрос: как вы думаете, что легче в проектировании игры — меню или парсер? Речь идёт не об учебных примерах для движка, а о качественных играх. Если немного копнуть, то для парсера можно обнаружить довольно много рекомендаций (например — первая, вторая). В хороших движках есть развитая библиотека объектов, которая позволяет создавать мир из готовых блоков — локации, предметы, декорации, актёры. У вас уже есть реализованные подсистемы навигации, инвентаря, очков, манипуляций с предметами. Вы можете создать качественную, интересную парсерную игру с нуля, сфокусировавшись на сценарии, механиках, наполнении. С соблюдением всех канонов.
С менюшными играми всё сложнее. «Бедные» движки предлагают по-умолчанию только систему гиперссылок, чуть «побогаче» добавляют сохранение, загрузку, медиаконтент. Если вы их выбрали, то вам необходимо предварительно разработать промежуточный слой поддержки навигации по локациям, инвентаря, работы с предметами и NPC. Так, чтобы игра расширялась удобнее и с ростом сложности вы не потеряли контроль. Самые навороченные движки, типа Instead, предлагают много готовых модулей, типа диалоговой системы и управления инвентарём. Однако по-прежнему не хватает главного — стройных методик для составления интересной менюшной игры. Поэтому дальше надо двигаться интуитивно.
Вывод следующий: хотите быть уверенным, что напишите интересную игру, в которую мало кто поиграет, то выбирайте парсер! Если вы хотите писать меню на простом движке, позаботьтесь о разработке промежуточного слоя.
Если у вас есть другое мнение, то пишите комментарий!
Меню проще, чем парсер, но именно поэтому парсер и интереснее меню, если умеешь в это играть.
Менюшки с упором на интересность сюжета проигрывают книгам, которые в этом моменте рвут менюшки как тузик грелку.
В общем в плане легкости меню победитель, но в плане интереса меню проигрывает всем. Этим и объясняется то, что при всей своей простоте и дружественности к игроку, менюшки так и не взлетели, оставшись интересными лишь самим авторам. Поэтому актуальным остается вопрос: а нужны ли вообще меню, если кроме формальной простоты управления им больше ничего конкурентоспособного и не предложить?
А мне кажется, всё зависит от сложности и качества головоломок, которые задумал автор. Менюшные игры тоже можно сделать сложными и очень интересными, хотя да, их немного. Лично для меня игра-победитель в этом направлении — «Зеркало».
А вообще, хотелось бы видеть больше игр на Instead, адаптированных для незрячих (Plaininstead перестал развиваться).
Поэтому не скажу, какая платформа лучше (с точки зрения игрока). Всё зависит от автора игры
А вот есть альтернативная точка зрения про «бедные» менюшные движки по сравнению с «богатыми» парсерными) https://ifhub.club/2018/06/06/zhivoy-dialog-s-npc-chat-ili-menyu.html А если не полноценный чат, то парсеры дальше «спросить о…» и «поговорить с…» не уходят. Так что про слой для работы с NPC это, скорее, к парсерам.
А то сравнивать меню и парсеры чисто по объектному моделированию мира как-то не совсем корректно.
Instead все-таки не меню. Это пойнт&клик текстовый. Ну в основном.
> Instead все-таки не меню. Это пойнт&клик текстовый. Ну в основном.
Меню — это перечень, то есть заранее известный набор управляющих действий, в отличии от ввода произвольных команд, чей набор также ограничен, но доподлинно пользователю неизвестен, так что пользователь может вводить всё, что угодно, и никогда не может быть уверен, что попробовал все допустимые варианты. Поэтому классический INSTEAD — это разновидность меню, так как там всё сразу видно. Управляющие действия пользователя в классическом INSTEAD имеют явно ограниченное интерфейсом конечное число вариантов.
Выбор из отдельно описанных вариантов действий (CYOA / choice-based ), клики по активным участкам прямо в тексте (hypertext), глагольное меню или контекстное меню действий на объектах — это всё лишь разновидности того, что объединяется зонтичным термином «меню». Классический INSTEAD — это попытка повторить дух графических point-and-click квестов, но по сути не что иное, как вариация на тему гипертекста с активными элементами управления прямо в тексте описаний.
Я бы инстед всё же выделил в отдельную категорию. Очень уж геймплейно классический инстед отличается как от меню, так и от парсера. Говорю как игрок. Что там внутри движков я без понятия.
Чтобы внести ясность:
Парсер — ввод комманд ручками, теоретически не ограниченная объектная модель мира
Меню — твайн, чойсы и подобное. Стена текста, несколько вариантов перехода, вновь стена текста и т. д. повторить до победного конца.
Инстед — объектная модель, ограниченная явно.
В любой игре любого жанра имеется заранее известный набор управляющих действий, явно ограниченных интерфейсом.
Это обстоятельство нисколько не мешает делать разнообразные, интересные, реиграбельные, смысловые, эмоционально цепляющие игры, что рождает мысль: может претензии к меню это нечто, напоминающее персонажей басни ‘Квартет’?
И только парсерный интерфейс это головоломка, суть которой в попытках игрока угадать логику автора игры.
Декларации адептов парсерного ввода сводятся к короткой фразе ‘все что не парсерная головоломка это го.но’.
>менюшки так и не взлетели, оставшись интересными лишь самим авторам
Lifeline и море производных от неё с тобой не согласны. 🙂
Sorcery! тоже. Не вспоминая уже игры Choice of games.
Самые что ни на есть менюшки и коммерчески успешные. Назови мне хотя бы пару коммерчески успешных парсеров за последние пару лет.