Які плюси і мінуси включення Lua в гру C ++?

У мене є книга програмування ігор на C ++, і в ній є розділ Луа. Я почав читати розділ Луа, і це звучить цікаво, але я не можу визначити плюси та мінуси використання Lua в моїй грі C ++. Єдиною перевагою, про яку я зараз можу придумати, є те, що ви можете зробити кілька оновлень кодування через Lua, не потребуючи перекомпіляції. Крім того, я нічого не можу придумати. Отже, які плюси та мінуси додавання Lua до гри на C ++?

Приклади були б вдячні.

Єдиною перевагою, про яку я зараз можу придумати, є те, що ви можете зробити кілька оновлень кодування через Lua, не потребуючи перекомпіляції.

Не знижуйте корисність цього так легко. Ви ніколи не зрозумієте, наскільки продуктивними ви будете, поки не заберете крок перекомпіляції.

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

Складіть рази, щоб все це вкрутити. Важко залишатися в потоці, якщо у вас є навіть 10-секундна компіляція між тестуванням чогось.

Коли ви розробляєте геймплей, зазвичай у вас є «тугий цикл». У вас є ідея, ви кодуєте тест, щоб побачити, чи працює він, а потім ви спробуєте його. Якщо це не працює, ви модифікуєте його та повторіть спробу. Час "коду на тест" дуже важливий для підтримки потоку. Отримати її якомога меншою мірою є вирішальним.

Що дозволяє Lua (або будь-якій вбудованій мові сценаріїв) - це перевірити зміни, не тільки без "компіляції", але жити в грі . Залежно від того, як ви будуєте свою гру, ви можете запустити команду, яка перезапустить гру з новими сценаріями без необхідності зупиняти і перезавантажувати дані тощо. Ви не тільки не повинні перекомпілювати, не потрібно повторно запускати.

Здатність робити це, за умови належної підтримки двигуна, може різко підвищити продуктивність.

Ще одна основна перевага сценаріїв - це можливість просто не турбуватися. Якщо ви довго витрачалися на написання С ++, ви були б вражені тим, скільки часу ви витрачаєте за минуту. Де видалено пам'ять. Де це звільняється. Навіть якщо ви використовуєтеshared_ptr скрізь, саме введення всіх цих назв змінних типів сповільнює вас.

Мовою сценаріїв, що динамічно набирається, вам не доведеться піклуватися. Оцінка простоти проста. Функції - це першокласні об'єкти; не потрібно вручну збирати функтори. Зробити деякі речі просто так просто .

Тепер це має негативи, якщо ви не дисциплінований програміст. У Луа дуже просто користуватися глобалами (хоча є способи запобігти цьому). Небайдужість означає, що ви можете бути дуже неохайними, коли кодуєте.

Але знову ж таки, бути дуже неохайним може мати переваги .

Ще одна перевага Луа полягає в тому, що вона робить приємну мову опису даних. Так само, як JSON - це лише файл JavaScript, який створює та повертає масив / таблицю, ви можете створювати скрипти Lua, які повертають таблиці.

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

О, і це все ще сценарій Lua, тому він може виконувати фактичну логіку. Недоліком цього є ... ну, це сценарій Lua, тому він може виконувати фактичну логіку . Це може бути катастрофічно в грі, оскільки користувач може потенційно почати викручувати речі.

Але насправді з цим легко впоратися. Lua розроблений для вбудовування, а це означає, що ізоляція насправді досить проста. Дійсно, свіжий стан Луа за замовчуванням не забезпечує нічого ; вам потрібно зробити щось, щоб викрити навіть найосновніші зі стандартних бібліотек Lua. Доступ до файлів, доступ до стану ігор тощо тощо - це все відмова, а не відмова. І кожен стан Луа є окремим один від одного. Стан Lua, який ви використовуєте для сценаріїв AI, не повинен бути статусом Lua, який ви використовуєте для файлів конфігурацій.

У мене фактично є код, який дозволяє реєструвати багато стандартних бібліотек Lua, але він проходить і видаляє всі файли IO. Зрештою, найгірше, що може зробити конфігураційний файл на основі скрипту Lua, - це призвести до краху вашої гри відразу після її запуску шляхом запуску її з пам'яті. А оскільки ви не ділитесь цими конфігураційними файлами вручну, це не буде дуже цікаво для хакера.

Я б сказав, що найбільшим недоліком будь-якої мови сценаріїв є налагодження. Більшість мов сценаріїв не мають налагоджувачів, і Lua нічим не відрізняється. У Луї є всі інструменти, які знадобляться для створення інструментів налагодження. Але він насправді не має вбудованого налагоджувача. Ви повинні скласти один. І це вимагатиме розумного ступеня роботи.

Або ви можете зробити це через "налагодження printf". Це дійсно залежить від того, скільки коду Lua ви пишете.

Де я працюю:

Плюси:

• покращення часу ітерації . Наша гра створена для опитування файлової системи хоста на предмет змін і автоматично "приглушує" зміни. (Вони набувають чинності лише при відкритті наступного файлу, але на практиці це головне поліпшення: перезавантажте рівень, і ваші нові зміни луа прийдуть негайно.)
• інтеграція консолей . Будь-яка функція налагодження може бути підключена до традиційної консолі Quake у стилі REPL. Для внутрішніх побудов ми можемо навіть підключити lua REPL до простого сокета, який говорить telnet, і ми маємо мережевий контроль над нашою грою.
• зменшена апі та нижча крива навчання . Нетехнічні художники та дизайнери можуть приєднатись до деяких завдань, які, як правило, мають вузькі програми.
• спеціалізований статичний аналіз коду . Легко розібрати вихід luac -lі заглянути в байт-код, щоб зробити якийсь аналіз; також досить легко проаналізувати більшість вихідних файлів Lua, особливо якщо у вас є умова кодування. Ми можемо застосовувати місцеві збори. Тут ви також можете заглянути в металую для ще більшої потужності.
• поводження з помилками . Якщо наш API без збоїв, навіть якщо Луа робить щось нерозумно, ми можемо його зловити і відновити за допомогою lua_pcall.
• просте розширення API . Написати нову функцію для API Lua <-> C ++ не надто складно. Існують також пакети, які допоможуть це автоматизувати.
• просте джерело . Внести зміни, наприклад, уникати математики з плаваючою точкою в інтерпретаторі lua (важливо на деяких вбудованих платформах) або оптимізувати для конкретних систем не надто складно!
• метатабелі . Це приголомшливі. Стільки потенціалу робити цікаві речі під час виконання. У нас є "віртуальні таблиці", які насправді не містять вмісту і здійснюють пошук у складній структурі даних на C ++ стороні наших ігор.
• корутини . Можливість зупинитись та відновити, наприклад, сценарії поведінки AI - це дивовижно. З боку луа-скриптера потрібно трохи більше розуму, проте ми все ще працюємо над тим, як зробити це більш "безпечним" за допомогою нашого двигуна.

Мінуси:

• непередбачуваний GC . Налаштування того, що ми stepповинні змінити, різко змінюється за гру. Деякі працюють краще з повним GC у кожному кадрі (невеликий робочий набір). Деякі працюють краще з набагато меншими проходами рідше. Зауважте, що вдосконалення GC для новіших версій lua та деяких патчів (які ви не повинні боятися використовувати!).
• вище накладні . Ми зберігаємо багато наших великих структур даних на C-стороні, щоб уникнути накладних оперативної пам'яті. C ++, C і збірка загалом створюють швидший код. Таким чином, він зберігається до 90% ігрового двигуна, що не є критичним для продуктивності, і ми іноді ми переносимо речі з луа на C (або навпаки).
• роздробленість . Мабуть, найбільше питання малої пам'яті. Зазвичай ми використовуємо невеликі об'єктивні пули та повністю окрему велику купу об'єктів для луа. Ми ставимо повні проходи GC у стратегічні моменти гри. Ми вивантажуємо сценарії або викидаємо lua_Stateцілком у деяких випадках. І у нас все ще іноді виникають проблеми. Налаштування розмірів малих об'єктних пулів (вони фіксовані, для простоти та нижчих витрат) та розміру специфічної для луа купи великих об'єктів може бути болем. Але в системах, більших приблизно від 4 Мб, ми ще не набридали спеціалізованими купами та пулами.
• відсутність безпеки типу . Якщо у вас не створений гарний набір інструментів для аналізу статичного коду, ви перейдете на багато перевірок помилок під час виконання (можливо, використання __indexта __newindex). Краще, якщо ви можете виявити помилки під час компіляції. Щоб полегшити це, ви можете зробити різні речі.

Луа настійно рекомендується, просто будьте готові трохи попрацювати з цим! Ви також можете перевірити Squirrel , хоча я вважаю, що у нього менша база користувачів.

Насправді є три чудові переваги:

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

Ці фактори дозволяють вам як розробнику ігор ввімкнути функції, які прискорять розвиток та підвищують якість вашої гри.

Наприклад:

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

З мого досвіду, трохи закипіла.

Плюси

• Початкова інтеграція дійсно проста. Існують інструменти, які допомагають генерувати прив’язки, але механізм прив'язки настільки простий, що ви можете за короткий час написати свою власну версію з власними спеціальними функціями.
• Ви отримуєте набагато швидшу ітерацію логіки гри (якщо припустити, що ви перезавантажуєте час виконання)
• У вас з’явиться визвольне середовище для експерименту: ви спробуєте більше речей, тому що накладні витрати на це значно зменшуються
• Знайомий синтаксис: зважаючи на всі його відмінності, вам буде важко натиснути як програміст C, щоб не було комфортно в ньому протягом години
• Краще розділення логіки гри на "двигун": ваш двигун стає постачальником послуг, який повинен виставити гідний API клієнту Lua. Мовний бар’єр змушує задуматися над цим більше, замість того, щоб просто зайти туди і підправити змінну члена

Мінуси

• Управління пам'яттю Lua не ідеально підходить для ігор. Ви впораєтеся з цим, вам це не подобається
• Lua налагодження жахливо поза коробкою. Вам доведеться попрацювати над покращенням досвіду
• Зберігання даних у Lua означає, що вам доведеться налагоджувати в Lua: перевірити їх від C спочатку буде складно
• Lua має велику кількість себе в синтаксисі стопи, як і всі змінні за замовчуванням є глобальними
• Lua - мова програмування, як і будь-яка інша. Не чекайте, що непрограмісти магічно перетворяться на програмістів лише тому, що ви видалили компілятор
• Робота з інтеграцією та підтримкою Lua - це велика частина роботи. Не сподівайтеся, що він вийде прямо з коробки. Справедливо вважати, що вам доведеться фактично амортизувати цю вартість протягом кількох ігор

Остаточний, особистий, вердикт: якщо ви будуєте гру пристойних розмірів і не маєте мови сценаріїв, тоді отримайте Lua. Це того варте.

Гаррі Мод - один із прикладів гри, яка використовує Lua та C ++. Вони використовують Lua для всіх мод, що робить їх набагато простішими для людей. C ++ використовується для всіх інтернетів. Єдине, про що я можу подумати, - це те, що Луа не такий швидкий, як C ++.