В урке много недостатков. Мне, как автору фурки можете поверить. Вообще, чем дальше я пишу фурку, тем лучше понимаю, какой должна быть идеальная менюшная ИЛ-платформа. Возможно, я её когда-нибудь напишу. Имя, по крайней мере, уже придумал. 🙂 Впрочем, я отвлёкся.
Одной из самых неудобных в урке вещей является инвентарь. Написать игру, в которой инвентарь используется вменяемым образом, довольно сложно. Даже очень сложно. Я не говорю сейчас об играх, в которых инвентарь играет роль декорации или используется минимально. Я говорю об играх, где, скажем, предметы могут по-разному использоваться на различных локациях, плюс список и реализация действий над предметами различаются в зависимости от внутриигровых факторов.
Нет, конечно, урка предоставляет средства. Но лучше сразу убиться, чем писать сложное взаимодействие с предметами инвентаря. В платформе моей мечты инвентарь будет удобным и практичным. Но мы говорим об урке.
Сейчас взаимодействие с предметом в инвентаре реализуется через локации вида:
: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 к такому состоянию хоть немножко.