Сегодня давайте остановимся на создании профессиональных роликов. Вернее, научимся делать так, чтобы уже имеющиеся мультики выглядели впечатляюще и, как минимум, "основательно".

Не буду начинать словами "трудно переоценить значение скриптовых сцен в восприятии миссии и кампании". Давайте сразу же приступим к делу. Нам понадобятся лишь элементарные знания по этому вопросу, вспомним для начала нужные для работы с камерой операторы. Уверен, Вы их знаете, но тут есть ряд замечаний:

_cam = "camera" CamCreate [x,y,z] - создать камеру на координатах, см. ниже.
_cam CameraEffect ["internal","back"] - это "включает" нашу камеру.
_cam camSetPos [x,y,z] - переместить камеру в нужные координаты.
_cam camSetTarget UNIT или [x,y,z] - нацелить камеру на объект или координаты. Здесь существует принципиальное различие, ниже остаовимся подробнее.
_cam camSetRelPos [+-X,+-Y,+-Z] - расположить камеру по указанным координатам ([влево-вправо, спереди-сзади, сверху-снизу]) относитльно объекта, на который нацелелена.
_cam camCommit N - камера изменит местоположение/объект за N секунд
CamDestroy _cam - уничтожить камеру по окончании работы. Многие этим пренебрегают, а зря - вещ весьма принципиальная.

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

Абсолютно или относительно?

Как всегда, начнём с начала. До недавнего времени в мире ОФП считалось "хорошим тоном" задавать абсолютные координаты для камеры и её цели. Как это делается? Да проще некуда: пишем в ините любого юнита this exec "camera.sqs", и запускается встроенный скрипт, которым пользовались ещё разработчики игры в далёком 2001 году. Мы видим перед собой камеру с "прицелом", которой можно упралять. Теперь, стоит лишь нажать на ctrl, как она "сфотографирует" текущий кадр. После этого выходим Alt-Tab'ом и находим в корневой папке игры Clipboard.txt, оттуда в удобочитаемом виде вынимаем сфотографированные координаты, вставляем в свой скрипт и идём пить пиво.

Казалось бы, куда проще? Сфоткал-вышел-скопировал, всё работает, к чему трудности? А трудности начинаются потом. Движок игры устроен таким образом, что при каждом новом запуске присутствует элемент рандомности в вычислении координат. Этим определяется, например, то, что АИ не может пройти два раза по одной и той же дорожке - каждый раз при запуске он "запоминает" дорогу и ходит по ней, пока игра не закрыта. При следующем запуске он уже так не пойдёт.

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

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

А что если...

"Хорошо!" - Воскликните вы - тогда будем задавать положение камеры, исходя из координат объекта! Ну что ж... Можно удариться и в эту крайность.

Как показывают наблюдения, наиболее эффектно для диалогов смотрится относительное положение камеры около [1, 1.7, 1.6]. Это значит, что камера будет находиться на метр правее объекта, на 1.7 перед ним и на высоте 1.6. Это действительно самое быстрое и простое решение для создания диалогов, когда камере нужно быть нацеленной то на одного, то на другого персонажа.

Преимущества данного подхода очевидны:

• Не возникает путаницы с истинным местоположением объекта. Камера всегда будет нацелена на него под таким углом, под каким задумывалось
• Практически любой диалог можно построить на двух-трёх стандартных позициях, и юзер этого не заметит.

Иным способом, кроме этого, невозможно привязать камеру к движущемуся объекту. Но тут же есть и ряд существенных недостатков как то:

• Трудно сделать большие сцены. Панорамные планы выглядят аляповато.
• Абсолютно невозможно сделать качественную съёмку в помещении. Невозможность "работы" в помещениях и заставила меня однажды выбрать способ номер драй, он же следующий.

Компромисс

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

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

Продолжаем разбор полётов.

Ну и напоследок - самое интересное. Мы вновь возвращаемся к типичным огрехам строителей и, что самое главное, учимся их избегать.

Оптимизация, Оптимизация и ещё раз Дисциплина, как любил говаривать один известный деятель с бородкой. А поскольку сегодняшняя статья посвящена мультикам, мы и поговорим, как они едят системные ресурсы и как это минимизировать.

Конец - делу венец...

Вобщем, можете как угодно воспринимать эту фразу, за извращённые фантазии каждого автор ответственности не несёт Я же подразумеваю под этим только одно - любой скрипт, имеющий начало, должен иметь и окончание, эту самую пресловутую строчку Exit.

И зря вы иронизируете. Игра не считает скрипт законченным, пока не увидит эту самую строчку, и продолжает резервировать память под уже давно выполненный и забытый скрипт. Если оных запущено десятка полтора, последствия в лице заметного падения FPS не заставят себя долго ждать. Мораль сей басни - никогда не пренебрегайте зеветной командой окончания, ведь при ряде обстоятельств, "не закрытые" скрипты продолжают читаться даже в следующих миссиях кампании! А следовательно, потеря производительности пойдёт по нарастающей. Лично я такое не раз наблюдал.

Коварный "drop"

Вижу, как уже смеются обладатели кулкомпов за кулбабки. Не родился - мол - ещё такой ламер, который оставит столько открытых скриптов, что мой мегакомп залагает!
И тут я спешу вас разочаровать. Есть штука, которая заставит и ваш супер атлон с оперативкой 1024 лагать, словно дохлый пень-два! Имя этому ужасному порождению злого гения, этому убийце видеокарт и поджигателю материнок - DROP. Чё это? Ну, это такая нездоровая фича версии 1.8 и выше, которая позволяет самому Строителю делать различные весёлые спецэффекты от дымка из дула - до ядрёных взрывов, фонтанов и водопадов. Скептиков отсылаю к сайту Ринзы, где в разделе "скрипты" лежит несколько убойных спецэффектов, сделанных руками отечественных умельцев.

Так о чём я? Без сомнения, любой Строитель, желающий перейти в разряд "продвинутых" (лично мне до сих пор непонятен смысл этого определения), хотя бы раз сталкивался с проблемой написания drop'а.

Не вдаваясь в подробности создания частиц и влияния сего на производительность, можно с уверенностью сказать, что "правило конца" (Эээ... Ну и выдал) в этом случае даже ещё более актуально. Частицы, как правило, создаются в цикле, и если этот цикл не прервать - они продолжают создаваться даже после выхода в Редактор и накапливаются по нарастающей с каждым новым preview! Причём, после двух-трёх предпросмотров без обрыва цикла, мой комп начинал так безбожно лагать, что даже в редакторе мышь еле двигалась! Немало перезагрузок я произвёл при разработке миссии ╧2 из "Циклона" (где падает дроповый снег), прежде чем понял, в чём дело...

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

Всё это, хотя и в немного меньшей степени, относится и ко всем, не законченным на момент выхода в редактор, циклам. В меньшей - потому как дропанье частиц - это само по себе удовольствие весьма ресурсоёмкое. Поэтому, всё зависит от каждого конкретного цикла.
Справедливости ради, этой же "болезнью" страдает и EventHandler, нередко при ошибочном написании можно видеть сообщение об ошибке даже после выхода в редактор. Однако здесь всё решается новым превью.

А камеру сломать вы не забыли?

Теперь, когда мы немного вникли во внутренние особенности игры, надеюсь не надо объяснять, почему в конце каждого мультика надо ставить CamDestroy _cam? Лучше всего, делать это после затемнения, когда зрителю уже всё равно, есть камера или нет. Вот типичный пример окончания ролика. Возьми любой мульт, и там будет тоо же самое:

titlecut ["","black",3]
3 fademusic 0
~3
_ca cameraeffect ["terminate","back"]
Camdestroy _cam
end1=true
exit

Надеюсь, всем понятно, что мы сначала ставим затемение за три секунды, за три же секунды - затухание музыки, а по окончании уничтожаем камеру, вызываем конец фильму и пишем волшебное "exit".

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

В заключение хочется напомнить, что работа с камерой не ограничивается только лишь роликами. Ведь с помощью CamCreate нередко приходится создавать и бомбы и артиллерийский обстрел... Так вот, стоит ли лишний раз напоминать, что уничтожать необходимо каждую камеру, чем бы она не являлась по-сути? Представьте, сколько таких бесхозных "камер" остаётся после наспех написанной артподготовки! Вот они, лаги-то. Потом не удивляйтесь.

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

Dead Kennedy [GSS]