Автор | Сообщение |
|
Отправлено: 18.01.09 19:19. Заголовок: Продвинутые возможности QSP-языка
Во-первых, хотелось бы поблагодарить создателя движка за отличную работу. Впечатляет, без смайлов! Но, во-вторых, к сожалению, бросается в глаза некоторая несбалансированность самого языка. Например, отсутствует поддержка функций, определенных пользователем (про объекты, которые значительно облегчают написание сколько-нибудь сложных игр я не говорю...). Эта ограниченность приводит к необходимости использовать обходные пути, использовать локации и инвентарь явно не по назначению и т.д., что в дальнейшем затрудняет понимание и редактирование собственного кода :( Разумеется, это объясняется тем, что язык рассчитан в идеале для людей, слабо разбирающих в программировании, но при этом присутствует такая продвинутая фича, как динамическая генерация кода, для адекватного использования которой требуется серьезный опыт кодинга. Хотелось бы задать вопрос - будет ли язык развиваться в плане добавления новых возможностей, таких как функции и классы? Заранее спасибо за ответ!
|
|
Профиль
Цитата
Ответить
|
Ответов - 72
, стр:
1
2
3
4
All
[только новые]
|
|
|
Отправлено: 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. Заголовок: Безусловно на куспе ..
Безусловно на куспе и урке удобнее писать по-другому. Но просто на определенном этапе хочется чуть большей организации и порядка, тогда ООП-подобный дизайн становится почти необходимостью, несмотря на определенные неудобства.
|
|
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 19.01.09 18:22. Заголовок: luciofulci милену см..
luciofulci милену смотрел? там всё что хошь для заядлого программера. и тебе циклы, и функции, и тырпыр.
|
|
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 18:45. Заголовок: Может, посмотрю... П..
Может, посмотрю... Просто на этот раз все-таки хотелось бы закончить игру. А то рано или поздно все вернется к старым заготовкам для python и вместо того, чтобы писать игру, буду долбить движок...
|
|
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 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 можно проверять любую локацию в игре.
|
|
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 20.01.09 15:57. Заголовок: luciofulci где-то зд..
luciofulci где-то здесь уже об этом писали... Но в хелп да, нужно добавить пример про $onnewloc.
|
|
Профиль
Цитата
Ответить
|
|
Отправлено: 20.01.09 16:29. Заголовок: Может, кто-нибудь во..
Может, кто-нибудь возьмётся за доработку справки? А я вышлю альфу QSP 5.5
|
|
Профиль
Цитата
Ответить
|
|
Отправлено: 20.01.09 16:53. Заголовок: Может сделать что-то..
Может сделать что-то типа вики с возможностью загрузить снэпшот в архиве? А так я мог бы, конечно, обновлять справку по ходу работы с игрой. Альфу тоже протестировать не отказался бы
|
|
Профиль
Цитата
Ответить
|
Ответов - 72
, стр:
1
2
3
4
All
[только новые]
|
|