Форум » » 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 История версий Планы на следующую версию Скачать последнюю версию Документация

Ответов - 191, стр: 1 2 3 4 5 6 7 8 9 10 All

fireton: Ну вот так в фурке сделано. Инклюды - это аналог php-шного require(), а не сишного include. Переделывать я не буду. Я и так не хотел их делать... Текст квеста в фурке сразу целиком загружается в память. соответственно, все инклюды прицепляются в конец при анализе текста уже загруженного.

fireton: FireURQ - 1.9.1 =============== - 0000225: [интерфейс] AV после нажатия на ссылку (fireton) - закрыт. - 0000228: [интерфейс] Картинки никогда не освобождаются из памяти (fireton) - закрыт. - 0000229: [интерфейс] Переменная decor_имя_enabled для кнопок-декораторов (fireton) - закрыт. - 0000230: [интерфейс] Нажатия на декораторы отрабатываются даже если декоратор не виден (fireton) - закрыт. - 0000231: [интерпретатор] Встроенная функция копирования части строки (fireton) - закрыт. - 0000232: [интерпретатор] Сделать одинарные и двойные кавычки равнозначными (fireton) - закрыт. - 0000236: [интерпретатор] Расширение синтаксиса кнопки (fireton) - закрыт. Всё, достойное упоминания, описано в блоге.

Ajenta: Фаер - герой! :)))

Chicago1920: Как считаете, на Win 95-98 бедет работать фурка?

Серый Волк: В рубрику "Вопросы с ifiction.ru": Здравствуйте! Сейчас попробовал превратить небольшой пример программы в qsz в исполняемый файл с расширением eхе. Все получилось, только прога не "видит" собственный скин, лежащий возле игрового файла. Скин работает только в файле qsz. Можно ли этот недочет исправить? (с) Vladimir

Windwalker: Спасибо Фаертону за замечательный плеер.Мне очень нравится. P.S.Уже второй год пишу свою игру на URQ,в ней пока нет сюжета,только движок(боевая система с множеством возможностей),и тот далек от завершения.Но файл игры весит уже 115 Кб. Если не заброшу это дело по каким либо причинам,получится долгострой.

fireton: Серый Волк пишет: Здравствуйте! Сейчас попробовал превратить небольшой пример программы в qsz в исполняемый файл с расширением eхе. Все получилось, только прога не "видит" собственный скин, лежащий возле игрового файла. Скин работает только в файле qsz. Можно ли этот недочет исправить? Я не понял. Он пытается превратить QSZ в EXE и у него не работают скины? Или он пытается положить скин рядом с exe-файлом? Что значит "собственный скин, лежащий возле игрового файла"?

Vladimir: Здравствуйте, Антон. Я запаковал игру вместе со своим скином (свои кнопки и декор-линия) в zip, потом поменял расширение на qsz. При запуске этого файла плеером FireURQ стандартный скин заменяется моим. Попробовал с помощью проги qsz2exe превратить упаковку qsz в exe-файл. После запуска игры, обнаружил, что кнопки и декор-линия в игре стандартные, а мой в самом exe-щнике программа "не видит". И еще. Предложение по Фурке. В некоторых старых адвентюрах на спектруме есть тоже прокрутка текста, но интересней она тем, что сверху есть небольшая картинка и она статична и прокручивается текст только под картинкой. При смене локации картинка меняется. Можно ли такое сделать на Фурке? Определить переменную по типу textalign, например, topmargin (отступ сверху), в которой записывается число строк сверху, которые не должны прокручиваться и текст там не выводится. Да, чуть не забыл. Вставил в прогу для проверки скрипт декоратора (decorscr star "mvr 50, 0, 1000/rot R(-90,90), 1500/rst"). Он у меня не заработал. Работают только отдельные команды для декоратора. ps. Нашел инфу про установление размеров текстового блока, поэтому вопрос о скроллинге под картинкой отпал.

fireton: Vladimir пишет: Я запаковал игру вместе со своим скином (свои кнопки и декор-линия) в zip, потом поменял расширение на qsz. При запуске этого файла плеером FireURQ стандартный скин заменяется моим. Попробовал с помощью проги qsz2exe превратить упаковку qsz в exe-файл. После запуска игры, обнаружил, что кнопки и декор-линия в игре стандартные, а мой в самом exe-щнике программа "не видит". Только что попробовал сделать экзешник из своей демки со скином. Всё отлично работает. Сделайте, пожалуйста минимальный пример (qsz файл), на котором ошибка повторяется, создайте запрос на багтрекере и прикрепите пример туда. Попробуем разобраться.

Vladimir: Здравствуйте, Антон. Разобрался я в своей проблеме. Я упаковывал папку с игрой, поэтому и была ошибка, а нужно было упаковывать сами файлы игры , находящимися внутри папки. Хотя если делать со стандартным скином, то разницы в способе упаковки нет (можно упаковать и папку с игрой)

Vulcano: Давно тут не появлялся, вот вспомнил старый свой проект. Есть идея, может подскажут здесь как ее грамотно осуществить. Собственно вся загвоздка в луте вещей, причем не просто луте, а рандомном. Сделать это не сложно, возникает проблема обработки этих рандомных вещей при их одевании или снятии. Обрабатывать такие манипуляции возможно только с помощью тотального описания всех возможных вариантов лута, чтобы изначально в коде игры присутствовали пары строк для двух состояний одной и той же вещи: Use_Снять_что-то, Use_Надеть_что-то. С кучей if'ов внутри для проверки, а что именно за характеристики будут добавляться персонажу, ну и их дальнейший расчет. Для примера я взял 90 предметов префикс - название предмета, плюс характеристику грейда: белый, зеленый, синий. Префиксов - 6, названий предметов - 5. Суть вопроса, как сделать работу со встроенным инвентарем менее затрудненной? Уже пробовал заменить название предмета на переменную, но так не получается, она не обрабатывается в названии локации как переменная, даже числовая. Стряпать отдельный текстовый инвентарь - можно, но хочется воспользоваться встроенным. Есть идеи? PS а где можно прочитать про нововведения с примерами, блог недоступен(((

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

Серый Волк: Vulcano пишет: PS а где можно прочитать про нововведения с примерами В заглавном посте темы нижняя ссылка "Документация".

Vulcano: Лучше делать менюшкой или отдельным интерфейсом Что под этим подразумевается? Если можно с простенькими примерами, чтобы суть словить. Менюшки вроде бы только еще назначены для Фурки в следующем обновлении, или я что-то упустил? В заглавном посте темы нижняя ссылка "Документация" Там очень неудобно смотреть последние нововведения и мне показалось, что там описано не все. Тем более примеров всего три - больших, но поведения некоторых команд, особенно новых, нет: расширение синтаксиса кнопки, пример включения в квест инклюда и т.д. А в блоге все это видимо было, жаль не застал.

vito: Vulcano пишет: Суть вопроса, как сделать работу со встроенным инвентарем менее затрудненной? Постараюсь ответить на вопрос так, как его поняла. Первое, что я бы сделала - систематизировала бы все-все возможные предметы по их характеристикам и возможным префиксам. Да, это будет самая муторная часть работы, но без нее ИМХО не обойтись. Пусть имеется n значений для первого модификатора предметов и m - для второго (в принципе можно масштабировать для любого количества модификаторов). Пусть они меняют следующие параметры игрока: силу, ловкость, ум. Пусть их можно надевать на голову, туловище или ноги. Тогда необходимо будет создать n*m наборов параметров и меток следующего вида: [pre2]idisp_Предмет_1_1="Деревянный шлем" ; Именно под таким названием данный предмет теперь будет отображаться в инвентаре Предмет_1_1_сила=0 Предмет_1_1_ловкость=2 Предмет_1_1_ум=1 Предмет_1_1_голова=1 ; Шлем надеваем на голову Предмет_1_1_туловище=0 Предмет_1_1_ноги=0 Предмет_1_1_надет=0 ; Флаг "надет/снят" use_Предмет_1_1_Снять_hide=1-#Предмет_1_1_надет$ ; Если предмет не надет, действие по его снятию будет скрыто use_Предмет_1_1_Надеть_hide=#Предмет_1_1_надет$ ; Если предмет уже надет, действие по его надеванию будет скрыто ; Аналогично для объектов Предмет_2_1, Предмет_1_2,..., вплоть до Предмет_n_m ; Далее, где-то определяем набор параметров, показывающих, надето ли что-то на голову, туловище или ноги игрока Игрок_голова=0 Игрок_туловище=0 Игрок_ноги=0 ; Мы можем осмотреть, надеть или снять шлем :use_Предмет_1_1 pln Обычный шлем из твердых пород дерева. pln end :use_Предмет_1_1_Надеть ; Обращение к общей процедуре надевания proc Н(1, 1) end :use_Предмет_1_1_Снять ; Обращение к общей процедуре снятия proc Сн(1, 1) end ; Общие процедуры - определяются только один раз ; Общая процедура надевания :Н ; Сначала проверяем, на какую часть тела надевается предмет if Предмет_#Н_1$_#Н_2$_голова=1 then goto Н_голова if Предмет_#Н_1$_#Н_2$_туловище=1 then goto Н_туловище if Предмет_#Н_1$_#Н_2$_ноги=1 then goto Н_ноги :Н_голова ; Проверяем, надето ли что-то уже у игрока на голове if Игрок_голова=0 then Игрок_голова=1 & proc Н_успех else pln Сначала необходимо снять имеющийся головной убор. end :Н_туловище ; Проверяем, надето ли что-то уже у игрока на туловище if Игрок_туловище=0 then Игрок_туловище=1 & proc Н_успех else pln Сначала необходимо снять имеющуюся одежду. end :Н_ноги ; Проверяем, надето ли что-то уже у игрока на туловище if Игрок_ноги=0 then Игрок_ноги=1 & proc Н_успех else pln Сначала необходимо снять имеющуюся обувь. end :Н_успех ; Успешное надевание предмета - соответствующее сообщение и смена параметров pln Ты надеваешь #%idisp_Предмет_#Н_1$_#Н_2$$. pln Предмет_#Н_1$_#Н_2$_надет=1 ; Флаг, что все надето use_Предмет_#Н_1$_#Н_2$_Надеть_hide=1 ; Действие по надеванию теряет смысл use_Предмет_#Н_1$_#Н_2$_Снять_hide=0 ; Зато появляется действие по снятию ; Меняем параметры игрока Игрок_сила=Игрок_сила+Предмет_#Н_1$_#Н_2$_сила Игрок_ловкость=Игрок_сила+Предмет_#Н_1$_#Н_2$_ловкость Игрок_ум=Игрок_сила+Предмет_#Н_1$_#Н_2$_ум end ; Общая процедура снятия :Сн ; Сначала проверяем, на какую часть тела надевается предмет if Предмет_#Сн_1$_#Сн_2$_голова=1 then Игрок_голова=0 if Предмет_#Сн_1$_#Сн_2$_туловище=1 then goto Игрок_туловище=0 if Предмет_#Сн_1$_#Сн_2$_ноги=1 then goto Игрок_ноги=0 ; Сообщение pln Ты снимаешь #%idisp_Предмет_#Сн_1$_#Сн_2$$. pln Предмет#Сн_1$_#Сн_2$_надет=0 ; Флаг, что все снято use_Предмет#Сн_1$_#Сн_2$_Надеть_hide=0 ; Отображение действия по надеванию use_Предмет_#Сн_1$_#Сн_2$_Снять_hide=1 ; Скрытие действия по снятию ; Меняем параметры игрока Игрок_сила=Игрок_сила-Предмет_#Сн_1$_#Сн_2$_сила Игрок_ловкость=Игрок_сила+Предмет#Сн_1$_#Сн_2$_ловкость Игрок_ум=Игрок_сила+Предмет_#Сн_1$_#Сн_2$_ум end[/pre2] Пример не отлаживала, так что могут вылезти ошибки

Ajenta: Витана монстр :))) Меня бы на такой пример не хватило, наверное.

apromix: Это наглядный пример "менее затрудненной" работы с инвентарем

Серый Волк: Как долго я ждал случая, чтобы это запостить! :) Картинка, если не ошибаюсь, Saint'а.

vito: apromix пишет: Это наглядный пример "менее затрудненной" работы с инвентарем Согласна, что выглядит все громоздко. Но поймите - если у человека куча предметов с прорвой свойств, влияющих на самые разнообразные характеристики персонажа, если "обрабатывать такие манипуляции возможно только с помощью тотального описания всех возможных вариантов лута", то совсем простого решения у него никак не получится. В моем примере вся работа по обработке снятия/надевания предмета и сопутствующему этим действиям изменению характеристик персонажа сконцентрирована всего в двух общих процедурах. Да, они объемистые (а с учетом конкретных стоящих перед Vulcano задач, возможно, распухнут еще сильнее), но зато их надо прописать всего один раз, а дальше просто "штамповать" однотипные простенькие наборы свойств предметов и вызовы в одну строчку к этим общим процедурам. ИМХО при большом количестве предметов это здорово упрощает и сокращает код (при условии, конечно, что автор потратит время на проработку целостной системы работы с предметами - именно эту часть работы я назвала самой муторной в своем предыдущем посте). И да, я бы с удовольствием ознакомилась с альтернативными предложениями по упрощению работы с инвентарем в рамках поставленных Vulcano граничных условий.

Ajenta: vito пишет: Согласна, что выглядит все громоздко. Но поймите - если у человека куча предметов с прорвой свойств, влияющих на самые разнообразные характеристики персонажа, если "обрабатывать такие манипуляции возможно только с помощью тотального описания всех возможных вариантов лута", то совсем простого решения у него никак не получится. В моем примере вся работа по обработке снятия/надевания предмета и сопутствующему этим действиям изменению характеристик персонажа сконцентрирована всего в двух общих процедурах. Да, они объемистые (а с учетом конкретных стоящих перед Vulcano задач, возможно, распухнут еще сильнее), но зато их надо прописать всего один раз, а дальше просто "штамповать" однотипные простенькие наборы свойств предметов и вызовы в одну строчку к этим общим процедурам. ИМХО при большом количестве предметов это здорово упрощает и сокращает код (при условии, конечно, что автор потратит время на проработку целостной системы работы с предметами - именно эту часть работы я назвала самой муторной в своем предыдущем посте). Нет нет, всё хорошо. Я как раз пишу код обычно ещё "муторней" и "движком" не заморачиваюсь. Разве только там, где если нужно поменять параметр, чтобы не пришлось его искать по коду везде, а он был только в одном месте. С проверками же у меня обычно полный бардак.



полная версия страницы