Каковы плюсы и минусы включения Lua в игру C ++?

У меня есть книга по программированию игр на C ++, в которой есть раздел Lua. Я начал читать раздел Lua, и это звучит интересно, но я не могу определить плюсы и минусы использования Lua в моей игре на C ++. Единственное преимущество, которое я могу себе представить, это то, что вы можете делать некоторые обновления кода через Lua без перекомпиляции. Кроме этого, я не могу думать ни о чем. Так каковы плюсы и минусы добавления Lua в игру на C ++?

Примеры будут оценены.

Единственное преимущество, которое я могу себе представить, это то, что вы можете делать некоторые обновления кода через Lua без перекомпиляции.

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

«Поток» довольно хорошо понимается психологическая концепция , когда речь идет о работе. Поток - это то чувство, которое возникает у вас, когда вы сосредоточены на какой-либо деятельности, когда вы анализируете и решаете проблемы почти не задумываясь и т. Д. Вы наиболее продуктивны, когда вы «течете».

Время компиляции все это испортит. Трудно оставаться в потоке, если у вас есть хотя бы 10-секундная компиляция между тестированием чего-либо.

Когда вы разрабатываете геймплей, то, что у вас обычно бывает, - это «тесная петля». У вас есть идея, вы пишете код теста, чтобы увидеть, работает ли он, а затем вы пробуете его. Если это не работает, измените его и попробуйте снова. Время «кода для тестирования» очень важно для поддержания потока. Получение как можно меньшего размера имеет решающее значение.

Lua (или любой встроенный язык сценариев) позволяет вам тестировать изменения не только без «компиляции», но и вживую в игру . В зависимости от того, как вы строите свою игру, вы можете запустить команду, которая перезапустит игру с новыми сценариями, не останавливая и не перезагружая данные и так далее. Вам не только не нужно перекомпилировать, вам не нужно перезапускать.

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

Еще одним важным преимуществом сценариев является возможность просто не заботиться. Если вы потратили много времени на написание C ++, вы были бы поражены тем, сколько времени вы тратите на мелочи. Где память удаляется. Где это освобождается. Даже если вы используете shared_ptrповсеместно, простое введение всех этих имен типов переменных замедляет работу.

На языке сценариев с динамической типизацией вам не нужно беспокоиться. Скоупинг прост. Функции являются первоклассными объектами; Вам не нужно создавать функторы вручную. Просто так легко делать некоторые вещи.

Теперь это имеет негативы, если вы не дисциплинированный программист. В Lua очень легко использовать глобальные переменные (хотя есть способы предотвратить это). Не заботиться означает, что вы можете быть очень неряшливым при кодировании.

Но опять же, быть очень небрежным может иметь преимущества .

Еще один плюс Lua в том, что он делает хороший язык описания данных. Так же, как JSON - это просто файл JavaScript, который создает и возвращает массив / таблицу, вы можете создавать сценарии Lua, которые возвращают таблицы.

Это полезно для файлов конфигурации; Формат таблицы Lua намного лучше, чем форматы .ini. Формат все еще довольно чистый, компактный и расширяемый.

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

Но на самом деле с этим легко справиться. Lua предназначен для встраивания, что означает, что изоляция на самом деле довольно проста. Действительно, новое состояние Lua по умолчанию ничего не дает ; Вы должны сделать что-то, чтобы показать даже самые простые из стандартных библиотек Lua. Доступ к файлам, доступ к игровому состоянию и т. Д. - все включено, а не отказано. И каждое состояние Lua отделено друг от друга. Состояние Lua, которое вы используете для AI-сценариев, не обязательно должно быть состоянием Lua, которое вы используете для конфигурационных файлов.

На самом деле у меня есть код, который позволяет вам зарегистрировать много стандартных библиотек Lua, но проходит и удаляет все файловые операции ввода-вывода. В конечном счете, худшее, что может сделать файл конфигурации на основе сценариев Lua, - это вызвать сбой вашей игры сразу после ее запуска, из-за нехватки памяти. А поскольку вы не делитесь этими конфигурационными файлами вручную, для хакера это не доставит большого удовольствия.

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

Или вы можете сделать это с помощью «printf debugging». Это действительно зависит от того, сколько кода Lua вы пишете.

Где я работаю:

Плюсы:

• Улучшения времени итерации . Наша игра настроена так, чтобы опрашивать файловую систему хоста на предмет изменений и автоматически вносить изменения. (Они вступают в силу только при следующем открытии файла, но на практике это значительное улучшение: перезагрузите уровень, и ваши новые изменения в lua вступят в силу немедленно.)
• Консольная интеграция . Любая функциональность отладки может быть подключена к традиционной консоли в стиле Quake с REPL. Для внутренних сборок мы можем даже подключить lua REPL к простому сокету, говорящему по telnet, и мы имеем сетевой контроль над нашей игрой.
• снижение API и более низкая кривая обучения . Нетехнические художники и дизайнеры могут присоединиться к некоторым задачам, которые обычно оказываются узкими местами для программистов.
• специализированный статический анализ кода . Легко проанализировать выходные данные luac -lи взглянуть на байт-код, чтобы провести некоторый анализ; также довольно легко разобрать большинство исходных файлов lua, особенно если у вас есть соглашение о кодировании. Мы можем обеспечить соблюдение местного соглашения. Вы также можете заглянуть в Metalua для еще большей власти здесь.
• обработка ошибок . Если наш API без сбоев, даже если lua делает что-то глупое, мы можем его перехватить и восстановить с помощью lua_pcall.
• простое расширение API . Написание новой функции для Lua <-> C ++ API не так уж сложно. Есть также пакеты, которые помогут автоматизировать это.
• простой источник . Внести изменения, например, чтобы избежать математики с плавающей запятой в интерпретаторе lua (важно для некоторых встроенных платформ) или оптимизировать под конкретные системы, не так уж сложно!
• метатаблицы . Это потрясающе. Так много возможностей делать интересные вещи во время выполнения. У нас есть «виртуальные таблицы», которые на самом деле не имеют содержимого, и выполняем поиск сложной структуры данных на стороне C ++ наших игр.
• сопрограммы . Возможность останавливать и возобновлять, например, сценарии поведения ИИ, удивительна. Однако со стороны сценария lua требуется немного больше знаний - мы все еще работаем над тем, как сделать это более «безопасным» с помощью нашего движка.

Минусы:

• непредсказуемый GC . Настройка того, что stepдолжно быть, радикально меняется в зависимости от игры. Некоторые лучше работают с полным GC в каждом кадре (небольшой рабочий набор). Некоторые работают лучше с намного меньшими проходами реже. Обратите внимание, что есть много работы по улучшению GC на новых версиях lua и в некоторых патчах (которые вы не должны бояться!)
• выше накладных расходов . Мы сохраняем большую часть наших больших структур данных на стороне C, чтобы избежать затрат памяти на каждую запись в таблице. C ++, C и сборка обычно производят более быстрый код. Таким образом, поддерживается 90% игрового движка, который не критичен к производительности, и иногда мы переносим вещи с lua на C (или наоборот).
• фрагментация . Возможно, самая большая проблема на небольших системах памяти. Мы обычно используем небольшие пулы объектов и полностью отдельную кучу больших объектов для lua. Мы ставим полные проходы GC в стратегических точках игры В lua_Stateнекоторых случаях мы выгружаем скрипты или выкидываем их целиком. И у нас все еще иногда возникают проблемы. Настраивать размеры пулов небольших объектов (они фиксированы, для простоты и меньших накладных расходов) и размера кучи больших объектов, характерных для lua, может быть трудной задачей. Но в системах размером более 4 МБ мы еще не утруждали себя специализированными кучами и пулами.
• отсутствие безопасности типа . Если у вас нет хорошего набора инструментов для статического анализа кода, вы наверняка воспользуетесь проверкой ошибок во время выполнения (возможно, с использованием __indexи __newindex). Лучше, если вы сможете отлавливать ошибки во время компиляции. Есть несколько вещей, которые вы можете сделать, чтобы облегчить это.

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

На самом деле есть 3 больших преимущества:

• Загрузка во время выполнения, которая позволяет загружать скрипты во время выполнения приложения.
• Песочница https://stackoverflow.com/questions/3400851/execution-time-limit-for-a-lua-script-called-from-the-c-api/3400896#3400896
• портативность

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

Например:

• Вы сможете изменить игровую логику, просто обновив игру из файла или сетевого сокета.
• Вы можете разрешить пользователям создавать свои собственные скрипты (для ботов или модов)
• Ваши игровые дизайнеры и художники смогут обновлять и тестировать части игры без использования набора инструментов компиляции.
• Вам не придется перекомпилировать каждый раз, когда вы меняете несколько скриптов.
• Вам не придется переписывать всю игру, если вы меняете платформы / движки / языки.

Из моего опыта немного сварился.

Pros

• Начальная интеграция действительно проста. Существуют инструменты, помогающие создавать привязки, но механизм привязки настолько прост, что вы можете в кратчайшие сроки написать свою собственную версию с собственными пользовательскими функциями.
• Вы получаете намного более быструю итерацию по игровой логике (при условии, что вы реализуете перезагрузку во время выполнения)
• Вы получите свободную среду для экспериментов: вы попробуете больше вещей, потому что затраты на это значительно уменьшатся
• Знакомый синтаксис: несмотря на все его различия, вам, как программисту на C, будет тяжело не чувствовать себя комфортно в течение нескольких часов
• Лучшее разделение игровой логики на «движок»: ваш движок становится поставщиком услуг, который должен предоставить достойный API клиенту Lua. Языковой барьер заставляет задуматься об этом больше, чем просто дотянуться туда и поиграть в переменную-член

Cons

• Управление памятью Lua не идеально подходит для игр. Вы справляетесь с этим, вам это не нравится
• Отладка Lua ужасна из коробки. Вам придется работать, чтобы улучшить опыт
• Хранение данных в Lua означает, что вам нужно будет отлаживать в Lua: проверка их из C будет изначально сложной
• У Lua достаточно много возможностей для самоконтроля, так как все переменные по умолчанию являются глобальными
• Lua - это язык программирования, как и любой другой. Не ожидайте, что непрограммисты волшебным образом превратятся в программистов только потому, что вы удалили компилятор
• Удача в интеграции и поддержке Lua - большая часть работы. Не ожидайте, что это будет мурлыкать прямо из коробки. Справедливо предположить, что вам придется амортизировать эту стоимость в течение нескольких игр.

Окончательный, личный, вердикт: если вы создаете игру достойного размера и у вас еще нет языка сценариев, тогда получите Lua. Это того стоит.

Garry's Mod - один из примеров игры, в которой используются Lua и C ++. Они используют Lua для всех модов, что делает их намного проще для людей. C ++ используется для всех внутренних устройств. Единственный минус, о котором я могу подумать, это то, что Lua не так быстр, как C ++.