Forum.iFiction.Ru

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

Есть объект "Река", который находится ("протекает") в нескольких локациях (этот пример мы обсуждали с Чеширом на канале #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, то в результате определения местонахождения вернётся НЕТ вне зависимости от наличия искомого объекта у персонажа "Игрок".

Хм… Иногда моя работа над Адским Движком™ напоминает мне это:

fireton написал:

Не, ну ты сам того добился.
Делал бы себе игру и движок молча... Теперь терпи.

Да я как-то не жалуюсь. Даже наоборот.

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

Хм… Сколько останется, если из "Бесконечности" вычесть "Всё что есть"?

 спойлер…

Несчётное количество несъедобных предметов?

Отредактировано uux (13.09.2011 22:14)

В правильном ролике "Алфавит по хардкору", глаз зацепился за кадр с буквой Q, из чего родилось настроение логотипа для Адского движка:

В своё время мою идею маскировать ссылки на объекты в тексте (делая их тем же цветом, что и текст) подвергли критике, хотя были и те, кто эту идею поддержал.

Однако, добавление в описание объектов только для антуража делает текст слишком "пёстрым". Так может для подобных объектов добавить свойство "Не выделять ссылку", при установке которого ссылка на этот объект и будет маскироваться под обычный текст?

P.S. Хотя со временем, идея маскировать ссылки мне кажется всё более привлекательной.

Ну так я с этой идеи — максимально маскировать ссылки — и начинал, потому как основная цель была в достижении как раз того эффекта, который ты описываешь. Так что потестирую, пожалуй, ещё. Или выведу маскировку ссылок в настройки — типа как уровень сложности.

Я обычно так и делаю, на мой взгляд самая удобная реализация ссылок. В один цвет нежелательно - начинается пиксельхантинг

Офигенная тема, хочу обсудить, но сообщение не скрывается :-(

По-моему, идея скрывать ссылки в играх плоха по трём причинам.

Во-первых, её труднее объяснить.

Во-вторых, на планшетах и телефонах такого события, как наведение курсора мыши, вообще не существует.

В-третьих, в чём должен заключаться сам процесс игры? Вот вывалилось на игрока два экрана текста. Либо он внимательно прочитает, пролистает, затем проверит мышкой каждое слово, затем начнёт думать, либо просто внимательно прочитает и начнёт думать. Зачем мешать ему думать над игрой, заставляя проверять каждое слово на двойное дно?

Отредактировано Oreolek (04.11.2011 11:37)

Мне очень нравится идея подсветки всех существительных в тексте с последующим интерактивом. Две трудности:
1. Дофига работы над описанием. Но это решаемо.
2. Удобная разметка текста. При достаточной насыщенности текста существительными код игры быстро превратится в нечитаемый треш. Тут простого решения нет. Либо идём путём инстеда и собираем описание из кусочков, либо надо как-то извращаться.

Хороший пример реализации - игра "Цветохимия (Ajenta; QSP), в которой предусмотрено два режима сложности. На одном ссылки подсвечены, на другом, соответственно, скрыты.
Ссылка на игру: http://qsp.su/index.php?option=com_sobi … p;Itemid=0

Отредактировано Серый Волк (08.11.2011 16:40)

Да, и пришлось обломаться с порционным выводом текста. То есть была задумка добавить в функцию вывода текста:

…ТекстНаЭкран, 'Привет мир!'

тег "<-далее->", чтобы команда:

…ТекстНаЭкран, 'Привет мир!<-далее->Я всех ненавижу!'

выводила сначала "Привет мир!", а потом (после нажатия на пробел или маленькую ссылочку "продолжить") — "Я всех ненавижу!". Это позволило бы нагнетать атмосферу и выводить неожиданные обороты. Драматическая пауза на заданное время — это выход, но я не люблю решения с фиксированными паузами (и недолюбливаю людей, которые этим приёмом злоупотребляют). Поэтому отложил это до лучших времён.

P.S. Почему не получилось? Потому что в QSP-Classic невозможно остановить выполнение кода в отдельной точке (если это не input или msg, конечно же), подождать действия игрока, а потом продолжить далее.