Forum.iFiction.Ru

Столкнулся с явлением перехода количества в качество: регулярность возникновения некоторых проблем перевела их из категории исключений в категорию "нереализованного общего подхода". Пришлось кое-что переписать, в том числе и модуль контейнеров. И параллельно нашлось, над чем подумать…

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

fireton написал:

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

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

Раз у нас такие лингвистические шутники водятся, то я, пожалуй, переименую константу "ЧЛ" ("ЧисЛо"), обозначающую числовой тип аргумента, в "ЧС".

А между тем работа, хоть и медленно, но идёт.

Кстати, сегодня ввиду плохого самочувствия и настроения пришла мысль, как сделать синтаксис команд Адского движка ещё кошмарнее:

Например, команда добавления действия с объектом:

GS 'УстановитьДействие', <Объект>, <Название пункта меню>, <Иконка>, <Условие>, <Обработчик>, <Модуль>

Её можно записать так (текущий работающий вариант):

GS 'УстановитьДействие', 'Портсигар', 'Осмотреть/Осмотреть портсигар', 'осмотреть', '', '', {
    GS 'ОписаниеНаЭкран', 'Портсигар'
}

а если порядок аргументов забыли (как я сегодня), то можно ведь сделать и так:

GS 'УстановитьДействие', $ПС + '
    Объект: Портсигар
    ПунктМеню: Осмотреть
    Действие: Осмотреть портсигар
    Иконка: осмотреть
    Модуль: "
        GS 'ОписаниеНаЭкран', 'Портсигар'
    "
'

$ПС в данном случае — это просто системный префикс, чтобы отловить такой вот изврат.

Что это добавляет кроме монументальности? Хороший вопрос!.. Наверное, в основном возможность произвольного расположения параметров и пропуска ненужных. Кроме того легче добавлять множество различных параметров, которые вроде как особо не нужны, но если их указать, то в некоторых случаях они могут изрядно сократить код.

Для альтернативно одарённых: советовать мне переходить на INSTEAD не надо.

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

Oreolek написал:

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

Насчёт планшетов и телефонов — резонно.

А зачем вываливать на игрока два экрана текста в самом игровом процессе (т.е. не во вступлении или текстовых вставках, а именно в описании локаций, объектов и т.п.)? Это пагубная привычка.

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

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

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

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

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

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

Да, и поскольку всякие действия, описания, упоминания и т.п. содержат модуль условия их использования, и этот модуль зачастую состоит из одной строчки типа:

{°Результат=IIF(©Параметр='Встать',Использовать,Пропускать)}

то добавил возможность использования сокращённой формы:

{if:©Параметр='Встать'}

Так и короче пишется, и не нужно помнить, какая константа ("Использовать", "Пропускать" и т.п.) для данной конструкции означает использование, а какая — пропуск.

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

Так, у меня на экране может одновременно находится описание нескольких локаций (textflow), а также описания предметов и действий с упоминаниями тех или иных объектов, ссылки на которые автоматически гасятся, если объекты недоступны. Я не припомню, чтобы кто-нибудь говорил про такое в контексте INSTEAD.

Nex написал:

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

В "Квантовом коте" на экране присутствует только результат последнего действия (после нажатия на ссылку) и текущее описание локации (подобный вариант я разбирал тут). Поэтому говорить, что там "давно решили эту проблему", неправильно — там этой проблемы просто не существует. А предложение "можно взять и сделать так же" — это типа как советовать желающему научиться кататься на лыжах сесть на санки. А что? ведь там "уже давно решили проблему" устойчивости…

Nex написал:

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

Вот только от вопроса ты отсёк всё, что не подходило к ответу. В том числе и накопленный контекст. Смотри аналогию с лыжами и санками.

Zeantar написал:

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

Ровно то, что написал в первой же строчке: "Понял, как важно не потерять исходники исходников…" Восстанавливать верхний кусок кода из нижнего в случае утраты исходников исходников будет непросто. Равно как и пытаться понять реализованные алгоритмы по нижнему варианту кода.

P.S. Вообще-то тут не приветствуется стиль общения а-ля чат. И важно не только смотреть на картинки, но и читать, что пишут другие.

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

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

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

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

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

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

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