Скрипты в играх что это такое

Скрипты в играх что это такое

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

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

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

Для этой книги я колебался между двумя различными типами скриптовых систем. Первая из них предполагает использование языка, похожего на С++. В файле скрипта вы печатаете команды, компилируете его и исполняете скомпилированный скрипт из вашей игры. Вторая система скриптов является значительно упрощенным вариантом первой. Вместо того, чтобы позволить вам печатать команды в файле, эта система обеспечивает создание скриптов путем выбора команд из предварительно определенного набора.

Поскольку моей целью было как можно быстрее предоставить вам работающий скриптовый движок, я выбрал использование второго типа скриптовой системы. Эта система, которую я назвал Mad Lib Scripting, работает используя набор предопределенных команд, называемых действия (actions), с каждым из которых связана игровая функция. Возьмем, для примера, действия из таблицы 10.1 — у каждого действия есть конкретная выполняемая функция.

Таблица 10.1. Примеры команд действий

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

Для примера скажем, что действию Play Sound соответствует номер 4, и действие требует единственного параметра — номера воспроизводимого звука. В скрипте вам потребуется сохранить только два числа: одно для действия, и одно, представляющее звук. Использование чисел для представления действий (вместо текста) делает обработку скриптов такого типа быстрой и простой.

Источник

Разработка нагрузочных скриптов для браузерных/мобильных игр. Часть 1

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

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

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

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

Проблема релевантных данных

При разработке скриптов для эмуляции банковских бизнес-процессов скрипты (обычно)
опираются на данные, которые “видят” на конкретном этапе (на веб-странице например). То есть, чтобы перейти на следующий шаг необходимо лишь расфасовать в нужные места заранее подготовленные (или взятые из этой же страницы) данные и отправить их.

Одна из главных проблем при разработке скриптов для игры — это сложность самого слежение (трекинга) изменений, которые произошли до данного конкретного момента, перед выполнением команды. Информация об изменённом состоянии объектов, ресурсов, юнитов и пр. может прийти в любой момент, даже после выполнения не связанных с конкретными данными действий. Если пропустить данное обновление, то виртуальный пользователь (VU, тред в Jmeter) будет рассинхронизован с игрой и начнет генерить ошибки аля “недостаточно ресурсов” или «нет места на карте» и превращать нагрузочный тест в нечто бесполезное. Конечно всегда есть вероятность того, что всё же скрипт выдаст что-то типа “нельзя атаковать союзника”, если он секунду назад стал таковым, но то же самое произойдет и в настоящем клиенте.

Также осложняет жизнь то, что почти всегда все исходные данные и текущее положение дел в игровом мире приходят в клиент только при логине в игру (обычно это огромный JSON на несколько мегабайт) и далее по ходу игры клиент исходя из этих первоначальных данных и преходящих изменений находится в релевантном состоянии, то есть знает о текущем положении дел. То же самое необходимо реализовать и в скрипте, надо чтобы каждый VU “запомнил” что игра присылает на стадии логина и далее аккуратно передавать и изменять эти данные в ходе выполнения теста. Далее приведу пример как я решал проблему с одной из игр компании InnoGames.

Forge of Empires

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

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

Вновь зарегистрированный игрок после логина видит примерно следующее: пустое поле и одно главное большое здание (ГЗ), пару деревьев и дорог на нем:

Само незанятое поле и объекты разбиты на квадраты, в зависимости от размера приходится считаться с размером самого здания и свободного места на карте. Здания делятся на типы: жилые, производственные, военные, культурные, дороги и прочее. Разные здания производят разные ресурсы: жилые — население и деньги, производственные — товары и ресурсы, культурные — счастье и так далее. При постройке каждого здания необходимо учитывать те же самые ресурсы и если их не хватает нужно либо ждать, либо, например, построить новый дом, чтобы восполнить население. Чувствуете куда я клоню? Это не бухгалтерские проводки эмулировать 🙂

Строительство

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

После нескольких часов раздумий пришла идея простого алгоритма, я назвал его “строительство слоями”. Суть его в следующем. Как вы могли заметить на скриншоте сверху, ГЗ прижато к краю карты за которым уже ничего строить нельзя и это сыграло на руку. Каждый VU после логина первым делом строит дорогу по контуру карты и самого главного здания, а уже потом строит необходимые здания, возле этой дороги, пока есть место. Таким образом все здания построенные у дороги будут связаны с ГЗ. Далее мы строим следующий “слой” дороги уже по контуру построенный зданий. Таким образом, первоначальную дорогу мы строим, исходя из условия: например если слева граница карты, справа — пусто, а сверху и снизу от проверяемого квадрата пусто или что-то есть, то мы вероятно можем построить дорогу.

Примерно так (зеленый квадрат — ГЗ, жёлтый — дорога, черный — какое-либо здание):

Поехали

Так как данная игра общается с клиентом исключительно посредством http с JSON`ами, я использую в Jmeter дополнительную библиотеку org.json для работы и парсинга запросов/ответов в post- и pre- процессорах.

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

Для упрощения кода впоследствии и уменьшения потребляемой памяти каждым java-тредом мы сохраняем из всего набора данных только те, которые будем использовать, поэтому предварительно необходимо создать и подключить два простеньких вспомогательных класса Entity и ExistEntity — первый отвечает за любое доступное в игре здание в принципе (со стоимостью, размером, функциями и прочим), а второй за уже построенное в городе (с координатами).

Первый POST-запрос StaticData_getData возвращает огромный JSON весом в 1-2 мегабайта. Распарсим его, создадим структуру, например HashMap и заполним её объектами Entity с ключами id, чтобы впоследствии обращаться к этому хэш-мапу за информацией о каждом конкретном здании:

Теперь каждый виртуальный пользователь знает всю необходимую информацию о зданиях. Далее необходимо “запомнить” территорию, её размеры и текущее расположение зданий в самом городе. Я использовал также HashMap, в котором в качестве ключей используются объекты класса java.awt.Point с координатами X, Y, а в качестве значений String с названием типа здания в данной координате.

Сама территория города не является квадратом а состоит из набора открытых областей, размером 4×4, поэтому изначально мы заполняем данный хэш-мап нулями по всем координатам которые открыты и доступны пользователю. Помимо этого, нам необходимо использовать данные из предыдущего шага, т.к. мы получая только координаты здания из данного запроса, должны также “залить” другие координаты, исходя из ширины и высоты здания.

При помощи vars.putObject() теперь каждый тред (VU) будет знать всю необходимую информацию, остаётся только вовремя обновлять данные объекты на каждом этапе выполнения скрипта, если игра присылает соответствующие данные.

Строим

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

Добавляем в HTTP Sampler jsr223 pre-processor и формируем запрос. Перебираем каждую квадратик, ищем пустой и тот, которого окружает хоть один (из 8) занятый другим объектом (включая границу) квадрат. Таким образом, мы “обведём” дорогой любой объект, включая границу территории (здесь есть большой простор для оптимизаций, надеюсь кто-нибудь подскажет более лучший алгоритм):

Далее нам необходимо построить само здание. Допустим, сейчас нам неважно какое, нам важен лишь его размер. Соответсвенно ищем на воображаемой карте такую координату, от которой на расстоянии ширины здания по оси X и высоты здания по оси Y находятся свободные квадраты, а также в одной из восьми квадратов по углам здания есть дорога (я правда проверяю 4 верхних, таким образом заполнение города идет сверху вниз):

Также необходимо удостовериться, что на всей желаемой территории будущего здания не окажется какого либо объекта (дерева например):

На самом верхнем уровне тест-плана Jmeter добавляем Post-processor который, будет реагировать на каждый входящий респонс от игры, парсить его и обновлять объекты, так как нам необходимо трекать изменение ресурсов, а также обновлять виртуальную карту новыми зданиями:

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

Спасибо за внимание, я решил не сваливать всё в кучу и разбить тему на несколько частей. Следующая часть будет посвящена решению той же самой проблемы, но в более жёстких условиях, когда клиент игры использует HTTP-протокол с protobuf, а обновления получает через web-сокет с STOMP.

Оставлю ссылку на наш гитхаб, может найдете что-то интересное.

Источник

Скрипты, когда и где они нужны? Как работают?

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

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

1. Чтобы свести на минимум количество перекомпиляций проекта во время разработки? А если проект небольшой, компьютер мощный, а код толково разделять на отдельные файлы hpp/cpp? Всё равно преимущество скриптов на лицо?

3. Когда наступает тот момент, когда однозначно нужно использовать систему скриптов в игре вместо «хардкоженья» всего на С++? Когда проект большой, или когда в команде много программистов, или это уже стандарт в индустрии?

4. Встречаются ли сейчас более менее серьёзные проекты без скриптов? Когда отказ от скриптов и написания всего проекта на С++ оправдано?

6. Связь между скриптом и монолитным нативным кодом игры для меня загадка. Вызываются ли скрипты каждый кадр, т.е. интерпретатор скриптов работает каждый кадр? И обмен переменными между скриптами и программой идёт постоянно во время работы игры?
или же скрипт выполняется только во время запуска сцены?
До недавнего я полагал, что на скриптах пишут, какие ресурсы грузить, какие объекты с какими параметрами для сцены создавать, условия победы/поражения и т.д.
А вот как можно писать логику на скриптах?
Насколько я понял, скрипты вызывают ф-ии нативного кода. Значит с++программисты пишут все необходимые действия (ф-ии), вроде перемещений объектов, физики и т.д., а скрипты дают команду вызывать те или иные ф-ии?

7. Если скрипты призваны облегчить процесс разработки, то есть ли возможность перед релизом скомпилировать скрипты во что-то более близкое к нативному коду дабы повысить производительность?

Спасибо, что дочитали сей выплеск)
Всех с Наступающим!)

Есть lua-jit например, не нативный код, конечно, но близко.

А как это будет выглядеть? В редакторе сцены вставляем верёвку и кирпич в нужную позицию, на верёвку цепляем скрипт, в котором кодируем поведение верёвки и её реакцию на клик? Это уже юнити какое-то) Получается сейчас все движки ведут себя как юнити в том смысле, что к каждому объекту прикрепляется скрипт, который дёргается каждый кадр? Или это совсем по-другому делается?

Другой нес овоську, в ней что то звенело
Шнурки на боткинках изгнили, истлели
Поднял вдруг бычек один и затянулся
Другой от усталости пошатнулся.

Я понял что это не кто не иные
А скриптеры бедные нищие хромые
Жестокий мир сферы Ай Ти
И правды в нем не найти

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

Zackary
> Это уже юнити какое-то) Получается сейчас все движки ведут себя как юнити в
> том смысле, что к каждому объекту прикрепляется скрипт, который дёргается
> каждый кадр? Или это совсем по-другому делается?
Каким то образом. Юнити это кстати очень хорошо, именно потому что можно вещи цеплять мышкой и сразу видеть результат.

>1. Чтобы свести на минимум количество перекомпиляций проекта во время разработки? А если проект небольшой, компьютер мощный, а код толково разделять на отдельные файлы hpp/cpp? Всё равно преимущество скриптов на лицо?
Это только одна из достигаемых целей. Формально, можно вынести логику в DLL и будет то же самое на С++.
Другие возможные цели: упростить всё и делегировать написание игрового кода дизайнерам, сделать изолированную песочницу чтобы можно было не бояться багов на этапе разработки, расширить возможности языка, превратить код в данные (на сях это тоже возможно, но придется писать генератор кода т.е. решение все равно будет стремиться к «скриптам»).

>3. Когда наступает тот момент, когда однозначно нужно использовать систему скриптов в игре вместо «хардкоженья» всего на С++? Когда проект большой, или когда в команде много программистов, или это уже стандарт в индустрии?
Когда это имеет смысл. Все названное никак не связано со скриптами.

>4. Встречаются ли сейчас более менее серьёзные проекты без скриптов? Когда отказ от скриптов и написания всего проекта на С++ оправдано?
Любые старые игры, не?

>6. Связь между скриптом и монолитным нативным кодом игры для меня загадка. Вызываются ли скрипты каждый кадр, т.е. интерпретатор скриптов работает каждый кадр?
Как сделаешь так и будет. Хоть только по редким событиям, хоть каждый кадр (это в общем-то тоже событие, какой-нибудь OnFrame).

>А вот как можно писать логику на скриптах?
Так же как и на С++, в чем проблема? Никто не мешает научить скрипты оперировать объектами напрямую, в том числе создавать их без вызова нэйтив функций.

-Eugene-
> Нет смысла дергать перекомпиляцию проекта каждый раз, когда нужно поправить
> циферку. А если среды нет? Такое вполне может быть, если в разработке участвует
> больше одного человека.
Дельное замечание.
Если картко: скрипты это удобно но менее быстродейственный код на выходе.

В общем случае, циферки не имеют отношения к скриптам.

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

x
Все в конфигах не предусмотришь. Особенно тогда, когда константа может зависеть от обстановки и ее следует вычислять.

Я не знаю что такое «обстановка». Константа может зависеть только от других констант и метода расчета из них.

Источник

Что такое скрипты и с чем их едят — Lua & C++

Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов

Что нужно знать?

Но есть способ, на голову выше — использование скриптов.

Решение проблемы

«Окей, для таких дел хватает обычного файла с описанием характеристиков игрока. Но что делать, если в бурно развивающемся проекте почти каждый день приходится немножко изменять логику главного игрока, и, следовательно, много раз компилировать проект?»
Хороший вопрос. В этом случае нам на помощь приходят скрипты, держащие именно логику игрока со всеми характеристиками либо какой-либо другой части игры.
Естественно, удобнее всего держать, логику игрока в виде кода какого-нибудь языка программирования.
Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.
К счастью, есть специальные библиотеки скриптовых языков для С++, которые принимают на вход текстовый файл и выполняют его.

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

Как это работает?

Прежде чем начать, важно понимать, как работает скриптовый язык. Дело в том, что в скриптовых языках есть очень мало функций, при наличии конструкций for, while, if, прочих.
В основном это функции вывода текста в консоль, математические функции и функции для работы с файлами.
Как же тогда можно управлять игроком через скрипты?

Мы в С++-программе делаем какие-либо функции, «регистрируем» их под каким-нибудь именем в скрипте и вызываем в скрипте. То есть если мы зарегистрировали функцию SetPos(x,y) для определения позиции игрока в С++-программе, то, встретив эту функцию в скрипте, «интерпретатор» из библиотеки скриптового языка вызывает эту функцию в С++-программе, естественно, с передачей всех методов.
Удивительно, да? 🙂

UPD: Внимание! Один юзер обратился мне с мейлом, что, когда я заливал код, я не полностью устранил все ошибки — habrahabr.ru/post/196272/#comment_6850016
В коде с позволения хабра проникли жучки
Замените участки кода вроде

И еще вместо lua_CFunction проскакивает lua_cfunction
Спасибо!

Я готов!

Когда вы поняли преимущества скриптовых языков программирования, самое время начать работать!
Скачайте из репозитория на гитхабе (низ топика) lib’у и includ’ы Lua, либо возмите их на официальном сайте.

Создаем консольный проект либо Win32 (это неважно) в Visual Studio (у меня стоит версия 2012)

Заходим в Проект->Свойства->Свойства конфигурации->Каталоги VC++ и в «каталоги включения» и «каталоги библиотек» добавьте папку Include и Lib из репозитория соответственно.

Теперь создаем файл main.cpp, пишем в нем:

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

Теперь переходим к кодингу

Обещаю, что буду тщательно объяснять каждый момент

У нас за скрипты будет отвечать класс Script. Я буду объявлять и одновременно реализовывать функции в Script.h/.cpp
Создаем Script.cpp и пишем в нем

Создаем Script.h и пишем в нем

После 2 строчки и перед #endif мы определяем класс скриптов
Этот код пишется для предотвращения взаимного включения файлов. Допустим, что файл Game.h подключает Script.h, а Script.h подключает Game.h — непорядок! А с таким кодом включение выполняется только 1 раз

Теперь пишем внутри этого кода вот это

Первая строчка подключает сам lua.lib из архива.
Для чего нужен extern «C»? Дело в том, что lua написан на С и поэтому такой код необходим для подключения библиотек.

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

Теперь приступим к определению класса

Самый главный объект библиотеки Lua для C++ — lua_State, он необходим для выполнения скриптов

Дальше идут публичные функции

Эта функция инициализирует lua_State

Его определение в Script.cpp

Первой строчкой мы инициализируем наш lua_State.
Потом мы объявляем список «подключенных библиотек». Дело в том, что в «чистом» виде в луа есть только функция print(). Для математических и прочих функций требуется подключать специальные библиотеки и потом вызывать их как math.foo, base.foo, io.foo. Для подключения других библиотек добавьте в lualibs, например, <«math», luaopen_math>. Все названия библиотек начинаются с luaopen_. в конце lialibs должен стоять

Просто используем lua_close()

А эта функция выполняет файл. На вход она принимает название файла, например, «C:\\script.lua».
Почему она возвращает int? Просто некоторые скрипты могут содержать return, прерывая работу скрипта и возвращая какое-нибудь значение.

Как вы видите, я выполняю скрипт и возвращаю int. Но возращать функция может не только int, но еще и bool и char*, просто я всегда возвращаю числа (lua_toboolean, lua_tostring)

Теперь мы сделаем функцию, регистрирующую константы (числа, строки, функции)

Мы действуем через шаблоны. Пример вызова функции:
Ее определение

Для каждого возможного значения class T мы определяем свои действия.
*Капитан* последнее определение — регистрация функции
Функции, годные для регистрации, выглядят так:

Где n — количество возвращаемых значений. Если n = 2, то в Луа можно сделать так:

Читайте мануалы по Луа, если были удивлены тем, что одна функция возвращает несколько значений 🙂

Следующая функция создает таблицу для Луа. Если непонятно, что это значит, то тамошная таблица все равно что массив

Следующая функция регистрирует элемент в таблице.

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

Наконец, заполненную таблицу нужно зарегистрировать

Ничего особенного нет

Следующие функции предназначены в основном только для функций типа int foo(lua_State*), которые нужны для регистрации в Луа.

Первая из них — получает количество аргументов

Эта функция нужна, например, для функции Write(), куда можно запихать сколь угодно аргументов, а можно и ни одного
Подобную функцию мы реализуем позже

Следующая функция получает аргумент, переданный функции в скрипте

Можно получить все типы, описывавшиеся ранее, кроме таблиц и функций
index — это номер аргумента. И первый аргумент начинается с 1.

Наконец, последняя функция, которая возвращает значение в скрипт

Боевой код

Пора что-нибудь сделать!
Изменяем main.cpp

Компилируем. Теперь можно приступить к тестированию нашего класса

Помните, я обещал сделать функцию Write? 🙂
Видоизменяем main.cpp

А в папке с проектом создаем файл script.lua

Компилируем и запускаем проект.

Теперь изменяем script.lua

Теперь программа будет выводить по 2 строки («\n» — создание новой строки), ждать нажатия Enter и снова выводить строки.

Экспериментируйте со скриптами!

Вот пример main.cpp с функциями и пример script.lua

Полезные советы

Вопросы и ответы

Источник