Forum.iFiction.Ru

Наткнулся на несколько головоломных моментов:

1. Ссылки на некоторые объекты хотелось бы иметь активными всегда, а не только когда объект находится в известных игроку "контейнерах". Известные контейнеры — это содержимое текущей локации и осмотренные игроком объекты в ней. Так, например, упоминание в описании каких-нибудь объектов или персонажей, которых рядом с игроком как бы и нет. В этом случае можно для объекта указать спец. режим обработки ссылок — т.е. ссылка активна всегда, когда объект в доступных контейнерах или когда при нажатии на него формируется меню.

Кстати, совсем забыл про полезную функцию — формирование меню в режиме проверки, т.е. сформированное меню в итоге не вызывается, а возвращается лишь количество пунктов в нём. Это можно использовать.

2. Что делать с ссылками на локации. Сейчас они у меня активны всегда, однако во время игры сразу же наткнулся на проблему "локация в нескольких переходах".
Вариант — активна всегда локация, в которой находится игрок, плюс автору добавляется возможность указывать перечень локаций, откуда будет доступна та или иная локация. А можно и не заморачиваться, а пойти по пункту 1 и локациям добавить автоматическое присвоение признака "ссылки активны всегда" — а уж за наличие пунктов в меню пусть отвечает автор.

P.S. Чтобы никто заново не возбуждался — под автором я всё ещё подразумеваю себя, хоть и говорю отвлечённо.

Фигасе, значки градуса и копирайта?! Как их набирать?

2. Что делать с ссылками на локации.

См. классику INSTEAD.

Вопрос.

Что делать с ссылками на локации.

Ответ.

См. классику INSTEAD.

В классических играх INSTEAD уже давно решили эту проблему. Можно взять того же "Квантового Кота", посмотреть, как это реализовано, и сделать так же.

При чем тут то, что находится на экране? Постановка вопроса такая:

Что делать с ссылками на локации. Сейчас они у меня активны всегда, однако во время игры сразу же наткнулся на проблему "локация в нескольких переходах".
Вариант — активна всегда локация, в которой находится игрок, плюс автору добавляется возможность указывать перечень локаций, откуда будет доступна та или иная локация. А можно и не заморачиваться, а пойти по пункту 1 и локациям добавить автоматическое присвоение признака "ссылки активны всегда" — а уж за наличие пунктов в меню пусть отвечает автор.

Вот на это я и дал ответ. То, что ты там подразумевал не то, о чем в итоге написал - твои проблемы.

Это был не совет, а ответ на вопрос. То, что мой ответ показался тебе неприемлемым, не моя забота.

Ой, ну хватит уже меня благодарить.

Обычная конструкция. Что ты хотел сказать этим?

Приветствуется твой монолог, хочешь сказать?
Будь проще.

А между тем на Asus EeePC 901 первоапрельский трейлер заметно притормаживает. Замеры времени выполнения некоторых участков кода (через MSECSCOUNT) выявили кое-какие любопытные участки с серьёзным ухудшением времени обработки. Есть над чем подумать.

Хм… Наткнулся на некоторую проблему (не знаю пока, насколько серьёзную) с реализацией чекпоинтов. А именно — момент сохранения чекпоинта.

Как в своё время отмечал Байт, нужно помнить, что при сохранении состояния игры командой SAVEGAME сохраняется не точка кода, а лишь, грубо говоря, состояние переменных и содержимое экрана. То есть нельзя рассчитывать на то, что при восстановлении код продолжит выполнятся с того места, где вы вызвали SAVEGAME — у вас просто нарисуется экран и восстановятся переменные.

Таким образом вызывать SAVEGAME нужно в том месте кода, после которого гарантировано ничего выполняться уже не будет. А у меня с этим очень непросто, потому как игровой код (откуда и вызывается команда создания точки сохранения) обрамлён служебным кодом фреймворка.

1. Начало служебной функции
2. Заполнение вспомогательной информации
3. Запуск игрового кода
4. Вызов SAVEGAME
5. Окончание игрового кода
6. Чистка вспомогательной информации
7. Завершение служебной функции

И если потом загрузить такой чекпоинт (командой OPENGAME), то в нём будет присутствовать всякий мусор, поскольку чистки вспомогательной информации (п.6) и корректного завершения служебной функции (п.7) произведено не было и не будет, потому как у нас восстановится состояние игры в пункте 4 и никаких дополнительных действий произведено не будет.

Предусмотреть состав вспомогательной информации, чтобы как-то почистить её в локации-обработчике загрузки состояния игры ($ONGLOAD), невозможно. Так что есть над чем подумать.

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

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

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

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

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

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

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

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

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

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

Как-то так…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как-то так…

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