Форум » » Продвинутые возможности QSP-языка » Ответить
Продвинутые возможности QSP-языка
luciofulci: Во-первых, хотелось бы поблагодарить создателя движка за отличную работу. Впечатляет, без смайлов! Но, во-вторых, к сожалению, бросается в глаза некоторая несбалансированность самого языка. Например, отсутствует поддержка функций, определенных пользователем (про объекты, которые значительно облегчают написание сколько-нибудь сложных игр я не говорю...). Эта ограниченность приводит к необходимости использовать обходные пути, использовать локации и инвентарь явно не по назначению и т.д., что в дальнейшем затрудняет понимание и редактирование собственного кода :( Разумеется, это объясняется тем, что язык рассчитан в идеале для людей, слабо разбирающих в программировании, но при этом присутствует такая продвинутая фича, как динамическая генерация кода, для адекватного использования которой требуется серьезный опыт кодинга. Хотелось бы задать вопрос - будет ли язык развиваться в плане добавления новых возможностей, таких как функции и классы? Заранее спасибо за ответ!
Ответов - 72, стр:
1 2 3 4 All
Ntropy: Нужно написать все эти мелкие локации и спрятать в отдельный файл, либу. Это решение не требует ничего в операторе не менять.
werewolf: Я сейчас думаю о переводе на qsp оной книги-игры, так там при получении любого предмета указвается смещение по параграфам (-10 или +50 например) при использовании этого предмета, поэтому хотелось к каждому предмету добавить меню из 2 пунктов "Осмотреть" и "Использовать". В этом случае с пунктом Использовать можно было обойтись одной локацией, где-бы просчитывалось такое смещение. Но в принципе с предметами ситуация обходима 2 путями - по клику на предмету выводить описание в окно доп описаний и туда же добавлять html ссылку которую сформировать проще или мне сейчас пришел в голову второй, более удобный - делать с menu, но добавлять команду unselect не в локацию обработчик выбора а в локации на которых обрабатываются пункты меню. Сложнее обойти второй момент который есть в книге - кроме предметов игрок получает информацию, опять же завязанную на смещении, вот здесь бы и хотелось использовать один предмет "Информация" и меню к нему, но как здесь обойтись одной локацией я не придумаю.
werewolf: Ntropy если все же создавать кучу локаций, то смысла выносить их в отдельный файл я не вижу, поскольку повторно их использовать скорее всего не придется
HIman: werewolf В твоем случае с параграфами можно совсем в лоб создавать столько локаций сколько параграфов и все переходы будут однозначны по GT Либо придется переработать книгу-игру и вначале куда нить на листочек выписать все свойства или описания предметов написаные в том-то параграфе чтобы их выводить опционно в окошке описания предметов и никуда не перемещаться с текущей локации.
Byte: werewolf так и сейчас это можно. Создаем таблицу "использований" предметов: [pre2] useobjs['палка']=23 useobjs['кольцо']=-43[/pre2] 23, -43 - смещения. На локации использования предмета смещение для выбранного предмета будет: [pre2]useobjs[$selobj][/pre2] В этом случае всё делается на одной локации для всех предметов.
werewolf: Да для предметов смещение реализовать проще, но как быть с информацией? есть предмет Информация при выборе которого игроку выводиться меню со списком известной ему информации, при выборе пункта пункта меню нужно просчитывать смещение и делать переход - здесь можно как-нибудь обойтись без создания отдельной локации на каждый пункт?
Byte: А список возможных пунктов меню ("меню со списком известной ему информации") для предметов большой? Обычно ведь это очень ограниченный набор возможных вариантов.
werewolf: В том то и дело что не маленький - я точно не считал, но где-то около 20 а то и больше.
Byte: Возможно аргумент для MENU добавится, неявный. Есть 2 варианта: 1) После вызова в ARGS[0] хранится индекс выбранного пункта меню. 2) После вызова в $ARGS[0] хранится название выбранного пункта меню. Вообще, 20 локаций - не так уж много)
werewolf: Byte пишет: Возможно аргумент для MENU добавится, неявный. Есть 2 варианта: 1) После вызова в ARGS[0] хранится индекс выбранного пункта меню. 2) После вызова в $ARGS[0] хранится название выбранного пункта меню. это будет просто отлично Byte пишет: Вообще, 20 локаций - не так уж много) Просто хотелось упростить себе жизнь, при большой нужде и 100 локаций добавить не проблема.
Nex: А если по команде MENU нужно будет вызвать пользовательскую функцию с параметрами? P.S. наверняка есть более простое решение.
Byte: Можно будет вызвать FUNC('моя ф-я',1,2,ARGS[0]) - оно будет нормально работать.
полная версия страницы