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

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

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

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

Byte: Функций и классов не будет, думаю. Конструкции вида [pre2] свойство1["предмет"]=56 $свойство2["предмет"]='sdsd' свойство1[$obj]=234[/pre2] позволяют легко обходиться без классов, предоставляя бОльшую гибкость. Функции добавят такое понятие, как "локальные переменные". Возможно, появятся оператор добавления значений на стек и ф-я получения значения со стека. Но, в абсолютном большинстве случаев, легко обойтись без локальных переменных, так что не вижу особого смысла их вводить.

luciofulci: Спасибо за ответ :) Обойтись можно, конечно :) Сейчас язык позволяет реализовать практически все, что только может в голову прийти :) ПыСы. А что, локальные переменные - это такое ЗЛО? :)

Nex: luciofulci локальные переменные заставят новичков печься о таких понятиях, как "область видимости", а это усложнит им жизнь => вредно. Если движок у игры "с хитростями", то поможет GOSUB, а если не поможет GOSUB, поможем мы, то есть этот форум. Новички - приоритет, и это всё решает.


luciofulci: Само введение функций, классов и т.д. не означает необходимость их использования. Например, динамическая генерация кода ("код как данные") - это концепция уровнем гораздо выше, чем область видимости, но тем не менее в QSP она есть и никому не мешает. Тот же объектно-ориентированный подход органично вписывается в разработку игр, так в них мы имеем дело с большим количеством объектов, таких как магазины, персонажи и т.д. Все это в рамках движка не предусмотришь. Повторюсь, сделать все это возможно и без классов с функциями, но вот реализация будет связана с трехэтажными хаками, write-only кодом и копипастом, когда чтобы поправить какую-то мелочь, нужно править ее в десятке мест. Проще ли это для новичков, чем локальные переменные? Не уверен.

Byte: я не понимаю, зачем нужны классы, когда есть более лёгкое в освоении и с не меньшими возможностями/удобством: [pre2] свойство1["предмет"]=56 $свойство2["предмет"]='sdsd' свойство1[$obj]=234[/pre2] любой класс можно описать через это, вместе с наследованием (насколько это возможно без локальных переменных). "объекты" передаются посредством их имени.

Byte: luciofulci пишет: Повторюсь, сделать все это возможно и без классов с функциями, но вот реализация будет связана с трехэтажными хаками, write-only кодом и копипастом, когда чтобы поправить какую-то мелочь, нужно править ее в десятке мест. Да нет здесь "трёхэтажных хаков". И копипаста можно успешно избежать :-)

luciofulci: В принципе, типы вполне можно реализовать через массивы со строковыми индексами. Классы используются именно для упрощения организации кода, когда, например, чтобы изменить поведение всех НПС определенного вида нужно изменить пару строк в определении этого вида, и все. Разумеется, для небольших проектов это абсолютно избыточная идея, да, но вот в более-менее сложных они серьезно облегчают жизнь. К тому же повторюсь, ООП - органично вписывается в написание игр, так, что с новичками проблем быть не должно, если в этом дело. Конечно, у меня нет никакого права никому ничего советовать, только размышлять об идеальном сферическом движке в вакууме :(. Хотя вот сейчас пишу игру на QSP, так вот по мере написания могу более четко сформулировать свои предложения - если это интересно, конечно.

Byte: А "функции" с параметрами, возможно, будут в QSP 5.5 :) Будет gs 'proc',2,3,4,'test',$sdsd При этом заполняется массив 'args' args[0]=2 args[1]=3 args[2]=4 $args[3]='test' $args[4]='fddfd' Функции - eval('proc',2,4) Результат из ф-и передаётся н-р через переменную $result

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

luciofulci: Byte пишет: А функции с параметрами, возможно, будут в QSP 5.5 :) Будет gs 'proc',2,3,4,'test',$sdsd При этом заполняется массив 'args' args[0]=2 args[1]=3 args[2]=4 $args[3]='test' $args[4]='fddfd' Круто При таком раскладе без классов вполне можно будет обойтись :)

Byte: Передать несколько параметров в gs и сейчас не сложно )

luciofulci: Ну, не сложно то не сложно, только геморно немного и выглядит довольно жутко. Да и использовать локацию в качестве функции,... гм. Кстати, не рассматривается возможность передачи DYNAMIC параметров в том же виде, что и GOSUB? В смысле что-то типа dynamic $code_block, arg1, arg2, arg3... соответственно с заполнением массива args?

HIman: Вы ребята что-то страшное решили сотворить на куспе... а на самом деле тех же локаций и переходов порой бывает достаточно для полноценной игры.

Byte: Сделал аргументы для GS. Правда, увидеть это можно будет только в след. версии.

Nex: Byte как насчёт передачи по ссылке?

luciofulci: HIman пишет: Вы ребята что-то страшное решили сотворить на куспе... Сейчас готовлю небольшой тутор для реализации классов на куспе, создание класса с полями и методами, создание экземпляров класса, наследованием :) Все это можно осуществить на нынешней версии QSP, правда код явно не для слабонервных Byte пишет: Сделал аргументы для GS. Правда, увидеть это можно будет только в след. версии. А нельзя ли поделиться development билдом?

Nex: Классы будут, функции будут, поля и методы, наследование будет, а игра-то будет? Или как всегда? Куча кода, игры нет?

luciofulci: Поменял название темы :) Допустим у меня есть множество игровых объектов, у которых есть несколько свойств: name, description, seen, а также метод show_description для вывода описания. Ничего особенного. Можно реализовать это в виде массива: $old_table['name'] = "Cтарый стол" old_table['seen'] = 0 $old_table['description'] = "Массивный стол с потрескавшейся лакировкой." $old_table['show_desc'] = "$old_table['seen'] = -1 & clear & p old_table['show_desc'] & goto $curloc" Теперь, например, можно добавить в окно описания локации следущий текст, не забыв где-то вначале активировать USEHTML: <a href="exec:dynamic $old_table['show_desc']">старый стол</a> Или добавить действие, в теле которого просто написать: dynamic $old_table['show_desc'] Когда игрок кликнет на эту ссылку или нажмет на кнопку действия, он увидит в окне дополнительного описания описание старого стола, а локация перезагрузится на тот, случай, если в ней, допустим, есть проверка на то, осмотрел ли игрок стол. Допустим, у меня в игре штук 20 таких объектов и меня возникает два естественных желания - упростить процесс их создания и, главное, иметь возможность контролировать формат вывода описания где-то в одном месте. Первое решается частично с учетом существующих возможностей языка (полностью - когда будет введена возможность передачи аргументов в gs), второе (и главное) уже сейчас решается полностью. Подробнее - в следующем сообщении.

luciofulci: Окей, вот как выглядит код локации-подпрограммы, создающей подобные объекты: $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 = "" Код, создающий локации в нынешней версии, выглядит так: $args[0] = "old_table" $args[1] = "Старый стол" $args[2] = "Массивный стол с потрескавшейся лакировкой." gs "make_item" В будующей версии все будет несколько проще: gs "make_item", "old_table", "Старый стол", "Массивный стол с потрескавшейся лакировкой." Допустим, я создал с десяток таких объектов и захотелось мне, чтобы show_desc включал в себя название объекта. Я беру код локации make_item и заменяю $show_desc = "<<$self>>['seen'] = -1 & clear & p $<<$self>>['desc'] & gt $curloc" на $show_desc = "<<$self>>['seen'] = -1 & clear & pl $<<$self>>['name'] & p $<<$self>>['desc'] & gt $curloc" То есть изменяю одну строку кода в одном месте, а не в десяти.

luciofulci: По поводу игры - для меня именно эта возможность стала узким местом, реализовать я ее сумел только после долгого, вдумчивого чтения хелпа и бесчеловечных опытов над dynamic'ом. Если кому интересно, могу пояснить, что вся эта тарабарщина значит и как самому делать подобные штуки, например, для генерации врагов и прочих неписей. До генерации локаций я еще не дошел - просто мне это на данный момент не нужно.



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