Жизнеспособна ли реализация вашего собственного языка сценариев?

Я пишу кодовую игру на C ++, и пришло время реализовать скрипты для событий, триггеров, кат-сцен и т. Д. Я перечитал в Интернете и получил немало информации. Моим первым решением было бы реализовать свой собственный язык сценариев, такой как в Cave Story . Я видел это предложенное, но большинство людей предлагают Луа, но это не соответствует моему типу программирования.

Вы сделали свой собственный язык сценариев? Почему вы выбрали накатить свой вместо того, чтобы использовать существующий? С какими ресурсами вы консультировались во время разработки?

Нет. По крайней мере, вероятно нет.

Это очень частый случай изобретения колеса - разработка игры, ошибка, которая все еще довольно популярна.

Если вы задаете этот вопрос, вы, скорее всего, будете зависеть от того, что делают другие, поэтому просто посмотрите, что Epic Games только что сделала с Unreal Engine:

• У UE3 была нестандартная, неоптимизированная, трудно отлаживаемая вещь UnrealScript,
• Если слух правдив, то его поддержка удаляется в UE4 в пользу горячо загружаемых библиотек C ++.

Как вы думаете, вы можете сделать лучше, чем Epic?

Создание языков программирования принадлежит создателям языков программирования , а не инженерам игр.

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

Чтобы ответить на ваши дополнительные вопросы, нет, по этим самым причинам я никогда не использовал свой собственный язык сценариев. Но я много страдала с некоторыми полусырыми. Поскольку они были созданы с очень узким набором функций, у них всегда были эти маленькие безумные причуды, которые сводили вас с ума. Часто вы обнаружите, что тратите очень много времени, пытаясь обойти ограничения языка вместо того, чтобы просто делать свою игру.

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

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

редактировать

Я только что посмотрел на список команд Cave Story, который вы связали. Уч:

<ECJx:y      [EC?] Jump           @ Jump to event Y if any npc with ID X is present

Я не хочу проявлять неуважение к разработчику, стоящему за Cave Story, но это прекрасный пример простого списка команд, который мутировал в неконтролируемом пользовательском языке сценариев. Это может все еще использоваться для отдельного разработчика или очень маленькой команды, но на этом этапе я советую переключиться на надлежащий Turing-полный и проверенный язык (например, Lua), где вы могли бы сделать:

if (npc.id == x) then
    jump_to_event(y)
end

Это значительно упростит ситуацию, когда, например, вам понадобится более сложное условие:

if (npc.id == x) or (npc.type == "enemy") then
    jump_to_event(y)
end

Вы создали свой собственный язык сценариев и почему вы выбрали собственный, а не существующий?

У меня есть, хотя я заимствовал синтаксис из других языков. В целом это был большой опыт обучения, и в моем случае это не так сложно, потому что язык был простым.

Я сделал это главным образом потому, что хотел использовать обычный синтаксис в стиле C для своих сценариев, так как все в команде были знакомы с ним.

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

С какими ресурсами вы консультировались во время разработки?

Моим основным ресурсом была эта книга:

Мне удалось выучить достаточно из этой книги, чтобы реализовать:

• Лексер: это было почти тривиально, используя регулярные выражения, просто используя Regex.Match для идентификации и разделения токенов.
• Парсер рекурсивного спуска: в основном одна функция для каждого правила в грамматике и несколько вспомогательных методов для просмотра и использования токенов. Я посмотрел на спецификации грамматики C # для вдохновения. Сложнее всего было иметь дело с арифметикой и приоритетами операторов отношений, не вдаваясь в бесконечную рекурсию.
• Интерпретатор AST: используя шаблон проектирования посетителя, я обошел дерево, сгенерированное из синтаксического анализатора, и рекурсивно выполнил каждый узел инструкции.

Я бы остановился на этом, поскольку почти все, что мне было нужно, уже работало, за исключением одного - вызова и выдачи сопрограмм Unity3D глубоко внутри рекурсивного интерпретатора. Чтобы решить эту проблему, мне пришлось избавиться от рекурсии и снова повернуться к книге. На этот раз я добавил:

• Компилятор: еще один посетитель, но вместо выполнения кода он генерирует список небольших атомарных инструкций из каждого узла AST (т. Е. Простой пользовательский язык ассемблера на основе стека). Такие операции, как цикл while или условие if, преобразуются в метки и инструкции типа goto. На этом этапе я также записываю скомпилированный скрипт на диск в виде двоичного файла.
• Интерпретатор байт-кода: просто перебирает простой список инструкций. Без рекурсии теперь было легко интегрироваться с сопрограммами Unity3D.

Весь процесс занял около 2 недель с нуля знаний, и было очень весело :)

PS: В конце я также хотел добавить подсветку синтаксиса и intellisense для моего пользовательского языка в наших инструментах. Сцинтилла была спасателем в этом отношении. Я использовал следующую обертку:

http://scintillanet.codeplex.com/

Я видел это предложенное, но большинство людей предлагают Луа, но это не соответствует моему типу программирования.

Хорошо, давайте попробуем это с другой стороны: что в Lua вам не нравится? Это что-то, что легко поправимо, или это что-то фундаментальное?

Например, используйте ключевые слова, такие как then/do/endобозначение блока кода, а не хорошие фигурные скобки в стиле C / C ++. Если это твоя проблема ... это то, что ты можешь исправить. Все, что вам нужно сделать, это определить свой собственный маленький диалект Lua и написать простой инструмент преобразования, который преобразует ваш синтаксис в фигурные скобки в настоящий Lua.

Хотите + = в какой-то форме? Это также легко сделать в системе предварительной обработки. Просто включите утверждения формы expr1 += expr2в expr1 = expr1 + expr2.

Конечно, вам нужно будет найти способ определить, представляют ли пару фигурных скобок таблицу или do/endпару. И вы должны подключить систему предварительной обработки в Lua Переопределелив dofile, loadstringи другими стандартными функциями библиотеки Lua. Но все это в конечном итоге выполнимо.

Если такие проблемы, как эта, вас беспокоят, и вы слишком привязаны к одному стилю программирования, чтобы просто изменить способ кодирования (обратите внимание: это вообще ужасное качество для программиста), это гораздо более жизнеспособная альтернатива, чем просто писать на своем родном языке. Это займет максимум пару недель . Сравните это с годами , которые будут потрачены на правильный язык, с богатой поддержкой отладки и тому подобным.

Если ваши проблемы больше, чем это (глобальные переменные являются значением по умолчанию, что требует от вас использования localвезде), некоторыми из них можно управлять (просто сделайте объявление нового глобального ошибочным, используя измененные среды и метатаблицы). Если вы ненавидите функции как первоклассные объекты, сопрограммы, сборщики мусора или другие базовые элементы Lua ... ну, тогда вы в своем собственном деле;)

И если вы действительно, действительно хотите быть хардкорным в этом, вы можете написать свой собственный язык, который вы компилируете в Lua. Таким образом, вы по крайней мере сможете использовать очень хорошо протестированную среду выполнения Lua, исключительный API Lua и другие базовые возможности Lua, все из вашего языка! Lua. Это займет время, но это не будут годы, которые вы потратите на что-то другое.

Чтобы дополнить другие ответы, это не является строго бинарным вариантом. В существующем языке сценариев вы также можете создать свой собственный Domain-specific_language . Преимущества этого подхода:

• Вам на самом деле не нужно возиться с формальными грамматиками, парсерами, реализацией пользовательских редакторов и т. Д.
• Вы получаете большую пользу от реализации специализированного языка сценариев, то есть дополнительной абстракции, специфичной для вашей игры.
• по сравнению с homebrew: пользователи, которые знакомы с выбранным вами языком сценариев, сразу же смогут использовать ваш DSL.
• по сравнению с простым существующим языком: пользователям, не знакомым с языком сценариев, просто понадобятся знания DSL для модификации вашей игры.

Основным недостатком является то, что вы будете проектировать DSL с учетом ограничений вашего «базового» языка.

Это может иметь смысл в зависимости от механики вашей игры. Некоторые игры с достаточно простой механикой могут использовать интерпретируемый язык, чтобы уберечь себя от чрезмерно сложного кодирования Lua / Python, но экономия от сложности может не стоить слишком многого. Например, в одной из этих игр Interactive Novel можно было легко использовать пользовательский сценарий.

Если ваша игра включает в себя физический движок, различные игровые компоненты и различную сложность персонажей и способностей, вам определенно следует рассмотреть возможность просмотра других существующих языков сценариев, чтобы не тратить усилия на добавление необходимых функций к своему собственному или исправлять ошибки с помощью Это. Хотя Lua, скорее всего, самый быстрый, есть много других, которые вам могут понравиться больше за их синтаксис, и многие из них хвастаются тем, насколько легко они интегрируются с C. Python, Ruby и Angelscript - это лишь немногие. (Не стесняйтесь упоминать других в комментариях)

Если вы убедитесь, что такие языки используются только для «логического контроля» (т. Е. Обработки конкретного случая столкновения для определенных типов объектов, таких как пламя бластера, касающегося ледяного блока), то производительность вряд ли когда-либо станет проблемой. Конечно, с другой стороны, если вы используете их для более рутинного кода (создание собственного алгоритма проверки столкновений, который запускает каждый кадр), это с большей вероятностью приведет к потере скорости.

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

Убедитесь, что вы начинаете с простого, часто тестируете и придерживаетесь своего идеала. Но всегда помните, LUA для вас.