Мови домену для сценаріїв [закрито]

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

Тож мої запитання такі:

• Які приклади таких DSL ви бачили в реальних іграх?
• Які проблеми виникли?
• Чи рекомендуєте ви цей маршрут іншим розробникам ігор та за яких обставин?
• Чи бачите ви, що це стає більш поширеним, коли розробка ігор рухається до більш зручних для метапрограмування мов, наприклад, Boo?

Моя порада буде "не робити".

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

Я, чесно кажучи, поняття не маю, про що думав. Вся справа була б простішою, ефективнішою, меншою кількістю багпрону та набагато менш трудомісткою, якби я щойно використовував Lua.

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

Я не можу рекомендувати проти DSL досить сильно.

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

Мови сценаріїв, як правило, є дорогим пропозицією в іграх. Навіть Lua, який досить швидкий, все ще дуже повільніше, ніж рідний код. Ігрові команди, як правило, готові сприймати цей удар, оскільки він купує їм дві дуже великі вигоди:

1. Можливість зміни скриптів без необхідності перекомпілювати та перезавантажити гру.
2. Можливість непрограмістів писати сценарії.

На жаль, DSL не дають вам цього.

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

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

Звичайно, вам потрібно буде написати аналізатор; для цього я думаю, що найбільш рекомендованим інструментом є ANTLR, який орієнтований на досить багато мов . На моєму проекті ми ходили маршрут комбінатора парсера з jParsec (наш сервіс - Java, є варіанти на інших мовах), що дуже приємно для його тісних стосунків з BNF, але, можливо, менш добре зафіксовано.

Моя порада була б: Робіть !

Але лише в тому випадку, якщо ви користуєтесь цим.

Не потрібно створювати DSL, якщо ви просто збираєтесь його використовувати самостійно - всередині.

Galaxy - це сценарна мова, якою використовується редактор Startcraft II. Це яскравий приклад мови, що залежить від домену.

Він орієнтований на ігрових дизайнерів, а не на програмістів:

Timer - Start Raise Lava Timer as a One Shot timer that will expire in 20.0 Game Time seconds
Variable - Set Raise Lava Timer = (Last started timer)
Timer - Create a timer window for (Last started timer), with the title "Lava will raise in: ", using Remaining time (initially Visible)
Variable - Set Lava Timer Window = (Last created timer window)
Timer - Show (Last created timer window) for (All players)
Variable - Set Lava Death? = false

Зразок навчального посібника

Lisp - це ідеальна мова, яка використовується для створення мов, визначених для домену, але, звичайно, є й інші варіанти. Як і Бу.

Таким чином, ваші дизайнери / моддери не повинні вивчати програмування, навіть якщо це просто Lua, це все-таки програмування.

Редагувати: Дозвольте додати, що DSL може бути реалізований на мові сценаріїв - це не синонім того, що не використовується мова сценаріїв. Особливо, якщо ви використовуєте Lisp або подібні, оскільки він надзвичайно добре створює мови, що відповідають домену.

Внутрішні DSL - це лише синтаксичний цукор на хорошому API. API - це найважливіше. Після того, як у вас є хороший API, виготовлення DSL - це банально, і це не так важливо.

Можливо, UnrealScript - це DSL. Здається, це виконає роботу, хоча я думаю, що можна зробити мови сценаріїв гри ще більш «доменними», ніж це. Я рекомендував би створити DSL, якщо є щось конкретне для домену, яке виграє від зміни мови - у мене є кілька ідей у ​​цій галузі, але в даний час нічого повністю не сформовано.

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

Однак я не думаю, що один досить новий двигун, що підтримує мову, є свідченням розвитку ігор у певному напрямку. Це ще ранні дні.

Якщо вам потрібна загальномовна мова програмування, то прокатка власної майже напевно помилка. Якщо ваша мова, здається, потребує змінних, оцінювання виразів, циклів, умовних умов, класів, функцій тощо, найкраще дотримуйтесь відомої мови, як Lua, Lisp, Python, JavaScript тощо. [Unreal покинув своє.]

Але якщо вам потрібно, це здебільшого питання визначення даних; можливо, декларативний, а не імперативний; можливо, визначає стани та правила (наприклад, GDL); і не потрібна більшість того, що добре працює в мові GP, тоді розглянемо DSL.

Але будьте обережні: створення мов та компіляторів може бути дуже важким, а попередній досвід - це велика допомога. Я рекомендував би парсер PEG (сам DSL) на основі граматики EBNF (інший DSL), і якщо це занадто великий запит, то краще не намагатися.