• Игролог
• Игры
• Об авторе

Постмортем разработки игры Zombotron

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

А пока мы ожидаем релиза, я расскажу немного о разработке. Началось все 8 января. Как раз где-то на новогодних праздниках я решил, что хватит заниматься всякими мелкими играми и нужно что-то сделать такое немного более масштабное, например стрелялочку с физикой. Хотя изначально мне казалось, что ничего тут особо сложного нет и разработка пойдет достаточно шустро, тем более опыт и наработки физического платформера у меня уже были на основе MiningTruck 1-2 части. Ну сделать вместо машинки с двумя колесиками человечка с одним колесиком и дать ему пушку, что может быть проще?! Какой же я был наивный :)

Так сразу даже и не объяснить, в чем же заключались основные сложности в разработке, но все оказалось не так уж и просто, как хотелось бы изначально.

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

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

Скролл игрового мира

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

Оранжевые прямоугольники показывают как будет разрезано статическое оформление уровня на кусочки.

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

Видны только те клеточки и их содержимое, которые попадают в область видимости экрана.

Физика

Все, кто работал с Box2D, прекрасно знают, что он начинает тормозить, когда количество динамических объектов в физическом мире приблежается к отметке в 100 единиц. Впрочем, этой проблемой грешат почти все физические движки на Flash. В прошлых играх на этапе создания уровня я создавал сразу весь физический мир и это было большой проблемой, на слабых компьютерах игра конечно выдавала меньше FPS, чем хотелось бы. А тут по мимо простых ящиков и бочек должны быть не только всякие конструкции с джоинтами, но и враги с искуственным интеллектом! �? как же быть?

Решение естественно только одно: создавать уровень динамически по мере продвижения персонажа по карте. Звучит сложно, но на деле все не так страшно.

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

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

Решение этой задачи в целом достаточно простое: я придумал такую вещь, как CreatorArea. Мм.. Даже не знаю, как кратко и понятно описать :) Но если в двух словах, то это некая произвольная область (прямоугольник), которая создает по команде объекты во всех клетках, которые покрывает и выполняет дополнительные методы, которые устанавливают соеденения и связи. Более того, позже я добавил и DestructorArea — это альтернативный вариант создателя, который удаляет все физические объекты из покрываемой области. Уничтожитель используется только в тех частях карты, которые игрок уже прошел и куда уже не может вернуться. Таким образом по факту получается так, что физическая модель мира существует в полном объеме исключительно вокруг игрока :)

Триггеры

Но Креаторы и Деструкторы — это только верхушка айсберга. Думаю, что каждый, кто пытался написать платформер, в котором при нажатии на кнопку открывалась бы дверь — сталкивался с вопросом: «Как же красиво связать дверь с кнопкой?». Знаю по своему опыту, что многие стараются делать прямые указатели, например с кнопки на двери и с двери на кнопку. Но мне нужен был универсальный вариант, чтобы у меня были какие-то объекты, например лифты, двери, а так же переключатели и триггеры-невидимки, которые бы их активировали. �? чтобы я мог по ходу создания уровня использовать разные их комбинации, например связать дверь с лифтом, или при открытии двери разрушать какие-то важные джоинты, чтобы игроку что-нибудь падало на голову — то есть прямыми указателями тут уже никак не обойтись.

А решение еще проще, чем с указателями: я написал класс контроллер, который все это безобразие контролировал. Самое смешное, что сам контроллер состоит из нескольких простых методов add(object), remove(object), callAction(), callDistanceAction(). А все объекты, которые могут быть добавлены в этот контроллер должны имплементировать интерфейс IBasicObject, а интерфейс в свою очередь обязывал все эти классы иметь alias, action(), switchState(). Догадываетесь в чем сила ООП? :)

А сила в том, что контроллер — это фактически хранилище всех объектов, с которыми могут быть произведены действия. Согласно интерфейсу каждый объект должен иметь уникальный alias (имя) и зная только имя этого объекта можно выполнить его действие, сказав контроллеру object.callAction("door1"); - контроллер перебирает список всех добавленных в него объектов и вызывает метод action() у объектов с именем "door1".

Соотвественно все алиасы прописываются в редакторе уровней, причем по мимо базового алиаса у объекта может быть callbackAlias — это как бы ссылка на другой объект, который вызывается, после того, как действие текущего объекта выполнено. Таким образом можно создавать всякие интересные цепочки событий. А у кнопок и триггеров невидимок есть targetAlias — это алиас того объекта, который должен выполнить свое действие, вызывается когда игрок активирует кнопку, ну или попадает в область триггера :) В общем получилось все очень универсально и все объекты можно связывать друг с другом как угодно, главное только чтобы алиасы были указаны верно.

Обратите внимание на обилие триггеров и других непонятных вещей — весь уровень заскриптован без кода.

Кстати, СreatorArea и DestructorArea для запланированного создания/удаления объектов тоже активируются триггерами невидимками. �? вообще большая часть игровых уровней как раз в итоге держится на всех этих триггерах.

�?скуственный интеллект

Впрочем поведение врагов сложно назвать настоящим искуственным интеллектом, но в итоге поведение врагов в игре получилось весьма интересным и порой непредсказуемым. В игре Mushroomer я уже имел опыт написания �?�?, но это была адская работа для меня, так как тот код по большей степени состоял из портянки if () { ... } else if () {...} и соотвественно пачки всяких флагов, на основе которых выбирались какие-то решения. А если вы играли и если вы помните, то там не все враги друг к другу равнодушны и их �?�? был достаточно запутанным в итоге с точки зрения кода.

Благо перед тем, как начать разработку игры, я прочитал пост RaymondGames с условным примером о том, на чем базируется �?�? в Half-Life и посмотрел TaskManager от Хитри.

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

Впрочем на деле TaskManager от Хитри тоже оказался очень полезной штукой, для выполнения каких-то простых списков задач — показать там кнопочки с заданным интервалом или запрограммировать эффект горения, или гибель монстра в несколько этапов. Но, к сожалению, в том виде в каком он есть его активно использовать чревато. Основной его недостаток — это перехват события Event.ENTER_FRAME — это конечно делает менеджер задач универсальной штукой, но если вдруг у вас в игре окажется 5-10-20 одновременно работающих менеджеров, то это уже беда. Вообще события очень тормозные, поэтому более одного перехватчика события Event.ENTER_FRAME лучше не использовать. Во всяком случае когда я переписал TaskManager таким образом, чтобы он не использовал перехват событий, то в дебажном плеере я заметил прирост производительности. Еще при использовании TaskManager я заметил мелкие скачки потребления/освобождения памяти и это при том, что у меня практически все кэшированное. Посмотрев еще раз внимательно на TaskManager я стал подозревать, что проблема заключается в методах shift(), unshift() класса Array, использующиеся для удаления и перемещения задач в очереди выполнения. Точно не знаю как эти методы устроены внутри, но когда я отказался от Array и сделал свой связный список то проблема исчезла.

Ну так вот, возвращаясь к алгоритму поведения врагов: в моем случае база �?�? достаточно проста. Враг в режиме idle шатается туда сюда, никаких дополнительных вычислений не делает, до тех пор пока в его радиус не попадет игрок, а вот дальше уже интереснее. Враг смотрит на игрока лучом (raycast) и, если луч не пересекает препятствий, то включается режим тревоги и враг непременно берет курс к игроку, при этом круша на своем пути все, что ломается. Более того, если другие враги вдруг обнаруживают, что сосед по партии врубил тревогу, то они включают тревогу дальше и таким образом пол уровня может быть поставленно на уши и все прибегут мочить игрока :) Вся эта простая идея возникла только потому, что мне хотелось создать максимум экшена и чтобы не было такого, чтобы игрок по одиночке всех мог не спеша отстрелять. Только вот реализация оказалась не простой.

Я наверное дня 3 бился с вопросом, как грамотно организовать эту цепочку, чтобы все бежали к игроку по тревоге, и потом еще 2 месяца время от времени балансировал эту систему. Путь тут искать сложно, враги сквозь друг друга не проходят и не видят т.п. Первое что пришло в голову — это например включать тревогу и пусть все бегут к тому, кто включил тревогу, при этом чтобы и сами врубали тревогу. Только тут случался парадокс (если можно так выразиться) — они как мухи на котлету друг к другу слетались и стояли большущей кучей, не обращая на игрока никакого внимания :) Вот тут-то мне и пришлось поломать голову.

Цифры над головами отображают их alarmId.

В итоге я придумал систему приоритета. То есть, по мимо флага alarm у врагов появился еще и флаг alarmId — формулу вычисления которого я рожал в долгих муках. Но идея такова, что тот, кто ближе к игроку, тот имеет высший приоритет, а тот кто дальше — более низкий приоритет, и враги бегут к тем своим соратникам на помощь, которые имеют высший приоритет и таким образом они выстраиваются в колонну и идут стройным рядом к игроку на смерть! :)

Расовые группы

Вообще получилось так, что все игровые объекты, включая и новые типы врагов, добавлялись в игру постепенно и в рядовых проверках �?�? на свой/чужой становилось все больше условий по типам объектов. Например, какие объекты можно ломать, а какие нет и таким образом добавляя в игру какой-нибудь новый игровой объект: ящик там или бочку — приходилось лезть в �?�? каждого врага, добавлять новые условия и потом все это тестировать, конечно в итоге мне все это надоело и я решил разделить объекты на группы. Даже не знаю почему сразу мне этого в голову не пришло, но на деле оказалось очень здорово! Например, в игре всего несколько групп GROUP_BREAKABLE, GROUP_PLAYER, GROUP_ZOMBIE, GROUP_ROBOT и т.п. �? когда нужно добавить нового врага или объект, просто его включаешь в какую-нибудь группу, и согласно этой группе другие объекты, обладающие �?�? и не очень, уже знают можно ли его сломать или убить. �? после добавления этих групп мне пришла неожиданная идея разделения врагов по расовому признаку. То есть грубо говоря все вражеские группы друг с другом воюют, как с игроком. �? в итоге все проверки в �?�? свелись до банального:

if (isFriend(seeObj.group))
{
  // Привет! Как дела?
  if (врагов видел?)
  {
    // Аа! Аларм, аларм!
    // Бегу на помощь!
  }
}
else if (!isFriend(seeObj.group))
{
  // Ааа!!1 За родину!
}

Я вообще не знаю с какого перепуга в играх враги друг с другом дружат, но при этом люто ненавидят игрока!? :) Поэтому в Зомботроне я сделал все по честному — все друг друга не любят! Зомби для зомби друг, зомби роботу враг, робот для робота друг и т.п. За счет чего порой кажется, что игрок так мимо проходил и в передрягу вдруг попал :) Зато на мой взгляд появилась некая атмосфера и присуствие жизни, которая течет в игровом мире как бы без игрока. В общем не знаю как вам, а мне в кайф накрыть из базуки группировку в 5-6 врагов, пока те выясняют отношения друг с другом :D Хотя есть предчувствие, что будут комментарии типа: «wtf!!?! Как это они тут перегрызлись без меня-то??».

Так же хочется отметить ключевую особенность игры — это рэгдольчики трупов врагов. А ключевая особенность она именно потому, что когда враги погибают — получаешь какое-то невероятное эстетическое удовольствие от процесса их убиения :) Конечно рэгдоллы — это далеко не новаторский подход и во многих стрелялках уже давно встречаются, но чаще всего разработчики рэгдолы отдают честной физике, что порой выглядит не по «голливудски» и скучно, ну упал реалистично и ладно. Я же постарался этому моменту уделить больше внимания и добавил кучу твиков для воздействия сил на бездыханную тушку, поэтому тела порой выполняют кульбиты, полеты и разрывы, не объяснимые с точки зрения законов физики, но зато на мой взгляд красочно и фаново :)

Рефакторинг

Рефакторинг — это отличная штука, но порой рефакторинг может создать рекурсию программиста и тот в свою очередь повиснит и никогда не закончит проект. В Зомботроне было много рефакторинга, причем меня порой переклинивало так, что если я придумал как что-то улучшить — я потом 2-3 дня копашил весь код, частично меняя архитектуру игры и тестировал все по новой. В большинстве случаев это с играло хорошую роль — код получился более менее понятным и доступным. Но где-то остались и «лохматые» кусочки :) Полгода приличный период времени и за это время некоторые мои подходы к разработке изменились, поэтому было забавно порой открывать какие-то старые классы, которые были написанны в числе первых и не подвергались дальнейшим переработкам — и вот смотришь на них и думаешь «какой я тупой... был». Но, к сожалению, или к счастью, некоторые «лохматые» кусочки, так и остались нерасчесанными.

А самый большой и возможно самый сложный рефакторинг мог случится это когда мне вдруг шарахнуло в голову переработать всю игру под ручной рендер. Мой мозг мучал мою совесть и обратно, наверное недели полторы — то еще противостояние было. Представляете, работаешь над игрой 3 месяца, много уже что готово и отлажено, а потом бац и ВНЕЗАПНО осознаешь, что стандартный рендер тебе не подходит, и пофиг, что предыдущие игры на нем работают, вот надо здесь и сейчас переделывать все под новый! Ууу... Я считаю себя большим героем, что справился с этим желанием, а то глазом моргнуть бы не успел, как месяц пролетел бы! :)

Музыка и звуки

Музыкой и звуками для этой игры, как и для прошлых игр вновь занимался Александр Ахура. На этот раз я в большей степени доверился Ахуре и не навязывал каких-то своих мыслей о музыкальном сопровождении. За счет чего получилось много экспериментов и в итоге для игры было написанно более 10 трэков в разных направлениях. Пробовали активную, немного попсовую и просто эмбиент, в итоге Ахура решил сделать музыку, как эмбиент, чтобы она не мешала действию и была просто достойным фоном, который должен дополнять происходящее и при этом не мешать. �? я думаю, что это у нас удалось. В игру вошло аж целых 7 музыкальных трэков!

Более того, мы сразу задумали сделать так, чтобы музыка была как-бы интерактивной, то есть когда происходит активное действие — включается более интенсивный трэк, а когда затишье просто спокойненький эмбиет. Но, на самом деле я боялся этого момента, т.к. времени и сил писать сложный скрипт для определения активности действия у меня, конечно, не было. �? позже в голову пришло простое решение: мы сделали переключение музыки по тригерам :) То есть музыкальное сопровождение расставленно на уровнях практически так же, как ящики, бочки и враги. Можно сказать интерактивно, дешево и сердито.

А вот со звуками больших эксперементов не было. Но звуков получилось в итоге очень много: 76 шт. Хотя казалось бы, чего там столько озвучивать!? Но и тут без хитростей не обошлось. Для разных вещей и событий порой используются одни и те же звуки, но подвоха на самом деле не заметно. То есть звуков могло бы быть и больше.

Но в итоге я озвучкой очень доволен, все получилось на высшем уровне! :)

�?тоги

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

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

Вообще, самый большой и толстый вывод, который я из всего этого сделал — Flash это не та платформа, которой нужны большие и сложные проекты, тем более если их делать в одиночку. Количество потраченного времени и объем вложенных затрат не влияет на успешность игры в целом. Наверное поэтому делать маленькие и очень успешные игры — это искусство :)

Но что сделано, то сделано. Релиз в среду, а там игроки оценят или нет. А я доволен проделанной работой как слон :P

P.S.: �?того в игре только 152 игровых класса не считая библиотеки Box2D и утилитных классов которые я таскаю в отдельном пакете из проекта в проект. Даже и не знаю чтобы со мной стало если бы я пытался ограничивать себя количеством классов в 5-10 шт. O_O