Автор | Сообщение |
|
Отправлено: 18.01.09 19:19. Заголовок: Продвинутые возможности QSP-языка
Во-первых, хотелось бы поблагодарить создателя движка за отличную работу. Впечатляет, без смайлов! Но, во-вторых, к сожалению, бросается в глаза некоторая несбалансированность самого языка. Например, отсутствует поддержка функций, определенных пользователем (про объекты, которые значительно облегчают написание сколько-нибудь сложных игр я не говорю...). Эта ограниченность приводит к необходимости использовать обходные пути, использовать локации и инвентарь явно не по назначению и т.д., что в дальнейшем затрудняет понимание и редактирование собственного кода :( Разумеется, это объясняется тем, что язык рассчитан в идеале для людей, слабо разбирающих в программировании, но при этом присутствует такая продвинутая фича, как динамическая генерация кода, для адекватного использования которой требуется серьезный опыт кодинга. Хотелось бы задать вопрос - будет ли язык развиваться в плане добавления новых возможностей, таких как функции и классы? Заранее спасибо за ответ!
| |
Профиль
Цитата
Ответить
|
Новых ответов нет
, стр:
1
2
3
4
All
[см. все]
|
|
|
Отправлено: 18.01.09 20:13. Заголовок: Функций и классов не..
Функций и классов не будет, думаю. Конструкции вида свойство1["предмет"]=56 $свойство2["предмет"]='sdsd' свойство1[$obj]=234 позволяют легко обходиться без классов, предоставляя бОльшую гибкость. Функции добавят такое понятие, как "локальные переменные". Возможно, появятся оператор добавления значений на стек и ф-я получения значения со стека. Но, в абсолютном большинстве случаев, легко обойтись без локальных переменных, так что не вижу особого смысла их вводить.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 20:45. Заголовок: Спасибо за ответ :) ..
Спасибо за ответ :) Обойтись можно, конечно :) Сейчас язык позволяет реализовать практически все, что только может в голову прийти :) ПыСы. А что, локальные переменные - это такое ЗЛО? :)
| |
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 18.01.09 21:54. Заголовок: luciofulci локальные..
luciofulci локальные переменные заставят новичков печься о таких понятиях, как "область видимости", а это усложнит им жизнь => вредно. Если движок у игры "с хитростями", то поможет GOSUB, а если не поможет GOSUB, поможем мы, то есть этот форум. Новички - приоритет, и это всё решает.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 22:25. Заголовок: Само введение функци..
Само введение функций, классов и т.д. не означает необходимость их использования. Например, динамическая генерация кода ("код как данные") - это концепция уровнем гораздо выше, чем область видимости, но тем не менее в QSP она есть и никому не мешает. Тот же объектно-ориентированный подход органично вписывается в разработку игр, так в них мы имеем дело с большим количеством объектов, таких как магазины, персонажи и т.д. Все это в рамках движка не предусмотришь. Повторюсь, сделать все это возможно и без классов с функциями, но вот реализация будет связана с трехэтажными хаками, write-only кодом и копипастом, когда чтобы поправить какую-то мелочь, нужно править ее в десятке мест. Проще ли это для новичков, чем локальные переменные? Не уверен.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 22:43. Заголовок: я не понимаю, зачем ..
я не понимаю, зачем нужны классы, когда есть более лёгкое в освоении и с не меньшими возможностями/удобством: свойство1["предмет"]=56 $свойство2["предмет"]='sdsd' свойство1[$obj]=234 любой класс можно описать через это, вместе с наследованием (насколько это возможно без локальных переменных). "объекты" передаются посредством их имени.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:00. Заголовок: luciofulci пишет: П..
luciofulci пишет: цитата: | Повторюсь, сделать все это возможно и без классов с функциями, но вот реализация будет связана с трехэтажными хаками, write-only кодом и копипастом, когда чтобы поправить какую-то мелочь, нужно править ее в десятке мест. |
| Да нет здесь "трёхэтажных хаков". И копипаста можно успешно избежать :-)
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:05. Заголовок: В принципе, типы впо..
В принципе, типы вполне можно реализовать через массивы со строковыми индексами. Классы используются именно для упрощения организации кода, когда, например, чтобы изменить поведение всех НПС определенного вида нужно изменить пару строк в определении этого вида, и все. Разумеется, для небольших проектов это абсолютно избыточная идея, да, но вот в более-менее сложных они серьезно облегчают жизнь. К тому же повторюсь, ООП - органично вписывается в написание игр, так, что с новичками проблем быть не должно, если в этом дело. Конечно, у меня нет никакого права никому ничего советовать, только размышлять об идеальном сферическом движке в вакууме :(. Хотя вот сейчас пишу игру на QSP, так вот по мере написания могу более четко сформулировать свои предложения - если это интересно, конечно.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:14. Заголовок: А функции с параметр..
А "функции" с параметрами, возможно, будут в 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
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:18. Заголовок: Поясню, что понимаю ..
Поясню, что понимаю под хаком. Это когда элементы языка явно используются не по назначению. Например, в одной дружественной платформе локации используются для всего чего угодно - например, для организации циклов :) Это разрушает абстракцию и нарушает стройность дизайна. Локация - это локация. Это некоторое место, которое игрок посещает, а не просто несколько строк кода. В куспе добавлены метки и одна эта фича уже позволяет локациям избежать подобного "насилия". Ну, вот что-то в этом духе...
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:27. Заголовок: Byte пишет: А функц..
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' |
| Круто При таком раскладе без классов вполне можно будет обойтись :)
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 18.01.09 23:40. Заголовок: Передать несколько п..
Передать несколько параметров в gs и сейчас не сложно )
| |
Профиль
Цитата
Ответить
|
|
|
Отправлено: 18.01.09 23:59. Заголовок: Ну, не сложно то не ..
Ну, не сложно то не сложно, только геморно немного и выглядит довольно жутко. Да и использовать локацию в качестве функции,... гм. Кстати, не рассматривается возможность передачи DYNAMIC параметров в том же виде, что и GOSUB? В смысле что-то типа dynamic $code_block, arg1, arg2, arg3... соответственно с заполнением массива args?
| |
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 19.01.09 00:53. Заголовок: Вы ребята что-то ..
Вы ребята что-то страшное решили сотворить на куспе... а на самом деле тех же локаций и переходов порой бывает достаточно для полноценной игры.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 02:25. Заголовок: Сделал аргументы для..
Сделал аргументы для GS. Правда, увидеть это можно будет только в след. версии.
| |
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 19.01.09 10:43. Заголовок: Byte как насчёт пере..
Byte как насчёт передачи по ссылке?
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 11:31. Заголовок: HIman пишет: Вы реб..
HIman пишет: цитата: | Вы ребята что-то страшное решили сотворить на куспе... |
| Сейчас готовлю небольшой тутор для реализации классов на куспе, создание класса с полями и методами, создание экземпляров класса, наследованием :) Все это можно осуществить на нынешней версии QSP, правда код явно не для слабонервных Byte пишет: цитата: | Сделал аргументы для GS. Правда, увидеть это можно будет только в след. версии. |
| А нельзя ли поделиться development билдом?
| |
Профиль
Цитата
Ответить
|
|
| moderator
|
|
|
Отправлено: 19.01.09 11:35. Заголовок: Классы будут, функци..
Классы будут, функции будут, поля и методы, наследование будет, а игра-то будет? Или как всегда? Куча кода, игры нет?
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 12:17. Заголовок: Поменял название тем..
Поменял название темы :) Допустим у меня есть множество игровых объектов, у которых есть несколько свойств: 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), второе (и главное) уже сейчас решается полностью. Подробнее - в следующем сообщении.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 13:05. Заголовок: Окей, вот как выгляд..
Окей, вот как выглядит код локации-подпрограммы, создающей подобные объекты: цитата: | $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" |
| То есть изменяю одну строку кода в одном месте, а не в десяти.
| |
Профиль
Цитата
Ответить
|
|
Отправлено: 19.01.09 13:40. Заголовок: По поводу игры - для..
По поводу игры - для меня именно эта возможность стала узким местом, реализовать я ее сумел только после долгого, вдумчивого чтения хелпа и бесчеловечных опытов над dynamic'ом. Если кому интересно, могу пояснить, что вся эта тарабарщина значит и как самому делать подобные штуки, например, для генерации врагов и прочих неписей. До генерации локаций я еще не дошел - просто мне это на данный момент не нужно.
| |
Профиль
Цитата
Ответить
|
Новых ответов нет
, стр:
1
2
3
4
All
[см. все]
|
|
|