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

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

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

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

 Отправлено: 19.01.09 14:37. Заголовок: А не проще ли сделат..

А не проще ли сделать так:

#showDesc
p $desc[$o]
seen[$o]=-1
! ...
--

#makeObj
$name[$o]=$o
$desc[$o]=$d
seen[$o]=0
--

Добавляем предметы так: $o='ящик' & $d='обычный ящик' & gs 'makeObj'
Показываем описания через $o='ящик' & gs 'showDesc'

То есть, зная имя предмета, можно вызвать единственный метод показа описания. Дублировать код показа также не нужно, он находится в одном месте для всех предметов.

 Отправлено: 19.01.09 14:59. Заголовок: Можно и так. Но мне ..

Можно и так. Но мне просто не нравится множить служебные локации, так как с каждой функцией (методом) необходимо создавать новую локацию. Но это как кому нравится :)

 Отправлено: 19.01.09 15:18. Заголовок: Даже в этом случае $..

Даже в этом случае

 
 $self = $args[0] 
  
 dynamic "$<<$self>>['name'] = $args[1]" 
 dynamic "$<<$self>>['desc'] = $args[2]" 
 dynamic "<<$self>>['seen'] = 0" 
  
 $show_desc = "<<$self>>['seen'] = -1 & clear & p $<<$self>>['desc'] & gt $curloc" 
 dynamic "$<<$self>>['show_desc'] = $show_desc" 
  
 $show_desc = "" & $self = ""

заменяется на более простое

 
 $self=$args[0] 
  
 $name[$self]=$args[1] 
 $desc[$self]=$args[2] 
 seen[$self]=0 
 $show_desc[$self]="seen['<<$self>>']=-1 & clear & p $desc['<<$self>>'] & gt $curloc"

Вызов н-р dynamic $show_desc['стол'] или dynamic $show_desc[$obj]

 Отправлено: 19.01.09 15:30. Заголовок: Да, спасибо, так дей..

Да, спасибо, так действительно лучше

 Отправлено: 19.01.09 15:33. Заголовок: Рады помочь :)..

Рады помочь :)

 Отправлено: 19.01.09 15:40. Заголовок: luciofulci, в стиле ..

luciofulci, в стиле ООП можно писать и на QSP.

цитата:

То есть изменяю одну строку кода в одном месте, а не в десяти.

допустим, есть сотня столов разных цветов, форм, размеров, и имеющие различные атрибуты местонахождения. и есть локация "показать". и есть переменные арг1, арг2, арг3,... . тогда меняем реакцию локации "показать" в одном месте программы. а не в ста. всё. и все эти заморочки с динамиком и т п - лишние.

цитата:

Локация - это локация. Это некоторое место, которое игрок посещает, а не просто несколько строк кода.

такой подход бывает крайне неудобен. пример: генерим мир 8х8 полей. получаем 64 локации. значит ли это, что в тексте программы должно появиться ещё 64-ре локации??

цитата:

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

удивительно. не слыхал пока о платформах без меток. впрочем, нет- в РТАДС и ТОМ, вроде бы обходятся без них.

UPD

насчёт столов и служебных локаций: да, зря в урке и куспе это названо локациями. потому как реально это- никакие не локации. то, что называется в этих платформах локациями- скорее такие особые функции/подпрограммы/куски. короче, что угодно. и с 'локациями' игрового мира зря путаницу внесли.

 Отправлено: 19.01.09 16:02. Заголовок: noname пишет: lucio..

noname пишет:

цитата:

luciofulci, в стиле ООП можно писать и на QSP.

Кто же спорит??

noname пишет:

цитата:

допустим, есть сотня столов разных цветов, форм, размеров, и имеющие различные атрибуты местонахождения. и есть локация "показать". и есть переменные арг1, арг2, арг3,... . тогда меняем реакцию локации "показать" в одном месте программы. а не в ста. всё. и все эти заморочки с динамиком и т п - лишние.

Да я понял уже эту фишку с show_desc. Правда метод show_desc для разного типа объектов может (и по идее должна) выполнять разные функции. И - если уж говорить об ООП - должна быть частью объекта.
В моем примере - реализация практически чистого ООП. Код опять же можно упростить добавив локации-обработчики. Для меня просто удобнее писать

цитата:

dynamic $old_table['show_desc']

, чем

цитата:

$o='old_table' & gs 'show_description'

, не более того :)

noname пишет:

цитата:

удивительно. не слыхал пока о платформах без меток. впрочем, нет- в РТАДС и ТОМ, вроде бы обходятся без них.

Разумеется, в TADS и TOM обходятся без них -там они абсолютно не к месту. А вот в urql, допустим, метки и локации - одно и то же. По крайней мере в стандартной версии.

 Отправлено: 19.01.09 16:42. Заголовок: Например, в C++ мето..

Например, в C++ методы классов являются самостоятельными функциями, просто первым "скрытым" аргументом в них передаётся адрес объекта (фактически, просто структуры с полями данных). Именно через этот адрес метод может получить доступ к полям структуры, для которой вызывался метод.

В QSP таким "адресом структуры" может являться имя объекта, через которое мы можем получить доступ к свойствам объекта.
код в сообщении http://qsp.borda.ru/?1-0-0-00000154-000-20-0#017 этой темы - тому пример.

 Отправлено: 19.01.09 17:01. Заголовок: Извините меня, пожа..

цитата:

Извините меня, пожалуйста, но предмет вашей ученой беседы настолько интересен, что...

ООП это стиль мысли а не язык. Можно писать на ассемлере объектно-ориентированный код, а можно в С++ наваять такого, что лучше бы классы вообще не трогать.
Если же говорить о языках, то язык либо содержит СПЕЦИАЛЬНЫЕ средства, поддерживающие ООП, либо их там нет. Все ИМХО.

 Отправлено: 19.01.09 17:11. Заголовок: Здесь речь идёт не к..

Здесь речь идёт не конкретно о языке, а о подходе, который можно реализовать на нём. Вот и всё.

 Отправлено: 19.01.09 17:43. Заголовок: luciofulci пишет: А ..

luciofulci пишет:

цитата:

А вот в urql, допустим, метки и локации - одно и то же.

почти одно и то же. в куспе же введены некоторые искуственные ограничения для их пущего различия. хорошо, хоть цикл в пределах локации всё-таки и на нём можно сделать. писать в стиле ООП на куспе можно, но ИМХО можно найти более удобный в рамках этого языка подход. поэтому в моём предложении и не было оопа.

впрочем, пока больше ничего писать сюда не буду, что бы не зафлудить тему...

 Отправлено: 19.01.09 17:58. Заголовок: Безусловно на куспе ..

Безусловно на куспе и урке удобнее писать по-другому. Но просто на определенном этапе хочется чуть большей организации и порядка, тогда ООП-подобный дизайн становится почти необходимостью, несмотря на определенные неудобства.

 Отправлено: 19.01.09 18:22. Заголовок: luciofulci милену см..

luciofulci милену смотрел?
там всё что хошь для заядлого программера. и тебе циклы, и функции, и тырпыр.

 Отправлено: 19.01.09 18:45. Заголовок: Может, посмотрю... П..

Может, посмотрю...
Просто на этот раз все-таки хотелось бы закончить игру. А то рано или поздно все вернется к старым заготовкам для python и вместо того, чтобы писать игру, буду долбить движок...

 Отправлено: 19.01.09 21:11. Заголовок: luciofulci чтоб тако..

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

 Отправлено: 20.01.09 00:54. Заголовок: Теперь добавил и фун..

Теперь добавил и функцию EVAL:

 
 #fact 
 if args[0]=1: 
 	result=1 
 else 
 	result=args[0]*eval('fact',args[0]-1) 
 end 
 --

вызываем как eval('fact',5)

Думаю, возможно имеет смысл сменить название на FUNC ?

UPD: Решил переименовать в FUNC. Ещё добавил функцию ARRSIZE($имя_массива) - возвращает число элементов массива.

 Отправлено: 20.01.09 15:19. Заголовок: Еще заметил в хелпе:..

Еще заметил в хелпе:

цитата:

Как проверить, был ли герой на какой-либо локации? 1) На той локации, которую нужно проверить, введите: set был_здесь=1 А на локации, где нужно это проверить: if был_здесь=1:[операторы] или: if был_здесь:[операторы] 2) Через массивы, с индексированием через строки: was_here[$curloc] = 1 Проверка: if was_here['башня']:[операторы]

По поводу второго способа, можно добавить, что was_here[$curloc] = -1 можно написать в коде локации, установленной в переменной $onnewloc , тогда на was_here можно проверять любую локацию в игре.

 Отправлено: 20.01.09 15:57. Заголовок: luciofulci где-то зд..

luciofulci где-то здесь уже об этом писали... Но в хелп да, нужно добавить пример про $onnewloc.

 Отправлено: 20.01.09 16:29. Заголовок: Может, кто-нибудь во..

Может, кто-нибудь возьмётся за доработку справки? А я вышлю альфу QSP 5.5

 Отправлено: 20.01.09 16:53. Заголовок: Может сделать что-то..

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