Ответы:
Скрипты обычно компилируются во время выполнения , в то время как основной язык будет компилироваться во время компиляции. Это означает, что нам не нужно перекомпилировать, если скрипт изменяется. Перекомпиляция полной игры может занять от нескольких минут до нескольких часов, что подразумевает значительный удар по производительности.
Как правило, критический код или код бэкэнда не записываются в сценарии. Этот код должен выполняться быстро, и часто управление памятью имеет решающее значение.
В играх игровая логика и конфигурация обычно содержатся в файлах сценариев. Эти сценарии могут быть легко обновлены непрограммистами (например, дизайнером) для настройки игрового процесса. Языки сценариев просты и действуют для этой цели всепрощающе.
Часто язык сценариев также используется для выполнения сценариев в режиме реального времени . Это удобно для настройки некоторых элементов игрового процесса или даже для отладки. Многие игры предоставляют консоль для этой (в основном, внутренней) цели.
Вполне возможно, что вы создадите игру, используя существующий игровой движок, просто используя сценарии. Таким образом, слой игрового движка полностью отделен от слоя игровой логики . Современные движки обычно могут быть использованы для создания игр FPS или RTS легко, как это, но это невозможно для любого жанра. MMO, вероятно, потребует другой тип двигателя.
Таким образом, нижняя строка отделяет Перечисленные выше преимущества часто перевешивают дополнительную работу по созданию или интеграции языка сценариев.
Вы задали неправильный вопрос. Реальный вопрос, я думаю, заключается в том, почему мы миримся с «не скриптовыми» языками, такими как C, C ++, Java и так далее? И ответ одна причина: производительность. (И, возможно, инерция, но эта инерция есть из-за производительности, и любой, кто может написать хороший C / C ++ / Java, может написать хотя бы сносный Ruby / Python / Lua / JavaScript.)
Мы используем «скриптовые» языки (что на самом деле означает очень высокий уровень, сборщик мусора и, как правило, некоторую форму более свободной типизации и динамической компиляции), потому что они, как правило, более простые языки для написания кода для всех - включая программистов. глупые вещи, такие как не забыть освободить после malloc или убедиться, что ваш код защищен от исключений, или забыть сделать все ваши деструкторы виртуальными. Если бы наши компьютеры были бесконечно быстрыми, мы бы использовали «скриптовые» языки для всего.
Языки сценариев для игровой логики являются очень хорошим примером структуры архитектуры программного обеспечения Alternate Hard и Soft Layers . На этом сайте (и других, я уверен) есть хорошая дискуссия о преимуществах этого.
Изменения скрипта легко развернуть. Например, вы можете хранить сценарии в базе данных, что означает, что вместо полного повторного развертывания двоичного кода и возможного перезапуска службы вы просто запускаете один оператор SQL UPDATE, за которым, возможно, следует сигнал запущенной службе для перезагрузки сценария.
Кроме того, языки сценариев часто просты для понимания и легки в программировании, поэтому вам не нужны «хардкорные» разработчики (те, которые занимаются управлением памятью / указателями и оптимизацией на уровне процессора) для большей части кода (если большая RPG, скрипты для ИИ, Заклинаний, Эффектов предметов и самого мира часто больше, чем код движка). Языки сценариев позволяют гораздо больше сосредоточиться на «что», а не «как» из-за сборки мусора (в случае Lua) и более высокого уровня абстракции.
Один сценарий, в котором полезны скрипты, - это когда мы хотим, чтобы наш движок был расширяемым с помощью плагинов / аддонов. Эти расширения во многих случаях создаются непрофессиональными людьми (например, опытными игроками и энтузиастами). Сценарии безопаснее и проще для этой цели. Используя скрипты, им не нужно использовать компиляторы и не нужно знать указатели ...
Прекрасным примером этого является игра World of Warcraft. Он имеет тысячи аддонов, созданных сообществом. Эти дополнения написаны с использованием LUA + XML.