В урке много недостатков. Мне, как автору фурки можете поверить. Вообще, чем дальше я пишу фурку, тем лучше понимаю, какой должна быть идеальная менюшная ИЛ-платформа. Возможно, я её когда-нибудь напишу. Имя, по крайней мере, уже придумал. 
Впрочем, я отвлёкся.
Одной из самых неудобных в урке вещей является инвентарь. Написать игру, в которой инвентарь используется вменяемым образом, довольно сложно. Даже очень сложно. Я не говорю сейчас об играх, в которых инвентарь играет роль декорации или используется минимально. Я говорю об играх, где, скажем, предметы могут по-разному использоваться на различных локациях, плюс список и реализация действий над предметами различаются в зависимости от внутриигровых факторов.
Нет, конечно, урка предоставляет средства. Но лучше сразу убиться, чем писать сложное взаимодействие с предметами инвентаря. В платформе моей мечты инвентарь будет удобным и практичным. Но мы говорим об урке.
Сейчас взаимодействие с предметом в инвентаре реализуется через локации вида:
:use_Зелье_Выпить
pln ...
Если нужно реализовать различное взаимодействие в зависимости от текущей локации, то приходится писать что-то вроде:
:use_Зелье_Выпить
if cur_loc="пещера" then goto ...
При этом, если локаций, на которых нужна разная реакция на выпитое зелье, много, то этих if и goto в локации-действии будет на пол-экрана. Кроме того, все реакции будут располагаться в коде одной куче, зачастую далеко от той локации, к которой привязаны.
Мне пришла в голову идея реализовать в фурке локации следующего вида:
:пещера
pln Вы в пещере...
...
end
:use_Зелье_Выпить@пещера
pln Пьём зелье в пещере...
...
Т.е. в зависимости от текущей локации будет выбираться та или иная реализация на действие над предметом. Если не нашлось «специализированной» реализации, то выполняется стандартная use_Зелье_Выпить.
Этот подход, мне кажется, имеет несколько важных плюсов:
- Реакцию на предметы можно описывать непосредственно рядом с локацией, к которой они привязаны. Это позволит упростить отладку и доработку сложного квеста.
- Нет безумных «макарон» из if и goto.
- Текст игры становится более «читабельным», что немаловажно, если игра большая.
Также удобство использования инвентаря повысят события (events), которые стоят в планах на реализацию. Но о них в другой раз.
Хм, я подумаю.
Просто знак @ читается как «at» (т.е. «на локации») и больше подходит именно логически…
Да! Расширение языка URQL для инвентаря подобным образом имеет право на жизнь!
Если вдуматься, то языку более логичен именно подход, который предложил тон. Возможно, лучше будет вместо знака «@» оставить второй знак в строке «:». Почему? А не нужно менять раскладку на клавиатуре, что удобно 
Мне кажется, нельзя сделать программирование в блокноте удобным на любом более-менее сложном языке программирования. Нужно идти двумя путями — добавлять в язык возможности и создавать GUI для программирования. В идеальном случае в GUI вообще не должно быть элементов языка.
Маленькая поправка к предыдущему комменту. Авторам сложнее применить мой подход в том случае, когда код для реакции очень большой, тогда его проще выносить в отдельную локу. Также вы можете заявить, что это может породить сложность при использовании обоих вариантов. Но, насколько я помню урковцы любят отдавать предпочтение одному из вариантов упрощения разработки. Поэтому вам проще будет создать приоритет проверки реакции на локацию с вашим вариантом, а потом искать в умолчалной реакции. Все, как говорится в канве URQL и по принятым между урковцами принципам работы их проигрывателей.
Для начала хочу сделать несколько замечаний для своего коллеги, fireton-а, абзацем ниже.
Вы описываете проблему связанную с проблемой формального языка URQL, поэтому не рекомендую связывать это все с самой платформой. В данном случае с ее исполнительной частью — проигрывателем, который всего лишь реализует определенные возможности. В моей статье «Введение» по своему проекту Неоргек, было хорошо и внятно все это разъяснено. Хоть эта статья и является частью моего проекта, другим она полезна ввиду ее проработанности, причем все может проверить любой в ней. Поэтому, все сказанное в вашем об «идеальной» платформе отметаю из-за не понимания того, что из себя представляет сама платформа и сам язык URQL. По вашему блогу явно видно, что вы ошибаетесь в своих суждениях и смотрите не на те вещи. Пытаясь решить вопрос о построении «Идеальной» платформы, через язык у вас два варианта развития, либо придти к выводу, что это ничего толком не дает, либо создать жуткое нагромождение. Может, когда-нибудь вы поймете, что в мире не может быть абсолюта, есть лишь только множество вариантов одного определения. Например, ИЛ у нас отражает такое же понимание данного вопроса и только выигрывает от этого. В языках также, а платформе трогать нет смысла — они только исполнительные части.
Что касаемо уже предложенного вами в языке URQL. То это просто уход от программирования. Как вы не пишите, а «проблема» с условиями останется. Одним словом, велосипед. Однако, есть более логичный и простой способ упростить программирование – перевести некоторые вещи на предметно-ориентированное понимание. Что я вам и покажу наглядным образом в данном вопросе.
В вашем случае это множественное условие с идентификатором локации. Так, добавьте специальный оператор.
Например:
:use_Зелье_Выпить
loc_пещера:
pln Пьём зелье в пещере…
loc_end
pln Может не здесь?
end
В этом тоже есть свои плюсы:
1) Реакцию на предметы можно группировать в одной локации, это позволит упростить отладку для действительно сложных квестов, а также не даст упустить из внимания все реакции связанные с данным действием.
2) Безумные макароны из if и goto не нужны, т.к. их использование здесь вообще не требуется.
3) Текст игры становится читабельным из-за убирания не нужных локаций и сокращения макарон из пункта 2. Т.к. при большом квесте всегда встречается нужда в некоей шаблонности названий локаций, а в URQL это является камнем преткновения для повышения читабельности и структурированности, что очень важно для нескольких авторов.
4) Это предметно-ориентированный вариант, без увеличения кол-ва лишних локаций.
Но насколько мне известно из собственной практики, авторам сложно применять подобный прием при маленьких реакциях (т.е. используется мало команд для реакции). Поэтому логичнее взглянуть на оба варианта и увидеть банальную мощь простоты языка. А это значит, добавить оператор реакции на указанную локу и добавить предложенный вариант в вашем блоге. Только лишь в этом случае, можно ощутить полноту предложенного вами способа. В этом случае, автор будет использовать, либо оба подхода по отдельности, либо комбинировать их, чтобы упростить код и увеличить читабельность.
В заключении моего комментария скажу, что меня всегда удивляет недальновидность моих коллег по разработке языка ИЛ. Это же ведь так просто и сразу видно, где чего не хватает, с учетом сохранения оригинальности, а также без усложнения языка URQL для проигрывателей с простенькими разборщиками входного кода квеста. Одним словом, это не так сложно, сколько просто. Надо лишь немного и хорошенько проработать все варианты и найти между ними общее, его и использовать. И вот у меня интересный вопрос возник. А сможете ли вы это претворить в жизнь, учтя все мои замечания по предложенному вами варианту или пойдете своим вариантом со всеми его недочетами?
З.Ы.
Желаю вам успехов и по меньше лени в проработке, предлагаемых вами вариантов.
Увы, но если думать категориями типа «пишем в блокноте», то на многие очень перспективные вещи можно забить просто из-за того, что они труднореализуемы или сложны для восприятия кода. У меня процесс изрядно тормозил, пока я не занялся GUI, в котором всякие нюансы разнесены по разным формам со своими кусочками кода (при выгрузке всё собирается автоматически в «макароны из if и goto»).
Ну, если рассматривать урк или кусп как своего рода «ассемблер», то такой подход вполне имеет право на жизнь. По такому принципу работает, например, Я — Мастер Книг, у которого есть экспорт в URQ.
Но я хочу, чтобы писать игры было удобно именно «в блокноте». И пытаюсь привести URQL к такому состоянию хоть немножко.