Forum.iFiction.Ru

Можно. Если это RInform + Glulx или метапарсер инстеда. Но никто это пока не делал.

Если подробнее, то в инстеде это просто ещё никто не делал, а в Inform такую сложность смогли написать только после появления Inform 7 (AFAIK).

Для Inform 7 (и как подсказку по алгоритмам) можно почитать код Kerkerkruip.

UPD: не заметил, что это раздел про RTADS :-) это вуду ещё сложнее, потому что HTML-TADS это урезанный HTML 3.2, очень старый и ограниченный для такого. Там нет возможности собирать одно изображение из нескольких, то есть, это будет одна большая карта из мелких тайлов и у каждого тайла по два варианта - без игрока и когда игрок на нём стоит. Если в игре кроме игрока ещё и перемещаются монстры, и их тоже хочется показывать на карте, то это ещё больше вариаций для тайлов и ещё больше размер игры. И это будет не слева, а в тексте игры, потому что опять же в TADS-HTML нет позиционирования блоков.

Отредактировано Oreolek (28.08.2018 10:18)

Если без картинок, то подойдет как в тетрисе. Нарисовать программно цветные квадраты-локации допустим с их названиями в центре, где нахождение игрока будет окрашивать квадрат-локацию в другой цвет. Картинка прилагается. Что-то похожее на «майнд-карты».

Отредактировано Kephra (28.08.2018 13:12)

Kephra написал:

Можно ли, чтобы от основного текста игры, допустим слева, была карта. Но, не статичная картинка, а на которой отображалось перемещение игрока, — ну как в обычных играх.

С учётом того, что текстовые парсерные игры были одними из первых, это ещё большой вопрос, кого считать обычными, а кого выпендрёжниками. :-)

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

Сама функция отрисовывает баннер с нужным позиционированием, сверяясь после каждого хода с игровой ситуацией. В зависимости от ваших потребностей можно использовать разные способы отрисовки карты внутри данного баннера:

• Если вариативность не очень высокая, то возможно наиболее простым и эффективным способом будет подготовить соответствующее количество статичных кадров, например, изображений карты мира с крестиком в каждой локации. Ну и в зависимости от места положения выводить просто нужный кадр.
• Если вариативность высокая и делать кадры трудозатратнее, чем делать динамическую карту, то рисовать её можно, например, через таблицу, "зажигая" и "гася" ячейки. Мелкими ячейками или баннерами можно нарисовать и более сложную геометрическую структуру, но если стоит вопрос скругления прямоугольных фигур, то это потребует слишком высокого разрешения, что может оказаться не очень благоприятно для производительности. Здесь можно выводить в стыкуемые области картинки с нужными формами.
• Также существует вариант ручной генерации внешнего ресурса в виде картинки, который можно будет уже считывать и отображать в баннере, если вы готовы писать алгоритм генерации графического файла на языке TADS или же выносить это во внешнюю функцию на языке с поддержкой интерфейса в стиле C, разруливая все вопросы переносимости кода, выходящего за рамки виртуальной машины TADS.

Откровенно говоря, дальше первого и первой половины второго вариантов я бы идти не советовал, а при сильном желании это сделать рекомендовал бы сменить платформу. С точки зрения задачи в рамках написания русскоязычной парсерной игры, пожалуй, на INSTEAD + Метапарсер 3, если соответствующие потери функциональности стандартной библиотеки  и специализированности языка разработки будут сочтены несущественными или приемлемыми.

При всём этом, в отрисовывающей баннер функции желательно не забыть сделать через systemInfo() проверку типа интерфейса пользователя, чтобы отключить все отрисовки для plain text, обеспечив воспроизводимость в данном режиме без вывода технического хлама.

(О функциях-демонах см. главу 4 (раздел 3) руководства RTADS, о работе с баннерами - гл. 9, о работе с внешними файлами - гл. 5, о создании внешних функций - приложение F.)

Kephra написал:

Ещё, как сделать перемещение по названию локаций, а не по сторонам света?

Команда типа "идти в %объект%" является частью стандартной библиотеки и обрабатывается методами verDoEnter и doEnter названного объекта. В зависимости от стоящих задач могут быть разные подходы к реализации:

• Если в описании локации перечисляются названия соседних локаций, то для этих локаций просто создаются декорационные объекты с соответствующими значениями свойств noun и adjective, которые имеют метод doEnter, выполняющий перемещение персонажа через метод travelTo. Если в целевую локацию есть дверь, то это всё работает уже в её объекте, надо только добавить нужные синонимы для обращения. Если это объект типа "лес на горизонте", то лучше использовать класс distantItem для удалённых объектов, которые можно видеть, но нельзя трогать и прочее.
• Если в какую-то локацию можно попасть из нескольких, например, это башня, к которой можно подойти с разных сторон, то достаточно создать один объект класса floatingItem и определить для него необходимый перечень локаций, в которые он должен автоматически "переплывать" за игроком. Тут стоит учитывать, что location самого игрока может возвращать не только объект локации, но также объекты вложенных комнат, типа кровати, на которую он лёг или пола, на который он сел, поэтому именно корневую локацию надёжнее и проще всего получать не как значение location объекта игрока, а как значение location объекта земли (theFloor.location). Также для надёжной проверки нахождения одного объекта внутри другого есть метод isIn, рекурсивно проходящий все вложения.
• Если стоит задача обеспечить проход в не соседнюю локацию, а, например, в кухню из комнаты, между которыми есть коридор, ну и так в любую несмежную локацию карты, то для этого лучше не перемещать кучу объектов класса floatingItem для каждой локации за игроком, а доработать объект глагола inVerb, модифицировав в нём методы validDo и validDoList, отвечающие за перечень валидных объектов, с которыми допускается взаимодействие. В стандартном виде inVerb валидными считает только объекты в прямой видимости персонажа, а для озвученной задачи надо расширить их список, допустив обращение к любым объектам, аналогично глаголам типа askVerb ("спросить о %любой_объект%"). При этой реализации отдельные декорационные объекты для локаций можно уже не создавать, просто добавив в сами объекты класса room свойства noun и adjective с их названиями. В какой-то момент может возникнуть вопрос, что логично переходить только в знакомые локации, а также в те локации, которые в принципе сейчас доступны, например, дверь в них не заперта. Посещённость локации проверяется свойством isseen её объекта, а доступность прохода можно проверять фактом возврата соответствующим свойством/методом объекта локации, отключая при необходимости вывод сюжетного текста через функцию outhide(), если вдруг переходы у вас сопровождаются какой-то дополнительной текстовой выдачей. Способы эффективного обхода графа и варианты его хранения в памяти имеет смысл не выдумывать, а изучить по какому-нибудь академическому курсу алгоритмов и структур данных, чтобы реализовать это с приемлемой асимптотикой.

(Подробности по упомянутым функциям, классам, объектам и их свойствам/методам см. в главе 5 и приложении B руководства RTADS.)

Oreolek написал:

Можно. Если это RInform + Glulx или метапарсер инстеда. Но никто это пока не делал.

Если уж вспоминать альтернативные платформы, то стоит упомянуть ADRIFT, где интерактивная карта является функцией "из коробки" в стандартном интерпретаторе. Вот только во всём остальном ADRIFT плох как парсерная платформа, особенно русскоязычная, в том числе и для решения второй поставленной задачи.

Oreolek написал:

И это будет не слева, а в тексте игры, потому что опять же в TADS-HTML нет позиционирования блоков.

TADS может позиционировать баннер как таковой, а также содержимое баннера средствами табличной вёрстки.

Oreolek написал:

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

Для того, чтобы не полагаться на везение надо чётко представлять, как работает механизм баннеров. Измерение, не задаваемое баннеру в явной форме, равняется размеру доступной свободной области. Доступная область чётко зависит от наших собственных предшествующих действий с баннерами. Изначально стандартная библиотека имеет только одно тонкое место, а именно баннер статусной строки в верхней части экрана. Если влезть раньше инициализации этого баннера в функции init(), то мы отхватим всю высоту, а если после, то высоту за вычетом статусбара.