Форум » » преимущества платформы qsp » Ответить

преимущества платформы qsp

abcdef: какими удобствами и преимуществами обладает платформа qsp? например в сравнении с urq

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

Ntropy: Hertz можно зайти по ссылке irc://irc.forestnet.org:6662/qsp

Aleks Versus: Есть очень большой плюс у QSP. Очень простой язык.

Ajenta: Ну у урки вроде как ещё проще :))


Eten: Aleks Versus пишет: Есть очень большой плюс у QSP. Очень простой язык. Хм, насколько помнится для авторов с гуманитарным уклоном, т.е. действительно авторам, qsp сложноват. Т.к. гуманитарии не очень смыслят в теории алгоритмов и ее применении. Написать что-то приличное без определенных знаний на qsp, одними базовыми средствами, на такое надо быть реально виртуазом простых вещей. ... Дальше полагаю объяснять не надо. Хорошие примеры, это прежде всего примеры людей знакомых с программированием, не более. На урке язык проще, но и ограничения есть. На куспе язык функциональней, но это не предел возможностей. Это только следующая ступень. В общем позабавила меня данная тема. З.Ы. "Бурление - это наша профессия!" (c) Анонимный тролль.

Nex: для авторов с гуманитарным уклоном, т.е. действительно авторам А те, кто разбирается в программировании, по-твоему, не настоящие авторы?

Eten: Nex пишет: А те, кто разбирается в программировании, по-твоему, не настоящие авторы? Я имел ввиду людей с литературным талантом, которым не ведомо программирование.

Nex: Eten одно другому мешает?

Eten: Nex пишет: Eten одно другому мешает? Лично у самих авторов спросить не довелось, от других узнал, с кем они имели дело. В общем тендеция такова, что авторам было не очень привычно работать. Я так полагаю, что это тоже самое, как сравнивать С++ с действительно ориентированным языком для ООП. Говоря проще язык немного сложноват в некоторых местах. Да и по ходу работы со своим долгостроем, выявилась такая мысль. У нас еще не было возможности создавать блоки кода заранее скомпилированные под определенную игру..., дабы избавить авторов от излишнего программирования, когда оно для них действительно излишне. Т.к. уже отработанные методы и стил написания у квестов в стиле "квест в игре" или "квест в квесте" не требуют сущевственных изменений в алгоритме. Плюс к этому, неплохо иметь возможность писать также, как например на QSP. Да, такое в принципе реализуется через библиотеки. Но в данном случае на мой взгляд, это все проще запрятать в операторы. Ну не писать же еще один язык. Замечу, что в каждом случае выявившиеся методы, создающие характерный стиль квестов, могут быть разными, что напрочь убивает саму идею об использовании библиотек общного типа (библиотеки - это упрощение только с т.з. программиста). Применив такой подход можно упростить создание квестов для определенной игровой тематики, например как для написания их для Космических Рейнджеров, учитывая их стиль. Или даже создание приличной текстовой РПГ, с хорошими квестами в жанре ИЛ. Вот именно такого подхода доселе я еще не видел. У себя такую тему уже давно продумываю. Интересно, а в QSP-е это как реализовано? З.Ы. Хотя, кто его знает. Может я слишком широко смотрю на возможности в квестостроении.

Nex: Ты не ответил на вопрос. А про "альтернативу библиотекам" вообще непонятно, что имел в виду. Если понимать буквально, про "блоки кода скомпилированные заранее", то в QSP никогда не было компиляции. И надеюсь, не будет.

Eten: Nex пишет: Ты не ответил на вопрос. А про "альтернативу библиотекам" вообще непонятно, что имел в виду. Если понимать буквально, про "блоки кода скомпилированные заранее", то в QSP никогда не было компиляции. И надеюсь, не будет. На вопрос я ответил развернутым постом. Тем более начале было указан ответ. Насколько ясно из поста, людям с гуманитарным складом ума или как-то там еще это мешает. Насчет предварительной компиляции твой ответ сомнений не вызывает, т.к. выше собственной головы не прыгнешь. QSP - это интерпритатор все-таки. Но вот в полезности такой фичи не сомневаюсь, есть места где это очень удобно применять. Но я это имею ввиду, как дополнение, а не основу. А про библиотеки говорить смысла нет, раз не понятно. З.Ы. Да, и сам QSP можно выразить, ввиде предкомпилированных блоков кода, заменив их операторами. Т.е. по сравнению с уркой он функциональней, но не более.

Nex: Человек с гуманитарным складом ума = "настоящий автор"?

Byte: Ничего не понятно :)

Piligrim: По моему, Eten имел в виду возможность вызывать локации с параметрами из подключаемых файлов, если выражаться в терминах QSP :), только не понятно почему они должны быть обязательно компилированными :(

Nex: Piligrim ты выразился еще непонятнее O_o

rrock.ru: Я ПОНЯЛ, Я ПОНЯЛ!!!! вроде... Так вот.. имелось ввиду то, что допустим во многих играх разных авторов используются одни и те же куски кода.. Так вот: Eten предложил убрать эти куски в дополнительные подключаемые библиотеки ( но, если не ошибаюсь, я где-то про это уже читал на этом форуме.. ), либо спрятать их за дополнительными операторами языка QSP... вот!

Nex: rrock.ru нет, библиотеки делать Eten не предлагал. Да и тем более возможность такая уже давно есть.

rrock.ru: Nex ну значит 2-ой вариант

Eten: rrock.ru пишет: Nex ну значит 2-ой вариант Эврика!! Долго же ждать пришлось, пока до вас дойдет. Вся фишка в том что, в играх большого масштаба, удобнее прятать один и тот же код под операторы. Для этого и нужна предкомпиляция, хммм.... (как бы проще выразить).... например, как в Linux. Он один, а сборки разные. Так и тут, основные операторы всегда одни, а вариации (т.е. сборки) для QSP разные. Говоря по простому у QSP нет возможности компиляции операторов в нужном направлении. Например, создать операторы для работы с инвертарем, когда заранее известен механизм действия с объектами. Насколько помню, в QSP-е можно реализовывать механизм работы с инвертарем по разному и самому, ручками. Для этого создаем все нужные операторы для работы с объектами инвертаря и компилим с основными операторами вместе и вуаля, новый QSP заточенный под вашу игру. Это особенно полезно для движка.... Для меня проще иметь язык низкого уровня, чтобы описать операторы языка QSP и вписать дополнительные операторы. Хмм...., используя возможности QSP это можно реализовать только возможностями библиотек функций в программерском стиле и то, как в PHP убрать необходимость писать аргументы в скобках. Упростим вопрос. В QSP есть возможность или предпросылки к тому, чтобы мочь создавать новые операторы на основе базовых, не прибегая при этом к изменению исходников самой платформы? Замечу, что новые операторы должны использоваться также, как и базовые, т.е. без заморочек.

Eten: Кста, Byte, все время хотел спросить, хотя бы в рамках темы. Почему ты логику языка написал не на Си++, а просто на Си? Лично я пока понял так. Компилятор Си++ сущевствует для каждой ОС свой, а на Си сами ОС. Т.е. у Си больше кросплатформенности. Но правильно ли я понял? Не упустил ли я чего? Да и насколько мне помнитеся еще, в Си нет работы с объектами, как в Си++.

Byte: Eten пишет: В QSP есть возможность или предпросылки к тому, чтобы мочь создавать новые операторы на основе базовых, не прибегая при этом к изменению исходников самой платформы? Да. Eten пишет: Почему ты логику языка написал не на Си++, а просто на Си? Переносимость выше.



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