Яка технологія дозволяє програмувати всередині гри?

Є деякі ігри, які дозволяють гравцеві писати / створювати сценарії в грі, наприклад: Космічні інженери або Psi .

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

Чи існує галузь програмування, яка охоплює можливість програмного забезпечення, щойно складене, для запуску нового коду, створеного користувачем?

Під галуззю програмування я маю на увазі щось на кшталт PTG (Procedural Terrain Generation).

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

Сценарії, написані сценаріями / вбудованими / інтерпретованими мовами, такими як "Lua", "Lisp" або "AngelScript" ( докладніше тут ), можна оновлювати під час гри [*], а потім інтерпретувати (= виконувати) на льоту.

Ви можете прив’язати елементи з цих сценаріїв до рідного скомпільованого кодування (C ++ тощо), щоб потім сценарії могли виконувати логіку з вашої програми. E. g. певна команда, яку користувач може ввести в сценарій, в результаті переміщує ігровий персонаж на задану відстань в ігровому світі.

Деякі відповідні питання:

• Яку мову сценаріїв слід вибрати для своєї гри?

• Що ви шукаєте на мові сценаріїв?

• Як додати мову гри до сценарію?

[*] або користувачем у рамках гри, або також розробниками для швидкої ітерації / тестування без перезавантаження програми

Вбудована мова - це відповідний технічний термін. На практиці мови, які використовуються всередині інших програм (наприклад, ігор), часто називають сценаріями або навіть інтерпретованими мовами, хоча їх не обов'язково інтерпретувати або використовувати для автоматизації рутинних завдань. Гуглінг "мови сценаріїв для ігор", ймовірно, дасть корисніші результати, ніж пошук "вбудованих мов".

Ви шукаєте спосіб зміни коду на деякі дії. Саме цим займаються перекладачі .

Погляньте на Python. Ви запускаєте це, і бам! Ви приземляєтесь у REPL ( R ead E val P rint L oop).

Ви визначаєте функцію "привіт", яка друкує "Привіт, світ". І там у вас є!

Зауважте, що ви нічого не склали; Інтерпретатор зробив якусь магію, щоб створити функцію на льоту (під час виконання), і тепер ви можете це зателефонувати.

Те саме стосується ігор. Замість того щоб мати REPL, у вас є гра з модулем REPL. Гра, ймовірно, запускає REPL, а потім запускає все інше в цій REPL, тож ви маєте доступ до даних і можете активно їх змінювати.

Якщо ви працюєте з величезними мовами, такими як C ++, вони, як правило, менш динамічні та, ймовірно, компільовані. Ви хочете трохи простіше. Ви або створюєте свою власну мову, або використовуєте деякі існуючі (наприклад, CoffeScript, Білка, Луа, Схема, ...)

Їх часто називають скриптовими мовами , оскільки ви використовуєте їх для написання сценаріїв , побудованих на ігровому двигуні, розробленому на іншій мові (наприклад, C ++).

Якщо мова програмування в іграх була розроблена тільки для цілей гри, то це мова, що залежить від домену .

Перевага (і недолік) мов, що належать до домену, полягає в тому, що сама мова може обмежувати, що може робити користувач (тобто ви можете заборонити підключення до Інтернету). Ви можете створити мову, яка робить типові ігрові завдання легшими, ніж у мові загального призначення. Недоліком є ​​те, що користувач має вивчити нову мову.

Тільки запуск несанітизованого коду користувача загальною мовою (наприклад, python чи perl) у вашій грі може дозволити користувачеві возитися з речами, з якими він не повинен возитися. Але це залежить від вашої гри. Якщо ви не заперечуєте проти того, щоб користувачі робили такі речі, як відкриття нових вікон у вашій грі або що завгодно, ви можете використовувати мову загального призначення та викривати прив’язки до певних особливостей вашого ігрового світу.

Є два приклади, які я можу придумати вгорі голови. Здається, що обидва роблять саме те, що ви просите.

Перший - це шпильки. https://screeps.com/ Ви можете прочитати багато про те, як він досягає цієї мети на веб-сайті http://support.screeps.com/hc/en-us/articles/205960931-Server-side-architecture-overview

Друга - ComputerCraft http://www.computercraft.info/ Вони не вкладаються в деталі щодо того, як це працює, але трохи їх можна побачити на їхній вікі http://www.computercraft.info/wiki/Main_Page

По суті, основна гра запускає інтерпретатора в окремий потік, потім дозволяє цьому потоку маніпулювати ігровим світом через дзвінки API.

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

Зазвичай для того, щоб почати щось подібне, потрібно дуже мало роботи. Тобі потрібно

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

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

Скомпільований виконуваний файл повинен містити аналізатор , здатний читати зовнішній код програми . Код програми не повинен виглядати як C або Python чи xyz - це можуть бути будь-які описові дані, що підходять для цілі, про яку йдеться. Наприклад шведська, або морзе.

Зовнішній програмний код повинен мати синтаксис , щоб аналізатор розумів його під час читання символу за символом. Синтаксис може описувати (і код може містити) ідентифікатори, числові значення, оператори тощо .

Аналізатор виправлений (компілюється), але він працює на гнучкому зовнішньому коді.

Скомпільований виконуваний файл повинен мати внутрішній API для його відповідного функціоналу. щоб парсер міг виконувати дії. Швидше за все, повинен бути (двонаправлений) доступ і до внутрішніх даних виконуваного файлу, або аналізатор повинен забезпечити певний тип зберігання та ведення ведення даних.

Аналізатор може прочитати зовнішній код програми при запуску виконавчого файлу , або він може прочитати (частини) його ad hoc , або він може перечитати його в кожному кадрі (було б неефективно), або код можна навіть ввести вручну і розміщується в аналізаторі по мірі готовності (наприклад: "перемістити блок X вперед на 5 кроків" [ввести]).

По суті, зовнішній код не виправлений - він може змінюватися в будь-який рік, день або хвилину, але все ж виконуваний файл не потрібно повторно компілювати. Змінюється лише результуюча поведінка, розміщена виконуваним файлом.

Текст, який ви зараз читаєте, (вид і навіть більше, якщо він був промовлений) інтерпретується тому, що ви «виконайте» його в головному мозку, читаючи його, не знаючи, що говорить наступне речення (або навіть, якщо це можливо, підлість змінюється правильно) зараз). На відміну від переповнення стека (попередньо) компілюючи всю історію в байт-код у вашому мозку, який потім виконує її - і ofc тоді вона більше не може змінюватися.

У Phenomen триває є interpretion. Сценарій - це лише акт створення deSCRIPTion або написання . Всі комп'ютерні кодування - це сценарій imo - ми описуємо, що ми хочемо статися. Слово «сценарій» набуло дещо нахиленого значення, але будьте добре. Ми знаємо, що ми маємо на увазі.

З інтерпретованими мовами немає абсолютно нічого надзвичайного, і це жодним чином не спірний термін . Їх існує безліч, а деякі найдавніші трактуються на відміну від складених. Інтерпретованою мовою можна, наприклад, ввести вручну:

sock = Socket.New (AddressFamily.InterNetwork, SocketType.Stream ProtocolType.Tcp) [ENTER]

... а потім піти на 30 ... ні, 45 хвилинну перерву на каву :-). Повертаючись, "шкарпетка" існує і готова до подальшого використання, набравши більше вручну або дозволяючи автоматизації перекладача продовжувати роботу.