Forum.iFiction.Ru

Кстати, добавил события и подписки на события.

С одной стороны у меня уже есть обработчики системных событий. То есть на ряд системных событий (например, получение свойства, перемещение объекта и т.п.) можно повесить модуль-обработчик, который будет выполняться при наступлении события. Например, есть объекты "Меч" и "Палица", у которых есть свойство "Урон". А у игрока есть свойство "Ловкость", которое должно увеличивать урон от оружия. Тогда такой вот обработчик:

    …ПриПолученииСвойства, 'Игрок', 'Урон', {
        °Значение = °Значение + …Получить('Игрок:Ловкость')
        }

увеличит значение урона от объекта на значение ловкости.

P.S. Для простоты я убрал код проверки, что объект, урон которого определяется, находится у игрока.

Однако кроме системных событий теперь есть ещё и авторские.

Например, вот код:

    …ПриНаступленииСобытия, 'СигнализацияСработала', '+', '', 'Сигнализация', После, {
        …Установить, 'Дракон:Спит', НЕТ
        …Переместить, 0, 'Дракон', '', 'Сокровищница'
        }
    
    …ПриНаступленииСобытия, 'СигнализацияСработала', '+', '', 'Сигнализация', После, {
        …Переместить, 0, 'Охранник', '', 'Сокровищница'
        }
    
    …ПриПеремещенииОбъекта, ИГРОК, 'Сокровищница', '', Перед, {
        if …Содержится(0, 'Корона', ИНВЕНТАРЬ, ДА) and …Получить(0, 'Сигнализация:Включена')=ДА {
            …Установить, 'Сигнализация:Орёт', ДА
            …ВызватьСобытие, 'СигнализацияСработала', ИГРОК, '', 'Сигнализация', После
            °Результат = Нельзя
            }
        }

Теперь если переместить игрока из "Сокровищницы", то

1. Отработает обработчик системного события "ПриПеремещенииОбъекта", и если у игрока в инвентаре есть корона, а сигнализация не отключена, то сигнализация начнёт орать: её свойство "Орёт" установится в ДА, и произойдёт авторское событие "СигнализацияСработала". И выйти игроку не получится.
2. На авторское событие "СигнализацияСработала" есть две подписки (они могут заполняться в разных местах: в модуле дракона и в модуле охранника), которые и вызовутся. В результате чего в сокровищнице окажутся и бодрствующий дракон, и охранник.

Как-то так…

Удалось решить старую проблему. Как я уже говорил и показывал, ссылки на объекты в тексте активируются или гасятся в зависимости от наличия объекта в инвентаре, текущей локации и в перечне доступных игроку контейнеров (если он осмотрел сундук, то ссылки на объекты из сундука должны быть активными). Таким образом, стоит игроку перейти в другую локацию, как ссылки на объекты их прежнего местонахождения гасятся. Точно так же, если объект исчезает из игрового окружения, то ссылка на него в предыдущем тексте будет погашена.

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

Всё это хорошо работало, но возникали следующие проблемы:

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

При всём при этом ещё нужно было отслеживать местонахождение игрока и всё такое.

В общем удалось привести это к единой методологии, что уже хорошо. Мужайтесь, дальше идут подробности.

Добавлена команда "УстановитьДоступностьСсылок", с помощью которой можно указать, ссылка на какой объект в каком месте будет активна (если конечно в меню есть пункты), если игрок находится в этом же месте. То есть когда игрок переходит в другую локацию, ссылка становится неактивной.

Но добавлено кое-что ещё более страшное и малопонятное.

Небольшой экскурс в правила формирования меню: при формировании контекстного меню можно указывать условия использования того или иного пункта. При этом в ссылке в тексте можно указать параметр, с помощью которого можно регулировать состав меню.

Например описание комнаты, где яблока нет, но чувствуется его запах:

В комнате стоит устойчивый запах ((яблок|Яблоко:Запах)).

Описание содержимого шкафа, где находится яблоко:

В шкафу на блюдце лежит ((яблоко|Яблоко)).

В данном случае объектом является "Яблоко", а "Запах" — это параметр, который передаётся в модуль формирования меню. И меню я могу формировать так:

…Добавить, 'Яблоко:Действия', 'Принюхаться',      '', {if:©Параметр ='Запах'}, {…ТекстНаЭкран, 'п. Запах усиливается по мере приближения к шкафу.'}
…Добавить, 'Яблоко:Действия', 'Осмотреть яблоко', '', {if:©Параметр<>'Запах'}, {…ОписаниеНаЭкран, 'Яблоко'}
…Добавить, 'Яблоко:Действия', 'Съесть яблоко',    '', {if:©Параметр<>'Запах'}, {…ТекстНаЭкран, 'п. Не стоит — тут явно какой-то подвох!'}

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

Но передача в модуль формирования меню параметра была уже давно. Я всё думал, как сократить запись, чтобы мне не приходилось скрупулёзно описывать все условия во всех пунктах. И вот что я добавил: если в описании ссылки написать что-нибудь такое: ((яблок|Яблоко:=Запах)) (то есть в начало параметра было добавлен символ "="), то это послужит фреймворку сигналом, что для данной ссылки нужно отбирать только те пункты, в условиях включения которых в том или ином виде обрабатывается значение параметра (в данном случае "Запах"). И теперь мне достаточно записать код так:

…Добавить, 'Яблоко:Действия', 'Принюхаться',      '', {if:©Параметр ='Запах'}, {…ТекстНаЭкран, 'п. Запах усиливается по мере приближения к шкафу.'}
…Добавить, 'Яблоко:Действия', 'Осмотреть яблоко', '', '', {…ОписаниеНаЭкран, 'Яблоко'}
…Добавить, 'Яблоко:Действия', 'Съесть яблоко',    '', '', {…ТекстНаЭкран, 'п. Не стоит — тут явно какой-то подвох!'}

При нажатии на ссылку ((яблок|Яблоко:=Запах)) фреймворк просто обросит пункты "Осмотреть яблоко" и "Съесть яблоко", поскольку в них не обрабатывается параметр "Запах".

Как-то так…

Zeantar написал:

Можешь выложить какой-нибудь пример, пару локаций, которые демонстрируют возможности, описанные в последних двух постах?

Хм… Почему бы и нет. Но только без глубокого экскурса в прошлое Адского Движка™.

Допустим есть три локации: Ворота, Утёс, Болото. От Ворот можно пройти к Утёсу, с Утёса можно спуститься к Болоту, ну и, само собой, можно подняться от Болота обратно на Утёс. Таким образом с локацией Утёс у нас связано два действия:

1. Пройти от Ворот к Утёсу.
2. Подняться с Болота на Утёс.

Поскольку действия в Адском Движке™ привязываются к объекту, то в данном случае мы должны привязать всё это к локации Утёс.

Можно, конечно, исхитриться по-другому, но это будет уже не то. А так у нас есть Утёс и есть ряд действий с ним.

Однако, просто накидать два действия мало:

…Добавить, ’Утёс:Действия’, 'Подойти к утёсу',    '', {…Переместить, ИГРОК, 0, 'Утёс', 'п. Пройдя несколько шагов по тропинке, вы остановились на краю утёса.'}
…Добавить, ’Утёс:Действия’, 'Взобраться на утёс', '', {…Переместить, ИГРОК, 0, 'Утёс', 'п. Взобравшись по хлипкой лестнице, вы оказались на утёсе.'}

Нужно дать понять фреймворку, когда какие действия нужно выводить.

Если я ещё не рассказывал про синтаксис команды "Действие", то вот он:

…Добавить, ’<Объект>:Действия’, <Название>, <Условие>, <Модуль>

Так вот параметр Условие и нужно заполнить, чтобы один пункт появлялся, когда игрок находится в локации Ворота, а другой — когда на Болоте. И только так. Два пункта сразу не нужны.

Совсем давно это можно было сделать так:

…Добавить, ’Утёс:Действия’, 'Подойти к утёсу',    {°Результат = IIF($ЛОКАЦИЯ = 'Ворота', Использовать, Пропустить)}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Пройдя несколько шагов по тропинке, вы остановились на краю утёса.'}
…Добавить, ’Утёс:Действия’, 'Взобраться на утёс', {°Результат = IIF($ЛОКАЦИЯ = 'Болото', Использовать, Пропустить)}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Взобравшись по хлипкой лестнице, вы оказались на утёсе.'}

После добавления "кратких условий" — так:

…Добавить, ’Утёс:Действия’, 'Подойти к утёсу',    {if:$ЛОКАЦИЯ = 'Ворота'}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Пройдя несколько шагов по тропинке, вы остановились на краю утёса.'}
…Добавить, ’Утёс:Действия’, 'Взобраться на утёс', {if:$ЛОКАЦИЯ = 'Болото'}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Взобравшись по хлипкой лестнице, вы оказались на утёсе.'}

Ну а теперь — достаточно описать условия так:

…Добавить, ’Утёс:Действия’, 'Подойти к утёсу',    {в:Ворота}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Пройдя несколько шагов по тропинке, вы остановились на краю утёса.'}
…Добавить, ’Утёс:Действия’, 'Взобраться на утёс', {в:Болото}, {…Переместить, ИГРОК, 0, 'Утёс', 'п. Взобравшись по хлипкой лестнице, вы оказались на утёсе.'}

Не бог весть какое новшество — несколько строчек кода, но нужно же напомнить об Адском Движке™…

Zeantar написал:

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

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

Да вроде игрок не полный даун, чтобы не понять, что по ссылке с названием "взобраться" ему предстоит именно взобраться. ) Ты, я думаю, привел слишком упрощенный и гипотетический пример. Если можно, сделай живой пример - не сложный, но правдоподобный.
С уважением.

Ссылка на объект "Утёс" может стоять на слове "утёс". Тогда в меню могут быть ещё пункты "Осмотреть", "Поковырять" и всё такое.

Я привёл пример работы с действиями. Не нужно обсуждать в этой теме теорию интерфейса игры на ссылках. Лучше перенести это обсуждение, например, сюда. Тут про Адский Движок™ всё же.

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

…передача в модуль формирования меню параметра была уже давно. Я всё думал, как сократить запись, чтобы мне не приходилось скрупулёзно описывать все условия во всех пунктах. И вот что я добавил: если в описании ссылки написать что-нибудь такое: ((яблок|Яблоко:=Запах)) (то есть в начало параметра было добавлен символ "="), то это послужит фреймворку сигналом, что для данной ссылки нужно отбирать только те пункты, в условиях включения которых в том или ином виде обрабатывается значение параметра (в данном случае "Запах")…

Лиха беда началом. Заменил символ "=" на "!", добавил два новых: "&" и "-", позволил писать их как в начале, так и в конце параметра. Про "&" говорить не буду — он отключает блок формирования пункта приглашения к взаимодействию с другими объектами. Зачем это нужно — в другой раз. А вот про "-" упомяну.

Раз у меня всё такое на ссылках, и в текущих вариантах дизайна ссылки отчётливо видны, то встала проблема: если хочется пораспихать по описанию ссылки на "предметы обстановки", с которыми нельзя взаимодействовать, но можно, например, осмотреть, потрогать или ещё чего (то есть чисто информация/антураж), то, после того как игрок по ним пройдётся, они будут мозолить глаза. Однако гасить их и не совсем правильно, да и хлопотно на уровне кода игры.

Для решения этой проблемы как раз и служит модификатор "-":

На обоях нарисовано ((яблоко|Обои:Рисунок-)).

В результате нажатия на ссылку "яблоко" будет сформировано меню, пункты для которого отбираются по параметру "Рисунок". И ссылка эта ничем не будет отличаться от остальных, пока игрок не переберёт все пункты меню. Как только он пройдётся по всему меню, ссылка поменяет цвет на менее заметный. А поскольку доступность ссылок проверяется у меня постоянно, то, если потом по каким-то условиям в данном меню прибавится пунктов,  ссылка вернёт свой исходный цвет, то есть опять начнёт мозолить игроку глаза.

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

Но придётся в каком-то виде и где-то задавать, что движок должен подставлять вместо %избушка% и %трубой%. Но это уже мелочи. Пока рассматриваю дополнительный параметр…

Забросил идею с дополнительным параметром — у меня их и так многовато. Пошёл по более дикому, но зато более универсальному пути, а именно добавил блок параметров прямо в текст. В коде эта строка выглядит так:

'У самого леса из земли торчит низенькая %избушка% с неприлично высокой и толстой %трубой%. Вот где враги жгут ваши брёвна!
'+$ттт+'
    избушка    = %|Избушка
    трубой     = %|Избушка:Труба
'

В переменной $ттт я зашил абракадабру, по которой специально обученная функция чётко разделяет текст и дополняет содержательную часть данными из блока подстановок. Ну и в редакторе это выглядит не настолько страшно, потому как блок со значениями подстановок всегда можно свернуть. А знак % в блоке параметров означает, что текст соответствует строке подстановки, ну, чтобы не писать по два раза: трубой=трубой|Избушка:Труба.

Добавил возможность добавлять в контейнер (содержимое) скрытые объекты, чтобы не заморачиваться с ними при выводе описания.

Если взять за пример тизер "Тестировщиков", то там есть момент, когда нужно вставить батарейки в телефон. При этом использовалась функция простого перемещения батареек из инвентаря в телефон, чтобы потом просто проверять, если ли батарейки в телефоне.

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

Теперь, если поместить батарейки в телефон командой:

…Поместить, 'Батарейки В Телефон Скрыть'

то батарейки при выводе описания телефона в блоке содержимого упоминаться не будут. Однако, функция

…Содержится('Батарейки В Телефон')

всё равно будет возвращать ДА.

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

Допустим есть два текста:

У самого леса из земли торчит низенькая %избушка% с неприлично высокой и толстой %трубой%. Вот где враги жгут ваши брёвна!

Стены %избушки% покрыты мхом и словно растут из земли. Неровный проём двери занавешен грубой рогожей. Из %трубы% идёт густой белый дым.

Чтобы не прописывать к каждому тексту замену шаблонов на ссылки, можно просто добавить две команды:

…ДобавитьШаблонДляТекстов, 'избушка|избушки', '((%|Избушка))'
…ДобавитьШаблонДляТекстов, 'трубой|трубы', '((%|Избушка:Труба))'

Теперь во всех текстах шаблоны (не слова, а именно шаблоны) "%избушка%", "%избушки%", "%трубой%", "%трубы%" будут заменены на ссылки.

Как-то так.

Давненько не делился зажигательными видео, демонстрирующими работу Адского Движка™.

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



Ну и код работы с кодовой панелью на двери приведён на скриншоте.