Специфичные для домена языки для сценариев [закрыто]

12

Как многие из вас знают, встроенные интерпретаторы для языков, таких как Lua и Python, широко используются для написания сценариев игровой логики, но я не видел много информации о людях, использующих специфичные для предметной области языки для своих сценариев, например, при создании небольшого диалекта «логический сценарий» 'поверх языка, используемого для остальной части игры, с использованием макросов или свободного программирования или еще чего-нибудь.

Итак, мои вопросы таковы:

  • Какие примеры таких DSL вы видели в реальных играх?
  • С какими проблемами столкнулись?
  • Вы бы порекомендовали этот маршрут для других разработчиков игр и при каких обстоятельствах?
  • Считаете ли вы, что это становится все более распространенным, когда разработка игр движется к более дружественным к метапрограммированию языкам, например, к Boo?
Коди Броусиус
источник
Чтобы ответить на реальный вопрос об использовании DSL, Battlefield 1942 использовал их. Хотя появилось много модов; с точки зрения программистов (моих) это было ужасно, и я очень быстро потерял интерес.
Джонатан Дикинсон

Ответы:

6

Мой совет будет «не надо».

Я использовал язык разметки для данных игры. Это была боль. Я потратил несколько дней на его разработку, а затем каждую неделю или две мне нужно было настроить его, чтобы добавить больше возможностей. В какой-то момент я понял, что мне нужно автоматически сгенерировать некоторые из моих игровых данных, и я закончил тем, что написал небольшую программу для анализа входных файлов на языке разметки, их обработки и вывода различных файлов также на языке разметки.

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

Если вы работаете в такой ограниченной системе, что не можете запустить среду Lua, то, возможно, вам следует использовать DSL, но будьте готовы к агонии. В противном случае я твердо верю, что вы должны просто использовать Lua. Первоначально Lua был разработан как простой язык разметки данных и все еще чрезвычайно удобен для использования как такового, и когда (не если) вы понимаете, что вам нужно что-то более сложное, вы уже получили его. Вся моя текущая разработка игр ведется на Lua, и я никогда не был более эффективным или менее уязвимым.

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

ZorbaTHut
источник
Э, а почему бы и нет? Если бы вы только что использовали Лисп, это было бы гораздо более приятным опытом, я думаю. :) В Starcraft II есть скриптовый язык Galaxy, который действительно является языком, специфичным для предметной области и предназначенным для нетехнических ребят.
Жакмо
3
Лисп не будет DSL больше, чем Lua или Python. Это был бы полностью сформированный язык, который кто-то потратил много времени на разработку, время, которое вы можете избежать тратить самостоятельно.
Coderanger
2

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

Языки сценариев, как правило, являются дорогостоящим предложением в играх. Даже Lua, который работает довольно быстро, все еще намного медленнее, чем нативный код. Игровые команды, как правило, готовы принять этот удар, потому что это дает им два очень больших преимущества:

  1. Возможность менять скрипты без необходимости перекомпиляции и перезагрузки игры.
  2. Возможность для непрограммистов писать сценарии.

К сожалению, DSL не дают этого.

необычайно щедрый
источник
Я бы сказал, что 2) красная сельдь. Для любого достаточно интересного скрипта непрограммисту понадобится больше помощи для отладки или отладки, чем оно того стоит. Есть хорошие программисты-дизайнеры, которым не нужна помощь, но вы не можете нанести Lua For Dummies на стол обычного дизайнера уровней и ожидать, что они будут веселиться.
Tenpn
Я согласен. Я не думаю, что # 2 хорошо работает на практике, но я видел, что это используется как очевидная причина для интеграции языка сценариев.
Великолепно
Есть много людей с хорошими игровыми идеями, которые могут писать сценарии Lua, но я бы никогда не доверился malloc / sprintf / любому месту, где им нужно было выбрать структуру данных / и т.д. Это действительно то, что означает # 2 - «Способность плохих программистов наносить минимальный ущерб и при этом выполнять работу».
Они могут не вызывать утечек памяти со скриптом, но плохой программист может все еще писать глючный, не поддерживаемый и медленный код. Плохие программисты не должны быть допущены к вашей игре. Наймите дизайнеров с проверенным опытом написания скриптов, и все будет в порядке.
Tenpn
2

Мне кажется любопытным, что ваш вопрос ограничивается внутренними DSL, поскольку я бы предпочел использовать внешний DSL для того, чтобы получить возможность загружать скрипты во время выполнения и особенно для того, чтобы не-разработчики могли писать игровую логику в DSL. ,

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

Конечно, вам нужно написать парсер; В связи с этим, я думаю, что наиболее рекомендуемым инструментом является ANTLR, который предназначен для нескольких языков . В моем проекте, хотя мы пошли по пути комбинатора синтаксического анализа с jParsec (наш бэкэнд - Java, есть варианты на других языках), что неплохо для его тесной связи с BNF, но, возможно, менее хорошо документировано.

Томас Дюфур
источник
2

Мой совет будет: Делай !

Но только если у вас есть для этого применение.

Нет необходимости создавать 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

Образец учебника

Лисп - идеальный язык для создания языков, специфичных для предметной области, но, конечно, есть и другие варианты. Как Бу.

Таким образом, ваши дизайнеры / моддеры не должны изучать программирование, даже если это просто Lua, это все еще программирование.

Изменить: Позвольте мне добавить, что DSL может быть реализован на языке сценариев - это не синонимично с использованием языка сценариев. Особенно, если вы используете Lisp или аналогичный, поскольку он очень хорошо подходит для создания доменных языков.

jacmoe
источник
1

Внутренние dsls являются просто синтаксическим сахаром на хорошем API. API - это то, что является наиболее важным. После того, как у вас есть хороший API, создание dsl становится тривиальным, и не таким важным.

Джонатан Фишофф
источник
0

Возможно, UnrealScript - это DSL. Похоже, работа выполнена, хотя я думаю, что языки сценариев игры можно сделать еще более «специфичными для предметной области», чем это. Я бы порекомендовал сделать DSL, если есть что-то конкретное для домена, которое выиграет от языковых изменений - у меня есть несколько идей в этой области, но в настоящее время ничего полностью не сформировано.

Считаете ли вы, что это становится все более распространенным, когда разработка игр движется к более дружественным к метапрограммированию языкам, например, к Boo?

Однако я не думаю, что один достаточно новый движок, поддерживающий язык, свидетельствует о том, что разработка игр движется в определенном направлении. Еще рано.

Kylotan
источник
0

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

Но если вам нужно в основном определить данные; возможно декларативный, а не императивный; возможно, определяет состояния и правила (например, GDL); и не требует большей части того, что хорошо делает язык GP, тогда рассмотрим DSL.

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

david.pfx
источник