Что вы ищете на языке сценариев? [закрыто]

10

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

Не раскрывая никаких подробностей (чтобы избежать предвзятости), мне интересно знать:

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

Если вы использовали Lua, Python или другой встроенный язык, такой как Tcl или Guile, в качестве основного языка сценариев в игровом проекте, какие аспекты вы считаете наиболее полезными?

  • Языковые особенности (лямбды, классы, параллелизм)

  • Особенности реализации (оптимизация производительности, JIT, аппаратное ускорение)

  • Интеграционные функции (привязки C, C ++ или .NET)

  • Или что-то совершенно другое?

Джон Перди
источник
2
Запутывание: потому что, если это может быть запутано, то это, вероятно, также довольно гибко. Возьмем, к примеру, Perl, который может быть запутан до такой степени, что он выглядит как выходной сигнал, вызванный шумом линии от модема 300 бит / с (когда кто-то другой взял трубку на другом конце дома), в те времена, когда они были быстрый. ;-P
Рэндольф Ричардсон
1
@Randolf: Хороший вопрос. Единственная проблема с запутыванием состоит в том, что он имеет тенденцию полагаться на стабильный язык, а молодые языки - нет. Обфускатор, который работает с 0.10, может не работать с 0.11.
Джон Перди
@Jon Purdy: Это правильно (+1 для вас). Есть также аспект запутанного кода, который труднее поддерживать. Однако важно отметить, что запутывание может дать один интересный показатель гибкости языка.
Рэндольф Ричардсон
5
@Randolf: когда Perl не выглядит так?
Кен
1
@Joe Wreschnig Это говорит «какой из них выбрать», это больше «какие функции хороши в языке сценариев».
Коммунистическая утка

Ответы:

4

Я ищу две вещи - скорость и интеграцию. Обычно оба идут вместе и со знакомыми. К сожалению, для C ++ практически нет языков, предлагающих скорость и интеграцию. Я использовал Lua, и это ужасно. Я потратил все время на написание связываний и совсем немного времени для написания кода.

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

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

Проблема, которую я обнаружил, заключалась в том, что в основном все существующие языки сценариев были разработаны для расширения C, а не C ++, и не поддерживают должным образом модель C ++ во многих отношениях, и в дополнение к этому они имеют совершенно другую семантику. Как, черт возьми, я собираюсь перевести shared_ptr, то есть автоматическое детерминированное уничтожение, в среду сбора мусора? Вы можете писать любые библиотеки обёрток, которые вам нужны, вы не измените семантику основного языка, поскольку она несовместима с языком, который вы пытаетесь расширить с помощью него. Как я могу гарантировать, что это void*правильный тип? Как я могу справиться с наследованием? Как бросать и ловить исключения? Это просто не работает.

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

DeadMG
источник
Вы должны попробовать что-то вроде этой библиотеки-оболочки, которую я недавно написал для себя, чтобы решить те же проблемы, что и у вас. Вы можете использовать shared_ptrs и прочее с этим просто отлично, это безопасно для типов (насколько это возможно в любом случае), вы можете решить, хотите ли вы, чтобы жизнь контролировалась вашим кодом или средой Lua, поддерживает ли наследование, и это очень похоже на обычный Lua API. Я не уверен, что получаю жалобу на создание привязок, я просто использую отрывки vim, чтобы делать привязки 99% времени.
Алекс Эймс
2

Для веб-игр для меня важны три фактора:

  • фамильярность
  • скорость
  • интеграция

Мне особенно нравится Perl, отчасти потому, что я уже знаком с языком, и потому что с модулем веб-сервера, таким как mod_perl2, есть огромное преимущество в производительности и интеграции - mod_perl2 сохраняет скомпилированную версию скриптов в ОЗУ (которые интерпретируются только при первой загрузки), что дает ему значительное преимущество в скорости по сравнению с другими интерпретируемыми языками, которые не имеют опций компиляции, а также интегрируется в сервер Apache HTTPd с многофункциональным API, обеспечивающим доступ ко многим очень мощным функциям.

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

Рэндольф Ричардсон
источник
2

Расположены в порядке (убывания) важности:

  • Читается с первого взгляда. На самом деле, это требование для любого языка, который я хочу использовать, но для сценариев это, возможно, более важно: сценарии, по определению, меняются чаще, чем «основной» код. Таким образом, нет LISP или PERL.
  • Краткость. Сценарии постоянно пишутся и переписываются, и ввод большого количества «шаблонного» кода неэффективен.
  • Простая отладка. Желательно с контрольными точками, пошаговыми и т. Д.
  • Простая интеграция с выбранной мной «базовой» технологией. Если я использую C ++ для своей игры, мне нужны хорошие привязки C ++, как в LUA. Если игра на C #, я бы выбрал язык на основе CLI: C #, IronPython, Boo.
  • Особенности языка: простые ассоциативные массивы, сопрограммы, возможно, лямбды. На самом деле, это в основном зависит от того, для чего я собираюсь использовать сценарии. Сценарии AI отличаются, скажем, от сценариев инициализации.
  • Хорошая документация. C # имеет целый MSDN, посвященный этому, а Boo имеет только источники. Вот почему C # намного лучше.
  • Хорошая среда разработки. VS или Eclipse каждый раз бьет Блокнот.
Ничего
источник
+1 Это очень помогает мне, спасибо. Я подожду, пока не начнется ли дальнейшая дискуссия, но я думаю, что вы хорошо ее рассмотрели.
Джон Перди