Горячая линия: игрострой

24 часа в сутки вопросы по созданию, модифицированию и вскрытию игр принимаются на адрес gamedev@igromania.ru и по SMS на короткий номер 1121 с префиксом #dev (в начале сообщения печатаете слово #dev, а затем, через пробел, сам вопрос). Стоимость каждого SMS — три рубля. Обратите внимание, что ответы на вопросы даются только в журнале.

Этот код управляет «кот»

Долгое время читал вашу рубрику «Вскрытие», начал сам копаться в игровом коде. Постоянно сталкиваюсь с различными комментариями, которые программисты вставляют после операндов и скриптов. Если честно, там зачастую такая абракадабра написана, что без пол-литры не разберешься. Я специально взял код одной игры, почистил его ото всех комментариев (это автозаменой легко делается) и получил файл в три (!) раза меньшего объема. Отсюда вопрос: зачем в комментариях пишут такую чушь и почему ее потом не удаляют? — Антон Романов (Москва)

Во-первых, комментарии пишутся для себя, во-вторых, для других программистов, которые могут работать с кодом. К сожалению, очень часто приходится видеть участки кода с комментариями, ничего толком не объясняющими, а просто словами описывающими то, что делает данная строчка кода. Скажем, вместо того чтобы написать « данная строка задает переменную здоровья персонажа Гладиатор », пишут « значение переменной, равное n, подгружается из таблицы 1 и назначается равным x+1*n, где n — характеристика героя из таблицы 2 ». В результате ни человеку, который написал комментарий, пользы никакой (из самого кода ведь и так понятно, какую операцию он производит), да еще и размер файла увеличился.

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

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

За что платим?

Некоторые игровые движки стоят огромных денег. Я не понимаю: за что там столько платить? Ведь есть бесплатные или недорогие технологии, которые по функционалу не так уж сильно отличаются. За полгода можно своими силами вывести такие движки на нужный уровень и сэкономить. — Георгий Рогозин

Деньги платятся не столько за сам движок, сколько за качественную поддержку. Программисты могут в любой момент позвонить или написать письмо создателю движка и получить квалифицированную консультацию. Не работает система частиц? Вам объяснят, как ее запустить. Не активируются шейдеры? Помогут написать код, их запускающий. В некоторых случаях для вас даже могут разработать дополнительные модули или плагины, добавляющие необходимые функции (чаще всего, правда, за дополнительную плату).

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

Я бы в дворники пошел

Реально ли устроиться сейчас, в кризис, на работу в игровую компанию? Я только-только выучился на программиста, но на работу меня упорно не принимают. Устал уже заявки рассылать. — Виталий Горин (Новороссийск)

Хотелось бы обнадежить, но ничего радостного, увы, нет. По отечественным игровым компаниям кризис тоже ударил: все испугались и окуклились до лучших времен. Устроиться на работу молодому специалисту сейчас архисложно — только если по знакомству. А вот профессионалов, которые по различным причинам остались без работы, умело ловят за шкирку и принимают на работу крупные геймдев-компании. На самом деле кризис — это отличное время для того, чтобы заполнить пробелы в штате квалифицированными сотрудниками, которые соглашаются даже на относительно небольшие зарплаты.

Game is not over

Подскажите, как в FIFA 09 максимально продлить тренерскую карьеру? А то в игре все как-то очень быстро заканчивается. — _SMS с номера 8-916--71-90_Все изменения нужно проводить в файлеcareer.iniиз архиваconfig.dat*. Первым делом повысьте значения атрибутовNUM_SEASONS_IN_CAREERиPOINTS_FOR_STAR_. Таким образом, если вы с пятнадцати сезонов перешли на двадцать пять, оптимальным вариантом будет подставить ко второму параметру следующий числовой ряд:0,1666,4166,8333,12500,20833,29166,41666,54166,66666,83333 (если все эти числа уменьшить, то карьера, как несложно догадаться, сократится). Теперь переходы на новый уровень равномерно распределены по удлиненной дистанции вашей тренерской работы.

Раз уж мы растянули процесс заработка звездного статуса тренером, логично сделать то же самое и по отношению к игрокам, для чего необходимо немного увеличить показатель NEWSPAPER_STAR_SIGNING , скажем до 90. Не помешает также повысить числа, соответствующие настройке FIRED_AT_STAR_ , до значений 0,500,467,433,400,367,333,283,233,183,133,83. Если есть желание, можете понизить значение настройки MIN_ACCADEMY_PLAYER_AGE до 12-13.

Опытным игрокам рекомендуем усложнить себе тренерскую жизнь. Для этого присвойте следующим параметрам указанные значения: JOB_OFFER_DROP_WHEN_FIRED — 4 , JOB_SECURITY_START_AT — 30-40 , NEWSPAPER_STAR_SIGNING — 90 , MORALE_STARTS_AT — 30-40 , FATIGUE_START_AT — 20-30 , POINTS_FOR_STAR — 0,1500,3750,7500,11250,18750,26250,37500,48750,60000,75000 , FIRED_AT_STAR_ — 0,450,420,390,360,330,300,255,210,165,120,75 , FATIGUE_BASE_LOSS_PER_DAY — 2 , INJURY_DURATION_AT_MED_UPGRADE_0 — 120 , INJURY_DURATION_AT_MED_UPGRADE_10 — 90 , MIN_ACCADEMY_PLAYERS — 1 , MONEY_MULTIPLIER — 10-15 , INITAL_MONEY_TWEAKER — 0.6-0.8 , PER_WEEK_SCOUT_CHANCE_OF_FIND — 10.

В недрах офиса

Мы молодая команда разработчиков. Делаем свой первый проект и немного подрабатываем аутсорсом. Игра идет медленно и натужно, а я — руководитель всего этого балагана. Давно встал вопрос, снимать офис или нет. Я пока тяну, боюсь, что разоримся, если начнем сейчас вкладываться в помещение. Давайте без обиняков, прямо по пунктам — какие плюсы и минусы офисной и надомной работы для новичков? — Сергей Шостак

По пунктам так по пунктам. Плюсы:

— Все сотрудники всегда под рукой. Можно подойти, погладить по шерстке, объяснить, что и как нужно делать, узнать, что уже сделано, вовремя заметить, что кто-то, вместо того чтобы работать, болтает по аське или рубится в CS.

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

— В офис всегда можно пригласить потенциального клиента/заказчика, дабы он воочию убедился, что вы серьезные люди. Шанс получить заказ значительно вырастает.

Минусы:

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

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

— Съемное помещение — это обычно полный рабочий день для всех плюс необходимость добираться в офис по утрам. Кто-то может не воодушевиться идеей дальних путешествий через весь город, кто-то учится, кому-то просто комфортней работать дома…

Альфа, бета… демо

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

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

Преальфа. Полностью пройти игру от начала и до конца нельзя, зато можно составить представление о геймплее. Если речь идет о шутере, то есть главный герой, есть враги, есть оружие (моделей может еще не быть, но есть некая «болванка-заглушка», которая выводится на экран). Также сделано несколько уровней (они могут быть даже без текстур).

Альфа-версия. Это полностью рабочая игра, которую можно пройти от начала и до конца, но отсутствуют некоторые вещи, которые напрямую не влияют на геймплей. Может не быть значительного числа моделей (деревья, горы, строения, трава), скриптовых роликов, некоторых диалогов, спецэффектов. Баланс тоже обычно весьма условный.

Бета-версия. С точки зрения разработчика это полностью законченная игра (то есть на всех пунктах диздока в плане поставлены галочки «сделано»), в которой лишь не выловлены баги.

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

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

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

Тестирование

Как работают бета-тестеры? То есть понятно, что они ловят ошибки в игре, но как конкретно это происходит? Они ведь, наверное, приезжают в офис, а может, пишут письма разработчикам или по телефону с ними разговаривают? Расскажите о технических моментах. — _SMS с номера 8-916--86-49_*

Существует практика офисного бета-тестирования, но чаще всего оно проходит удаленно. Причем главная задача бета-тестера не просто играть, как многие думают, а еще и создавать необычные игровые ситуации, которые могут вызвать сбой. Бета-тестеры, мыслящие нестандартно, особенно ценятся разработчиками. Вот лишь несколько примеров такого мышления. А что будет, если начать убивать противника, когда персонаж присел на корточки? Как отреагирует движок, если одновременно скастовать несколько заклятий, а пока анимация не закончилась, открыть инвентарь и что-нибудь там перетасовать? Если выделять юнитов рамкой не всех сразу, а по одному, и посылать их в одну и ту же точку, куда можно пройти разными путями, то все ломанутся по одной дороге или каждый разработает свой маршрут? Что будет, если нажать одновременно несколько «горячих» клавиш, которые отвечают за противоположные по смыслу действия?

В задачи бета-тестера входит не только обнаружить ошибку, но и попытаться выявить закономерности ее появления. Одно дело, если какой-то враг каждый раз, когда его атакуют, пропадает с экрана. Совсем другое — если пропадает он лишь иногда. Понять, от чего зависит исчезновение, бывает очень сложно. Мы как-то принимали участие в бета-тестировании сетевого шутера и выявили забавный баг. При выстреле по врагу из пистолета с расстояния больше чем 50 метров в некоторых случаях фиксировался хедшот, хотя пуля попадала в тело или в ногу. Долго не могли понять, в чем же дело. Только через неделю разобрались, что хедшот происходил только в том случае, если в инвентаре в этот момент была снайперская винтовка (причем не просто в инвентаре, а повешена на горячую клавишу любимого оружия). В этом случае движок почему-то подменял обычный пистолет (не внешне, а только по функциям) на объект « снайперская винтовка, наведенная на середину лба ».

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

Разносторонний Flash

Я пристально слежу за развитием флэш-игр. Удивительное дело, сам пакет Adobe Flash (в младенчестве Macromedia Flash) не так уж сильно изменился за последнее время. По крайней мере, радикальных переделок не случилось, а вот игры выходят все сложнее и качественнее. Некоторые из них уже вполне могут конкурировать со своими большими собратьями. Почему так получается? — Станислав Субботин

Ничего удивительного. Чем дольше существует технология, тем больше дополнительных инструментов, плагинов и аддонов для нее появляется. Если посмотреть на арсенал современного флэш-разработчика, то вы обнаружите огромное количество всевозможных присадок, надстроек и уже готовых скриптов. К примеру, на создание реалистичной воды раньше нужно было потратить несколько недель, а теперь достаточно скачать пару плагинов и поелозить в них ползунками. Аналогичная ситуация с другими эффектами и физикой.

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

Архив архиву рознь

Расскажите, какие типы архивов обычно используют разработчики игр. Я знаю, что DAT-файлы зачастую оказываются простыми RAR-архивами, а иногда их не открыть ни одним архиватором. Какие еще возможны варианты? Если архив полностью открытый, то зачем вообще он нужен и как разобраться в его структуре? — _SMS с номера 8-903--45-81_*

Открытые архивы нужны в первую очередь для того, чтобы уменьшить число файлов, с которыми приходится работать движку. Подгружать в память один файл значительно проще, чем несколько тысяч. Чтобы шаловливые ручки игроков не дотянулись до игровой музыки, звуков, скриптов и прочей начинки игры, вместо стандартных архивов вроде RAR, ZIP и ARJ чаще всего используются свои собственные внутренние форматы. К таким даже опытный хакер далеко не сразу подберет ключик.

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

Чтобы распотрошить сжатые архивы, желательно знать языки программирования. А вот несжатые вполне может раскурочить даже неопытный человек. Такие архивы можно поделить на два вида. Одни хранят информацию (имя файла/размер/смещение до него от начала архива и т.д.) об упакованных файлах и сами файлы в одном файловом архиве (типичный пример — архивы Half-Life 2 ). Архивы второго вида хранят информацию в двух разных файлах (скажем, архивы Crysis ). Первый вид архивов обычно разделяют еще на три типа. Первый — информация об упакованных файлах хранится в начале архива. Его структура выглядит приблизительно так:

заголовок архива (не всегда бывает);

количество файлов в архиве (числовое значение);

информация о файлах;

данные (сами файлы).

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

заголовок архива (не всегда бывает);

смещение до информации о файлах (чтобы движок знал, откуда считывать информацию);

данные (сами файлы);

информация о файлах (читается, пока архив не закончится).

Третий тип — самый редкий (и самый медленный), он хранит информацию о файле непосредственно перед каждым файлом:

Заголовок архива (не всегда)

{Цикл повторяется до конца архива}

Информация о файле

Данные (сам файл)

{Конец цикла}

Как определить, к какому типу относится тот или иной архив? Просто открываете архив текстовым или, лучше, HEX-редактором и анализируете символы на экране. Если в самом начале текста мелькнуло несколько названий файлов, разделенных небольшими пробелами или иероглифами, то это первый тип. Если файлы разделены большим количеством иероглифов (до нескольких страниц), то это третий тип. Если же названия файлов прописаны в конце архива, то это второй тип.

Мутант или мутатор?

В Unreal Tournament 3 очень мало режимов игры. Vehicle CTF так и вовсе лишь вариация обычного Capture the Flag. Last Man Standing удалили… Расскажите, как написать собственные мутаторы? Я бы с удовольствием добавил несколько старых режимов игры или разработал что-то новое. Кстати, в Сети часто попадаются мутаторы, которые непонятно как подключить к игре, — это еще одна проблема. — Алексей Торин

Разработка мутаторов (по сути, это обыкновенные моды) предполагает написание скриптов. Unreal Tournament 3 использует объектно-ориентированный скриптовый язык UnrealScript. Сразу предупреждаем, что все изменения и дополнения здешних скриптов должны быть произведены не путем правки исходного кода, а за счет его расширения — проще говоря, создания новых файлов. Если вы нарушите это простое правило, игра откажется пускать вас в онлайновый режим.

Первое, что нам нужно сделать, — это распаковать игровые скрипты, пребывающие в архиве UT3ScriptSource_1.1.rar. Находящуюся в нем директорию \Src со всем ее содержимым скопируйте по адресу: \Documents and Settings\X\Мои документы\My Games\Unreal Tournament 3\UTGame (названный каталог образуется после первого запуска игры), где X — имя пользователя, под которым вы входите в систему. Зайдите в появившуюся папку \Src и в ней создайте подкаталог для нового мутатора — назовем его \FirstMutator. Внутри него создайте поддиректорию \Classes. В ней будут храниться все наши скрипты. Но прежде чем мы начнем писать их, нужно проделать еще одну несложную операцию. Откройте в «Блокноте» файл UTEditor.ini , расположенный здесь: \Documents and Settings\ <Имя пользователя>\Мои документы\My Games\Unreal Tournament 3\UTGame\Config. Найдите в нем раздел ModPackages. В конец блока вставьте новую (третью по счету) строчку:

ModPackages=FirstMutator

Мы указали UnrealScript-компилятору, где ему искать новый код. Сам компилятор можно найти следующим образом. Зайдите в меню Пуск/Все программы/Unreal Tournament 3 и, зажав Ctrl , перетащите на рабочий стол значок Unreal Tournament 3 Editor (запускающий редактор игры). Если вы заглянете в его свойства, то увидите, что он ссылается на запускаемый файл игры ( UT3.exe ), при этом, правда, добавляется параметр editor. Скажем, если вы устанавливали игру в папку C:\Games\UnrealT3 , то полный путь будет выглядеть как C:\Games\UnrealT3\Binaries\UT3.exe editor. Слово editor следует заменить на make. Назовите новый ярлык Unreal Tournament 3 Compiler. С помощью этой иконки вы сможете запускать компилятор.

Следующий шаг — создание в каталоге \FirstMutator\Classes файла FirstMutator.uc — он будет содержать основной код для мутатора. Расширение .uc сигнализирует компилятору о том, что этот файл нужно обработать. Файлы другого типа программой не воспринимаются — можете использовать их в качестве временных (например, для хранения фрагментов кода, которые могут вам пригодиться потом, различных шаблонов, старых версий мутатора и т.п.).

Приступаем непосредственно к написанию скриптов. Для этих целей нам понадобится текстовый редактор, причем сойдет даже стандартный «Блокнот». В начало файла FirstMutator.uc вставьте следующий текст:

class FirstMutator extends UTMutator;

defaultproperties

{

}

Он является обязательным для любого мутатора (различаться будет только наименование — FirstMutator ). В нашем примере полностью код мода будет выглядеть следующим образом:

class FirstMutator extends UTMutator;

function ModifyPlayer(Pawn Other)

{

local UTPawn P;

P = UTPawn(Other);

if (P != None)

{

*P.DamageScaling = 2;

}

Super.ModifyPlayer(Other);

}

defaultproperties

{

}

Если не хотите набирать все это вручную, то зайдите в файл UTMutator_SuperBerserk.uc , который вы (после недавней распаковки и копирования скриптов) можете найти по адресу: \Documents and Settings\ <Имя пользователя>\Мои документы\My Games\Unreal Tournament 3\UTGame\Src\UTGame\Classes. Часть содержащегося в файле кода очень похожа на приведенный выше фрагмент, так что может скопировать ее в буфер и использовать в качестве основы (но будьте внимательны: расхождения имеются).

А вообще скриптовые файлы (те, что отвечают за мутаторы, имеют в названии префикс UTMutator_ ) из указанной чуть выше папки могут вам здорово помочь при разработке собственных модов.

Теперь разберемся, что же мы с вами понаписали. Параметр DamageScaling (префикс P. показывает, что он относится к игрокам, ботам в том числе) — это умножитель урона. В приведенном примере мы определили ему значение 2 , благодаря чему все повреждения удваиваются.

Скрипт для нового мутатора готов. Осталось его скомпилировать. Помните, мы создали для программы-компилятора отдельный ярлычок? Жмите на него и немного подождите. Если в коде содержатся какие-то ошибки, процесс компиляции прервется, а программа выдаст сообщение с указанием ошибки. Впрочем, в нашем случае, если вы строго следовали указаниям, это исключено. Зеленая надпись «Success — 0 error(s), 0 warning(s)» извещает о том, что операция успешно завершена.

В результате компиляции в папке \Documents and Settings\ <Имя пользователя>\Мои документы\My Games\Unreal Tournament 3\UTGame образуются два новых файла: первый, FirstMutator.u (который содержит скрипт нашего мутатора в конечном, понятном игре виде), — в подкаталоге \ Unpublished\CookedPC\Script , а второй, UTFirstMutator.ini , — в \ Config.