Python нашёл себе место почти во всех сферах IT. Разработка веб-сайтов, управление станками ЧПУ, desktop, мобильные приложения, а уж про искусственный интеллект, машинное обучение и анализ данных я вообще молчу. Сейчас Python лучший друг хоть школьнику, хоть сотруднику научно-исследовательской лаборатории. А что на счёт игр? Компьютерные игры - это огромная доля IT рынка, которая уже набрала и продолжает набирать обороты. Игры то делать можно на питоне? Сегодня мы расставим все точки над i. Меня зовут Макс, я один из авторов YouTube канала PyLounge, а вы читаете статью в которой я расскажу можно ли создавать игры на Python и какую нишу занял Python в сфере gamedev.
Для удобства разделим все игры на несколько категорий:
AAA-проекты по типу Assassin's Creed и Call of Duty, которые разрабатывают е крупные студии;
любительские инди-игры;
мобильные игры.
В таком порядке и будем разбираться.
Все масштабные 3D игры так или иначе создаются с помощью специальных игровых движков. Игровой движок - это по сути набор инструментов, который позволяет работать с графикой, физикой, скриптами и прочим.
Движки довольно требовательны к производительности, а Python сам по себе медленный, поэтому непосредственно ядро игры на Python не пишут. Движки, как правило, создаются на компилируемых языках, таких как С/С++ или С#.
Крупные компании зачастую используют Unity, Unreal Engine 4, CryEngine, Source или пишут собственные движки (Anvil, Fox, REDengine) обычно на С++. Хотя и существуют специальные игровые движки, написанные на Python, но о них чуть дальше.
Перемещение по меню, переходы между локациями, управление персонажем, движение камеры, смена музыки, диалоги, система квестов, ИИ — всё это и многое другое приходится программировать на каком-то языке, который поддерживает тот или иной движок.
Unreal Engine 4 используют С++, Blueprint и некоторое подобие JavaScript, основой для Unity является C# (была попытка ввести язык Boo, это по сути типизованный Python, но идея провалилась). Из более менее крупных, ходовых движков Python как основу использует пожалуй только Godot (точнее он использует GDScript, по сути видоизменённый Python с небольшими фишками).
Поэтому не смотря на возможность работы с графикой и в целом реальность разработки игр, сам по себе Python не используется или практически не используется, как основной язык для разработки крупных игр. Но его часто используют как вспомогательный инструмент.
На нём пишут игровую логику, используют для написания внутриигровых скриптов и подсобной работы, не касающейся рендеринга, например, организации серверных элементов управления, внутриигрового моддинга, интерфейсов и прочего. На написании игровых скриптов остановимся поподробнее.
В первую очередь скриптовый язык Python позволяет отделить игровую логику, от всего остального (графики, физики, ввода/вывода, сетевого взаимодействия). Скрипты на Python могут применяться для написания взаимодействия персонажей, запуска сцен, диалогов, взаимодействие NPC с триггерами (например, ходьба где-то, остановка, чтобы поговорить с другим NPC, а затем продолжить бежать куда-то), статистика противника (здоровье, скорость, точность), а также обработки различных событий.
Игровая логика обычно не содержит сложных вычислений и скорость языка отходит на второй план. Это и ляжет на плечи Python. Действительно сложные или требующие высокой производительности части (какой-нибудь условный поиск пути) можно унести в движок.
Получается, что скриптовые языки такие как Python или Lua вызывают какие-либо методы движка и оперируют ими для создания игровой логики и наоборот: движок может вызывать заранее оговоренные функции в скрипте, где разработчик уже как-то обрабатывает вызов. То есть скрипты позволяют разделить слои логики игры и логики игрового движка. Вы можете изменять игровую логику, настройку игры и прочие параметры без необходимости перекомпиляции всего кода.
Скрипты Python можно использовать, даже если игра написана на другом языке. Python использовался в Battlefiled, Sims, Civilization, World of Tanks, Vampire: The Masquerade: Bloodlines и ещё много где.
Кроме того, Python часто используют для написания тестов, что тоже важно. Получается, что Python не такой уж редкий гость в крупном геймдеве, однако используется он далеко не как основной язык и конкуренцию ему составляет(-ли,-вят) Lua\JS\TypeScript (возможно) и т.д. С крупными многобюджетными играми на этом всё.
Когда же речь идёт о чём-то более простом, о создании не навороченных 2D и 3D игр Python выступает во всей красе. Для создания хобби-проектов, инди и мобильные игр под Android Питон предоставляет несколько хороших и относительно популярных инструментов.
Pygame – это библиотека модулей для языка Python, созданная для разработки 2D игр. Также Pygame можно называть своего рода фреймворком для создания игр. Он имеет хорошее сообщество, открытый исходный код, кроссплатформенность, качественную документацию, множеством примеров игр, а ещё он довольно простотой для изучения.
PyGame хорошее начало, чтобы познакомиться с особенностями разработки игр. Более опытными программистами Pygame может использоваться для быстрого создания прототипа игры, чтобы посмотреть, как все будет работать. После этого игра переписывается на другом языке. Другими словами, преимущество Pygame в легком обучении и быстрой разработке. С помощью него вполне можно создать отличную игру, но скорее всего казуалку. Pygame-приложения могут работать под Android на телефонах и планшетах с использованием подмножества Pygame для Android.
Panda3D — игровой движок, включающий графику, звук, ввод-вывод, обнаружение столкновений и другие функции, относящиеся к созданию 3D игр. Основным языком программирования, предназначенном для работы с SDK Panda3D, является Python, однако ядро движка написано на C++. Panda3D использовался даже для крупных коммерческих игр (Toontown Online, Pirates of the Caribbean Online). Он также включает работу с графикой, звуком, сетью, устройствами ввода (мышь, клавиатура, джойстик и т.п.), физикой на базе ODE и многими другими вещами, требующимися при разработке игры. Основным графическим API для "панды" является OpenGL, так же возможно использование и DirectX. Движок достаточно простой в изучении и при должной сноровке, с помощью него вполне реально сделать что-то простое, но интересное.
Отдельно стоит отметить движок RenPy . Это именно то, на что действительно стоит обратить своё внимание.
RenPy — это бесплатный, написанный на Python, свободный игровой движок для создания визуальных новелл (графических квестов с диалоговой системой) в 2D-графике. Поддерживает платформы Windows, Linux, Android, iOS. Именно на этом движке созданы такие известные игры как Бесконечное Лето и Корона из Листьев.
Движок использует сценариообразный скриптовый язык, что превращает создание простых игр в несложное дело, оставаясь гибким и предоставляя широкие возможности опытным авторам. Для более сложных игр необходимо применять Python: есть возможности подключение видео и использование различных спецэффектов на движке; также можно подключать мини-игры, системы подсчёта параметров, чтобы сделать не просто диалоговую кликалку.
Кроме того, он предоставляет возможности, ожидаемые в каждой визуальной новелле, например, сохранение-загрузка, доступ к настройке различных параметров игры и перемотка диалогов. RenPy имеет отличный официальный туториал, документацию и большое русскоязычное комьюнити.
По данным из Wiki cвыше 1200 игр используют движок RenPy. И это действительно тот инструмент, который поможет вам реально и без особых проблем воплотить ваши игровые идеи в жизнь, пусть и в формате визуальной новеллы. Достаточно только наличие базовых знаний Python, идеи и хорошего художника. Дерзайте, возможно именно ваша игра покорит интернет, как это было в случае БЛ.
Из всего этого следуют, что Python вполне применим для создания игр, зачастую более простых, но и в крупных проектах встретить его вполне реально, хоть и происходит это редко. Некоторые игры на Python имеют огромную популярность, тоже Бесконечное лето, о котором говорилось ранее. Однако, очевидно, что язык не совсем про разработку игр. Он гораздо более применим совсем в других сферах.
P.S. Также есть видеоверсия данной статьи на YouTube.
Комментарии (51)
Jam-ik
19.06.2022 20:22+2С Python можно разрабатывать не сложные игры, но с его скоростью и динамической типизацией легко наступать на грабли. Лучше смотреть в сторону компилируемых статически типизированных языков.
Если хотите создавать масштабные игры смотрите в сторону C++(SDL, Oxygen, SFML, Ogre3D), Java(libGDX, LWJGL, JMonkeyEngine), C#, разных движков Unity(C#), Unreal Engine(C++), или Godot, его GDScript похож на Python.
loginmen
19.06.2022 21:12SDL грубо говоря Сишный аналог плюсового SFML, построенный на структурах, сырых указателях и без ООП, что мало вписывается в концепции современного языка, так что относить его к плюсовым либам считаю неправильным. Перечислены для плюсов в большинстве графические библиотеки для 2д игр.
LWJGL это только биндинги к языку плюсовых апи. С их помощью можно писать игры, но они все лишком уж низкоуровневые, например OpenGL, OpenAL, OpenVR, Vulkan и тд. Хотя сам язык мало подходит для игр и кроме майнкрафта сложно назвать известные проекты.
ShadF0x
20.06.2022 23:39кроме майнкрафта сложно назвать известные проекты
Starsector и Project Zomboid, из наиболее известных.
loginmen
19.06.2022 21:07Unreal Engine 4 используют С++, Blueprint и некоторое подобие JavaScript
Скрипт был только в 3 версии движка, в 4 и 5 его нету, формально к нему можно приписать еще и C# и Python. Первый используется в скриптах сборки, а второй в автоматизации в редакторе.
TimurBaldin
20.06.2022 00:14Получается...Что игры то не на python....питон тут тонкая прослойка для сишных библиотек...
germn
20.06.2022 11:49+1Да что уж. И Сишные библиотеки так, надстроечка над ассемблером. А тот в свою очередь прослойка над машинным кодом.
Vsevo10d
20.06.2022 01:51Хотя и существуют специальные игровые движки, написанные на Python, но о них чуть дальше.
И в результате из чисто питоновых приведен
движок RenPy . Это именно то, на что действительно стоит обратить своё внимание
странно, что
игры для онанистоввизуальные новеллы вообще нуждаются в движке. Их на каком-нибудь VBA писать можно.
b237
20.06.2022 09:24+2странно, что
игры для онанистоввизуальные новеллы вообще нуждаются в движке. Их на каком-нибудь VBA писать можно.Движок там для того, чтобы писать их можно было одной рукой. Если не заморачиваться с анимациями и интерфейсом, то код может выглядеть как тупо текст новеллы вперемешку с картинками
label start: #картинки могут находиться сами при определенном нейминге scene my_scene #Вообще для людей есть класс Character но для тупого примера пойдет и так "character name" "text" return
SilverHorse
20.06.2022 14:18+1Если не заморачиваться с анимациями и интерфейсом, это уже будет не VN, а текстовый квест в лучшем случае, состоящий из пустых экранов с текстом и кнопками "вперед" и "назад". В самом-самом примитивном виде VN делаются так, только вот если вы хотите игру, а не плохо отформатированную книжку в exe-формате, нужен полноценный движок, который будет отрисовывать текст, анимацию спрайтов, переходить по flowchart сюжета, показывая опции, отрисовывать саму эту flowchart, выставлять флаги событий, делать сейвы, выводить озвучку персонажей, менять фоны и CG, поддерживать галерею, меню, мини-игры, видеоролики, и еще с десяток других самых-самых базовых опций. Я посмотрю как вы что-нибудь типа Steins;Gate "одной рукой" напишете, особенно в ELITE версии. Или MLA. Или меметичного School Days. Или ef. И это я еще не упомянул популярного в последнее время Live2D. Если не знакомы с рынком VN дальше того же VNMaker, который как раз предназначен для написания подобных наколеночных поделий "одной рукой", и который, внезапно, и предоставляет пишущему этот самый достаточно примитивный движок, позволяющий это делать именно в описанном виде, лучше сначала хоть немного в предмет углубитесь, прежде чем рассуждать.
b237
20.06.2022 15:42согласен. я говорил скорее в том смысле, что в RenPy можно без каких-либо навыков программирования начать делать VN. абсолютно базовый функционал вроде главного меню, сохранения прогресса, проигрывания музыки, self-voicing, отматывания в любую сторону с правильной обработкой переменных, изменяющихся при откатывании назад, и другие вещи уже реализованы в каком-то виде и можно сосредоточиться на написании/отрисовке истории. а мини-играми, анимированными переходами из главного меню в игру и обратно и прочими QoL фичами можно заняться тогда, когда коробочного функционала станет недостаточно.
кстати, а какие есть инструменты для работы с флоучартом сюжета и его отрисовкой?
SilverHorse
20.06.2022 23:03+1кстати, а какие есть инструменты для работы с флоучартом сюжета и его отрисовкой?
Для разработчика или для игрока? Для разработчика не скажу, да и игр с явно встроенной flowchart мало, мне навскидку только серия фейта вспоминается. Для игроков я тоже не встречал, хотя было бы удобно перебивать гайды к некоторым обширным играм в них, чтобы видеть, где какие флаги триггерят ветвления, а то списки выборов вида "ответ 1 - ответ 4 - ответ 2 - ответ 2 - ... -> концовка 5" часто трудно понять, и они абсолютно не отражают всех возможных веток диалогов. Я был например очень удивлен, когда спустя 8 лет с первого прочтения Кланнада при перечитывании случайно обнаружил, что рут Котоми в нем имеет два слегка отличающихся good end, и это до сих пор не указано ни в одном гайде по нему.
Всякие блок-схемы бизнес-процессов и подобные вещи я в университетскую юность в старушке Dia рисовал, но мне она казалась очень неудобной. Хотя сейчас заглянул на ее сайт и обнаружил, что у нее даже есть надстройки, позволяющие ее схемы преобразовывать в программный код и наоборот, так что для принципиальной работы с flowchart она очень даже может подойти.
QuAzI
20.06.2022 09:18+2Очень веселит нытьё про динамическую типизацию. А вы сколько лет в информационном вакууме? Или вам просто нравится так оправдывать свой говнокод неприкрытый даже тестами?
Static_electro
20.06.2022 09:44+9про динамическую типизацию обычно ноют не для того, чтоб оправдать свой говнокод, а чтоб поделиться болью от чужого, который видишь в первый раз и в котором хочешь разобраться. А там в функцию иногда прилетает строка, иногда объект, а иногда tuple... И пусть он хоть трижды проходит все тесты, легче не становится
germn
20.06.2022 11:51+1Для этого изобрели аннотации типов.
pecheny
20.06.2022 17:37+1Но ведь если аннотировать типы и проверять их согласованность, то это уже и не динамическая типизация?
germn
20.06.2022 22:12Аннотации типов решают проблему "видишь в первый раз и в котором хочешь разобраться. А там в функцию иногда прилетает строка, иногда объект, а иногда tuple".
Задачи проверять их согласованность (и тем более делать это во время компиляции, которого в динамически типизированных языках как правило нет) не стояло и не стоит.
Согласованность типов данных, как вам подсказали выше, весьма успешно подтверждается тестами, без которых и в статически типизированных языках сейчас нормально не обойтись.
pecheny
20.06.2022 22:42-1Я не то чтобы не понимаю этого или возражаю. Скорее, я не понимаю, зачем выбирать связку: аннотации, которые не проверяются (и, следовательно, могут врать) + тесты, когда можно просто выбрать статически-типизированный язык.
Причем, динамическая типизация у меня не вызывает отторжения, у нее есть преимущества в определенных ситуациях. Мне весьма импонируют лиспы, например.
Но я искренне не понимаю, зачем защищать динамическую типизацию в ситуациях «без тестов – говнокод, а аннотации можно и написать», когда можно просто взять статически-типизированный язык. И не писать целый класс тестов, связанных с проверками типов. Получается как в анекдоте про суровых сибирских мужиков и японскую бензопилу.germn
21.06.2022 00:36зачем выбирать связку: аннотации, которые не проверяются (и, следовательно, могут врать) + тесты, когда можно просто выбрать статически-типизированный язык
На мой взгляд, потому что:
1) В динамически типизированных языках далеко не всё нужно аннотировать, а что-то можно аннотировать Generic'ами. Т.е. трудозатраты всё равно будут сильно меньше, чем в статических ЯП, без серьёзной потери в безопасности.
2) Никакая типизация не заменит необходимость в тестах. На более-менее большом проекте их всё равно придётся писать даже при статических ЯП.
Но это всё, конечно, извечный холивар :) Сколько людей, столько и мнений. Мой ультимативный аргумент — популярность языков в реальной жизни. Если у нас JS с Питоном хочешь, не хочешь всё-таки вытесняют Джаву с собратьями в конкурентной среде, значит, кто бы что ни говорил, это имеет смысл.
pecheny
21.06.2022 01:23+11) Даже в статически-типизированых языках далеко не все нужно аннотировать благодаря Хиндли-Милнеру. И как можно говорить о без «без серьёзной потери в безопасности», если аннотации никак не проверяются?
2) Типизация – это не замена тестов. Типизация – это замена тестов, проверяющих соответствие типов и аналогичных им.
3) И про ультимативный аргумент – тоже есть что возразить. Во-первых, с ростом популярности этих языков как раз стали видны подвижки в сторону аннотирования типов, что иллюстрирует неспособность чисто динамической типизации удовлетворить потребности «конкурентной среды». Во-вторых, само утверждение о вытеснении и конкурентной среде мне кажется натянутым, так как у нас нет объективных данных, чтобы констатировать это вытеснение.
Про холиварность – согласен, но я повторюсь. Я не против динамической типизации, я против ее защиты в тех местах, где более уместна статическая. Особенно в грубоватой форме, с которой началась эта ветка дискуссии.
SilverHorse
20.06.2022 11:16+5Можно капельку оффтоп-нытья?
Можно Ли Делать Игры На Python?
Пожалуйста, не Надо Использовать Title Case в Заголовках на Русском Языке, Это Очень Раздражает и в Частности в Длинных Заголовках Делает Их Нечитабельными.
Тем более использовать неправильно, согласно различным гайдлайнам для редакторов прессы, в Title Case не пишутся с заглавными служебные части речи как минимум. Title Case - изобретение, пришедшее в английский язык еще из латыни, и закрепившееся в Новое время, насколько я помню, как стиль газетных заголовков, где его использование было отчасти оправдано для смыслового выделения текста на убористо напечатанной газетной странице и привлечения внимания читателя. В русском языке, да еще на веб-странице с установленным форматированием его использование выглядит просто глупо. В англоязычном вебе его до сих пор используют на новостных сайтах, вместе с также традиционным для этого стиля фраз написанием в Йоды мастера форме... пожалуйста, не надо повторять за ними.
tommyangelo27
20.06.2022 13:30+3Когда-то было на Баше
Заголовок спойлераЦитата #402188
20 января 2009. Разместил: bash.org.ru
ГламуРрКа: ПрИвЕтИк
ATM: Чё надо?
ГламуРрКа: Ты ЧиВо ТаКаЯ БукА? =)))
ATM: Иди нахуй
ГламуРрКа: ЧеГоО?!?!?!
ATM: ИдИ НаХуЙ
AlexanderAstafiev
21.06.2022 04:44Почему-то никто не упомянул Arcade. На официальном сайте есть отдельная статья-сравнение с Pygame, где Arcade, естественно, выигрывает. Лично мне он зашел больше, чем Pygame.
tlittle
21.06.2022 21:45Вам бы орфографию и пунктуацию поправить. Претендуете на серьезную статью, а ошибки детские...
dendron
Краткий ответ: можно, но не нужно.
Большая ошибка, за которую впоследствии возможно придётся дорого заплатить.
Кроме того, выскажу личное мнение: как встраиваемый язык Python просто отвратителен (при том что я люблю этот язык, он приятный для ненапряжного программирования). Python был очень модный в этом качестве когда-то давно (где-то в районе нулевых) и его пихали всюду (примерно как XML). Но сама его модель вседозволенности и динамичности (которая и делает его таким интересным) - это просто ужасный яд для встраиваемого языка. Про производительность и аппетиты к ресурсам я даже не говорю. Так что есть веская причина, почему он "не взлетел" в этом качестве.
Static_electro
а где были скрипты на питоне в нулевых? Или вы не про геймдев? Там же луа во все поля была
lebedec
Например, в Blender. Я тогда начал писать плагин для экспорта моделей и случайно переквалифицировался с Java на Python.
В начале развития Unity3D была поддержка самостоятельной версии языка Boo.
Ну и образцовый пример — это конечно EVE Online.
Static_electro
не, про тулзы понятно. Я думал, речь про игры. Что напомнили про eve - спасибо :)
Bromles
Ева уже вешается там из-за этого питона. Они сидят на нестандартном несовместимом компиляторе (чтобы избавиться от GIL, который авторы стандартного питона фиксить не собираются видимо), половину бэка утащили на Азуры, мигрировали полностью на gRPC, каждую парочку звездных систем обслуживает отдельный сервер (просто этого глазами не видно), и все равно лагает)
Собственно поэтому им и пришлось много лет назад добавить TiDi, оно же космокисель. Это когда при увеличении нагрузки на сервер (большое сражение) сервер начинает замедлять тики, чтобы успевать все обрабатывать. В итоге абсолютно все процессы в игре происходят дольше (коэффициент замедления), при максимуме "кисельности" битва 6к игроков идет 27 часов)
А съехать с питона они не могут. Другого не умеют, плюс там лютый лапшекод, настаивавшийся с 2003 года. Вот и страдают все. Пять лет уже плотно переписывают все, и лет 15 просто пытаются как-то решить лаги. Но воз и ныне там
Nengchak
TD добавлен для юзеров, чтобы лагало у всех поровну, а не в зависимости от железа.
Bromles
А лагает-то из-за чего по-вашему? TD вводится на всей ноде, поэтому зачастую можно влететь в такой кисель за 3-4 системы от самого сражения. Потому что лагает сама нода, и таким образом пытается это компенсировать. И именно поэтому при подключении резервных нод TD отключается или сводится к минимуму. Потому что он рассчитывается от нагрузки сервера, а не клиентов
fzfx
Ну насчёт "каждую парочку" всё же не совсем верно: в некоторых не самых населённых регах (например, в Immensia) целые консты могут на одном сервере находиться. Плюс к тому они явно порой их перераспределяют, вряд ли полностью автоматически. Порой флоты примерно схожих размеров ловят лагалово в том же месте, но просто неделю спустя.
Bromles
Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули
rdo
каждую парочку звездных систем обслуживает отдельный серверТак вот как они единый мир сделали, а то раньше были статьи, что у них там суперкомпьютер из топ-100 чтобы мир вычислять.
Bromles
Да не, эта система с нодами у них со времен Царя Гороха. Я в Еву играл 5 лет и с самого старта в 2016 году помню про это узнал. И даже старички с 15-летним стажем говорили, что почти всегда так было
А бэк у них тривиальный. Лютая двадцатилетняя лапша на питоне ("POS code" стал уже грустным мемом), дико лагающая. И сервер представляет собой кластер из кучи нод, между которыми игроки переключаются при проходе в гиперворота, использовании джампдрайва, порталов и тд
Кстати сервер игрового чата один и отдельный от игрового. Поэтому он нередко отваливался, когда сам игровой сервер продолжал работать и играть было можно, но без чата)
Все их проблемы уже вряд ли лишатся, ибо компания и изнутри, и снаружи, на полных парах летит в бездну. А жаль, почти 20 лет такую уникальную игру держали на плаву и с адекватным онлайном
withkittens
Blade of Darkness, как один пример.
dendron
Ну, например в моей любимой Severance: Blade of Darkness. При этом там игровая логика частично валяется в открытых скриптах, вот прям в исходном виде, благодаря чему фанаты наклепали кучу модов (даже я немного покопался, очень весело). Практически наполовину опен-сорс, хоть и без лицензии.
Кстати, можно за недорого купить ремастер в Steam, если есть желание поковырять.
PTM
дико плюсую)
Naranek
Civilization IV
tooler
Python так или иначе есть в Houdini, Blender, Modo, Rhino, Qgis, Davinci Resolve. А для пользовательских приложений HUD и прочего, внутри симулятора, используется в гонках Assetto Corsa.
loginmen
Он есть еще в Maya, 3Ds Max и думаю еще куче другого софта, обычно в паре со своим скриптовым языком. Только вот в Гудини питон не рекомендуют использовать для взаимодействия с геометрией, только изменение интерфейса программы и создание/удаление нод, так как слишком медленно.
goldrobot
А какие есть альтернативы по встраимому языку, помимо Lua давно стагнирующему и полумертвому?
playermet
А что в Lua стагнирующего и полумертвого? Новые версии у него периодически выходят. Богатая стандартная библиотека ему и не нужна, как раз потому что он предназначен в первую очередь для встраивания, а это значит что во-первых он должен быть легковесным, а во-вторых специфичный функционал должен пробрасываться из приложения. По сути Lua сейчас в завершенном состоянии, в нем только баги фиксить и производительность улучшать.