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

Стандарт URQL

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

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

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



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