Отправлено: 29.11.05 18:11. Заголовок: Предложения по поводу URQ
есть предложения. 1) Я сделал очень сложную настройку цветов. Но для этого я использовал кучу меток. Хочется, чтобы при нажатии кнопки совершалось какое-либо действие. ТО есть нажатие на кнопку не переносит нас на локацию, а делает какое-либо действие. 2) Почему бы не ввести константы - переменные, которые неизменяются. В моём будущем квесте переменные используются очень часто, так что необходимость есть.
1. Предлагаю использовать из акурки функцию hide_use_имя-предмета_действие (если такая переменная не равна нулю, то действие скрывается) 2. xbtn куда,{список операторов},Название кнопки или xbtn куда,оператор,Название кнопки 3. Новый оператор печати текста pn 'Здесь всякий текст #%переменная$ в том числе "в кавычках" ' - всё, что внутри апостофов просто выводится на печать, в том числе и операторы URQL. А то попробуйте напечатать оператором pln вот такую строчку: pln If not God then I am God else I am slave of God! 4. Теги мне кажется не так уж нужны, самое их распространенное использование - центрирование и выделение заголовка, поэтому наверное был бы смысл добавить такую функцию в оператор pn: pnc - печатает текст по центру, pnl - прижимает к левому краю, pnr - к правому. 5. В операторе input хорошо бы сделать историю ввода команд (массив строковых переменных, пролистываемый при активации input стрелкой вверх или вниз, соответственно этот массив можно было бы сделать набором системных переменных с именем hinput№ (0-n). 6. Ну еще хочется упорядочить работу со строковыми переменными а то там сейчас черт ногу сломит. Например выполнять присвоение строковой переменной по типу instr stroka='Тут всякий текст ' чтобы потом оператор pln #%stroka$разный
6. Ну еще хочется упорядочить работу со строковыми переменными а то там сейчас черт ногу сломит. Например выполнять присвоение строковой переменной по типу instr stroka='Тут всякий текст ' чтобы потом оператор pln #%stroka$разный
напечатал: Тут всякий текст разный - с пробелом!
Ты хочешь чтоб "Адский Квест" (с) в новой досурке работал неправильно?
Korwin пишет:
цитата:
1. Предлагаю использовать из акурки функцию hide_use_имя-предмета_действие (если такая переменная не равна нулю, то действие скрывается)
Имеет смысл только в том случае, если инвентарь в досурке кто-то перепишет полностью в нормальный вид, которым можно пользоваца.
Korwin пишет:
цитата:
3. Новый оператор печати текста pn 'Здесь всякий текст #%переменная$ в том числе "в кавычках" ' - всё, что внутри апостофов просто выводится на печать, в том числе и операторы URQL. А то попробуйте напечатать оператором pln вот такую строчку: pln If not God then I am God else I am slave of God!
Ну почему же, как мне сказали это легко: pln ##70$f not God ##116$hen I am God ##101$lse I am slave of God! Когда я просил напечатать строку: pln Поели; Настасья Петровна попросила принести кокаин.
Korwin пишет:
цитата:
2. xbtn куда,{список операторов},Название кнопки или xbtn куда,оператор,Название кнопки
Правда нехватает?
:self If not God then btn self, {pln ##70$f not God ##116$hen I am God ##101$lse I am slave of God!&God=true}, I am God else btn self, {pln Поели; Настасья Петровна попросила принести кокаин.&God=false}, I am slave of God end
Что делает эта локация? Где в ней ошибка? Ты правда считаешь что это удачный синтаксис и хочешь такое отлаживать в своем квесте?
Korwin пишет:
цитата:
5. В операторе input хорошо бы сделать историю ввода команд (массив строковых переменных, пролистываемый при активации input стрелкой вверх или вниз, соответственно этот массив можно было бы сделать набором системных переменных с именем hinput№ (0-n).
Ты хочешь заставить нас ввести еще больше всяких строк чем в игре про Люцифера? Кстати в досурке есть все средства для того чтоб ты мог написать эту функцию самостоятельно. Строк в 50. И хватит плодить системные переменные, их и так слишком много.
А я сейчас хотел поразмышлять об интерфейсе текстовых квестов. У нас есть главное окно, в котором игра выводит описания локаций и всех действий игрока. Есть окно кнопок, в котором игрок выбирает свои действия. Есть строка ввода, куда игрок вводит то, что от него требует игра. Есть окно инвентаря, где постоянно видно, что у Вас есть с собой. И есть окно картинок, которое всплывает где-то сбоку, порой загораживая текст. Мне кажется, что такое количество окон совершенно избыточно и рассеивает внимание игрока, отвлекая его от собственно текста, кроме того, оно провоцирует автора игры на затруднение прохождения игры нечестным способом - применением РАЗНОГО стандарта решения игровых загадок. Т.е. одна загадка решается добыванием нужного предмета и доставлением его в нужную локацию, где в ответ на это появляется скрытое ранее действие, а другая - через операции с инвентарем. Это сильно осложняет игру, при этом не добавляя играбельности. Если добавить в игру работу с картинкой, точнее с кликами мышкой по разным местам картинки, то в сочетании с двумя вышеописанными способами решения пазлов возникнет полная путаница.
Поэтому я предлагаю стандартизировать интерфейс менюшных квестов: 1. Оставить только одно окно, в котором будут выводиться как текст, так и названия кнопок и даже картинки-иллюстрации.
2. Инвентарь сделать доступным по стандартной кнопке, кочующей из локации в локацию под номером 0, если наличие инвентаря предполагается автором. Название "инвентарь" записать по умолчанию в строковую системную переменную, которую автор сможет менять по своему усмотрению на "вещи", "мешок" или как ему будет удобно. По нажатию этой кнопки игрок попадает в особую локацию, которой принадлежат объекты инвентаря. Выбор любого объекта открывает доступ к списку действий, которые с ним возможны.
3. Все прочие действия пронумерованы от 1 до 9. Честно говоря, я считаю неудачными менюшные квесты, в которых игроку предлагается более 5-7 действий на выбор в один момент времени. При необходимости можно обозначить кнопки 10-а, 11-b и т.д. или ввести двухсимвольное обозначение 00, 01,... , 10, 11, ..., 99. Но эта мысль мне кажется не слишком удачной. Игра должна быть играбельной! Осмысливать разницу между 12 разными действиями вряд ли интересно. Кроме того, с таким ограничением будет куда легче портировать игру под сотовые телефоны.
4. Я призываю отказаться от раскраски текста в разные цвета автором игры (сам грешен, злоупотреблял)- эти ухищрения отвлекают внимание игрока от собственно текста, который должен быть хорошо читаемым. Следовательно, максимум, что можно позволить - выделить нужное место ЗАГЛАВНЫМИ БУКВАМИ, жирным шрифтом, р а з р я д к о й или курсивом.
5. О графике. Можно применить картинку для создания заставки, нагнетания определенного настроения, изображения карты или персонажа, или иллюстрации к загадке. Но иллюстрация должна дублироваться подписями, позволяющими обойтись и без нее - нашими игроками могут быть и слепые люди. Т.е в режиме "графика выключена", игра должна быть по-прежнему проходима!
6. Музыка должна быть отключаема игроком, так же как авторские настройки цвета фона, текста, размера шрифтов - кроме вышеупомянутых выделений. Следовательно, оператор print придется дорабатывать...
7. Хорошо бы иметь возможность, как в досурке, делать лог-файл...
"Вот всё что я знаю о ловле креветок" (c) цитата из фильма "Форрест Гамп"
xbtn куда,{список операторов},Название кнопки или xbtn куда,оператор,Название кнопки
Капитан Блуд пишет:
цитата:
Правда нехватает?
Правда. Обхожусь, конечно, тем, что есть, но необходимость писать игры совместимые под досурку и под акурку вынуждает использовать не самые оптимальные функции. Видел в GEM как я рассчитывал экспоненциальное увеличение плотности воздуха с падением высоты? Мне так больше не хочется!!!
1: Получается квест в виде книги. Я тоже об этом думал. Да, наверное, получится очень удобно. 2: Насчёт инвентаря пока не знаю… Мне досурковый вариант нравится, но он не очень вписывается в (1). 3: Это уже есть в Акурке. 4: Заглавные буквы — зло. Моё предложение: позаимствовать у html теги <strong>, <em> и <h> (не обязательно в виде тегов, но с той же идеей — как это будет отображаться, решать автору движка, голосовой движок, например, будет менять высоту и громкость голоса, досовский — цвет, Windows-овский — шрифт). 5: Это до нас придумали уже. <img> с обязательным атрибутом alt. Опять же, не обязательно тег. И, повторюсь, только в качестве иллюстраций. 6: Музыку вообще убрать — я включу себе то, что хочу, или буду играть в тишине. Пункты (5 и 6) потому, что это текстовый квест! 7: Я бы голосовал за одноходовый undo. PS: И лучше б вы оставили в покое URQ и сделали нормальный язык. Потому что если ещё и это в URQ добавить, писать на нём будет неприятно.
1. Квест и должен быть в виде книги. 2. Мне не нравится не досурковый ни акурковый варианты инвентаря. Я вообще в последнее время начинаю думать что наличие инвентаря в играх на урке вообще плохо. Но убирать его конечно нельзя ясное дело :) Просто то что недоделано, я стараюсь не использовать или переписать. 3. Осмысливать разницу между 12ю вариантами может быть интересно, но только в специальных ситуациях, конечно следует старатся избегать такого в общем случае. 4. Ничего плохого в раскраске не вижу. Что плохого, например, в том, что в локациях типа "лес" герой видит зеленый текст(или фон), в локациях типа "подземелье" серый, а в локациях типа "адский" красный? Также цвета могут быть частью паззла, такой прецедент уже был :) 5. Тег альт конечно никто не отменял но опять же что плохого в графических паззлах? Да, играть как оказалось могут слепые люди, но для них автору игры следует просто предусмотреть альтернативный картинке текст, если он считает это возможным и рассматривает незрячих как часть целевой аудитории. 6. Если кто-то напишет приемлимого качества звук к игре, то почему нет? Также в звуках могут быть паззлы (та же морзянка, игрок слышит композицию хачатуряна танец с саблями и угадывает таким образом пароль-подсказку, и т.п.) Опять же, автор должен предусмотреть альтернативные подскзки в таких случаях, для глухих или людей с поломанной звуковой картой (если конечно он рассматривает их как целевую аудиторию). А вставлять ворованные мидишки из других игр в квест конечно не надо. Каждый автор может сделать цвета/картинки/музыку для игры отключаемыми, если он считает это возможным для своей игры (если я пишу квест для обучения азбуке Морзе в интерактивной форме, согласись, отключение звука не имеет смысла) 7. Undo легко реализуется средствами языка урк, лог файл
Если уж Корвин ты говоришь о слепых людях, то подумай лучше, как они вводят слова из "мозгового шторма" в игре "Джин", победителе недавнего конкурса, чем запрещать нам цвета, музыку и видео
Goraph, обучение азбуке Морзе на языке для текстовых квестов… Не лучше ли использовать для этого более подходящий язык?
Undo… «Игрок имеет право не быть убитым без предупреждения» (или как там?). Вот если это правило будет всеми выполняться, мне ни лог-файла, ни Undo не надо.
Раскраска. Представь, я просидел десять часов за компом, хочу отдохнуть (да, отдыхаю я тоже за компом ^_^), а тут автор квеста выдаёт мне жёлтый текст на зелёном фоне. А у меня глаза устали… Поэтому я либо отключу раскраску, либо удалю квест (скорее второе).
Goraph, обучение азбуке Морзе на языке для текстовых квестов… Не лучше ли использовать для этого более подходящий язык?
Я же писал "в игровой форме". Т.е. это текстовый квест где часть игры происходит в расшифровке/кодировании сообщений азбукой морзе, а еще это квест :) В урке есть все что надо для создания такой игры прямо сейчас. Вобщем-то это только пример.
SFeLi пишет:
цитата:
Undo… «Игрок имеет право не быть убитым без предупреждения» (или как там?). Вот если это правило будет всеми выполняться, мне ни лог-файла, ни Undo не надо.
Мне ундо тогда тоже не надо. Кстати, если оно будет, это еще не причина не соблюдать этого правила. А лог-файл нужен не игроку а автору квеста. Впрочем в менюшном квесте он не является чемто необходимым, это в парсерном без него нельзя нормально отладится.
Раскраска это часть игры. Если мне нужна по сюжету плохая раскраска, значит должна быть неотключаемая плохая раскраска. Нет же отключаемой раскраски в браузере интернет эксплорер. Хотя там все тоже самое. А вобще это несущественный вопрос. :)
2. xbtn куда,{список операторов},Название кнопки или xbtn куда,оператор,Название кнопки
ДА! ДА! да-да-да-да-ДА! Капитан Блуд пишет:
цитата:
Правда нехватает?
:self If not God then btn self, {pln ##70$f not God ##116$hen I am God ##101$lse I am slave of God!&God=true}, I am God else btn self, {pln Поели; Настасья Петровна попросила принести кокаин.&God=false}, I am slave of God end
Что делает эта локация? Где в ней ошибка? Ты правда считаешь что это удачный синтаксис и хочешь такое отлаживать в своем квесте?
можно привести неудобоваримый пример использования любого оператора, но это не повод его выкидывать из языка. xbtn часто бывает удобен, а в некоторых редких случаях (напр переменное кол-во кнопок, составленных из доступных комбинаций действие+аргумент) бывает абсолютно необходим. в приведённом тобой случае я весь прогруз про God запихнул бы в отдельную переменную- читабельность кода очень важна для больших проектов, и я постарался бы в строчку с xbtn вставлять только вызовы процедур.
. Ну еще хочется упорядочить работу со строковыми переменными а то там сейчас черт ногу сломит. Например выполнять присвоение строковой переменной по типу instr stroka='Тут всякий текст ' чтобы потом оператор pln #%stroka$разный
да, и вправду замечал некоторые неудобства. их можно обойти, но не всегда это удобно.
и ещё: хорошо бы сделать bpause - паузу до нажатия игроком любого btn, иначе неудобно отрисовывать btn в процедуре. в редких случаях- когда квест по ситуации вычисляет нужные btn хотелось бы выводить btn-ы в процедуре, затем- ждать нажатия баттона, а уже потом- продолжать выполнение дальше.
можно обойтись и без bpause, но представьте, что выполняется некий цикл и в любой момент обработка процессов, происходящих в мире может потребовать действий игрока. из цикла вызывается процедура с отрисовкой кнопок, а после возвращения из процедуры цикл должен как ни в чём ни бывало продолжиться.
Оставить только одно окно, в котором будут выводиться как текст, так и названия кнопок и даже картинки-иллюстрации.
2. Инвентарь сделать доступным по стандартной кнопке, кочующей из локации в локацию под номером 0, если наличие инвентаря предполагается автором. Название "инвентарь" записать по умолчанию в строковую системную переменную, которую автор сможет менять по своему усмотрению на "вещи", "мешок" или как ему будет удобно. По нажатию этой кнопки игрок попадает в особую локацию, которой принадлежат объекты инвентаря. Выбор любого объекта открывает доступ к списку действий, которые с ним возможны.
и я за такое! только, чур системные переменные делать английскими буковками.
Отправлено: 11.04.08 23:15. Заголовок: графика и звук пусть..
графика и звук пусть будут доступны опционально для создания атмосферы
и ещё- по поводу предыдущего поста: а не сделать ли полноэкранный интерфейс? я мог бы такое с использованием, к примеру, функций directx_8(или даже 7).
тогда стандарт- чёрный а-ля дос экран, серебрянный цвет а-ля дос буковок (но в хорошем разрешении), ест-ссно моноширинный шрифт, вперемешку с текстом где угодно и как угодно можно вставлять картинки, которые могут скроллироваться (или не скроллироваться) вместе с текстом.
как туда впихнуть гиперссылки- надо дооолго подумать.
как сделать интерпретатор досурки- тоже надо подумать. идеи есть. по-моему Victor пошёл по простому пути, когда задумал #$ - это просто и гениально... но сработает ли моя догадка?
p.s. как же не хочется затевать написание интерпретатора! +интерфейс +библиотеки функций и расширений, подключаемые опционально
Отправлено: 14.04.08 04:12. Заголовок: Александр, я как раз..
Александр, я как раз имела в виду, что на Милене вам, как не сегодняшний день самому активному разработчику несложно реализовать многое нужное из того, что обсуждалось в этой ветке, тем более, что многое уже реализовано! Потому и посоветовала noname-qwerty вместо изобретения велосипеда посмотреть в сторону Вашей платформы. Которая лично мне весьма симпатична. Эстетически. И с точки зрения отзывчивости автора.
Все даты в формате GMT
3 час. Хитов сегодня: 0
Права: смайлы да, картинки да, шрифты нет, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
- участник сейчас на форуме
- участник вне форума