Какой язык сценариев выбрать для своей игры? [закрыто]

53

В каких случаях языки сценариев лучше других?

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

(Помните, один язык за ответ)

Linus Sjögren
источник

Ответы:

39

Lua широко используется в игровой индустрии . От независимых игр ( Аквариум ) до титулов ААА (Цивилизация).

Основная причина? Я бы сказал, потому что это легко учиться и легко включать в свои игры. Но то же самое можно сказать и о Python, я уверен. Сценарии, как правило, не сложно. Я думаю, что настоящая причина, по которой вы должны использовать Lua, заключается в том, что она доказала, что приводит к гораздо большему количеству ресурсов, из которых вы можете извлечь уроки. Если вам хочется экспериментировать с чем-то, выходящим за рамки нормы, я бы начал возиться с другим языком.

Дэвид Макгроу
источник
8
Lua очень популярен, потому что предоставляет функции «метаязыка». Вы можете реализовать объектно-ориентированные структуры или чисто процедурные функции и т. Д. Он имеет очень простой интерфейс C и дает разработчику движка большую гибкость в самом языке.
Каранца
3
Я не уверен, что Python сделает хороший выбор. Привязки C для python гораздо больше направлены на расширение python с помощью C, чем на встраивание python в C.
SpoonMeiser
5
Из того, что я слышал, у Ĺua также хорошая производительность во время выполнения по сравнению с другими языками сценариев, такими как Python. (и он полностью поддерживает замыкания - очень интересная функция, если вы спросите меня ...)
thbusch
2
На самом деле Цивилизация IV использует Python ...
Эмилиано
2
@happy_emi Действительно, в то время как Civ V использует Lua
Тобиас Кинцлер
23

белочка

Белка имеет интересную историю. Он был построен после того, как у игрового архитектора возникли проблемы с непредсказуемой сборкой мусора Lua, и сумасшедшее все равно нулю, даже если его не существует .

Белка - это язык написания сценариев, используемый в Left 4 Dead 2 . API очень похож на lua (автор Squirrel любит дизайн Lua ).

Итак, Squirrel - это потрясающий язык, так как это своего рода Lua второго поколения. Он взял хорошие идеи и убрал раздражающие чудачества.

То же самое из Lua:

  • сопрограммы
  • таблицы и метатаблицы
  • динамический тип
  • еще больше

Новое для Белка:

  • классы
  • массивы
  • регулярные выражения вместо синтаксиса соответствия Lua.
  • Язык стилей C / C ++ / Java / C # вместо стиля Pascal / Delphi.
  • еще больше

Основной недостаток белки - это не Луа. Луа гораздо более широко используется. Но если это не проблема, «Белка» - это легкая победа. Однако часто популярность языка сама по себе является полезной функцией, поэтому решение не так однозначно.

deft_code
источник
9

V8 Javascript от Google.

PRO:

Довольно прост в использовании

Постоянно поправляется

Мощный и гибкий

Другие Как уже упоминалось, javascript - это распространенный инструмент для программистов. Добавление его в мои игры открыло гораздо больше людей, которые чувствуют себя способными, чем другие языки. Он также поддерживает огромное количество приведения и преобразования, чтобы сэкономить на работе для программиста, также делает его действительно простым в использовании, хорошо работает с STL.

Возможные CON:

Документация может сбивать с толку. Это действительно не самое лучшее.

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

Шаблоны Иногда их ненавидят или избегают.

Размер кодовой базы SDK Размер сгенерированного кода может рассматриваться как раздувание.

оборота FuzzYspo0N
источник
Одним из минусов для меня был размер. Если вы создаете простую / казуальную игру, то движок v8 достаточно велик и даже может быть во много раз больше, чем вся ваша игра.
Зак Человек
Правда, но как отдельный файл .lib это большая проблема? Это просто слоты рядом с вашим SDL или вашей луей. Если вы имели в виду размер сгенерированного кода, то я не проверял, насколько он велик, но это неплохой момент.
Подчеркнутое
Я имел в виду размер сгенерированного кода. Я полагаю, это не ТАКОЕ большое, учитывая размер большинства игр сегодня.
Зак Человек
1
Протестировано, Shell.cc по умолчанию с последними часами SVN в 1.441 МБ bit.ly/9DNn8J . Хотя это кажется довольно трудоемким, большинству библиотек нужно делать что-то еще (сеть, графика), что добавит к этому столь же драматично. Мой сторонний проект с v8, phoenixGL, ENet, пакетами наддува и большим количеством кода внутри решения (например, сжатие, шифрование, библиотеки графического интерфейса, awesomium) работает с частотой 2,5 МБ в Visual Studio 2008 - и упакован в " релиз "сборки весов в 861 кб. Для меня это не так уж и плохо. На некоторых платформах я мог видеть, что это проблематично - не для большинства, хотя :)
подчеркивается
1
Я использовал V8 несколько раз в моих проектах. IMO Javascript - это самый идеальный язык для сценариев игры. Природа на основе событий и объекты на основе прототипов делают все так просто. :)
Стивен Белэнджер
7

Это зависит от игры и ее целевой платформы.

Игра, в которой участвуют 100 неигровых персонажей (игры RTS), отличается от игры, в которой играют только 2 (Street Fighter). Игра, которая работает на ПК, имеет другие потребности, чем игра, которая работает на консоли.

Луа популярен

GameMonkey используется несколькими командами. Это быстрее, чем Lua и лучше в потоке.

Python был использован в нескольких играх.

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

Есть также специализированные языки.

SCUMM использовался в нескольких приключенческих играх и особенно подходит для этих игр.

GMan
источник
Javascript - это действительно хорошая идея. Интересно, почему у этого, кажется, не было тяги в этом месте? Есть идеи?
cflewis
У JavaScript есть тяга. Единство использует это. Как и Wolfire Games для своего движка.
А.А. Грапсас
Два двигателя действительно не делают тяги. Я предполагаю, что причина этого только в том, что до Mono и V8 не было много хороших интерпретаторов JavaScript. SpiderMonkey - это не совсем то, на что вы смотрите и говорите: «Да, я хочу, чтобы моя игра была такой быстрой, быстрой и стабильной!»
4

Для полноты картины, другой вариант - это mono-script , который позволяет использовать реализацию скриптов .NET для Novell. Это то, что использует Unity . Вот еще одна страница о встраивании моно в ваше приложение.

Среда Mono работает быстрее, чем большинство (возможно, все?) Языков сценариев, потому что она не интерпретируется, и поскольку между компилятором и набором инструкций существует слой, она позволяет программировать на различных языках, включая C # и диалекты Python, Lua и Javascript.

Однако я не уверен, что это бесплатно на всех платформах.

Сандер ван Россен
источник
4
Обратите внимание, что если вы занимаетесь разработкой консоли, то о JITing-коде, очевидно, не может быть и речи, поскольку вы не можете пометить страницы данных как исполняемые. IL это должно быть предварительно скомпилировано для целевой платформы.
Джефф
3
Проблема JIT также относится к iOS. Также Mono имеет лицензионные ограничения. Вам нужна коммерческая лицензия, если вы хотите использовать ее в среде, где конечный пользователь не может / не может обновить среду выполнения Mono.
Сэм
4

Лично я обнаружил, что AngelScript (см. Ссылку ниже) гораздо проще связать с C ++, чем с Lua, когда я выбирал язык сценариев для своего собственного проекта. (На самом деле я написал небольшую библиотеку-обертку, чтобы сделать ее еще проще в использовании за счет некоторой гибкости.)

http://www.angelcode.com/angelscript/

При этом я подозреваю, что у Lua есть несколько преимуществ, которые делают его привлекательным для разработчиков коммерческих игр:

(а) Он более зрелый и распространенный, чем AngelScript

(b) Его синтаксис проще для непрограммистов (AngelScript очень похож на C ++)

(c) Он имеет меньшую площадь, чем AngelScript (по крайней мере, насколько я помню)

Если вы просто пишете хобби-проект, я бы сказал, что AngelScript по крайней мере стоит посмотреть.

Стюарт Голодец
источник
2

Вы должны выбрать язык сценариев, который имеет стабильные и хорошо поддерживаемые привязки к основному языку разработки вашей игры. Если вы пишете свою игру на C или C ++, то для Python и Lua есть довольно надежные привязки. Если вы пишете свою игру для платформы .NET (используя C # или другой язык), тогда я настоятельно рекомендую использовать IronPython или IronRuby. Оба варианта представляют собой полные языковые реализации, в которых используется динамическая языковая среда выполнения Microsoft (DLR), которая обеспечивает отличную производительность и очень тесную интеграцию с .NET Framework. Функциональная совместимость между C # и IronPython / IronRuby в наши дни довольно гладкая, особенно с введением динамического связывания сайтов вызовов в C # 4.0.

Майк Штробель
источник
2

Схема

Ну, лукавство конкретно.

С guile вы можете иметь свой собственный DSL (Domain Specific Language) только для вашей игры. Как только вы привыкнете к скобкам и префиксным обозначениям, схема - это рай для работы.

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

Джо Д
источник
1

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

Для более полноценного подхода я бы сказал, что Python - правильный выбор. Civ IV использовал его для достойного эффекта.

cflewis
источник
0

Выбор одного языка сценариев над другим зависит от ваших конкретных требований.

Некоторые из вариантов, которые вы должны выбрать между:

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

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

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

Blackbone
источник
0

Если вы работаете над заголовком для Windows и пишете управляемый код, работающий поверх Common Language Runtime (CLR) - скажем, например, в C # - я бы посоветовал вам взглянуть на интеграцию (Iron) Python как языка сценариев.

По моему опыту, Python очень легко преподавать непрограммистам / дизайнерам. Разработчикам подобрать его еще проще, так как он по сути читается как псевдокод. Динамическая типизация - это только один из аспектов, который помогает людям быстро освоиться с языком и практически не иметь опыта программирования.

В дополнение к тому, что язык прост в изучении и мощен, CLR и языковые группы в Microsoft (Андерс Хейлсберг, Эрик Липперт, Мадс Торгерсен, Джим Хугунин и др.) Проделали большую работу по раскрытию функций компилятора и среды выполнения с помощью нового Dynamic. Language Runtime (DLR) в .NET 4, делающий взаимодействие между статически типизированным кодом и динамически типизированным кодом гораздо более простым. Из того, что я видел и пробовал до сих пор, стандартный код сведен к минимуму. Это сохранит вашу кодовую базу чистой и поддерживаемой.

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

codesurgeon
источник
0

Ответ очень зависит от вашей среды. В настоящее время я работаю с Unity, поэтому я использую моно-язык (в моем случае C #, но Javascript и Boo также являются опциями). Ответ полностью зависит от ваших конкретных обстоятельств.

user266
источник
-2

ActionScript - это гибридный динамический / статический типизированный язык, используемый для создания Flash-игр, который может широко распространяться в Интернете. Он довольно хорошо поддерживается такими библиотеками, как Flixel, FlashPunk и Box2d.

Iain
источник
-2

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

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

Andreas
источник
Я бы написал интерпретатор или jit-компилятор в haskell для sth, таких как lisp / схема, или bash, или python, или lua, или erlang (что-нибудь без стандартных библиотек) через один или два дня. Я бы не советовал писать интерпретатор, например, в C ++ или Java, если он не предназначен для интерпретации как sth lisp. Но это был не вопрос, во всяком случае.
Comonad
Я думаю, что вопрос был больше связан с плюсами и минусами языков сценариев, а не с тем, как решить, какой из них использовать. Все еще полезно, я полагаю.
Майкл Коулман