У моєму поточному проекті скрипти Lua викликаються функціями C ++ на стороні сервера. Після цього сценарії знову викликають функції C ++, які все ще знаходяться в цьому рішенні. Чому ми повинні робити такі речі, а не викликати функцію C ++ безпосередньо? Які ситуації потрібні сценарії?
Відповіді:
Сценарії, як правило, компілюються під час виконання , тоді як мова хосту буде збиратися під час компіляції. Це означає, що нам не потрібно перекомпілювати, якщо сценарій зміниться. Перекомпіляція повноцінної гри може зайняти від декількох годин до годин, що означає великий хід продуктивності.
Зазвичай критичний або допоміжний код не буде сценарієм. Цей код повинен працювати швидко і часто управління пам'яттю має вирішальне значення.
В іграх логіка та конфігурація гри зазвичай містяться у файлах сценаріїв. Ці сценарії можуть бути легко оновлені непрограмістами (наприклад, дизайнером) для налаштування ігрового процесу. Мови скриптів є простими і діють прощально для цієї мети.
Часто мову скриптів також використовують, щоб робити сценарії в режимі реального часу . Це зручно для налаштування деяких елементів гри або навіть для налагодження. Багато ігор забезпечують консоль для цієї (переважно внутрішньої) мети.
Цілком можливо, що ви створюєте гру, використовуючи існуючий ігровий движок, просто за допомогою сценаріїв. Таким чином, шар ігрового двигуна повністю відокремлюється від логічного рівня гри . Сучасні двигуни зазвичай можуть бути використані для створення ігор FPS або RTS легко, як це, але це неможливо для будь-якого жанру. MMO, ймовірно, вимагатиме іншого типу двигуна.
Таким чином, суть є роз'єднанням. Перелічені вище переваги часто переважають зайву роботу зі створення або інтеграції мови сценаріїв.
Ви задали неправильне запитання. Справжнє питання, я думаю, це чому ми миримося з "не-сценарієм" мовами, такими як C, C ++, Java тощо? І відповідь одна з причин: продуктивність. (І може бути інерція, але ця інертність є завдяки продуктивності, і кожен, хто вміє добре писати C / C ++ / Java, може написати принаймні Ruby / Python / Lua / JavaScript.)
Ми використовуємо "скриптові" мови (що насправді означає, що дуже високий рівень, зібраний сміття, і, як правило, певна форма більш дружнього введення та динамічної компіляції), оскільки вони, як правило, простіші мови для всіх - включені програмісти - для написання коду. Тут менше дурні речі, такі як запам’ятовування, щоб звільнити їх після вибору або переконатися, що ваш код є безпечним для винятків, або пам'ятати, щоб зробити всі ваші деструктори віртуальними. Якби наші комп’ютери були нескінченно швидкими, ми б використовували "скриптові" мови для всього.
Мови сценаріїв для логіки ігор - дуже хороший приклад схеми архітектури програмного забезпечення Alternate Hard and Soft Layers . На цьому сайті є хороша дискусія (та й інші впевнені) про переваги цього.
Зміни сценарію легко розгортати. Наприклад, ви можете зберігати скрипти в базі даних, що означає, що замість повного перерозподілу бінарних файлів та можливого перезавантаження служби, ви просто видаєте єдиний оператор оновлення SQL UPDATE, можливо, подаючи сигнал до запущеної служби, щоб перезавантажити скрипт.
Також мови скриптів часто прості для розуміння та їх легко програмувати, тому вам не потрібні «жорсткі» диски (ті, що стосуються управління пам’яттю / покажчиками та оптимізаціями на рівні процесора) для більшості кодів (якщо великий RPG, сценарії для AI, Spells, Item Effects та самого світу часто більше, ніж код двигуна). Мови сценаріїв дозволяють набагато більше зосередитись на тому, що робити, а не на тому, як завдяки збору сміття (у випадку Луа) та більш високому рівню абстракції.
Один із сценаріїв, коли сценарії корисні - це коли ми хочемо, щоб наш мотор був розширюваним плагінами / аддонами. Ці розширення створюються у багатьох випадках непрофесійними людьми (наприклад, просунутими геймерами та ентузіастами). Сценарії безпечніші та легші для цієї мети. Використовуючи сценарії, їм не потрібно використовувати компілятори і не потрібно знати про вказівники ...
Чудовим прикладом цього є гра World of Warcraft. У ньому є тисячі адонів, створених громадою. Ці доповнення записуються за допомогою LUA + XML.