Форум » » Продвинутые возможности QSP-языка » Ответить

Продвинутые возможности QSP-языка

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

Ответов - 72, стр: 1 2 3 4 All

Byte: А не проще ли сделать так: #showDesc p $desc[$o] seen[$o]=-1 ! ... -- #makeObj $name[$o]=$o $desc[$o]=$d seen[$o]=0 -- Добавляем предметы так: $o='ящик' & $d='обычный ящик' & gs 'makeObj' Показываем описания через $o='ящик' & gs 'showDesc' То есть, зная имя предмета, можно вызвать единственный метод показа описания. Дублировать код показа также не нужно, он находится в одном месте для всех предметов.

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

Byte: Даже в этом случае [pre2] $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 = ""[/pre2] заменяется на более простое [pre2] $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"[/pre2] Вызов н-р dynamic $show_desc['стол'] или dynamic $show_desc[$obj]


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

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

noname: luciofulci, в стиле ООП можно писать и на QSP. То есть изменяю одну строку кода в одном месте, а не в десяти. допустим, есть сотня столов разных цветов, форм, размеров, и имеющие различные атрибуты местонахождения. и есть локация "показать". и есть переменные арг1, арг2, арг3,... . тогда меняем реакцию локации "показать" в одном месте программы. а не в ста. всё. и все эти заморочки с динамиком и т п - лишние.Локация - это локация. Это некоторое место, которое игрок посещает, а не просто несколько строк кода. такой подход бывает крайне неудобен. пример: генерим мир 8х8 полей. получаем 64 локации. значит ли это, что в тексте программы должно появиться ещё 64-ре локации?? Например, в одной дружественной платформе локации используются для всего чего угодно - например, для организации цикловудивительно. не слыхал пока о платформах без меток. впрочем, нет- в РТАДС и ТОМ, вроде бы обходятся без них. UPD насчёт столов и служебных локаций: да, зря в урке и куспе это названо локациями. потому как реально это- никакие не локации. то, что называется в этих платформах локациями- скорее такие особые функции/подпрограммы/куски. короче, что угодно. и с 'локациями' игрового мира зря путаницу внесли.

luciofulci: 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, допустим, метки и локации - одно и то же. По крайней мере в стандартной версии.

Byte: Например, в C++ методы классов являются самостоятельными функциями, просто первым "скрытым" аргументом в них передаётся адрес объекта (фактически, просто структуры с полями данных). Именно через этот адрес метод может получить доступ к полям структуры, для которой вызывался метод. В QSP таким "адресом структуры" может являться имя объекта, через которое мы можем получить доступ к свойствам объекта. код в сообщении http://qsp.borda.ru/?1-0-0-00000154-000-20-0#017 этой темы - тому пример.

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

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

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

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

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

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

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

Byte: Теперь добавил и функцию EVAL: [pre2] #fact if args[0]=1: result=1 else result=args[0]*eval('fact',args[0]-1) end --[/pre2] вызываем как eval('fact',5) Думаю, возможно имеет смысл сменить название на FUNC ? UPD: Решил переименовать в FUNC. Ещё добавил функцию ARRSIZE($имя_массива) - возвращает число элементов массива.

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

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

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

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



полная версия страницы