b9e79b94

Почему и почему бы нет?


Прежде всего, зачем использовать скрипт-язык? Большая часть игровой логики может быть описана на скрипт-языке для различных целей, вместо того, чтобы программировать ее как часть игрового движка. Например, загрузка или инициализации уровня. После загрузки уровня, возможно Вы захотите перевести сцену к игровому плану или может быть захотите показать некоторый предварительный текст. Используя скрипт-систему, Вы могли бы заставить некоторые объекты игры выполнять определенные задачи. Также, подумайте о реализации искусственного интеллекта. Не Игровые Персонажи должны знать, что делать. Программирование каждого NPC "вручную", в теле игрового движка излишне усложнит задачу. Когда Вы захотите изменить поведение NPC, Вам придется перекомпилировать ваш проект. С скрипт-системой, Вы можете делать это в интерактивном режиме, изменяя поведение и сохраняя настройки.

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

Давайте представим, что Джо, наш несчастный программист, пишет весь игровой движок, инструменты и логику игры сам. Да, Джо придется туго, но давайте предположим, что ему все нипочем. У нас так же имеется Брендон, игровой дизайнер. Брендон довольно развитый парнишка с шикарными идеями насчет игры. И так, наш кодер Джо, уползает и осуществляет всю игровую логику используя инструментарий, который он разработал основываясь на начальном проекте Брендона. Все хорошо в конторке. Первый этап закончен и Джо с Брендоном сидят в зале заседаний и проверяют свои немалые труды.
Брендон замечает несколько проблем в геймплее, который ведет себя не должным образом. Так что Джо возвращается к коду и делает требуемые изменения. Этот процесс может занять день, по крайней мере, если это не тривиальное изменение. Затем еще день для перекомпилирования проекта. Чтобы не терять лишние сутки большинство контор оставляют процесс сборки на ночь. Так, как мы видим проходит 24 часа прежде, чем Брендон увидит изменения, которое он требовал.

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

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

1. Кодер заинтересован в написании кода движка/инструментов, а не логики игры. 

2.  Время было потрачено на написание движка/инструментов игры. 

3.  Дизайнерам нравится "баловаться" с вещами.Скриптинг открывает им свободу в проектировании уровней и функциональных возможностей. Это также добавляет им больше гибкости, чтобы экспериментировать с вещами, для которых они обычно привлекали программиста. 

4.  Вы не должны перекомпилировать, если хотите изменить функциональные возможности игры. Просто измените скрипт. 

5.  Вы хотите разрушить связь между машинным и игровым кодом. Они должны быть двумя отдельными частями. Таким образом, будет удобно использовать движок для последующих сиквелов (я надеюсь). 

Здесь я сделаю несколько прогнозов. В течение 5 лет, дизайнеры уровней должны будут делать больше, чем просто строить уровни. Они должны быть способными использовать скрипт для игровых сцен. Несколько компаний с передовыми взглядами уже применили этот подход. Также, Вы можете увидеть этот способ интеграции в редакторах подобно UnrealEd и Aurora toolset Bioware.


Содержание раздела