Форум » » Стандарт URQL » Ответить

Стандарт URQL

Дженни: Предлагаю здесь обсуждать уже сложившийся стандарт языка URQL и вносить свои предложения по его оптимизации. Для обсуждения можно использовать описание WalkyTalky-Korwin. Находится на http://tightbow.narod.ru/URQL_dos.rar

Ответов - 79, стр: 1 2 3 4 All

Агент 007: Заметил кое что по учебнику: >и при этом существует проблема их совместимости, то есть, квесты, понимаемые досуркой, могут не работать на Win URQ. Правда, сама досурка, без проблем понимает все квесты написанные для ее Windows-сестрички Не скажите! Досурка не может обработать некоторых объединённые функции винурки. Это наглядно можно увидеть в моём новом ещё не доделанном квесте ПБ. Кого это волнует могу предложить куски кода из этого квеста. >А если Вы хотите писать квесты легко и просто - милости прошу к нам, на WWW.URQ.RU и используйте... По-моему этот сайт закрылся. Дженни пишет: quote:Предлагаю здесь обсуждать уже сложившийся стандарт языка URQL и вносить свои предложения по его оптимизации. Что-ты имеешь в виду под словом стандарт? Тоесть напиши что нибудь стандартное в плане языка URQL. Предположим когда я пишу квест я отделяю локи между собой, можно ли это принять как стандарт? пример btn лока2,Название кнопки end :лока2 pln Текст локи 2... А учебник сам по себе хороший.

CANKILLER: (сообщение удалено администратором)

AlSid: quote:(сообщение удалено администратором) Вот так всегда...


Larry: Вот банкоубиватель сначала сам матерится на форуме, а потом вызывает агентов на дуели, ибо они мол не следят за базааром.

CANKILLER: Ларри Ларри...

Larry: Шо? Дуэль нумер пять?))

Korwin: 1. Предлагаю эту тему не загрязнять дуэлями, а все дуэли собрать в одной ветке 2. Формат xbtn, насколько мне известно не утвержден окончательно - неясно, что делать в случае: xbtn to_loc,pln Написать, что-то там, о земле и небе&inv+ 1,Звездолет&pln У тебя есть магическая метла!,Купить звездолет - нет возможности определить, где кончился xbtn и начался следующий оператор! Akela предложил xbtn 1,{inv+ 5,монет and x++},Взять! Это решает проблему, но выглядит не по-урковски! Вопрос: как лучше?

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

сэр Ольгерд: Ребят, введите матрицу плиз! )

Goraph: сэр Ольгерд пишет: Ребят, введите матрицу плиз! ) Не понял вопроса :) Если тебе нужны массивы то они уже в принципе есть.. достойный (ладно, не достойный, но рабочий) аналог по крайней мере. А именно: i=7 j=12 ;вводим array#i$#j$=157 ;и выводим :) pln #array#i$#j$$

сэр Ольгерд: Goraph Хм, а где описана команда "array"? первый раз вижу..

Акела: да какая же это команда. это переменную просто Гор так назвал.

сэр Ольгерд: Ну, такой уровень не достаточен... Даже если в процедуры это загнать, получится нетехноолгично...

Акела: напиши как должно быть. добавлю в акурку.

CANKILLER: Вроде была в WinURQL команда, отсчитывающая время после запуска квеста, не помню как называлась... А в досе есть такая? или в акурке

Евгений: А зачем? В начале квеста сохраняешь time в переменную и когда нужно отнимаешь её от текущего time. сэр Ольгерд пишет: Ну, такой уровень не достаточен... Даже если в процедуры это загнать, получится нетехноолгично... В смысле? На данном этапе нет абсолютно никакой разницы будешь ты использовать массивы или переменные. "Процедуры" так и так придётся писать свои, тут от нового типа данных ничего не поменяется. А "нетехнологично" и "urq" вообще близкие понятия ;) И вообще напиши, что ты хотел бы сделать с массивами?

CANKILLER: Евгений пишет: А зачем? В начале квеста сохраняешь time в переменную и когда нужно отнимаешь её от текущего time. Как пел В.С. Высоцкий, "мы снова говорим на разных языках..."

Дженни: Я заметила странный эффект в досурке (которая dos-32) if then else - работает IF THEN ELSE - не работает ELSE!

сэр Ольгерд: Ребят, расскажите, что за Акурка и будет ли она совместима с досуркой. Сто я хотел насчет массивов.. Например, я хочу создать более менее нормальный движок для конкретной игры. Я рандомно генерируюю некоторые параметры, которые должны хранится в массиве. Там могут бытть числовые переменные, вроде количества комнат, так и текстовые, вроде названия локации. ТО есть в моем представлении должна быть болшущая матирца с кучей столбцов и строк, откуда по ходу игры можно было бы удобно выдергивать нужную информацию (это уже можно отдать на откуп процедурам). зы: Когда будет приличный дизайн сайта?

Дженни: http://tightbow.narod.ru/URQL_dos.rar - Ольгерд, здесь лежит Описание URQL, там кое-что есть о массивах. Вообще, я в массивах не спец, но по логике, на урке можно организовать как числовые, так и текстовые массивы неограниченной размерности, например: mx=3; Размер массива по x my=4; Размер массива по y mz=5; Размер массива по z x=0 y=1 z=1 :loop x=x+1 if x>mx then x=0 & y=y+1 if y>my then y=1 & z=z+1 if z>mz then goto next a_#x$_#y$_#z$=rnd100 ;Заполняем массив размером 3х4х5 случайными значениями от 1 до 100 goto loop :next x=rnd3 y=rnd4 z=rnd5 pln Значение a_#x$_#y$_#z$=#a_#x$_#y$_#z$$ btn next,Еще одно значение? btn ex,Хватит end :ex end

Victor: По поводу массива и матрицы есть пример: Сапер.

Korwin: Виктор, может быть ты смог бы написать кое-какие ограничения стандарта URQL? Например: 1.имя_метки (какие символы допустимы, какая длина, могут ли стоять пробелы после имени метки?) 2. С какой точностью вычислятся выражения (до какого знака после запятой?) 3. Допустимые имена переменных? Можно ли употреблять пробел в имени переменной, до и после нее? 4. Можно ли после if условие then оператор&оператор else оператор&оператор вставить другой оператор или обязательно должен быть конец строки? 5. Допустимые символы в строковой переменной? (Экспериментально доказано, что нельзя употреблять '&' - так как instr var=abra&kadabra считывает только строку abra.) А какие еще нельзя?

ding: По поводу строковых переменных. Тут я как-то наткнулся на отсутствие возможности их сравнения иначе чем через "==". Пришлось как в известном мне анекдоте "вырезать гланды через задницу"... Вот если-б было что-нибудь типа "<>", или "not" тогда бы да ...

Saruman: Хотел в связи с появлением Милены 2 создать новую тему - ан, вспомнил, что где-то что-то такое видел... В общем предлагаю стандартные операторы описывать здесь. И нестандартные обсуждать тоже.

Ajenta: Так, всем привет, а скажите мне - как можно лучше организовать рассчёт случайного числа, с примером плизз. Я пока только начинаю игры писать и с языком не сильно знакома, а учебник чё-то не находится никак

fireton: Из канонического описания языка: Rnd[x] - системная переменная (только для чтения) которая при пустом значении x хранит в себе случайное значение от 0 до 1, включая 1, а при целом x (к примеру, X=6) выдает выдает целые значения (от 1 до 6 включительно в нашем случае). Т.е. можно написать [pre]число = RND[/pre] если нужно число от 0 до 1 и [pre]число = RND10[/pre] если нужно число от 1 до 10. А ты правда девушка или просто притворяешься? Мы тут женским вниманием не избалованы. :) По-любому, велкам. :)

Ajenta: Правда девушка А ещё интересно, вот объясните чем собственно qsp от urq отличается? Насколько я понимаю для обоих квесты можно ваять в тулзе "смсквест". Или я что-то путаю?

fireton: А ещё интересно, вот объясните чем собственно qsp от urq отличается? Насколько я понимаю для обоих квесты можно ваять в тулзе "смсквест". Или я что-то путаю? Пока тебя тут не распяли за вопрос, я тебе отвечу. Теоретически - можно, т.к. для QSP есть тулза для конвертации игры из текстового файла. Но смсквест - все-таки для урки. QSP и URQ отличаются тем, что это разные языки программирования. :) Хоть и предназначены для одного и того же. QSP правильнее, логичнее, лучше поддерживается и документирована. URQ веселее, безбашенней и непредсказуемей. :) Выбирай, что тебе больше подходит.

NewMan: Это разные вещи, разные платформы... Рекомендую qsp.

Ajenta: Хммм, мне бы тогда книжечки по обоим форматам, можно? Ссылки там, где взять и т. д. Спасибо заранее.

NewMan: QSP - http://qsp.org.ru Здесь лежит справка: http://qsp.org.ru/files/index.php?subcat=5

fireton: По QSP еще есть уроки на вики. А по URQ - вот: http://tightbow.narod.ru/URQL_dos.rar

Korwin: А тут http://urq.plut.info/soft - все лучшие интерпретаторы URQ и помощь по АкURQ Ajenta пишет: А ещё интересно, вот объясните чем собственно qsp от urq отличается? Насколько я понимаю для обоих квесты можно ваять в тулзе "смсквест". Или я что-то путаю? Лучше все-таки для QSP использовать его "родные" инструменты QGen или QSpell или Блокнот в паре с txt2gam. А SMSQ придется настраивать под выделение операторов QSP - зачем оно надо? Ближайший конкурс на URQ - ЗОКА 2008. Ближайший на QSP - будет весной 2009. Можно еще на КРИЛ 2008 принять участие если поторопиться. А вообще-то все это оффтопик и к стандарту URQL отношения не имеет

Ajenta: Спасибо большое Значит я всё-таки на URQ до сих пор писала. Успокоили :) А на конкурсы посмотрим, пока надо хоть парочку игрушек доделать, кстати, у выше объявленных конкурсов сроки где можно посмотреть? Сорри за офтопик. И непосредственно к стандарту. Мне вот оченно нехватило вывода строки с конкретной позицию экрана. Можно это как-то средствами языка не так криво сделать как я это делала? pl <куча пробелов> <Название игры> Хочется чтобы название всегда было посередине экрана, а не получается. Или я опять просто чего-то не знаю. Подскажите, пожалуйста.

noname: на http://ifiction.ru/ увидишь тему: Обсуждение правил КРИЛ 2008 впрочем, читать её незачем, главное знать, что: последний срок приёма работ 30-го ноября а на чём ты пишешь? pl- вроде бы с QSP, тогда лучше спросить на их форуме

noname: и ещё о сроках конкурсов: 30-го ноября конец приёма работ на КРИЛ-2008 месяц можно передохнуть 30-го апреля конец приёма работ на QSP-Compo 2009 (4-ре месяца- идеальный для меня срок создания квеста средних размеров) идеально было бы, если б до конца августа провели ЛОКу-2009 а до конца декабря КРИЛ-2009 ну, и ещё неплохо было бы каких-нить конкурсов мини-игр провести между этими, основными- штоп было где показать миниатюрные наработки. впрочем, обсуждать распорядок конкурсов лучше в отдельной теме

Ajenta: Пишу на урке в смсквесте. Гммм. Так есть там какое-нибудь выравнивание посередине страницы?. Исправляю pln <куча пробелов> <Название игры> За инфу о конкурсах спасибо.

noname: нету там выравнивания, насколько я знаю. я пишу в блокноте и, ориентируясь по координатам курсора в строке состояния ставлю свою <кучу пробелов>. про СМСквест ничего сказать не могу- привык к блокноту. кста, урки тоже бывают разные. я предпочитаю ДосУрку, а ещё есть АкУрки всякие, но это уже дело вкуса.

Григорий: noname пишет: ну, и ещё неплохо было бы каких-нить конкурсов мини-игр провести между этими, основными- штоп было где показать миниатюрные наработки. Даже у буржуев нету стока конкурсов сколько у нас. Кроме того размер игр на конкурсах "больших" игр и мини-игр чаще всего не отличается.

Korwin: На Акурке можно выравнивание сделать с использованием html. Пример - в "Джинне из машины". instr name=Гений из машины Style_BackColor=0 html true /* хтмл режим включается и выключается с помощью html true и html false */ <html> <body bgcolor="black"> <center> <hr> <font size=6 color="yellow"> #name$ <hr> </center> <div align="center"><img src="#quest_path$/gexm.jpg" class="foto" alt="ИНТРО"></div> <br> <p align="right"> <font size=4 color="orange"> автор идеи и текста Korwin <br> автор картинки - заставки Евгений Бычков ака Евг </p> </body> </html> end

uux: noname пишет: ну, и ещё неплохо было бы каких-нить конкурсов мини-игр провести между этими, основными- штоп было где показать миниатюрные наработки. Коли не помру - будет конкурс мини-игр. Как обычно - с дедлайном в конце июня - начале июля. Григорий пишет: Кроме того размер игр на конкурсах "больших" игр и мини-игр чаще всего не отличается. Это - художественное преувеличение;). "Станенко", "Память" и "Возрождение" для конкурса мини-игр все-таки великоваты...

Nex: Ближайший на QSP - будет весной 2009. Korwin, QSP-Compo уже начался.

Григорий: uux пишет: Это - художественное преувеличение;). "Станенко", "Память" и "Возрождение" для конкурса мини-игр все-таки великоваты... ну со "станенко" я пусть соглашусь для разнообразия но у "ли гуана" время геймплея было явно больше чем у "памяти" и "возрождения"

uux: Григорий пишет: но у "ли гуана" время геймплея было явно больше чем у "памяти" и "возрождения" В "Память" ты, насколько мне не изменяет память;), вообще не играл. Там один лабиринт по длине больше, чем весь "Ли Гуан", по-моему;). И если в "Возрождении" посчитать клики, необходимые для перемещения по лабиринтам и борьбы с гоблинами, тоже получится намного больше 80-ти, предусмотренных регламентом СМИИ (цифра, конечно, условная, но все же...)

Korwin: Григорий пишет: но у "ли гуана" время геймплея было явно больше чем у "памяти" и "возрождения" Григорий играл в Ли Гуана!!! Я счастлив!!! Лог игры прошу чуть ли не на коленях.

Григорий: Korwin пишет: Григорий играл в Ли Гуана!!! Я счастлив!!! Лог игры прошу чуть ли не на коленях. к сожалению лог яйца выеденного не стоит :( в ли гуана я к сожалению играл с солюшеном в виде Евга который мне присоветовал поиграть в нее ради концовки, чтоб ее извратить для дуэльной игры, что я сравнительно успешно реазиловал :( и вообще после таких комментов у меня возникают сомнения что ты играл в Семирамиду :)) В Память я действительно вообще не играл, насчет Возрождения я имею серьезные сомнения в плане минимального продолжения, мне кажется (конечно я могу быть не прав), что оно в разы короче 80 кликов. Зато за 80 кликов явно проходятся Сыны Свободы. Кстати, uux, а ты что, прошел Семирамиду за 80 кликов?

uux: Григорий пишет: Кстати, uux, а ты что, прошел Семирамиду за 80 кликов? Не считал - настолько было увлекательно;).

Korwin: Григорий пишет: Кстати, uux, а ты что, прошел Семирамиду за 80 кликов? Я считал - проходится.

qwerty: Дженни пишет: Предлагаю здесь обсуждать уже сложившийся стандарт языка URQL и вносить свои предложения по его оптимизации. ... Korwin пишет:...Формат xbtn, насколько мне известно не утвержден окончательно - неясно, что делать в случае: xbtn to_loc,pln Написать, что-то там, о земле и небе&inv+ 1,Звездолет&pln У тебя есть магическая метла!,Купить звездолет - нет возможности определить, где кончился xbtn и начался следующий оператор! Akela предложил xbtn 1,{inv+ 5,монет and x++},Взять! Это решает проблему, но выглядит не по-урковски! Вопрос: как лучше?Пора бы расширить btn и proc, как в fireurq. Эх, если б Victor сделал бы это с досуркой (хотяб для совместимости с fireurq)... Тогда можно было б и описание URQL до[пере?]писать. p.s. ;Ну, а пока можно хотябы ссылку в заглавном сообщении подправить. И надеяться на новый интерфейс fireurq. Лишь бы Тон не недо-пере-борщил там... UPD: теперь ссылка работает

elmortem: qwerty А что у вас с многострочными if/else конструкциями? Судя по какому-то описанию их исползовать нельзя, это так? Будет ли расширение языка в этом плане?

Korwin: elmortem пишет: qwerty А что у вас с многострочными if/else конструкциями? Судя по какому-то описанию их исползовать нельзя, это так? Будет ли расширение языка в этом плане? Вопрос не по адресу.

elmortem: Korwin Адреса тут нету, т.к. стандартом никто не занимается. Я интересуюсь в общем. Без привязки к интерпретатору.

noname: Присвоение вида inv_Вампирские стрелы = 15 работает в досурке только если в инвентаре уже есть предмет Вампирские стрелы. (Это- пожалуй, действительно не совсем корректно. Но так уж есть.) А в фурке - всегда работает. хорошоб, чтоб и на досурке работало. p.s. интересно, Victor надёжно забил на досурку, или его есть шанс расшевелить? я просто не в курсе последних старых сплетен

Григорий: noname пишет: интересно, Victor надёжно забил на досурку, или его есть шанс расшевелить? я просто не в курсе последних старых сплетен Последняя версия датируется ноябрем 2004го года. Тебе уже ясен ответ? :)

qwerty: abcdef,когда стал разбираться с синтаксисом переменных, оказалось что они могут состоять из нескольких слов ??? 1. предлагаю продолжить обсуждение реализации платформ сюда, или в твоей теме(хотя её название мне не нравится), или- создать новую 2. насчёт синтаксиса переменных: --- до сих пор ни в одном квесте (ну, я их повидал не мало, и- ни в одном пока такого не видел) НЕ использовались переменные из нескольких слов. смотрим описание URQL: - имя числовой переменной подчиняется общим требованиям к строке (то есть допустимы пробелы и практически любые символы, кроме '#' '$' ',' ';' '/*' '*/' '&' но для совместимости со следующими версиями лучше не использовать других знаков, кроме букв русского или латинского алфавита, знака подчеркивания, цифр. Еще переменные нельзя называть ключевыми словами типа if, then, not, and, or и др. так как в выражениях такие имена будут распознаваться как ключевые слова. таким образом, переменные из нескольких слов смело можно не поддерживать- их просто никто не использует --- НО есть одна ВАЖНАЯ ОГОВОРКА: автор квеста под досурку может захотеть хранить в инвентаре предметы с двойным названием (как в том же примере с вампирьими стрелами). впрочем, реализация инвентаря- довольно спорная штука. он вовсе не является верхом удобства, что стало особенно очевидно после выхода игры "Второй неверный шаг". думаю, со временем от ТАКОГО инвентаря по-любому придётся отказаться --- и, да- сейчас, имея Акурку пре6 (и досурку) можно запустить почти любой квест. в дальнейшем кол-во необходимых интерпретаторов, возможно, вырастет. НО я считаю, что это не только оправдано, но и неизбежно- URQL должен найти свой достойный графический облик, и это случится не за один миг, и у разных программеров могут быть разные идеи по этому поводу. так что период анархии, видимо, неизбежен

fireton: В фурке переменные могут состоять из нескольких слов.

noname: заметил одну интересную вещь- и в досурке и в фурке строковые переменные могут объявляться безо всякого instr: x="dssd" pln #%x$ input x pln #%x$ работает нормально. в описании досурки instr используется в-основном для создания текстовой переменной перед тем, как input в неё ввод пользователя(это- необходимо) ИМХО гораздо проще для этого писать x="", а оператор instr описать в новом хелпе как устаревший, и поддерживаемый(пока) лишь для поддержки старых игрушек. позже можно в старых играх заменить instr означенным способом, и отказаться от поддержки этого оператора совсем // немного теоретических рассуждалок: В фурке переменные могут состоять из нескольких словОК! только сильно баловать авторов не надо: как бы не возникли проблемы позже- если в последующих версиях интерпретаторов поддержка пробела в именах переменных станет нежелательной(как напр случилось со скобками) что касается названий предметов, то я вижу два хороших варианта решения: 1) предметы кроме фиксированного имени(без пробела) будут иметь ещё и caption(текст с любыми знаками препинания, выводимый в качестве соотв пункта инвентаря). этот вариант удобен тем, что caption предмета можно без проблем изменять, как обычную переменную. по умолчанию, если caption не задан, то он становится равным названию предмета(для поддержки старых игр). если же caption уже задан, то этого делать не нужно 2) автор задаёт имя предмета ч/з подчёркивание, но при выводе этого имени подчёркивание заменяется пробелом 3) оставить всё как есть- т е позволить автору использовать пробелы в названиях предметов

Cheshire: Вариант 1, конечно, самый лучший. Вообще странно, почему до сих пор он не был реализован. Если не ошибаюсь, Акурка опускает подчеркивание в названии предмета ("Предмет_1"->"Предмет1"), но все равно появляются проблемы с действиями на этот предмет.

fireton: noname пишет: предметы кроме фиксированного имени(без пробела) будут иметь ещё и caption(текст с любыми знаками препинания, выводимый в качестве соотв пункта инвентаря). Только вчера обсуждали с Корвином в аське. :) С инвентарем вообще много чего надо сделать. Например, возможность скрывать некоторые действия над предметом. Я думаю над этим.

qwerty: Cheshire пишет: Вариант 1, конечно, самый лучший fireton пишет: Например, возможность скрывать некоторые действия над предметом тот же самый caption? если он равен пробелу- действие не показывается

Nolite: Хрошая идея. Можно не с пробелом, а пустой строкой сравнивать.

noname: Nolite пишет: Хрошая идея. Можно не с пробелом, а пустой строкой сравнивать если caption-пустая строка(или если он необъявлен совсем), то его нужно сделать равным имени предмета(или действия- смотря чей caption). для поддержки нормальной работы старых игрушек впрочем, сильно за эту самую поддержку держаться не стОит- досурка, надеюсь, всегда будет с нами :) да, а ещё- можно написать утилиту конвертации квестов из старого формата в новый

qwerty: как мы все некоторые ветераны urq знают, логика инвентаря фурки и досурки различна. когда после действия в инвентаре игра доходит до end, завершающего действие, на досурке прога возвращается в локацию, в которой был игрок. т е переходит на начало той самой локации и выполняет все её операторы на фурке прога отображает баттоны той локации, в которой был игрок. причём отображает их без учёта произошедших в игре изменений ( а в результате действий с предметами в инвентаре вполне могут произойти какие-то изменения) почему так? в досурке- Вик её знает почему, наверное так было проще в фурке- что бы не срабатывали действия, выполняемые при посещении локации Тон её знает почему, наверное так было проще попробую продемонстрировать всё это на примерах // и скажу сразу- я 'болею' за вариант досурки, о чём уже писал в своё время где-то здесь

qwerty: ;пример первый, предельно анти-фурковский, демонстрирующий важность корректного отображения ТЕКУЩЕЙ ситуации в игре, ; что на досурке (в данном примере) не требует каких-то дополнительных ухищрений: :начало flag=0 inv+ шкатулка goto поляна end :поляна pln p красивая поляна, if flag=0 then pln здесь нет ничего интересного if flag=1 then pln здесь лежит что-то интересное. наверное оно выпало из коробки & btn нечто_осм, осмотреть это btn застрел, застрелиться end :use_шкатулка pln pln ты повертел шкатулку в руках flag=1 end :нечто_осм pln pln надо же, это именно то, что ты хотел увидеть! pln ПОБЕДА !!! pln молодец, возьми с полки пирожок pln end :застрел pln pln побробуй выйграть на досурке и фурке. сравни результат pln end ; заранее прошу прощения у firetonа за такие примеры, постараюсь обрисовать ситуацию со всех сторон

qwerty: ; пример второй, беспредельно умеренно анти-фурковский, требующий некоторых пояснений. работает данный пример и на фурке и на досурке почти одинаково, НО есть одна маааленькая особенность: в одной из моих недоначатых недоделок по выбору инвентарь->предмет->осмотреть выводится его *.jpg- изображение, под которым оказываются баттоны 'осмотреть' и 'идти'. однако нажатие баттона 'осмотреть' приведёт вовсе не к осмотру предмета, так как это- баттон локации, который фурка подставляет после действий с инвентарём. попробую дать поясняющий пример: :начало flag=0 inv+ шкатулка goto поляна end :поляна pln pln красивая поляна, здесь много интересного btn выбор_интересного, осмотреть ... end :use_шкатулка pln pln [^$=O=$^] ( - это шкатулка) end ; в этом примере если находясь на красивой поляне осмотреть шкатулку, ; то на фурке увидим под её изображением кнопку 'осмотреть', ; которая на самом деле относится НЕ к ней.

noname: скажу сразу, что эти оба примера можно легко 'адаптировать' под фурку таким образом, что бы вызов инвентаря работал аналогично тому, как это сделано в досурке. достаточно 1. перед end в локации инвентаря вставить оператор clsb (тогда фурка не станет выводить старые кнопки ) 2. и goto #%current_loc$ (а лучше- btn). тогда прога перейдёт на последнюю локацию, на которую был совершён переход по btn и, собственно, будёт работать всё как в досурке осталось теперь привести пример в пользу фурки

noname: // и, да- штоп народ не возмущался, поясняю: fireton сам посоветовал вынести рассмотрение этого вопроса на форум хмм... вместо примера в пользу фурки обнаружил странную досурк-аномалию. нижеследующий пример должен был демонстрировать следующее: игрок входит в музей, затратив 500руб. и каждый раз после использования инвентаря(напр: просмотр газеты), прога выполняет действия локации заново, отимая у него по 500руб, что в корне неверно. после этого я планировал провести анализ того, как адаптировать эту дему под досурку и подвести итоги сравнения: что проще/лучше/логичнее и т п НО не тут-то было! логика работы инвентаря досурки как-то ускользает от меня: подготовленный пример прекрасно на ней работает, и лишних денег 'за чтение газеты в музее' не снимает признаюсь, это меня даже беспокоит: пути интерпретатора не должны быть настолько неисповедимы. он должен работать каким-либо известным, определённым образом, а не стремиться корректно исполнять некорректные демы вот сам пример: :инициализация inv+ газета деньги = 2500 goto бульвар end :бульвар pln pln У тебя #деньги$руб, а билет в музей стоит 500руб. if деньги>=500 then btn музей, посетить музей end :музей деньги= деньги-500 pln pln У тебя #деньги$руб. Ты находишься в музее палеонтологии. Здесь нет ничего съедобного- все кости давно обглоданы. btn бульвар, выйти end :use_газета pln pln Ты не читаешь газет на тощак. Бережёшь нервную систему end

qwerty: собственно, претензия к инвентарю фурки была следующей: его недостатки таковы, что во многих случаях придётся имитировать поведение инвентаря досурки. а это проще игру никак не сделает я уже продумал, как легко и логично избавиться от проблемы с 'взиманием денег за чтение в музее', предполагая, что с ней придётся столкнуться в любом случае, но как оказалось- логика работы инвентаря досурки иная, чем я предполагал

noname: так же хочу ещё раз обратить внимание на ранее ведшееся обсуждение этого вопроса здесь, моё мнение представлено в сообщении от 20.03.09 22:38: to uux: ветку читал, просто понял не так: я думал, что то отличие уже исправлено в выложенной после этого версии, и теперь Тон обдумывает, исправлять ли ему другое отличие(из примера с палкой). надеюсь, что qwerty удалось показать, что досурка вполне корректно ведёт себя и в этом случае спасибо за разъяснение I love Sinclair, DOS and URQ пояснения qwerty касались контр-примера fireton с палкой, и касались того момента, что btn ДО goto я стал бы делать ТОЛЬКО в тех случаях, когда она(btn) НЕ должна быть видна при переходе на ТЕСТ из другого места. так что досурка этот момент обрабатывает верно // а спасибо в моём цитированном сообщении было to uux- за его разъяснения

fireton: noname пишет: НО не тут-то было! логика работы инвентаря досурки как-то ускользает от меня: подготовленный пример прекрасно на ней работает, и лишних денег 'за чтение газеты в музее' не снимает Цитата из корвиновского описания URQL: Использование предмета - это подпрограмма из которой идет возврат в ту же локацию, где вы были. Еще при возврате из I и U на время выполнения одной локации устанавливается режим только чтение для всех переменных, если бы этого не было и в локации, например, есть что-нибудь вроде inv+ 10,патронов, то путем просмотра инвентаря можно было бы накрутить себе гораздо больше боеприпасов. Честно говоря, такое поведение показалось мне очень уж большой жестью. "Здесь играем, здесь не играем, здесь рыбу заворачивали..." qwerty пишет: в одной из моих недоначатых недоделок по выбору инвентарь->предмет->осмотреть выводится его *.jpg- изображение, под которым оказываются баттоны 'осмотреть' и 'идти'. однако нажатие баттона 'осмотреть' приведёт вовсе не к осмотру предмета, так как это- баттон локации Ну, тут как раз все просто. Надо на локации писать более вменяемые надписи на кнопках. Не "осмотреть", а "осмотреться" или "осмотреть поляну". Тогда будет понятно, к чему они относятся. А вообще, я был бы признателен, если кто-нибудь предложит вменяемую схему работы с инвентарем. Пока то, как я это реализовал в фурке, мне кажется наименьшим злом. Но чтобы реализовать изменение локации с помощью предметов, как справедливо указал noname, приходится плясать с бубном.

qwerty: fireton пишет: Честно говоря, такое поведение показалось мне очень уж большой жестью. "Здесь играем, здесь не играем, здесь рыбу заворачивали..." это да. хотелось бы логику попроще fireton пишет: Ну, тут как раз все просто. Надо на локации писать более вменяемые надписи на кнопках. Не "осмотреть", а "осмотреться" или "осмотреть поляну". Тогда будет понятно, к чему они относятся дело в том, что бывает по нескольку действий на локации, каждое из которых может выполняться над несколькими предметами. т е имелось ввиду, что в локации выбираем 'осмотреть', а затем- что конкретно осмотреть. на фурке подобное разделение действий по группам особенно актуально: на досурке я без проблем могу под 4-х строчным описанием вывалить штук 20-ть кнопок. на фурке подобное будет выглядеть не комильфо. следовательно- прибегаем к разбиению действий по группам с баттонами типа "осмотреть" и т п НО и без такого разбиения как-то странно смотрятся баттоны локации под описанием предмета. например, если на каменной шкатулке выбит грубый цветок. игрок, находясь на цветочной поляне осматривает шкатулку. под её описанием появляется кнопка 'осмотреть цветок', относящееся к поляне. что делать в этом случае? на каждом баттоне поляны указывать "осмотреть ...., находящийся на поляне"? это будет по меньшей мере странно. не лучше ли НЕ допускать того, что бы баттоны, относящиеся к одному описанию лепились под другим? fireton пишет: Пока то, как я это реализовал в фурке, мне кажется наименьшим злом. Но чтобы реализовать изменение локации с помощью предметов, как справедливо указал noname, приходится плясать с бубном. не всё так хорошо(хотя, конечно, не всё так и плохо). имеющиеся недостатки таковы, что инвентарь без 'плясок с бубном' можно использовать не в таком уж и большом круге задач. поясняю: ситуация 1: есть у вас в инвентаре предмет, действия с которым никак не повлияют на состояние игрового мира. например, ч/з инвентарь его можно только осмотреть, а учёт наличия этого предмета и соотв реакция на него делается не-инвентарными методами. тогда при фурковской реализации инвентаря мы имеем минимум неприятностей, НО всё равно в случае, когда описания на кнопках планировались автором именно под описанием локации(а ведь мы говорим о текстовых играх, где могут быть использованы намёки, игра слов и мало ли что ещё), ТО автору придётся прибегать к 'пляскам с бубном' для того, чтобы кнопки не 'блуждали' и не оказывались под описанием предмета, под которым они могут иметь другой смысл ввиду другого контекста ситуация 2: тот самый случай, когда действия с предметом хоть на что-то влияют. естественно, что в текстовой игре происходящие изменения отражаются в выводимых описаниях. это я к тому, что данный случай вовсе не относится к особо редким ВЫВОД: у досурковского варианта я вижу пока только один недостаток: недостаточно простая логика его работы. впрочем, фурковская реализация имеет И подобный же недостаток, и ещё парочку в нагрузку. и плюс к этому- неоправданный отход от совместимости с досуркой. т е внесённые различия 'не окупаются' потрясающим возрастанием удобства и логичности нового варианта. с этим, я думаю, никто не поспорит ----- А вообще, я был бы признателен, если кто-нибудь предложит вменяемую схему работы с инвентарем ну, о проблемах рассказал, теперь попробую поговорить о РЕШЕНИЯХ: ПРЕДЛАГАЮ самый логичный ИМХО вариант: 1. по завершении действия в инвентаре (когда прога дошла до end) делать так, как было принято в досурке. для обеспечения совместимости. НО при этом добавить ещё И альтернативные варианты оператора end специально для завершения инвентарных действий. замечу, что совместимость хороша ещё и тем, что описание досурки замечательно подойдёт так же и для изучения фурки, да и вообще совместимость имеет массу преймуществ 2. альтернативные варианты оператора end реализовать через системную переменную end_of_inventory. (важно: для того, что бы обилие системных переменных не мешало вводить авторам собственные переменные, системные переменные должны быть на английском языке и состоять по-возможности из нескольких слов. так например, был случай когда автор пытался вести отсчёт времени в переменной time, не зная, что есть системная переменнная с таким названием. надо обязательно обращать внимание авторов на то, что имена их переменных НЕ должны совпадать с системными переменными ) таким образом, если автор НЕ модифицирует эту переменную, то работа с инвентарём происходит как в досурке. для того, что бы выбрать нужную логику работы инвентаря достаточно установить эту переменную один раз в начале программы 3. предлагаю сделать эту системную переменную строковой, и ввести следующие значения: ton, dosurq - если end_of_inventory="ton", то обработка инвентаря выполняется по текущей логике фурки - если end_of_inventory="dos_urq", то обработка инвентаря выполняется по логике dos_urq (устанавливается по умолчанию) P.S. 4. так же для особо извращённых авторов можно ввести следующие значения: simply, stop - если end_of_inventory="simply", то по выходу из инвентаря возвращаемся в локацию, где и были. т е просто переходим на метку этой локации (это- мой любимый вариант). главное его достоинство- простота и предсказуемость логики работы. от всех возникающих проблем можно отвертеться при любом варианте, но в данном случае понять происходящее будет проще всего - если end_of_inventory="stop", то по достижении инвентарного end программа остановится, как по достижении обычного end. в этом случае автору стоит позаботиться о наличии баттонов в инвентаре, что не совсем корректно. ну дык данный вариант и задумывался исключительно для особо извращённых пытливых экспериментаторов

fireton: Теперь представь ситуацию, что на локации куча текста. Мы выводим, к примеру, описание предмета, а потом проигрываем локацию заново. Получается, что описание предмета оказывается где-то наверху текста локации. Плюс, рушится нафик повествование. Возможно, автор не предполагал, что в эту локацию можно заходить дважды и написал там что-то вроде "Вы осторожно приоткрываете дверь и на цыпочках входите в комнату..." Игрушке будет нанесен вред, вернее, восприятию игрока. Плодить системные переменные - тоже не выход, на самом деле. Возможно, следует сделать оператор типа replay, который будет заново проигрывать текущую локацию. И заканчивать им локации-действия инвентаря. В общем, надо думать.

Nolite: Возможно, добавление одной конструкции решит проблему с инвентарем. :начало flag=0 inv+ шкатулка goto поляна end :поляна pln p красивая поляна, if flag=0 then pln здесь нет ничего интересного onInvUse{ if flag=1 then{ if doOnce pln здесь лежит что-то интересное. наверное оно выпало из коробки & btn нечто_осм, осмотреть это } } btn застрел, застрелиться end :use_шкатулка pln pln ты повертел шкатулку в руках flag=1 end :нечто_осм pln pln надо же, это именно то, что ты хотел увидеть! pln ПОБЕДА !!! pln молодец, возьми с полки пирожок pln end :застрел pln pln побробуй выйграть на досурке и фурке. сравни результат pln end Команды, которые находится в скобках после onInvUse, выполняются при использовании инвентаря, если игра остановилась на локации "поляна" Условие if doOnce выполняется только один раз за работу квеста. Такие условия можно группировать: if doOnce then pln Я здесь в первый раз. else if doOnce then pln Я здесь во второй раз. else if doOnce then pln Я здесь в третий раз. else pln Я здесь был много раз. Пока ни onInvUse, ни doOnce не начал реализовывать.

fireton: ты хочешь ввести блоки кода в уркл? ;) Это круто, но не уркстайл. :)

frodo: Голосую за вариант qwerty! Возможно, автор не предполагал, что... Это уже недочет автора. Либо пускай так не пишет, либо пусть устанавливает нужный режим инвентаря. Получается, что описание предмета оказывается где-то наверху текста локации. Если описание инвентаря и текст локации можно отличить друг от друга, не вижу особого неудобства. UPD: Ведь, если много текста, фурка остановится и будет ждать, пока пользователь нажмет любую кнопку. Таким образом, описание инвентаря окажется в самом верху. По-моему, это даже удобно.

noname: fireton, в-общем и целом твой способ довольно хорош. пока я его критиковал- смог оценить хорошенько и теперь вижу его определённые достоинства fireton пишет: Теперь представь ситуацию, что на локации куча текста. Мы выводим, к примеру, описание предмета, а потом проигрываем локацию заново. Получается, что описание предмета оказывается где-то наверху текста локации да. досурке это не мешало, т к игрок сначала 'разбирался' с инвентарём, затем нажимал баттон и после этого видел текст локации. вполне хороший вариант. то, что длинный текст локации может вытеснить описание осмотренного предмета ( как и все предыдущие описания) - вполне логично. тут уж только скроллинг поможет fireton пишет: Возможно, автор не предполагал, что в эту локацию можно заходить дважды и написал там что-то вроде "Вы осторожно приоткрываете дверь и на цыпочках входите в комнату..." трудно судить, насколько это хорошо или плохо. т е допустим, игрок в этой ситуации предпринимает какие-то действия. так ли уж плохо, если после возни с инвентарём он вернётся куда и был? при этом повторюсь: именно досурковская реализация позволит увидеть ему текущую, а не устаревшую ситуацию. то, что в каких-то особо хитрых случаях автору на досурке придётся прописать лишнюю строчку проверки, или лишнюю промежуточную локацию, ну никак не является поводом для ввода другой реализации со своими специфическими проблемами, которые могут проявляться даже в сравнительно простых(и распространённых) ситуациях. про совместимость я уже говорил fireton пишет: Плодить системные переменные - тоже не выход, на самом деле. Возможно, следует сделать оператор типа replay любой оператор однозначно хуже системной переменной сразу по нескольким причинам: 1. его придётся писать перед каждым инвентарным эндом, что не очень-то удобно => провоцирует появление лишних багов. в то время как служебную переменную достаточно задать в начале всего один раз 2. лишние операторы плодить тоже плохо- их придётся знать хотя бы для того, чтобы не давать такие имена своим переменным, при этом системную переменную можно сделать из нескольких слов(end_of_inventory)- её всё равно придётся устанавливать(в подавляющем большинстве случаев) не более одного раза, и то в самом начале вероятность того, что автор будет использовать для какой-то цели флаг с именем end_of_inventory стремится к нулю, в отличие от replay 3. в случае с оператором replay полученный текст программы будет по-любому не совместим с досуркой, в отличие от ситуации, когда используется присвоение какого-то значения переменной: тогда по крайней мере какие-то квесты будут совместимы. т е у автора будет шанс поддержать совместимость при желании // на данном этапе, учитывая высокое качество фурки, совместимость пержде всего нужна для простоты её освоения с помощью имеющихся описаний и уже готовых игр, которые можно использовать в качестве примера ----- и если уж вводить оператор, то вместо replay можно ввести оператор fend (фурковский end), либо end с параметром(end furq). тогда если инвентарное действие завершается оператором fend- обработка идёт как в текущей реализации инвентаря фурки, если же автор использует обычные end, то обработка идёт как в досурке, что(помимо прочего) повышает совместимость этих платформ ----- и, да - я вовсе не хочу, что бы показалось, что для меня этот вопрос стоит как-то особенно остро. пожалуй, мне текущая реализация инвентаря мешает НЕ сильно, и мало что добавляет к прочим мелким неудобствам, вызванным необходимостью 'притираться' к новой платформе //просматривая тему фурки заметил, что Korwin предлагал оставить вариант досурки // так же uux обратил внимание на то, что в досурке его пример (с инвентарём) работал корректно, а на фурке- нет из достоинств новой реализации могу отметить, что неприходится жать лишних, не водившихся автором квеста баттонов полсе осмотра предмета. (впрочем, достоинство немного сомнительное с учётом того, что досурковский вариант чётко разделял действия с инвентарём+соотв описания и описание+баттоны локаций) в общем, что я вообще хотел сказать: я хотел а) высказать своё мнение о реализации инвентаря б) популярно его разъяснить, штоп было ясно, что именно я имею ввиду в) убедительно обосновать мнение моё на данный момент такое: в досурке инвентарь реализован однозначно лучше фуух! всё, задача выполнена P.S. ИМХО о текущих интерпретаторах URQL: фурка- лучшая ! // теперь уже да

noname: Nolite, Оккама нет на твой onInvUse. с бритвой

Nolite: Блок кода использовался еще в xbtn. Оттуда я его и выдрал, только | на символ перевода строки заменил ;) UPD. Как решить проблему с инвентарем не создавая новых сущностей, не знаю.

qwerty: а вот ещё одна тема с обсуждением языка URQL: Предложения по поводу URQ



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