Forum.iFiction.Ru

Что я подразумеваю под "Упоминанием" объекта?

Чтобы не заморачиваться со встраиванием информации об игровых объектах в том или ином тексте посредством программного кода (возьмём любимый пример [1, 2] Некса):

*P 'Вы на кухне.'
IF роджер=1: ' Здесь находится Роджер.'

(и так — в каждой локации, где может появиться Роджер)

я пошёл по другому пути. Описание локаций у меня содержит ссылку на упоминание о Роджере, а у объекта "Роджер" расписаны упоминания о нём в зависимости от того, в какой локации он находится:

GS 'УстановитьОписание', 'Кухня', 'Кухня', '
    п. Вы на кухне. [[Роджер]]
'
GS 'УстановитьОписание', 'Туалет', 'Туалет', '
    п. Вы в туалете. [[Роджер]]
'
!----------
GS 'УстановитьУпоминание', 'Роджер', 'Локации:Описания', '', {
    $Локация=$ARGS[0]
    $Текст=$ARGS[1]
    !----------
    if $Локация='кухня' and роджер=1:
        $Текст='Здесь находится Роджер.'
    elseif $Локация='туалет' and роджер=2:
        $Текст='Здесь спит Роджер.'
    end
    !----------
    $Result=$Текст
}

Теперь обращение к описанию локации:

*NL func('Описание', $ТекущаяЛокация, 'Текст')

возвращает мне законченный текст с учётом упоминания о Роджере.

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

Доделал вывод описания объектов (локаций, предметов, персонажей) со всеми потрохами, т.е. находящимися "внутри них" объектами. Всё работает именно так, как описано в предыдущем сообщении.

Чтобы при выводе описания появилось перечисление "хранящихся" внутри объектов, нужно это описание связать с тем или иным контейнером. Например:

GS 'УстановитьОписание', 'Сундук:Основное', 'Громоздкий сундук', '
    п. Здоровенный деревянный ((сундук|Сундук)), обтянутый железными полосками.
'
!----------
GS 'УстановитьОписание', 'Сундук:ЧтоВнутри', 'Громоздкий сундук', '
    п. Изнутри ((сундук|Сундук)) обит потёртой выцветшей тканью.
', '', '', 'Содержимое'

Первое описание ("Основное") выводится при внешнем осмотре сундука. Второе ("ЧтоВнутри") — при осмотре содержимого. При этом второе описание связано с контейнером "Содержимое", следовательно, при выводе описания текст будет дополнен перечислением всех объектов, находящихся в контейнере "Содержимое" объекта "Сундук".

Так, самая простая часть — технически погасить или восстановить ссылки — работает и работает отлично.

1. Берётся область экрана, в которую выводится игровая информация.
2. Из этой области вытаскиваются все (как активные, так и погашенные) ссылки.
3. Из ссылки вычленяется ID объекта.
4. Проверяется доступность объекта.
5. Если объект недоступен, то ссылка гасится.

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

Так, приехали. Кажется, QSP-плеер начал тормозить…

Olegus t.Gl. написал:

Так, кое-что удалось реализовать:

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

Перебор ссылок и анализ доступности каждого объекта (если это не локация):

1. Если объект находится в инвентаре, то ссылка на экране не нужна (объект доступен через инвентарь) — блокируем.
2. Если объект находится в содержимом локации, то ссылка нужна — активизируем.
3. Если объект находится в одном из доступных к этому времени контейнеров, то ссылка также пригодится — активизируем.

4. Если текущее местоположение объекта соответствует сохранённому на момент формирования ссылки — активизируем.

Nex написал:

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

Получившийся код слишком сложен для ручного набора?

Ajenta, вертикальный разделитель в меню появляется в Windows 7 (виден на скриншотах из предыдущего поста), в WinXP его нет.

Так, что же делать с объектом, который хочется рассовать в разные места: разложить по разным локациям, засунуть в разные предметы, распихать по карманам разных персонажей?..

Когда объект существует в игре в единственном экземпляре, то проблем нет — в момент любых манипуляций просто берём объект и его текущее местоположение. Если же объект один, но расположен в нескольких местах, то нужно точно знать в каком именно месте производятся манипуляции с этим объектом. Проблема усугубляется тем, что у меня может существовать множество контейнеров в одном объекте. Так, у персонажа могут быть одновременно контейнеры "Карманы" и "Шляпа", в каждый из которых можно положить, скажем, по сигарете. Допустим, игрок обыскивает персонажа: он осматривает сначала карманы, а затем шляпу. В таком случае перед ним на экране выведено содержимое обоих контейнеров, и в обоих текстах упоминается сигарета. Само собой, ткнув на сигарету в описании шляпы и выбрав пункт "Взять сигарету" нужно переместить сигарету именно из шляпы, а не из карманов. При этом хочется чтобы автору игры нужно было как можно меньше знать подобных нюансов, да и в параметрах команд указывать лишь самое необходимое.

Вот, например, рабочий код для ситуации, когда объект может быть только в единственном экземпляре:

! У объекта "Сигарета" добавляем пункт в меню…
GS 'УстановитьДействие', 'Сигарета', 'Взять сигарету', {
    ! …который будет появляться, только если объект "Сигарета" отсутствует у игрока
    ARGS['Результат']=IIF(func('Местонахождение', 'Сигарета', 'Игрок')=НЕТ, Использовать, Пропускать)
}, {
    ! Если игрок выбрал этот пункт, то перемещаем объект в инвентарь игрока
    if func('Переместить', 'Сигарета', 'Игрок')=Продолжить:
        GS 'ТекстНаЭкран', 'п. Вы взяли ((сигарету|Сигарета)).'
    end
}

В случае с многочисленными экземплярами объекта возникают следующие моменты:

1. При формировании описания содержимого объекта нужно определять его местонахождение — причём не просто в лоб, а с привязкой к выводимому описанию. И уже это местонахождение фиксировать в ссылке как ID-Места.
2. В системный обработчик ссылки нужно передавать вместе с ID-Объекта ещё и ID-Места, где он находится.
3. В авторский модуль обработки ссылки также нужно передавать ID-Места.
4. Использование этого ID-Места хотелось бы сделать незаметным для автора. Т.е. упоминаемый автором в коде идентификатор объекта система воспринимает как связку ID-Объекта + ID-Места.

Если допустить, что все условия и авторские модули передаются как строки или через {…}, то при реализации пунктов 1 и 2 можно провернуть такой финт: во все авторские модули передаётся параметр, в котором в запакованном виде хранится связка ID-Объекта + ID-Места, а в начало каждого авторского модуля автоматически добавляется строка:

ARGS['Объект']=ARGS[0]

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

! У объекта "Сигарета" добавляем пункт в меню…
GS 'УстановитьДействие', 'Сигарета', 'Взять сигарету', {
    ! …который будет появляться, только если объект "Сигарета" отсутствует у игрока
    ARGS['Результат']=IIF(func('Местонахождение', ARGS['Объект'], 'Игрок')=НЕТ, Использовать, Пропускать)
}, {
    ! Если игрок выбрал этот пункт, то перемещаем объект в инвентарь игрока
    if func('Переместить', ARGS['Объект'], 'Игрок')=Продолжить:
        GS 'ТекстНаЭкран', 'п. Вы взяли ((сигарету|Сигарета)).'
    end
}

Однако, это всё же частный случай. Ситуаций, когда нужно будет ссылаться на конкретный объект в конкретном месте, всяко больше — как в этом случае выходить из ситуации, надо ещё подумать.

Всё хорошо — пока всё получается как и задумывалось.

Чтобы не отпугивать благовоспитанных людей "Адский Движок" на публике будет выступать под мирским именем "Az"…

Что делать с контейнерами объекта, который может быть в нескольких экземплярах?

Есть объект "Река", который находится ("протекает") в нескольких локациях (этот пример мы обсуждали с Чеширом на канале #ifrus). Почему есть смысл сделать реку одним объектом? Да чтобы модули ("осмотреть", "посмотреться", "попить", "набрать воды") не дублировать — надо всего лишь один раз прописать взаимодействие с одним объектом "Река". Однако тут есть нюанс — а что, если нужно что-то положить в реку?

Можно реализовать это так — при перемещении каких-нибудь объектов в "Реку" на самом деле размещать их в специально выделенном для этой цели контейнере "ДноРеки", но принадлежащем не объекту "Река", а текущей локации:

GS 'ДобавитьВзаимодействие', 'Пистолет', 'Река', 'Бросить пистолет в реку', $ico['положить'], {
        Result = IIF(func('Местонахождение', ИГРОК, $ОБЪЕКТ1, '$ЛОКАЦИЯ:ДноРеки'), Пропускать, Использовать)
    }, 0, {
        if func('Переместить', ИГРОК, $ОБЪЕКТ1, 0, '$ЛОКАЦИЯ:ДноРеки') = Продолжить:
            GS 'ТекстНаЭкран', 'п. Вы бросили ((пистолет|$ОБЪЕКТ1)) в ((реку|$ОБЪЕКТ2)).'
        end
    }

При попытке взаимодействия "Пистолета" и "Реки" (при условии, что Пистолет уже не находится в контейнере "ДноРеки" текущей локации) "Пистолет" перемещается в контейнер "ДноРеки" текущей локации.

Соответственно, при выполнении осмотра дна "Реки" (что-то типа действия "Пошарить по дну реки") нужно просто дополнительно вывести содержимое контейнера "ДноРеки" текущей локации.

Наверное, стоит пока остановиться на этом обходном манёвре…

Кстати, раз уж последнее, что я переделывал — это обработчик "ПриОпределенииМестонахождения", то расскажу немного о нём.
Обработчик "ПриОпределенииМестонахождения" относится к системным обработчикам, то есть вызывается фреймворком автоматически при отработке тех или иных ситуаций, связанных с определением местонахождения объекта.

Синтаксис обработчика пока следующий:

GS 'ПриОпределенииМестонахождения', <Инициатор>, <Объект>, <Местонахождение>, <Модуль>

Инициатор — кто определяет местонахождение.
Объект — местонахождение чего определяется.
Местонахождение — где именно определяется местонахождение объекта.

Вызов данного обработчика происходит во всех возможных комбинациях параметров, включая пустые, что позволяет обрабатывать такие ситуации, как, например, определение игроком (Инициатор="ИГРОК") местонахождения чего угодно (Объект=0) в локации "Зал" (Местонахождение="Зал").

Попробую проиллюстрировать как задаётся и используется данный обработчик на примере. Допустим, игрок должен вынести из помещения статуэтку. На выходе стоит сканер, который срабатывает в случае, если обнаруживает что-нибудь у игрока при выходе из помещения. Однако, если у сканера отключить питание, то ничего обнаруживать он не должен. В этом случае как раз и пригодится обработчик "ПриОпределенииМестонахождения":

GS 'ПриОпределенииМестонахождения', 'Сканер', 0, ИГРОК, {
    if func('Свойство', 0, 'Сканер', 'Питание'):
        ARGS['Результат']=ДА
    else
        ARGS['Результат']=НЕТ
    end
}

Данный обработчик вызывается при определении объектом "Сканер" наличия какого угодно объекта у текущего персонажа. Если свойство "Питание" объекта "Сканер" в этот момент равно 0, то в результате определения местонахождения вернётся НЕТ вне зависимости от наличия искомого объекта у персонажа "Игрок".