Какие языковые функции необходимы для сценариев игры?

Question

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

• статические и динамические типы
• На кого это должно быть направлено: программисты или дизайнеры?
• синтаксис (должен выглядеть как C?)
• На каком высоком уровне он должен быть? (C против Lisp например - или императив против функциональности)
• Что он должен уметь делать. Как быстро это должно быть?

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

Answer 1

Как насчет поиска языков, которые фактически используются для написания сценариев в играх, таких как Python и Lua для некоторых идей?

И то и другое динамически типизировано, и с точки зрения синтаксиса Python очень не похож на C, а Lua не очень похож на C.

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

Answer 2

Вы, кажется, задаете очень общий вопрос (если вы не знаете, что должен делать язык сценариев или как быстро он должен быть), и ожидаете конкретных ответов.

Основная причина языка сценариев - позволить людям менять игру, не взламывая исходный код. Пойдем с этим.

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

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

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

Это предполагает что-то вроде Lua или Python.

Answer 3

Частично это зависит от того, какой отдел будет заниматься большинством сценариев. Если дизайнеры уровней, например, выполняют большую часть сценариев, то лучшим типом языка будет что-то ближе к естественному языку, который не требует крутой кривой обучения. Дизайнер уровней не обязательно хочет изучать сложный синтаксис, такой как C / C ++, только для воспроизведения звука.

Псевдоязык может выглядеть следующим образом (сценарии TES Construction Set такие):

script MagicCaveDoorScript
    on UseAction
        if HasItem magicDoorKey
            PlaySound2D magicDoorOpen
            ChangeArea magicCave01
        else
            Message "You need the magic door key to enter..."
        end
    end
end

Но если программисты - те, кто делает много сценариев, то, вероятно, более гибкий и мощный способ использовать более сложный язык, такой как Lua или Squirrel, с классами, объектами и тому подобным.

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

Answer 4

Мой идеальный язык сценариев игры должен иметь похожий на Python синтаксис и может быть встроен в другие языки так же легко, как LUA.
Кроме того, он должен иметь возможность встраиваться в XNA, который в настоящее время (и, вероятно, навсегда) не имеет функций отражения, от которых зависят LuaInterface и встроенный IronPython.