Разработка игровых сценариев, презентация
Презентация для конференции в Луганске
www.slideshare.net/vkozhaev/ss-12298009
Замечания, предложение о сотрудничестве и просто конструктивная критика приветствуется
Презентация для конференции в Луганске
www.slideshare.net/vkozhaev/ss-12298009
Замечания, предложение о сотрудничестве и просто конструктивная критика приветствуется
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівДа троллинг это..... или действительно все уже выехали((
buisnes — эта 5 ))
Я уже молчу про опечатки, ошибки орфографические и пунктуацию, полное неструктурирование информации на слайдах.
Кроме того, слова типа «глюкавые», «ахтунг» и прочее — сомневаюсь, что они в формате конференции воспримутся нормально
Ну в общем lurkmore.to/Гном
Презентация невыразимо чудовищна :))
XML — плохо читаем, лучше юзать json.
А еще лучше тоже самое на питоне в виде мапов и списков, при этом легко раширять вставляя питонячий код.
А еще лучше писать просто на питоне, вполне нормальный дсл, при этом легко дебажить к примеру.
Интересно, кто то действительно програмит игровую логику в виде конечных автоматов?
Интерпретатор питона на экшенскрипте, или встроенный в андроид — программу будет работать невыразимо медленно. На столько медленно, что играть в такую игру никто не будет:не станет игрок ждать пару часиков, пока программа подумает какой ей ход сделать.
Нету такого средства, чтоб написать на питоне и получилась флеш игра. Для unity, JavaScript, Android, IoS тоже нету.Возможно есть для всеми забытого J2ME.
На самом деле, чуть менее, чем все. Просто у каждого этот автомат свой.p.s. Спасибо за первый комментарий по сути
Это не так. Экшен скрипт 3.0 язык императивный и строго типизированный — в качестве DSL не подходит. Я слабо себе представляю редактор диаграмм последовательностей, или состояний, который строит диаграмму по ActionScript коду. Да и вообще, мне кажется, внутренний DSL для такого дела плох. .
Кроме того, допустим в какой то системе язык подходит для создания внутреннего DSL. Где взять транслятор данного языка для других систем?Получается, что при портировании игры на другую платформу логику придется переписывать, чего как раз и хотелось — бы избежать.
Есть тесты интерпретаторов для Java, они работают медленно. Если это все перенести на андроид будет ещё медленнее ввиду особенностей железа мобилок и планшетов.
И вообще я так понимаю флешовые игры запускаются на других платформах в портированном рантайме без всяких переписываний, а иначе перенос скриптовой части будет самой простой задачей в процессе портирования.
А с чего ты взял что твой продукт кроме сильной обрезанности будет быстрее?
Это интерпретатор, его скорость по определению меньше, чем скорость компилированного языка. Добавь сюда решение задач искусственного интеллекта. Таких, как поиск пути например, или поиск рационального хода, короче поиск на графе — ресурсоёмкие задачи с которыми и компилированный код справляется плохо. Кроме того, железо на всяких гаджетах явно хуже, чем на стандартном лаптопе. В общем, выходит что интерпретатор можно использовать только для скриптов верхнего уровня, которые запускаются один раз за игру
Да, но собственно логику писать на ActionScript никак не легче, то есть абсолютно:. Получается, если выбираем кроссплатформенность — получаем язык не удобный для DSL. Если с DSL все в порядке, решение будет не кроссплатформенным.
Потому, что скрипты не перечитываются каждый раз, как в интерпретаторе. Из указанного языка формируется структура данных на компилированном языке, хранится она в памяти и это выходит на порядок быстрее, чем каждый раз интерпретировать скрипт.
Ну ты же свой xml тоже не компилировать собрался?
Ну да, обычно такие вещи выносят в нативный язык а потомо вызывают из скрипта.
С чего ты решил что будет каждый раз перечитываться? Я не знаю как там в луа сделано, но в питоне все компилится в промежуточный байт код. Ну и не факт что узкое место будет именно в парсинге а не в твоем коде.
И кстати по поводу автоматов:
пока что все игрухи которые я видел скриптовались или писались на нативных языках, никаких автоматов я еще не видел.
Из XML собирается структура данных, она висит в оперативной памяти и никаких дополнительных расходов на интерпретацию не потребляет. Прочли один раз, сформировали конечный автомат и вуаля — все работает
Вот — вот, поэтому, даже в случае использования библиотек, как минимум оценочную функцию нужно реализовывать новую
Это в питоне, который у тебя установлен на обычном компьютере. Если питон встроен внутрь игры, это получается обыкновенный интерпретатор. Вот возьмем, например, флеш. Ты себе представляешь, как дергать питоновские функции изнутри броузера?Я вот не представляю. Или возьмем игру для мобильного телефона, ты вместе с ней предлагаешь ставить питон, потом дергать его из игры? В аппсторе такую игру просто не пропустят и я не уверен, что такое можно сделать в принципе.
Если интересно, пиши в личку — дам тебе список литературы с примерами.
Ну вот когда твой код будет бегать по правилам перехода, это и называется интерпретацией, а компиляцией, это когда ты сгенерировал оптимизированный машинный код который это делает.
Как и в твоем xml подходе.
В случае луа они используют adobe alchemy что бы ранать абсолютно тот же интерпретатор/компилятор что и у меня на компьютере.
По Lua я сырцы не смотрел, но посмотрю обязательно.
Нет, в XML — е эта функция будет задаваться один раз: её не нужно будет каждый раз писать новую. Это значит, что юниттесты будут работать одинаково.
А на компьютере у тебя, ты думаешь, как то по другому все устроено? Просто C++ язык более быстрый, чем AS.Да и даже будь он не вполне быстрым, Lua не подходит для создания DSL. В презентации это тоже сказано.
Лиспы всякие бывают, CLISP компилит вполне в байткод.
Ты предлагаешь алгоритм поиска реализовать в твоем автоматном xml? Так и представляю себе обьявления о работе: ищутся програмисты автоматов Мили, знание машимы Тьюринга и частично-рекурсивных функций — большой плюс.
В презентации написано что причина отказа от скриптов — спагетти код. Я представляю себе какой лапша код будет писаться на твоем xml.
Да, но встроенным в игру может быть только интерпретатор. Особенно, если мы говорим о мобильной, или флешовой игре — интерпретатор медленный.
Да нет, достаточно записать формулу. Оценочные функции обычно простые.
DSL язык потому и хорош, что очень маленький — написать на нем спагетти не выйдет
Интерпретироваться вполне может байт код, что вполне моожет оказаться быстрее твоих xmл структур.
Ок, оценочная функция очень маленький кусок кода, а остальной алгоритм всяких оптимальных поисков будешь ведь переписывать под каждую платформу?
Для спагетти достаточно if then else, ну и луа и питон тоже маленькие.
Тебе не кажется, что это много сложнее сделать, чем распарсить XML?
Да, конечно, но это будет сделано один раз — клиентскому программисту не нужно будет переписывать все заново
А нету в моёмXML-е if-then-else, ну нету — см. пример в презентации.
Всяко больше, чем DSL
НУ так я эту идею как раз и продвигал для скриптовых языков выше, а тебе что-то не понравилось.
Та да, представляю как программисты будут разрабатывать логику игр на языке без if-then-else, маразмом попахивает.
А помоему очень отличный компромис между функциональностью и компактностью. При чем это не мое личное мнение, луа повсеместно используется для программирования логики игр.
Почитай о преимуществах внешнего DSL
Ты предлагал в качестве DSL — языка lua или питон, по моему мнению этого категорически нельзя делать, поскольку теряются основные преимущества DSL
Логики верхнего уровня: разметка гуя, маппинг свойств персонажей и т.п. Для высоконагруженного кода не подходит.С другой стороны, для задания конечного автомата вполне достаточно DSL на базе XML
Пойми, dsl это не язык программирования общепринятом смысле, он выполняется для одной задачи — для других неприменим. И это как раз его преимущество, поскольку делает очень маленьким компактным и понятным
В третий раз — задача уже решена.
Это твои личные религиозные заблуждения.
Будут бенчмарки твоей xml библиотеки и сравнение с производительностью луа, тогда и сможешь категорично утверждать.
То есть, нужно написать компилятор Lua в байткод, потом виртуальную машину, мало того эту виртуальную машину нужно написать на экшенскрипте и включить в состав игры.
Ты извини, но моск ломается.
Создан ИНТЕРПРЕТАТОР lua, виртуальной машины lua я не знаю!
С lua я не сравнивал, но сравнивал с интерпретатором лиспа: есть интерпретатор лиспа на экшенскрипте www.solve-et-coagula.com/As3Lisp.htmlВ начале я хотел написать DSL на лиспе.
Даже опустив то, что интерпретатор этот безбожно глючит, использование DSL языка на базе XML работает на много быстрее.
Не нужно, можно взять уже готовый.
Вариантов много, можно написать интерпретатор байткода/виртуальную машину на экшн скрипте конечно, думаю задача одинаковой сложности с твоим xml языком. А можно уже взять готовую вирт. машину на ц++ и заинтегрировать ее в флеш с помощьйю adome alchemy, на что я тебе уже в четвертый раз жирно намекаю.Это чисто терминологический вопрос.
И ты делаешь из этого выводы о луа?
Большой получится. Или недоделанный + сложность реализации
Ты когда нибудь писал компиляторы? Для справки, по разработке толкового компилятора целые талмуды созданы. Посмотри на теорию компиляторов Ахо, Сети и Ульмана, ей же убить можно.
Я делаю выводы о том, что скорости интерпретатора встроенного в другой язык не достаточно.Кроме того, виртуальная машина внутри другой виртуальной машины мне кажется сомнительным делом.
Луа компактный и доделанный.
В пятый раз — компилер писать не нужно, он уже написан.Это все игры в терминологию. Твой xml runtime такая же виртуальная машина как и интерпретатор байткода луа.
Но не DSL ни разу + медленный
Виртуальную машину пушкин писать будет?
В том — то и дело, что нет
Та нет, тебя просто в гугле забанили, иначе ты бы давно уже ввел «lua dsl» и походил бы по ссылкам.
См. про бан в гугле: lmgtfy.com/?q=lua flashНу и спасибо что заставляешь меня уже в третий раз отвечать на этот вопрос.
Может снизойдешь до обьяснений?
Ты бы вообще перед тем как какую то бредовую идею толкать налабал бы какой прототипчик простенький, и написал бы на нем простенькую игру, например пакмана, что бы проверить жизнеспособность идеи. И сразу бы все стало ясно и про скорость, и про читабельность твоего суперxmlкода.
Коментар порушує правила спільноти і видалений модераторами.
Ты предлагаешь написать на Lua внутренний DSL, потом собрать с помощью Adobe Alchemy виртуальную машину исполняющую Lua байткод, включить её в игру и в таком виде управлять роботом. Цепочка рассуждений, если я тебя правильно понял, получается такая внутренний lua dsl —> lua —> виртуальная машина на ActionScript. Я же создаю внешний DSL на базе XML.
Это интерпретаторы, причем не байткода — самого кодаLUA.
Можно в не столь саркастичном тоне: конечно я расскажу.
1) В предлагаемой тобой виртуальной машине будет выполняться любой код на Lua, которая как известно — язык общего назначения. Гораздо быстрее будет работать средство заточенное на очень маленький язык, выполняющий одну и только одну задачу — маппинг конечных автоматов.2) DSL на столько прост, что физически не позволяет написать спагетти — код. lua — легко
3)
Посмотри презентацию ещё раз, там есть ссылка на github. В том числе там лежит простенький прототипчик
Уже выяснена, работает гораздо быстрее, чем интерпретируемый язык. Более того, проблем со скоростью вообще не замечено.
Читаемость XML конечно не очень хороша по определению, но ты посмотри презентациюСейчас я занимаюсь созданием текстового языка, который будет транслироваться в XML
Потом создам графический редактор конечных автоматов, управляющих ботами.
И в чем проблема с моим подходом?
Это с чего ты взял? Они там берут стоковую дистрибуцию луа, которая интерпретирует именно байткод.
Утверждение высосано из пальца. Очевидно многое зависит от прямоты твоих и разработчиков луа рук
Опять 25, ты же еще не сравнивал с луа?
Ну вот он совсем простенький, а код уже стотонний наблюдатель не прочитает, в отличие кода на луа, я уж не говорю что видимо 90% логики не портируется и прийдется переписывать заново под каждую новую платформу.
xml в этой цепочке явно лишний, но вектор развития правильный, в конце концов через годик напишешь свою луа.
Я же говорю о том, что на DSL пишем только логику, в декларативном стиле. Ничего другого на DSL писать нельзя, по определению!
DSL предназначен для чтения людей у которых руки кривые по определению: сценаристов и геймдизайнеров.
См. ниже, текстовый язык.
Во первых, XML легко парсить, аргументы о неприменимости LUA ты слышал. Текстовый язык тоже читать будет не сложно, я уже создал его грамматику — получилось простоВо вторых, легко читать не посвященным в язык людям — гораздо легче, чем LUA код
В третьих, xml удобнее использовать как входной формат, для текстового редактора.
Это я вообще не осилил. Какого конкретно текстового редактора?
Упс, забыл перелогиниться?