×Закрыть
👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Да троллинг это..... или действительно все уже выехали((

buisnes — эта 5 ))

Такое впечатление, что презентацию делал школьник, впервые видящий PowerPoint — разный размер шрифта на одинаковых по логике слайдах, нечитаемый красный текст на синем и т.п.
Я уже молчу про опечатки, ошибки орфографические и пунктуацию, полное неструктурирование информации на слайдах.

Кроме того, слова типа «глюкавые», «ахтунг» и прочее — сомневаюсь, что они в формате конференции воспримутся нормально

Презентация невыразимо чудовищна :))

Мое мнение — адский сумбур и война с ветряными мельницами.
XML — плохо читаем, лучше юзать json.
А еще лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код.
А еще лучше писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.

Интересно, кто то действительно програмит игровую логику в виде конечных автоматов?

лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код

Интерпретатор питона на экшенскрипте, или встроенный в андроид — программу будет работать невыразимо медленно. На столько медленно, что играть в такую игру никто не будет:не станет игрок ждать пару часиков, пока программа подумает какой ей ход сделать.

писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.

Нету такого средства, чтоб написать на питоне и получилась флеш игра. Для unity, JavaScript, Android, IoS тоже нету.

Возможно есть для всеми забытого J2ME.

Интересно, кто то действительно програмит игровую логику в виде конечных автоматов?

На самом деле, чуть менее, чем все. Просто у каждого этот автомат свой.

p.s. Спасибо за первый комментарий по сути

Интерпретатор питона на экшенскрипте
Так экшн скрипт вроде вполне сам по себе нормальный язычек для скриптования.
встроенный в андроид — программу будет работать невыразимо медленно
Есть конкретные бенчмарки?

экшн скрипт вроде вполне сам по себе нормальный язычек для скриптования.

Это не так. Экшен скрипт 3.0 язык императивный и строго типизированный — в качестве DSL не подходит. Я слабо себе представляю редактор диаграмм последовательностей, или состояний, который строит диаграмму по ActionScript коду. Да и вообще, мне кажется, внутренний DSL для такого дела плох. .

Кроме того, допустим в какой то системе язык подходит для создания внутреннего DSL. Где взять транслятор данного языка для других систем?

Получается, что при портировании игры на другую платформу логику придется переписывать, чего как раз и хотелось — бы избежать.

Есть конкретные бенчмарки?

Есть тесты интерпретаторов для Java, они работают медленно. Если это все перенести на андроид будет ещё медленнее ввиду особенностей железа мобилок и планшетов.

Получается, что при портировании игры на другую платформу логику придется переписывать, чего как раз и хотелось — бы избежать.

Ок, в интернете гуглится интерпретатор для флеша языка Lua, который есть и под андроид и под юнити и под иос.

И вообще я так понимаю флешовые игры запускаются на других платформах в портированном рантайме без всяких переписываний, а иначе перенос скриптовой части будет самой простой задачей в процессе портирования.

Есть тесты интерпретаторов для Java, они работают медленно. Если это все перенести на андроид будет ещё медленнее ввиду особенностей железа мобилок и планшетов.

А с чего ты взял что твой продукт кроме сильной обрезанности будет быстрее?

интерпретатор для флеша языка Lua, который есть и под андроид и под юнити и под иос.

Это интерпретатор, его скорость по определению меньше, чем скорость компилированного языка. Добавь сюда решение задач искусственного интеллекта. Таких, как поиск пути например, или поиск рационального хода, короче поиск на графе — ресурсоёмкие задачи с которыми и компилированный код справляется плохо. Кроме того, железо на всяких гаджетах явно хуже, чем на стандартном лаптопе. В общем, выходит что интерпретатор можно использовать только для скриптов верхнего уровня, которые запускаются один раз за игру

флешовые игры запускаются на других платформах в портированном рантайме без всяких переписываний

Да, но собственно логику писать на ActionScript никак не легче, то есть абсолютно:. Получается, если выбираем кроссплатформенность — получаем язык не удобный для DSL. Если с DSL все в порядке, решение будет не кроссплатформенным.

А с чего ты взял что твой продукт кроме сильной обрезанности будет быстрее?

Потому, что скрипты не перечитываются каждый раз, как в интерпретаторе. Из указанного языка формируется структура данных на компилированном языке, хранится она в памяти и это выходит на порядок быстрее, чем каждый раз интерпретировать скрипт.

Это интерпретатор, его скорость по определению меньше, чем скорость компилированного языка.

Ну ты же свой xml тоже не компилировать собрался?

Добавь сюда решение задач искусственного интеллекта. Таких, как поиск пути например, или поиск рационального хода, короче поиск на графе — ресурсоёмкие задачи с которыми и компилированный код справляется плохо.

Ну да, обычно такие вещи выносят в нативный язык а потомо вызывают из скрипта.

отому, что скрипты не перечитываются каждый раз, как в интерпретаторе. Из указанного языка формируется структура данных на компилированном языке, хранится она в памяти и это выходит на порядок быстрее, чем каждый раз интерпретировать скрипт.

С чего ты решил что будет каждый раз перечитываться? Я не знаю как там в луа сделано, но в питоне все компилится в промежуточный байт код. Ну и не факт что узкое место будет именно в парсинге а не в твоем коде.

И кстати по поводу автоматов:

На самом деле, чуть менее, чем все. Просто у каждого этот автомат свой.

пока что все игрухи которые я видел скриптовались или писались на нативных языках, никаких автоматов я еще не видел.

Ну ты же свой xml тоже не компилировать собрался?

Из XML собирается структура данных, она висит в оперативной памяти и никаких дополнительных расходов на интерпретацию не потребляет. Прочли один раз, сформировали конечный автомат и вуаля — все работает

обычно такие вещи выносят в нативный язык а потомо вызывают из скрипта.

Вот — вот, поэтому, даже в случае использования библиотек, как минимум оценочную функцию нужно реализовывать новую

в питоне все компилится в промежуточный байт код

Это в питоне, который у тебя установлен на обычном компьютере. Если питон встроен внутрь игры, это получается обыкновенный интерпретатор. Вот возьмем, например, флеш. Ты себе представляешь, как дергать питоновские функции изнутри броузера?

Я вот не представляю. Или возьмем игру для мобильного телефона, ты вместе с ней предлагаешь ставить питон, потом дергать его из игры? В аппсторе такую игру просто не пропустят и я не уверен, что такое можно сделать в принципе.

пока что все игрухи которые я видел скриптовались или писались на нативных языках, никаких автоматов я еще не видел

Если интересно, пиши в личку — дам тебе список литературы с примерами.

Из XML собирается структура данных, она висит в оперативной памяти и никаких дополнительных расходов на интерпретацию не потребляет. Прочли один раз, сформировали конечный автомат и вуаля — все работает

Ну вот когда твой код будет бегать по правилам перехода, это и называется интерпретацией, а компиляцией, это когда ты сгенерировал оптимизированный машинный код который это делает.

Вот — вот, поэтому, даже в случае использования библиотек, как минимум оценочную функцию нужно реализовывать новую

Как и в твоем xml подходе.

Ты себе представляешь, как дергать питоновские функции изнутри броузера?

В случае луа они используют adobe alchemy что бы ранать абсолютно тот же интерпретатор/компилятор что и у меня на компьютере.

когда твой код будет бегать по правилам перехода, это и называется интерпретацией

Не совсем. То что я видел для интерпретатора, к примеру, лиспа, на AS работает именно так — через eval строки.

По Lua я сырцы не смотрел, но посмотрю обязательно.

Как и в твоем xml подходе.

Нет, в XML — е эта функция будет задаваться один раз: её не нужно будет каждый раз писать новую. Это значит, что юниттесты будут работать одинаково.

они используют adobe alchemy что бы ранать абсолютно тот же интерпретатор/компилятор что и у меня на компьютере.

А на компьютере у тебя, ты думаешь, как то по другому все устроено? Просто C++ язык более быстрый, чем AS.

Да и даже будь он не вполне быстрым, Lua не подходит для создания DSL. В презентации это тоже сказано.

Не совсем. То что я видел для интерпретатора, к примеру, лиспа, на AS работает именно так — через eval строки.

По Lua я сырцы не смотрел, но посмотрю обязательно.

Лиспы всякие бывают, CLISP компилит вполне в байткод.

Нет, в XML — е эта функция будет задаваться один раз: её не нужно будет каждый раз писать новую.

Ты предлагаешь алгоритм поиска реализовать в твоем автоматном xml? Так и представляю себе обьявления о работе: ищутся програмисты автоматов Мили, знание машимы Тьюринга и частично-рекурсивных функций — большой плюс.

Да и даже будь он не вполне быстрым, Lua не подходит для создания DSL. В презентации это тоже сказано.

В презентации написано что причина отказа от скриптов — спагетти код. Я представляю себе какой лапша код будет писаться на твоем xml.

Лиспы всякие бывают, CLISP компилит вполне в байткод.

Да, но встроенным в игру может быть только интерпретатор. Особенно, если мы говорим о мобильной, или флешовой игре — интерпретатор медленный.

ищутся програмисты автоматов Мили, знание машимы Тьюринга и частично-рекурсивных функций — большой плюс.

Да нет, достаточно записать формулу. Оценочные функции обычно простые.

причина отказа от скриптов — спагетти код. Я представляю себе какой лапша код будет писаться на твоем xml.

DSL язык потому и хорош, что очень маленький — написать на нем спагетти не выйдет

Да, но встроенным в игру может быть только интерпретатор.

Интерпретироваться вполне может байт код, что вполне моожет оказаться быстрее твоих xmл структур.

Да нет, достаточно записать формулу. Оценочные функции обычно простые.

Ок, оценочная функция очень маленький кусок кода, а остальной алгоритм всяких оптимальных поисков будешь ведь переписывать под каждую платформу?

DSL язык потому и хорош, что очень маленький — написать на нем спагетти не выйдет

Для спагетти достаточно if then else, ну и луа и питон тоже маленькие.

Интерпретироваться вполне может байт код

То есть, ты предлагаешь написать транслятор лиспа в байткод для виртуальной машины ActionScript 3.0?

Тебе не кажется, что это много сложнее сделать, чем распарсить XML?

оценочная функция очень маленький кусок кода, а остальной алгоритм всяких оптимальных поисков будешь ведь переписывать под каждую платформу?

Да, конечно, но это будет сделано один раз — клиентскому программисту не нужно будет переписывать все заново

Для спагетти достаточно if then else,

А нету в моём XML-е if-then-else, ну нету — см. пример в презентации.

луа и питон тоже маленькие.

Всяко больше, чем DSL

То есть, ты предлагаешь написать транслятор лиспа в байткод для виртуальной машины ActionScript 3.0?

Я не поклонник лиспа, и предпочел бы питон или lua. Ну и луа как я уже упоминал вроде как удачно перенесен используя adobe alchemy. Ну и совершенно очевидно что транслятор писать не надо, трансляция может происходить на девелоперской машине, нужно портировать интерпретатор байткода.

Да, конечно, но это будет сделано один раз — клиентскому программисту не нужно будет переписывать все заново

НУ так я эту идею как раз и продвигал для скриптовых языков выше, а тебе что-то не понравилось.

А нету в моём XML-е if-then-else, ну нету — см. пример в презентации.

Та да, представляю как программисты будут разрабатывать логику игр на языке без if-then-else, маразмом попахивает.

Всяко больше, чем DSL

А помоему очень отличный компромис между функциональностью и компактностью. При чем это не мое личное мнение, луа повсеместно используется для программирования логики игр.

нужно портировать интерпретатор байткода

Ничего не понял. Ты предлагаешь, чтоб писать на lua, а получался байткод на actionscript? Дело в том, что эта задача во первых чрезмерно сложна, во вторых lua это не DSL ни разу. Ты можешь не соглашаться с этим утверждением, но lua — язык общего назначения.

Почитай о преимуществах внешнего DSL

я эту идею как раз и продвигал для скриптовых языков выше, а тебе что-то не понравилось.

Ты предлагал в качестве DSL — языка lua или питон, по моему мнению этого категорически нельзя делать, поскольку теряются основные преимущества DSL

луа повсеместно используется для программирования логики игр.

Логики верхнего уровня: разметка гуя, маппинг свойств персонажей и т.п. Для высоконагруженного кода не подходит.

С другой стороны, для задания конечного автомата вполне достаточно DSL на базе XML

Пойми, dsl это не язык программирования общепринятом смысле, он выполняется для одной задачи — для других неприменим. И это как раз его преимущество, поскольку делает очень маленьким компактным и понятным

Ничего не понял. Ты предлагаешь, чтоб писать на lua, а получался байткод на actionscript?

Нет, интерпретировать нужно байт код луа.

Дело в том, что эта задача во первых чрезмерно сложна

В третий раз — задача уже решена.

во вторых lua это не DSL ни разу. Ты можешь не соглашаться с этим утверждением, но lua — язык общего назначения.

Почитай о преимуществах внешнего DSL Ты предлагал в качестве DSL — языка lua или питон, по моему мнению этого категорически нельзя делать, поскольку теряются основные преимущества DSL

Это твои личные религиозные заблуждения.

Для высоконагруженного кода не подходит.

Будут бенчмарки твоей xml библиотеки и сравнение с производительностью луа, тогда и сможешь категорично утверждать.

интерпретировать нужно байт код луа.

Интерпретировать байт-код lua на экшенскрипте???
То есть, нужно написать компилятор Lua в байткод, потом виртуальную машину, мало того эту виртуальную машину нужно написать на экшенскрипте и включить в состав игры.

Ты извини, но моск ломается.

В третий раз — задача уже решена.

Создан ИНТЕРПРЕТАТОР lua, виртуальной машины lua я не знаю!

Будут бенчмарки твоей xml библиотеки и сравнение с производительностью луа, тогда и сможешь категорично утверждать.

С lua я не сравнивал, но сравнивал с интерпретатором лиспа: есть интерпретатор лиспа на экшенскрипте www.solve-et-coagula.com/As3Lisp.html
В начале я хотел написать DSL на лиспе.

Даже опустив то, что интерпретатор этот безбожно глючит, использование DSL языка на базе XML работает на много быстрее.

Интерпретировать байт-код lua на экшенскрипте???

А в чем проблема?

То есть, нужно написать компилятор Lua в байткод,

Не нужно, можно взять уже готовый.

потом виртуальную машину, мало того эту виртуальную машину нужно написать на экшенскрипте и включить в состав игры.
Вариантов много, можно написать интерпретатор байткода/виртуальную машину на экшн скрипте конечно, думаю задача одинаковой сложности с твоим xml языком. А можно уже взять готовую вирт. машину на ц++ и заинтегрировать ее в флеш с помощьйю adome alchemy, на что я тебе уже в четвертый раз жирно намекаю.

Создан ИНТЕРПРЕТАТОР lua, виртуальной машины lua я не знаю!

Это чисто терминологический вопрос.

Даже опустив то, что интерпретатор этот безбожно глючит, использование DSL языка на базе XML работает на много быстрее.

И ты делаешь из этого выводы о луа?

А в чем проблема?

Большой получится. Или недоделанный + сложность реализации

виртуальную машину на экшн скрипте конечно, думаю задача одинаковой сложности с твоим xml языком

Ты когда нибудь писал компиляторы? Для справки, по разработке толкового компилятора целые талмуды созданы. Посмотри на теорию компиляторов Ахо, Сети и Ульмана, ей же убить можно.

И ты делаешь из этого выводы о луа?

Я делаю выводы о том, что скорости интерпретатора встроенного в другой язык не достаточно.

Кроме того, виртуальная машина внутри другой виртуальной машины мне кажется сомнительным делом.

Большой получится. Или недоделанный + сложность реализации

Луа компактный и доделанный.

Ты когда нибудь писал компиляторы? Для справки, по разработке толкового компилятора целые талмуды созданы. Посмотри на теорию компиляторов Ахо, Сети и Ульмана, ей же убить можно.

В пятый раз — компилер писать не нужно, он уже написан.
Я делаю выводы о том, что скорости интерпретатора встроенного в другой язык не достаточно.

Кроме того, виртуальная машина внутри другой виртуальной машины мне кажется сомнительным делом.

Это все игры в терминологию. Твой xml runtime такая же виртуальная машина как и интерпретатор байткода луа.

Луа компактный и доделанный.

Но не DSL ни разу + медленный

компилер писать не нужно, он уже написан

Виртуальную машину пушкин писать будет?

Твой xml runtime такая же виртуальная машина как и интерпретатор байткода луа.

В том — то и дело, что нет

Но не DSL ни разу

Та нет, тебя просто в гугле забанили, иначе ты бы давно уже ввел «lua dsl» и походил бы по ссылкам.

Виртуальную машину пушкин писать будет?

См. про бан в гугле: lmgtfy.com/?q=lua flash

Ну и спасибо что заставляешь меня уже в третий раз отвечать на этот вопрос.

Твой xml runtime такая же виртуальная машина как и интерпретатор байткода луа.

В том — то и дело, что нет

Может снизойдешь до обьяснений?

Ты бы вообще перед тем как какую то бредовую идею толкать налабал бы какой прототипчик простенький, и написал бы на нем простенькую игру, например пакмана, что бы проверить жизнеспособность идеи. И сразу бы все стало ясно и про скорость, и про читабельность твоего суперxmlкода.

давно уже ввел «lua dsl» и походил бы по ссылкам.

Ты предлагаешь написать на Lua внутренний DSL, потом собрать с помощью Adobe Alchemy виртуальную машину исполняющую Lua байткод, включить её в игру и в таком виде управлять роботом. Цепочка рассуждений, если я тебя правильно понял, получается такая внутренний lua dsl —> lua —> виртуальная машина на ActionScript. Я же создаю внешний DSL на базе XML.

спасибо что заставляешь меня уже в третий раз отвечать на этот вопрос.

Это интерпретаторы, причем не байткода — самого кода

LUA.

Может снизойдешь до обьяснений?

Можно в не столь саркастичном тоне: конечно я расскажу.

1) В предлагаемой тобой виртуальной машине будет выполняться любой код на Lua, которая как известно — язык общего назначения. Гораздо быстрее будет работать средство заточенное на очень маленький язык, выполняющий одну и только одну задачу — маппинг конечных автоматов.
2) DSL на столько прост, что физически не позволяет написать спагетти — код. lua — легко

3)

налабал бы какой прототипчик простенький, и написал бы на нем простенькую игру

Посмотри презентацию ещё раз, там есть ссылка на github. В том числе там лежит простенький прототипчик

скорость... суперxmlкода.

Уже выяснена, работает гораздо быстрее, чем интерпретируемый язык. Более того, проблем со скоростью вообще не замечено.

читабельность твоего суперxmlкода.

Читаемость XML конечно не очень хороша по определению, но ты посмотри презентацию
Сейчас я занимаюсь созданием текстового языка, который будет транслироваться в XML

Потом создам графический редактор конечных автоматов, управляющих ботами.

Ты предлагаешь написать на Lua внутренний DSL, потом собрать с помощью Adobe Alchemy виртуальную машину исполняющую Lua байткод, включить её в игру и в таком виде управлять роботом. Цепочка рассуждений, если я тебя правильно понял, получается такая внутренний lua dsl —> lua —> виртуальная машина на ActionScript. Я же создаю внешний DSL на базе XML.

Та нет, с чего ты взял? Я предлагаю использовать луа как дсл.

И в чем проблема с моим подходом?

Это интерпретаторы, причем не байткода — самого кода

LUA.

Это с чего ты взял? Они там берут стоковую дистрибуцию луа, которая интерпретирует именно байткод.

Гораздо быстрее будет работать средство заточенное на очень маленький язык

Утверждение высосано из пальца. Очевидно многое зависит от прямоты твоих и разработчиков луа рук

Уже выяснена, работает гораздо быстрее, чем интерпретируемый язык.

Опять 25, ты же еще не сравнивал с луа?

Посмотри презентацию ещё раз, там есть ссылка на github. В том числе там лежит простенький прототипчик

Ну вот он совсем простенький, а код уже стотонний наблюдатель не прочитает, в отличие кода на луа, я уж не говорю что видимо 90% логики не портируется и прийдется переписывать заново под каждую новую платформу.

Сейчас я занимаюсь созданием текстового языка, который будет транслироваться в XML

xml в этой цепочке явно лишний, но вектор развития правильный, в конце концов через годик напишешь свою луа.

Я предлагаю использовать луа как дсл.

И в чем проблема с моим подходом?

В том, что в качестве DSL категорически нельзя использовать универсальный язык. DSL — Domain Specific Language — язык для решения конкретной задачи. Если у него будут возможности сравнимые с базовым языком, получится каша: часть методов будет реализована на нём, часть — на базовом языке.

Я же говорю о том, что на DSL пишем только логику, в декларативном стиле. Ничего другого на DSL писать нельзя, по определению!

Я предлагаю использовать луа как дсл.

И в чем проблема с моим подходом?

DSL предназначен для чтения людей у которых руки кривые по определению: сценаристов и геймдизайнеров.

Ну вот он совсем простенький, а код уже стотонний наблюдатель не прочитает

См. ниже, текстовый язык.

xml в этой цепочке явно лишний

Во первых, XML легко парсить, аргументы о неприменимости LUA ты слышал. Текстовый язык тоже читать будет не сложно, я уже создал его грамматику — получилось просто
Во вторых, легко читать не посвященным в язык людям — гораздо легче, чем LUA код

В третьих, xml удобнее использовать как входной формат, для текстового редактора.

В том, что в качестве DSL категорически нельзя использовать универсальный язык. DSL — Domain Specific Language — язык для решения конкретной задачи. Если у него будут возможности сравнимые с базовым языком, получится каша: часть методов будет реализована на нём, часть — на базовом языке.
Я же говорю о том, что на DSL пишем только логику, в декларативном стиле. Ничего другого на DSL писать нельзя, по определению!

DSL предназначен для чтения людей у которых руки кривые по определению: сценаристов и геймдизайнеров.

Отлично, все это про луа.

Во первых, XML легко парсить,

Ну ты ж все равно будешь свой новый язык парсить, так что аргумент не состоятелен.

Во вторых, легко читать не посвященным в язык людям — гораздо легче, чем LUA код

Ну это твое крайне субьективное мнение.

В третьих, xml удобнее использовать как входной формат, для текстового редактора.

Это я вообще не осилил. Какого конкретно текстового редактора?

Подписаться на комментарии