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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

Отчасти зависит от того, какой отдел будет выполнять большинство сценариев. Если дизайнеры уровня, например, занимаются большой частью сценариев, то лучший тип языка будет чем-то ближе к естественному языку, который не требует крутой кривой обучения. Дизайнер уровня не обязательно хочет изучать сложный синтаксис, например 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 с классами, объектами и т. д.

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