Разработка игровых сценариев, презентация
Презентация для конференции в Луганске
www.slideshare.net/vkozhaev/ss-12298009
Замечания, предложение о сотрудничестве и просто конструктивная критика приветствуется
Facebook
Twitter
LinkedIn
Dart Vader
Да троллинг это..... или действительно все уже выехали((
Olga Gnatenko
Tijeretta Mail
Такое впечатление, что презентацию делал школьник, впервые видящий PowerPoint — разный размер шрифта на одинаковых по логике слайдах, нечитаемый красный текст на синем и т.п.
Я уже молчу про опечатки, ошибки орфографические и пунктуацию, полное неструктурирование информации на слайдах.
Я уже молчу про опечатки, ошибки орфографические и пунктуацию, полное неструктурирование информации на слайдах.
Кроме того, слова типа «глюкавые», «ахтунг» и прочее — сомневаюсь, что они в формате конференции воспримутся нормально
Bogdan Shyiak
Ну в общем lurkmore.to/Гном
reality_hacker
Мое мнение — адский сумбур и война с ветряными мельницами.
XML — плохо читаем, лучше юзать json.
А еще лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код.
А еще лучше писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.
XML — плохо читаем, лучше юзать json.
А еще лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код.
А еще лучше писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.
Интересно, кто то действительно програмит игровую логику в виде конечных автоматов?
лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код
Интерпретатор питона на экшенскрипте, или встроенный в андроид — программу будет работать невыразимо медленно. На столько медленно, что играть в такую игру никто не будет:не станет игрок ждать пару часиков, пока программа подумает какой ей ход сделать.
Нету такого средства, чтоб написать на питоне и получилась флеш игра. Для unity, JavaScript, Android, IoS тоже нету.писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.
Возможно есть для всеми забытого J2ME.
На самом деле, чуть менее, чем все. Просто у каждого этот автомат свой.Интересно, кто то действительно програмит игровую логику в виде конечных автоматов?
p.s. Спасибо за первый комментарий по сути
reality_hacker
Интерпретатор питона на экшенскриптеТак экшн скрипт вроде вполне сам по себе нормальный язычек для скриптования.
встроенный в андроид — программу будет работать невыразимо медленноЕсть конкретные бенчмарки?
экшн скрипт вроде вполне сам по себе нормальный язычек для скриптования.
Это не так. Экшен скрипт 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 — е эта функция будет задаваться один раз: её не нужно будет каждый раз писать новую. Это значит, что юниттесты будут работать одинаково.
А на компьютере у тебя, ты думаешь, как то по другому все устроено? Просто C++ язык более быстрый, чем AS.они используют adobe alchemy что бы ранать абсолютно тот же интерпретатор/компилятор что и у меня на компьютере.
Да и даже будь он не вполне быстрым, 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,
А нету в моём
луа и питон тоже маленькие.
Всяко больше, чем DSL
Я не поклонник лиспа, и предпочел бы питон или lua. Ну и луа как я уже упоминал вроде как удачно перенесен используя adobe alchemy. Ну и совершенно очевидно что транслятор писать не надо, трансляция может происходить на девелоперской машине, нужно портировать интерпретатор байткода.То есть, ты предлагаешь написать транслятор лиспа в байткод для виртуальной машины ActionScript 3.0?
Да, конечно, но это будет сделано один раз — клиентскому программисту не нужно будет переписывать все заново
НУ так я эту идею как раз и продвигал для скриптовых языков выше, а тебе что-то не понравилось.
А нету в моём
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 я не знаю!
С lua я не сравнивал, но сравнивал с интерпретатором лиспа: есть интерпретатор лиспа на экшенскрипте www.solve-et-coagula.com/As3Lisp.htmlБудут бенчмарки твоей xml библиотеки и сравнение с производительностью луа, тогда и сможешь категорично утверждать.
В начале я хотел написать 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 легко парсить, аргументы о неприменимости LUA ты слышал. Текстовый язык тоже читать будет не сложно, я уже создал его грамматику — получилось простоxml в этой цепочке явно лишний
Во вторых, легко читать не посвященным в язык людям — гораздо легче, чем LUA код
В третьих, xml удобнее использовать как входной формат, для текстового редактора.
В том, что в качестве DSL категорически нельзя использовать универсальный язык. DSL — Domain Specific Language — язык для решения конкретной задачи. Если у него будут возможности сравнимые с базовым языком, получится каша: часть методов будет реализована на нём, часть — на базовом языке.Отлично, все это про луа.
Я же говорю о том, что на DSL пишем только логику, в декларативном стиле. Ничего другого на DSL писать нельзя, по определению!DSL предназначен для чтения людей у которых руки кривые по определению: сценаристов и геймдизайнеров.
Ну ты ж все равно будешь свой новый язык парсить, так что аргумент не состоятелен.Во первых, XML легко парсить,
Ну это твое крайне субьективное мнение.Во вторых, легко читать не посвященным в язык людям — гораздо легче, чем LUA код
В третьих, xml удобнее использовать как входной формат, для текстового редактора.
Это я вообще не осилил. Какого конкретно текстового редактора?
Aleksey G
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів