Яку мову сценаріїв ви б рекомендували для ігрового проекту C ++? [зачинено]


14

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

У такій мові, як Lua, є такі обгортки, як luabind, але коли я використовував її раніше, у неї виникли проблеми, оскільки він не підтримував перевизначення методу в контексті успадкування.

Які ваші пропозиції щодо мови / обгортки використовувати чи не використовувати?

Відповіді:


9

Відео-ігри,
розроблені Lua, ігрові двигуни Lua

Я думаю, що Луа - найкращий знімок.

У цій статті йдеться про інтеграцію Lua та C ++. Він говорить:

LuaBind - чудовий продукт, але для мене це виглядало занадто складно. Для одного коду непросто простежити, де перебувають класи та об’єкти. Також, побачивши, що я хотів інтегрувати Lua у додаток wxWidgets, використання шаблонів було трохи ні-ні (ви можете прочитати проблеми з платформою на сайті wxWidgets).

Є багато інших обов'язкових бібліотек:

http://luabridge.sourceforge.net/
http://www.stackedboxes.org/~lmb/diluculum/
http://cpplua.sourceforge.net/
http://www.tecgraf.puc-rio.br/~ труби / толуа /

Яка найкраща обгортка C ++ / Lua?

Просто виберіть і насолоджуйтесь.


Так, Lua досить просто та дуже легко інтегруватись із C. Насправді, це головна мета Луа - вбудована мова.
Марко Мустапік

Дякую за посилання на LuaBind, можливо, перекопування в інших обов'язкових бібліотеках переконає мене знову взяти Луа
Frédérick Imbeault

Однак я б запропонував запускати ваші сценарії в основному потоці та надавати для нього розподільник пулу, якщо продуктивність викликає занепокоєння
Килотан

5

Мені сподобався Chaiscript ; Я не дуже довго його використовую, але поки здається досить солідним.

На відміну від Python або lua, він побудований з нуля, щоб використовувати його з C ++. Процес зв'язування здається набагато більш чистим, ніж з luabind / тощо.

Ось підсумок веб-сайту:

ChaiScript - це перша і єдина сценарна мова, розроблена з нуля з урахуванням сумісності C ++>. Це натхненна ECMAScript вбудована функціональна мова.

ChaiScript ліцензується під ліцензією BSD.


Цікаво. Що з тестами на ефективність? Чи є порівняння ChaiScript / Lua / Python?
точний

Цікаво, чи є якісь недоліки / помилки / результативність, через які ви пережили поки що?
Frédérick Imbeault

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

1
Просто FYI, оскільки цьому коментарю вже 6 років - ChaiScript зараз робить неявні числові перетворення.
lefticus

5

Я б рекомендував Луа .
Python теж дуже популярний. Багато популярних ігрових двигунів (наприклад, Blender) використовують його.
C ++ :: Boost має бібліотеку для роботи з Python.
Я читав про Білку , але не користувався нею.

Ви можете прочитати цей огляд Game Engine . Є Scriptingколонка. Ви можете бачити, що Lua та Python - найпопулярніші мови сценаріїв.


Щодо Boost, я думаю, можливо, це величезна бібліотека, і багато чого іншого не дуже корисне у всіх проектах. Насправді луабінд багато використовує Boost, і це одна з речей, які мені не сподобалися.
Фредерік Імбео

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

1
І ви включаєте лише ті бібліотеки (заголовки Boost), які вам потрібні. Підвищення величезне, але вам все одно, поки вам не потрібно це чи те.
точний

А щодо python та Lua, чи є якісь обгортки для C ++, які дозволяють переглядати методи класу, створювати нові методи тощо? І чи можна цю функцію контролювати за допомогою коду C ++ (для безпеки)? Як я вже говорив, LuaBind робить це, але провалюється в умовах спадкування, що досить часто зустрічається в ігровому проекті. Методи, які я хотів би переосмислити, - це для прикладу, тестування певного циклу ігор, методів оновлення таких об'єктів, як гравець, метод оновлення самого ігрового світу тощо
Frédérick Imbeault

У Lua немає класів та об’єктів, але вони можуть бути імітовані таблицями. Ось бібліотека Lua для OOP, яку я віддаю перевагу: love2d.org/wiki/MiddleClass .
точний

4

Чому б не побудувати свій власний?

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

Переваги

  1. Ви дізнаєтесь про цікаву частину інформатики.
  2. Розвиваючи "власний" сценарій двигуна, він дає вам повний контроль від початку до кінця, дозволяючи підганяти двигун саме до того, що вам потрібно.
  3. Якщо вам потрібно буде внести будь-які зміни пізніше в дорозі, вони можуть зробити дещо простішими знання ваших і кодових кодів вашої власної бази даних, а не вивчення інших і інших.
  4. Вам не доведеться турбуватися про те, щоб підтримувати двигун в курсі чужих патчів.

Недоліки

  1. Час. Не так вже й багато людей. Якщо вам потрібно щось зараз, спробуйте вже існуючий двигун (наприклад, один із запропонованих).

  2. Швидкість. Дуже багато існуючих сценаріїв дуже швидкі - користувацьке рішення може бути не таким швидким.

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

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

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

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

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

"Створення систем сценаріїв на C ++", здається, є улюбленою статтею, якою люди поділяються під час обговорення теми: http://www.gamedev.net/reference/list.asp?categoryid=76


2
Я погодився, що це має певну перевагу в освіті. Але це вимагає певних знань та навичок з теорії мов програмування (про які думає багато людей) та певних знань з теорії обчислень. Якщо це відповість на шви, які приваблюють когось, я б запропонував тези двох книг: amazon.com/gp/product/0136073476/ref=oss_product та amazon.com/gp/product/0534950973/ref=oss_product
Frédérick Imbeault

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

Був там зробив те. Дізнався багато про синтаксичний розбір, дизайн компілятора, машини байт-коду, все таке. Наступного разу я, мабуть, буду використовувати Lua і оцінювати це ще більше. :)
Kaz Dragon

2

Я спробував Lua, Python, Scheme та Squirrel. Луа опрацював найкраще; він має більшу спільноту та кращу підтримку, ніж Білка, та набагато кращі пам’яті та експлуатаційні характеристики, ніж Python. Схема теж дуже добре працювала і має по-справжньому крихітного тлумача, але дизайнерам було важко обернути голову навколо функціональної мови.


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.