Введение в Lua.
Недавно мой близкий друг ходил на собеседование по устройству на работу в местную компанию разработки игр. Я не собираюсь здесь называть имена, скажу только, что это был своего рода большой бутик Разработки Игр в Ванкувере. Он не получил работу, но сегодня речь не о нем. Лично я полагаю, что одна из причин была из-за его недостаточно дружественных отношений со скрипт-языком Lua, который они используют.
Автор: Ash Matheson
Введение
Почему и почему бы нет?
Разъяснение и разглагольствования
Состояние модуля (или: Кто имеет VM?)
Получение данных из файла
Интеграция в Наш Код
Стек LUA
Введение
Я занимаюсь этой областью, так как обучаю студентов программированию игр, но именно этой теме я уделил не достаточно внимания в прошлом. Мы охватываем Unreal Script как часть курса «Использование существующих игровых движков». Но мы фактически не рассматривали скрипт-движок, как часть утилит или часть движка. Так, вооружившись вебсайтом, я решил сломать этот небольшой барьер. Результат описан в этом документе.
Единственное, я не уверен, насколько большим будет этот документ. Я могу разбить его на несколько небольших частей или опубликовать целиком длинной тирадой от начала до конца. Так или иначе, я решу это немного позже, когда оформлю свои записи в более осмысленный и последовательный формат.
Почему и почему бы нет?
Прежде всего, зачем использовать скрипт-язык? Большая часть игровой логики может быть описана на скрипт-языке для различных целей, вместо того, чтобы программировать ее как часть игрового движка. Например, загрузка или инициализации уровня. После загрузки уровня, возможно Вы захотите перевести сцену к игровому плану или может быть захотите показать некоторый предварительный текст. Используя скрипт-систему, Вы могли бы заставить некоторые объекты игры выполнять определенные задачи. Также, подумайте о реализации искусственного интеллекта. Не Игровые Персонажи должны знать, что делать. Программирование каждого NPC «вручную», в теле игрового движка излишне усложнит задачу. Когда Вы захотите изменить поведение NPC, Вам придется перекомпилировать ваш проект. С скрипт-системой, Вы можете делать это в интерактивном режиме, изменяя поведение и сохраняя настройки.
Я немного затронул эту проблему в последнем параграфе, мы еще поговорим об этом немного позже. Вопрос, почему бы не написать логику исключительно на C/C++? Проще говоря, что в перспективе у программиста то, что все ложится непосредственно на него и начнет он соответственно с игрового кода, заодно придется писать и движок и утилиты и т.д. Но мы теперь можем с простым скрипт-языком переложить некоторые задачи функциональных возможностей на дизайнеров уровней. Они могут начать возиться с уровнем и оптимизировать геймплей. Вот собственно пример:
Давайте представим, что Джо, наш несчастный программист, пишет весь игровой движок, инструменты и логику игры сам. Да, Джо придется туго, но давайте предположим, что ему все нипочем. У нас так же имеется Брендон, игровой дизайнер. Брендон довольно развитый парнишка с шикарными идеями насчет игры. И так, наш кодер Джо, уползает и осуществляет всю игровую логику используя инструментарий, который он разработал основываясь на начальном проекте Брендона. Все хорошо в конторке. Первый этап закончен и Джо с Брендоном сидят в зале заседаний и проверяют свои немалые труды. Брендон замечает несколько проблем в геймплее, который ведет себя не должным образом. Так что Джо возвращается к коду и делает требуемые изменения. Этот процесс может занять день, по крайней мере, если это не тривиальное изменение. Затем еще день для перекомпилирования проекта. Чтобы не терять лишние сутки большинство контор оставляют процесс сборки на ночь. Так, как мы видим проходит 24 часа прежде, чем Брендон увидит изменения, которое он требовал.
Теперь, давайте представим, что наш главный герой Джо решил, что реализация игровой логики использует скрипт-движок в его интересах. Это займет в начале некоторое время, но он чувствует, что в конечном счете это принесет пользу. И так, он перекладывает с игрового движка некоторые функциональные возможности на скрипт-систему игры. Он также пишет всю игровую логику в упомянутой ранее скрипт-системе. И так, когда он встречается с Брендоном и дизайнер замечает кое-что, не отвечающее его задумке, Джо быстренько открывает консоль, делает некоторые изменения в скрипте, перезапускает игру и уже видит новое поведение. Изменения могут быть сразу внесены и показаны немедленно, вместо того, чтобы ждать рекомпиллинг. И если Джо был особенно выразителен, скрипт-система могла быть использована для утилит и доступна левел-дизайнерам при построении уровней. Если двигаться по такому пути, то при небольшом обучении проектировщики уровней могли бы сами устанавливать игровые события, такие как триггеры, двери, другие игровые события и радоваться жизни не напрягая программиста.
Это довольно надуманный пример и может быть немного преувеличен, но я надеюсь, что он покажет разницу между подходами. Так что мы попробуем сделать с такой моделью, что означает движение к большему количеству автоматически управляемых данных. Так, по существу, куда мы движемся:
- Кодер заинтересован в написании кода движка/инструментов, а не логики игры.
- Время было потрачено на написание движка/инструментов игры.
- Дизайнерам нравится "баловаться" с вещами. Скриптинг открывает им свободу в проектировании уровней и функциональных возможностей. Это также добавляет им больше гибкости, чтобы экспериментировать с вещами, для которых они обычно привлекали программиста.
- Вы не должны перекомпилировать, если хотите изменить функциональные возможности игры. Просто измените скрипт.
- Вы хотите разрушить связь между машинным и игровым кодом. Они должны быть двумя отдельными частями. Таким образом, будет удобно использовать движок для последующих сиквелов (я надеюсь).
Здесь я сделаю несколько прогнозов. В течение 5 лет, дизайнеры уровней должны будут делать больше, чем просто строить уровни. Они должны быть способными использовать скрипт для игровых сцен. Несколько компаний с передовыми взглядами уже применили этот подход. Также, Вы можете увидеть этот способ интеграции в редакторах подобно UnrealEd и Aurora toolset Bioware.
Разъяснение и разглагольствования
Надеюсь сейчас Вы уже купились на мои слова и захотели включить скрипт-компонент в вашу игру. И так, следующий вопрос: как, черт возьми, Вы это делаете?
Что я собираюсь использовать для моего скрипт-компонента — это внедряемый скрипт-движок Lua. В начале скажу, что я не спец в Lua, но это относительно простой язык и не потребует утомительного изучения для овладения им. Некоторые последующие примеры, по которым я буду пробегаться, довольно просты. В конце этого документа, я собираюсь включить некоторый дополнительный справочный материал. По справедливости, есть и другие скрипт-языки, типа Small, Simkin, Python, Perl. Однако Lua приятный и чистый язык. Это действительно хорошее преимущество.
Lua имеет открытый исходный код. Это хорошо, потому что: (a) Вы получаете исходники языка и можете рыться в них сколько вздумается, (b) он бесплатен. Вы можете использовать его в коммерческих приложениях, и не раскидываться деньгами. Ну а для некоммерческих проектов сами понимаете бесплатно == хорошо.
Так, кто в настоящее время использует Lua? Lua написан шарашкиной конторкой и его используют только бедные? Ммм... не совсем так. Lua появился не вчера и использовался достаточно известными личностями:
- Lucasarts
- Grim Fandango
- Escape from Monkey Island
- Bioware
- Neverwinter Nights
- MDK2
Ок, достаточно с кто-есть-кто из lua разработчиков. Вы можете это сами увидеть на вебсайте lua.
Давайте начнем с действительно простого. Первая вещь, которую мы должны построить, покажет нам как используется lua интерпретатор. Что для этого потребуется:
- Получение кода интерпретатора Lua.
- Настройка вашей среды разработки.
- Сборка интерпретатора с нуля.
Эй, я подумал, Вы сказали достаточно разглагольствований?
Ну что, достаточно? Так, давайте перейдем к делу. Вы можете получить весь исходный код Lua на офиуиальном сайте. Я также хотел бы взять секунду и обратить Ваше внимание, что на горизонте есть новая версия lua 5.0. Я не собираюсь обсуждать эту версию в этой статье. Я разберусь с ней позднее, а пока, мы будем использовать 4.0.1.
Первая вещь, которую мы сделаем - соберем библиотеку lua. Таким образом, нам не понадобится включать исходники каждый раз при сборке проекта. Это не сложно и это не цель наших уроков. Поэтому я заранее включил библиотеку как часть этой статьи. Я использовал статическую библиотеку для этого примера. Да, возможно я собрал бы ее как DLL, но для скрипт-системы статическая библиотека работает немного быстрее. Заметьте, не на много, но быстрее.
17 августа 2003 (Обновление: 15 фев 2012)