Форум » » FireURQ (продолжение) » Ответить
FireURQ (продолжение)
fireton: FireURQ - это GUI-based интерпретатор URQ. Блог разработчика Текущая версия:2.2.1 Основные возможности: Реализация URQL, близкая к классической URQ_DOS Расширенный синтаксис, позволяющий, например, передавать параметры в локацию-подпрограмму (отличия синтаксиса подробно описаны в файле справки). Возможность вставки изображения (или его части) в текст. Декораторы: фрагменты текста или изображения (включая анимированные GIF), которые можно поместить в любое место на экране и по-разному ими манипулировать. Пользовательские шрифты. Поддержка архивного формата квестов .QSZ, при использовании которого ресурсы можно поместить в файл квеста Расширенная поддержка музыки и звука. Поддерживаются форматы WAV, AIFF, MP3, MP2, MP1, OGG, а также трекерные форматы музыки: XM, IT, S3M, MOD, MTM, UMX. Кроме того, воспроизводится и MIDI-музыка (файлы MID). Также поддерживается формат MO3 (трекерная музыка с OGG-упакованными семплами). Реализован fadein и fadeout для музыки. Удобная озвучка локаций. Возможность создания exe-файла игры. Удобный режим отладки, в котором легко обнаружить ошибку и модифицировать квест без перезапуска проигрывателя. Многое другое (для справки смотрите прилагающийся файл FireURQ.html). Баги и пожелания направляйте в FireURQ Bug Tracker. Демонстрации возможностей: 1) http://ifwiki.ru/files/Fireurq_demo.qsz 2) http://ifwiki.ru/files/Decodemo.qsz 3) http://ifwiki.ru/files/Skindemo.qsz История версий Планы на следующую версию Скачать последнюю версию Документация
Steks: Очень ограничена настройка у скинов. Например я хочу две кнопки вывести сверху, над текстом, еще одну посередине внизу, а остальные в ряд по горизонтали. Не сочтите эти "хотелки" через чур завышенными, но во многие игры это могло бы привнести удобство, если например хочется сделать кнопку периодически доступную игроку, но логически отделить ее от инвентаря. Было бы уместно проверять в Common необходимость вывода кнопки, а затем просто ее вывод, а шаблон вывода уже определил бы, что вывести ее необходимо сверху от текста. Например: игра про сыщика. При небольших верных догадках игрока накапливаются очки, когда их накапливается пять, то открывается доступ к "блестящей идее", ее можно использовать для того чтобы сыщик вдруг по мельчайшим штрихам вдруг выдал интересную мысль - последовательность действий преступника, удивив этим самым своих помощников и наблюдателей, для ускорения процесса дела.
Korwin: Честно говоря, я считаю, что качество текстовой игры в минимальной степени зависит от расположения кнопок. Вывод дополнительной кнопки можно сделать и современными средствами, без дополнений в платформу. Где конкретно будет располагаться данная кнопка - не так важно, более того, логичнее ее делать там, где игрок привык искать новые кнопки - то есть внизу. Я пробовал делать квесты с появлением новых возможностей в определенных местах в инвентаре. Получались весьма "зубодробительные" вещи - в которых пользователь вставал в тупик. Не потому, что он тупой, а потому что я сделал нестандартный игровой интерфейс. Все вышесказанное - как всегда - мое скромное мнение, не претендующее на то, чтобы быть единственной истиной.
Windwalker: Есть пара вопросов по FireURQ. 1.При переходах по goto не обновляется переменная current_loc,это можно изменить?(поведение фурки в этом случае) 2.Почему-то при сохранении save current_loc и последующей загрузке локации не появляются ни текст ни кнопки,хотя инвентарь сохраняется,это как исправить?(Сохранение написал через предмет инвентяря,только для отладки игры пока ) Пример кода :use_режим отладки_сохраниться save current_loc end P.S.Снимаю вопрос,уже ответили в другой теме
Eddie: Кто подскажет, как можно на определенной локации полностью закрыть доступ к инвентарю? При это не допускается удалять предметы, либо прятать действия, применяемые к ним, параметром _hide=1. Требуется просто взять и закрыть весь инвентарь. А потом снова его открыть...
vito: Eddie пишет: При это не допускается удалять предметы, либо прятать действия, применяемые к ним, параметром _hide=1. А можно узнать, почему не допускается?
Eddie: Можно узнать. Локация будет вызываться несколько раз за игру. В этой локации у игрока не должно быть доступа к инвентарю. При этом у игрока может быть абсолютно разный набор предметов (квест не совсем линейный). Соответственно, неизвестно, какие именно предметы нужно будет удалять и потом восстанавливать в инвентаре. Поэтому вариант с удалением предметов не проканает.
vito: Все равно не понимаю. Что, мы в конкретный момент времени не знаем, какие предметы должны быть в инвентаре? И нельзя сделать для всех предметов в игре специальный флаг, в инвентаре они должны быть или нет, и в зависимости от этого добавлять их в инвентарь при необходимости? Вообще, наверно, инвентарь можно отрубать, играя со скинами, но тут я не сильна. Либо еще можно постоянно выводить декоратор в определенный участок экрана, при клике на котором будет отображаться инвентарь (реализованный альтернативными средствами), а основной инвентарь отрубить.
Eddie: vito пишет: Что, мы в конкретный момент времени не знаем, какие предметы должны быть в инвентаре? Совершенно верно. В конкретный момент мы не знаем, какие именно предметы соберет игрок. Это зависит от его блуждания по квесту. В этом-то и есть основная загвоздка. Если бы квест был линеен - проблемы бы не было совсем. А так... vito пишет: Либо еще можно постоянно выводить декоратор в определенный участок экрана, при клике на котором будет отображаться инвентарь (реализованный альтернативными средствами), а основной инвентарь отрубить. С реализацией инвентаря через декоратор чета не понял. Как это возможно?
noname: Eddie пишет: Совершенно верно. В конкретный момент мы не знаем, какие именно предметы соберет игрок. 1. vito намекает, что можно взять, да и проверить(программно), какие предметы игрок уже взял, а какие- нет. её идею с флагами я понял так: для каждого предмета(специально для реализации твоей задумки) заводим флаг: был ли в инвентаре такой-то предмет перед заходом в твою особую комнату. перед заходом в комнату, для каждого предмета проверяем, есть ли он в инвентаре и выставляем нужные флаги, а предметы из инвентаря все выкидываем. после выхода из комнаты, проверяем флаги и соответствующие предметы ложим в инвентарь. 2. альтернативная реализация инвентаря это так: делаешь кнопку или декоратор, по нажатию на которую ты сам выводишь список собранных предметов. в этом случае ты совсем не используешь в программе команд работы с инвентарём, а делаешь всё сам, по-своему. 3. можно напрячь Фаертона и выпросить у него ввести функцию отключения инвентаря. входим в особую комнату- отключаем инвентарь. все предметы остаются на месте. при необходимости, программно можно в инвентарь что-то добавлять или убирать, в-общем, всё работает так же, но только игроку инвентарь не доступен. при выходе из комнаты включаем инвентарь обратно. -- лично мне наиболее нравится первый способ, как относительно простой и универсальный одновременно: так ты сможешь отключать не весь инвентарь а, например, заблокировать все вещи, кроме некоторых, которые использовать можно. кроме того, если поднапрячься, и завести больше флагов, то можно сделать ещё лучше: не удалять предметы, а блокировать только те действия, которые не возможны. т е, например, оставить возможность игроку осматривать вещи. в этом случае делается всё то же самое, только флаги отвечают не за предметы, а за действия, которые можно совершать с предметами. и, соответственно, при входе в комнату, не удаляем предмет, а блокируем соотв действия. // реализация этого требует некоторого опыта в программировании. с другой стороны, если универсальность не нужна, зато нужно как можно проще, то да- тогда лучше способ N3.
Eddie: Угу, noname. Вариант №1 один я тоже рассматривал, причем именно с блокированием действий, а не выкидыванием предметов из инвентаря. Но флагов уж больно много получается. Муторный немного алгоритм выходит... Идеален был бы вариант №3. Но вот будет ли Фаертон вносить такое обновление в фурку...
Korwin: Eddie пишет: Идеален был бы вариант №3. Но вот будет ли Фаертон вносить такое обновление в фурку... Я что-то не пойму Ваших страданий? :start pln Проверка инвентаря. Вы взяли меч и щит. inv+ Меч inv+ Щит btn dark,Войти в пещеру end :dark if Меч then dark_Меч=1 & inv- Меч if Щит then dark_Щит=1 & inv- Щит pln Вы в пещере. Так темно, что не видно, есть ли у Вас что-то! btn light,Выйти из пещеры. end :light pln Вы снаружи. Все видно. btn dark,Войти в пещеру end :common if dark_Меч=1 then inv+ Меч & dark_Меч=0 if dark_Щит=1 then inv+ Щит & dark_Щит=0 end "Муторный алгоритм" это всего то две строчки кода на каждый предмет - одна на входе в локацию, а вторая на выходе из нее. Строчки размножаются копипастом. Предметы прописываются ручками. В чем проблема-то?
Eddie: Блин, да не проблема это, Корв. Я так и реализовал алгоритм. Просто искал возможность сделать все немного проще, без присвоения флагов наличия предметов и выкидывания их из инвентаря с последующим восстановлением. Все-таки это увеличило исходный код на пару сотен строк. В любом случае, спасибо за помощь vito, noname, Korwin. P.S. А вот команды типа "инвентарь_hide=1" фурке все-таки не достает.
noname: Eddie пишет: Все-таки это увеличило исходный код на пару сотен строк. если такая особая локация встречается в нескольких местах, как у тебя, то лучше убирание и добавление предметов обратно сделать подпрограммами. тогда получится примерно две строки кода на предмет + ещё немножко строк.
Eddie: noname пишет: если такая особая локация встречается в нескольких местах, как у тебя, то лучше убирание и добавление предметов обратно сделать подпрограммами. тогда получится примерно две строки кода на предмет + ещё немножко строк. Согласен полностью. Я через proc организовал алгоритм. Насчет пары сотен строк я погорячился, конечно. По три строки на предмет вышло. (присвоил флажок, восстановил предмет в инвентаре по наличию флажка, обнулил флажок).
noname: Eddie пишет: Согласен полностью. Я через proc организовал алгоритм. Насчет пары сотен строк я погорячился, конечно. По три строки на предмет вышло. (присвоил флажок, восстановил предмет в инвентаре по наличию флажка, обнулил флажок). при таком алгоритме можно не обнулять флаг после выхода из комнаты, а при присвоении флажка, присваивать тем предметам, которых нет- ноль, а тем предметам, которые есть- единицу. предыдущие значения флажков тогда будут не важны, и можно будет не опасаться, что где-то случайно поднятый флаг повлияет на результат.
fireton: FireURQ - 1.6.2 =============== - 0000194: [интерпретатор] В текстовом декораторе нельзя указать шрифт без указания цвета - 0000191: [интерпретатор] Невозможно ввести пробел в input
Vulcano: Внесу и свою копейку. При написании кода тоже столкнулся с некоторыми трудностями. Возможно уже что-то и писали из этого, однако в логах разработчика ничего не нашел 1. Злосчастный оператор if...then, почему бы не сделать срабатывание тела оператора не в одной строчке а во всех, пока не встречается else или какой-то знак окончания тела. Иногда очень громоздко получается прописывать все действия в одну строчку через &. Конструкция могла бы выглядеть вот так: if x>1 then [ <действие1> ... <действиеN> ] Я понимаю, что сейчас пишу нечто очень банальное, поскольку во многих языках программирования сделано нечто подобное с разными скобочками, словами и т.д. Но это же просто удобно. 2. Как вы относитесь к тому, чтобы написать некий простенький статус бар с обычными, почти для всех игр, элементами: Полоска здоровья/маны (или численное представление; на выбор), значения нескольких переменных, вроде денег, патронов, и т.д. Такие переменные есть в 90% игр и смотреть свое здоровье в инвентаре и прочие названные статусные переменные, ну как-то странно. Я знаю, что можно сделать окно статуса, но постоянно вызывать его - очень надоедает. А так глянул на строчку вверху квеста и все стало понятно. Конечно же для предметов однозначно подходит инвентарь, да и для характеристик в виде статусного окна. А вот остальное... Заранее спасибо за возможность высказать мнение.
fireton: 1. Исторически сложилось. Блоков кода нет. Можно делать некое подобие через знак подчёркивания в начале строки. Делать блоки кода - значит переделывать весь парсер и интерпретатор, а мне влом. 2. Это всё можно делать декораторами. Числовые значения - текстовыми, полосочки-"градусники" - типа RECT.
Korwin: fireton пишет: 1. Исторически сложилось. Блоков кода нет. Можно делать некое подобие через знак подчёркивания в начале строки. Делать блоки кода - значит переделывать весь парсер и интерпретатор, а мне влом. Более того, подобная переделка интерпретатора может уничтожить совместимость со всеми написанными ранее играми! Не надо, а?
fireton: FireURQ - 1.7 ============= - 0000195: [интерпретатор] Выпадающие меню - 0000196: [интерфейс] Не должны работать ссылки при input и anykey В фурке появилась возможность создания выпадающих меню в ответ на нажатие на ссылку или на кнопку. Формат вызова такой: [pre2]btn %menu, По этой кнопке будет меню ... :menu btn someloc, Первый пункт меню btn anotherloc, Второй пункт меню btn yetonemoreloc, Третий пункт меню end[/pre2] Другими словами, все кнопки в меню-локации превращаются в пункты меню. Причём можно делать меню вложенными. В меню-локациях не разрешается использовать практически ничего, кроме конструкций if..then..else, goto, proc и работы с переменными, которые можно назначать и проверять. Ну и btn, понятное дело, можно использовать. Все фантомные btn (ведущие на несуществующую локацию) становятся неактивными пунктами меню. Если в качестве имени кнопки использовать "-" (дефис), то в меню будет вставлена полоска-разделитель. Переменные для оформления меню (их тоже можно указывать прямо в меню-локации): menu_textfont - шрифт меню menu_bgcolor - цвет фона (можно делать и полупрозрачным) menu_bordercolor - цвет рамки menu_textcolor - цвет пунктов меню menu_hindent - отбивка по горизонтали menu_vindent - отбивка по вертикали menu_selectioncolor - цвет фона выбранного элемента menu_seltextcolor - цвет шрифта выбранного элемента menu_disabledcolor - цвет шрифта неактивного элемента Более наглядно значения этих переменных можно посмотреть в руководстве по скинам, там даже картинка есть, поясняющая каждую из переменных:
полная версия страницы