Отправлено: 18.01.09 19:19. Заголовок: Продвинутые возможности QSP-языка

Во-первых, хотелось бы поблагодарить создателя движка за отличную работу. Впечатляет, без смайлов!

Но, во-вторых, к сожалению, бросается в глаза некоторая несбалансированность самого языка.
Например, отсутствует поддержка функций, определенных пользователем (про объекты, которые значительно облегчают написание сколько-нибудь сложных игр я не говорю...). Эта ограниченность приводит к необходимости использовать обходные пути, использовать локации и инвентарь явно не по назначению и т.д., что в дальнейшем затрудняет понимание и редактирование собственного кода :(
Разумеется, это объясняется тем, что язык рассчитан в идеале для людей, слабо разбирающих в программировании, но при этом присутствует такая продвинутая фича, как динамическая генерация кода, для адекватного использования которой требуется серьезный опыт кодинга.

Хотелось бы задать вопрос - будет ли язык развиваться в плане добавления новых возможностей, таких как функции и классы? Заранее спасибо за ответ!

 Отправлено: 10.06.09 10:26. Заголовок: Нужно написать все э..

Нужно написать все эти мелкие локации и спрятать в отдельный файл, либу. Это решение не требует ничего в операторе не менять.

 Отправлено: 10.06.09 10:38. Заголовок: Я сейчас думаю о пер..

Я сейчас думаю о переводе на qsp оной книги-игры, так там при получении любого предмета указвается смещение по параграфам (-10 или +50 например) при использовании этого предмета, поэтому хотелось к каждому предмету добавить меню из 2 пунктов "Осмотреть" и "Использовать". В этом случае с пунктом Использовать можно было обойтись одной локацией, где-бы просчитывалось такое смещение.
Но в принципе с предметами ситуация обходима 2 путями - по клику на предмету выводить описание в окно доп описаний и туда же добавлять html ссылку которую сформировать проще или мне сейчас пришел в голову второй, более удобный - делать с menu, но добавлять команду unselect не в локацию обработчик выбора а в локации на которых обрабатываются пункты меню.
Сложнее обойти второй момент который есть в книге - кроме предметов игрок получает информацию, опять же завязанную на смещении, вот здесь бы и хотелось использовать один предмет "Информация" и меню к нему, но как здесь обойтись одной локацией я не придумаю.

 Отправлено: 10.06.09 10:41. Заголовок: Ntropy если все же ..

Ntropy
если все же создавать кучу локаций, то смысла выносить их в отдельный файл я не вижу, поскольку повторно их использовать скорее всего не придется

 Отправлено: 10.06.09 10:47. Заголовок: werewolf В твоем..

werewolf
В твоем случае с параграфами можно совсем в лоб создавать столько локаций сколько параграфов и все переходы будут однозначны по GT
Либо придется переработать книгу-игру и вначале куда нить на листочек выписать все свойства или описания предметов написаные в том-то параграфе чтобы их выводить опционно в окошке описания предметов и никуда не перемещаться с текущей локации.

 Отправлено: 10.06.09 10:53. Заголовок: werewolf так и сейча..

werewolf так и сейчас это можно.
Создаем таблицу "использований" предметов:

 
 useobjs['палка']=23 
 useobjs['кольцо']=-43

23, -43 - смещения.
На локации использования предмета смещение для выбранного предмета будет:

useobjs[$selobj]

В этом случае всё делается на одной локации для всех предметов.

 Отправлено: 10.06.09 11:02. Заголовок: Да для предметов сме..

Да для предметов смещение реализовать проще, но как быть с информацией?
есть предмет Информация при выборе которого игроку выводиться меню со списком известной ему информации, при выборе пункта пункта меню нужно просчитывать смещение и делать переход - здесь можно как-нибудь обойтись без создания отдельной локации на каждый пункт?

 Отправлено: 10.06.09 11:06. Заголовок: А список возможных п..

А список возможных пунктов меню ("меню со списком известной ему информации") для предметов большой? Обычно ведь это очень ограниченный набор возможных вариантов.

 Отправлено: 10.06.09 11:08. Заголовок: В том то и дело что ..

В том то и дело что не маленький - я точно не считал, но где-то около 20 а то и больше.

 Отправлено: 10.06.09 12:04. Заголовок: Возможно аргумент дл..

Возможно аргумент для MENU добавится, неявный. Есть 2 варианта:
1) После вызова в ARGS[0] хранится индекс выбранного пункта меню.
2) После вызова в $ARGS[0] хранится название выбранного пункта меню.

Вообще, 20 локаций - не так уж много)

 Отправлено: 10.06.09 12:10. Заголовок: Byte пишет: Возможн..

Byte пишет:

цитата:

Возможно аргумент для MENU добавится, неявный. Есть 2 варианта: 1) После вызова в ARGS[0] хранится индекс выбранного пункта меню. 2) После вызова в $ARGS[0] хранится название выбранного пункта меню.

это будет просто отлично
Byte пишет:

цитата:

Вообще, 20 локаций - не так уж много)

Просто хотелось упростить себе жизнь, при большой нужде и 100 локаций добавить не проблема.

 Отправлено: 10.06.09 13:06. Заголовок: А если по команде ME..

А если по команде MENU нужно будет вызвать пользовательскую функцию с параметрами?

P.S. наверняка есть более простое решение.

 Отправлено: 10.06.09 13:08. Заголовок: Можно будет вызвать ..

Можно будет вызвать FUNC('моя ф-я',1,2,ARGS[0]) - оно будет нормально работать.