Bob the Robber 2 - постмортем

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

Пару слов об оригинале

Первый Bob the Robber был весьма любим игроками, выиграл номинацию «самый хулиганский разработчик» на Флэшгаме в Киеве 2011, удостоился статьи на JIG. Одним из главных референсов игрового процесса была культовая игра TRILBY: The Art of Theft. Также были проанализированы имеющиеся на тот момент стелс флэшки, подчеркнуты сильные моменты, отброшены излишне хардкорные элементы и в итоге была сформирована концепция, подходящая, на мой взгляд, для портального казуального игрока.
Перед началом разработки я и представить не мог что для такой простой на первый взгляд механики (там ведь даже физики нет) будет столько тонких моментов с поведением охранников и камер. Вроде все играли в классику стелс жанра вроде Thief, Splinter Cell и Metal Gear Solid. Казалось бы все уже придумано. Вот тут охранник видит героя и поднимает тревогу, вот тут теряет его из виду и начинает какое-то время его искать и звать подмогу. Но полностью разложить все возможные ситуации на набор четких правил оказалось весьма не тривиальной задачей. Наверное этот этап разработки и запомнился больше всего. В итоге разработка первой части заняла около четырех месяцев.



Сделать хорошо?


Когда в 2012 году мы решили сесть за продолжение Bob the Robber я вполне обоснованно думал что львиная доля работы уже сделана. Надо просто поправить ряд багов, придумать новую историю и пару новых противников, нарисовать 10+ клевых уровней, сделать больше миниигр и добавить магазин в котором можно тратить «награбленные» деньги. Работы на три месяца, ну максимум четыре до нового года. В итоге разработка затянулась на 9 месяцев с сентября 2012 по июнь 2013. Почему так долго? Давайте разбираться.
После того как была озвучена проблема с переходами между экранами мы решили уместить все новые уровни в один экран. Чтобы вместить все — пришлось уменьшить масштаб. Очень быстро выяснилось что движок первой части не очень то для этого годится. Чтобы сделать хорошо нам надо фактически переписать его с нуля. Ну надо так надо! В новом движке мы постарались изначально исправить и остальные косяки первой части. Добавить индикаторы «вырубленных» врагов, проработать миниигры, отполировать механику перемещения героя. Помню над таким простым элементом как лифт мы сидели минимум неделю. В отличие от первой части мы сделали задержку на перемещение между этажами и тень-индикатор текущего положения Боба.
Кучу времени мы полишили вхождение игрока в двери, залезание и слезание с лестниц. Чтобы можно было держать кнопку движения вбок не отпуская и персонаж продолжал движение вбок — вверх — вбок, не застревая на стыках.
Даже карту уровней решили проработать нестандартно. Учитывая что все уровни-постройки имели разную высоту и частично перекрывали друг друга, хотелось сделать «выделение» уровня более удобным и заметным. В итоге придумали и реализовали фишку с поднятием плит земли из ландшафта. Не знаю обратили ли вы на нее внимание — но меня лично прямо «прет» когда пробегаешься мышкой по открытым уровням и приподнимаешь волной тверди земные ))



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

Про уровни и магазин

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




Основная сложность заключалась в том что если требовалось внести какие-то изменения в уровень то можно было жонглировать объектами, тенями, но вот изменить фон уровней было уже более проблематично. И тут дело дошло до магазина…
Изначально мы планировали дать возможность покупать 5 гаджетов и 5 пассивных скилов (покупаешь один раз — действует всегда).
Цена скилов должна была быть значительно дороже гаджетов, и вся эта система обладала большим количеством вариантов, в зависимости от того что игрок будет покупать первым. На поздних этапах планирования количества денег на уровне и балансировки экономики систему стало очень сложно просчитывать. А скил — дополнительные деньги, вводил параллельную систему стоимостей, что наводило на мысли о квантовом компьютере.



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

Не надо недооценивать игроков


При дизайне уровней мы старались оторваться на полную и оставили кучу референсов на классику игр и кино. Ганнибал Лектор в тюрьме с плакатом девушки на стене за которым вырыт проход как в побеге из Шоушенка. Скелет беглеца с плюшевым мишкой в вентиляционной шахте (это был просто прикол без конкретной отсылки, но игроки вспомнили Чужого). Разбитый фонарь Бэтмена в кладовке полицейского участка. Компания GUMP которая виновата в появлении зомби (обратите внимание на логотип). И собственно президент компании — мужик с чемоданчиком прообразом которого стал небезызвестный персонаж из Half-Life. Файлы в компьютерах — минииграх тоже не остались незамеченными (легендарная hotgirl.txt перекочевала без изменений из первой части).



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

Итоги:
Сейчас спустя месяц после того как игра увидела свет можно положа руку на сердце сказать что сделать хорошо все-таки получилось, и старания были не напрасны. Релиз вернул нам потраченные силы и эмоции сполна. Мы взяли weekly 3rd и mounthly 9th на Kongregate (оценка 3.81). Буквально на прошлой неделе игра дождалась бейджей и снова на главной.



Kongregate традиционно стал основной площадкой для сбора фидбэка и активного общения с игроками. Мы старались оперативно исправлять ошибки. За две недели игра выдержала 10 итераций (прокачалась c версии 1.01 до 1.10). А сегодня, спустя уже месяц мы зальем версию 1.11 в которой продолжаем фиксить критические баги.
Уже с основными исправлениями через неделю после релиза игра стала доступна на Mochi. Колин попросил вставить их новую CPA рекламу и взамен зафичерил игру, что тоже неплохо сказалось на трафике. Про нас снова написали статейку на JIG, что тоже внесло свою лепту в дистрибуцию и трафик.
В итоге игра разошлась на 1200+ хостов и у нее спустя месяц уже 8,5 млн просмотров (с китайцами). Это конечно не самый наш популярный релиз (Truck Loader 4, к примеру, переплюнул 10 млн за первый месяц), но цифры весьма достойные, мы довольны. Учитывая что игра монетизируется через собственный портал, хороший трафик — залог более быстрого срока окупаемости.
В игре использовалась система защиты с подгрузкой внешнего файла конфига, о которой я уже писал в другом посте. Функция позволяющая на лету выключать на конкретном домене рекламу оказалась весьма кстати. Делать так чтобы игра перестала запускаться на домене, блокирующем ссылки нам пришлось всего один раз. Для китайцев заблаговременно были подготовлены специальные сайтлоки с их рекламой и с одной внешней (зато работающей) ссылкой. В конечном итоге такая работа с их сегментом себя оправдывает.

Не маленький вышел постмортем. Спасибо всем кто осилил!

P.S. Предвосхищая вопрос — будет ли доступна игра на мобильных платформах, скажу что делать порт силами своей студии мы пока не планируем, но уже следующую нашу игру мы уже одновременно пилим и на флэше и на юнити.
  • +34

Комментарии (50)

0
Спасибо! От души.
0
но уже следующую нашу игру мы уже одновременно пилим и на флэше и на юнити
а можешь рассказать зачем делаете сразу на том и на этом — на юнити так понимаю чтобы на мобильные платформы — а чем AIR не устраивает? просто я понимаю когда студия выбирает юнити вместо флеши — но когда идет разработка и на флеши и на юнити… это уже другое дело
+2
Я какое-то время серьезно ломал голову над окончательным выбором в пользу одной из технологий. Изучал плюсы минусы и в конечном итоге пришел к выводу что для мобильных платформ, как и для win/mac юнити гораздо удобнее. В то же время флэш платформа пока еще значительно более понятна и в плане разработки, и в плане монетизации. Она позволяет новую игру обкатать на миллионах игроков, получить фидбэк, определенную узнаваемость тайтла и окупить разработку. Поэтому для нас на текущий момент продуктивнее изначально разрабатывать на флэше (прототипирование, анимации, левелдизайн), а потом уже «готовый продукт» с учетом поправок переносить на юнити.
0
но и все же чем юнити удобнее флеши для мобильной разработки да и для мак/PC? я конечно имею ввиду разработку 2d игр
0
я на самом деле почти ничего не знаю про юнити — поэтому и интересно какие такие удобства он дает по сравнению с AIR
0
Ну если даже не брать во внимание очень клевый редактор (реально удобно работать) и большой assets store полезностей. То это прежде всего быстродействие (если игра пойдет, к примеру, на steam). Разговаривал с vap (который intrusion 2) на эту тему — у AIP по сравнению с юнити очень ограничена производительность. Кстати, показательный пример, сам vap сейчас перешел именно на unity.
0
кстати вот нашел сравнение производительности Starling + AIR Vs. Unity 3D, интересно что AIR не всегда проигрывает Unity в производительности — но даже когда проигрывает — то не на всех девайсах так значительно — хотя на старом iPad 1 AIR проигрывает конкретно: blog.juiceboxmobile.com/2013/03/06/2d-gaming-mobile-performance-starling-air-vs-unity-3d/
0
оффтоп
в какой проге ВАП анимирует?

пс много пишет кто про этот юнитевский редактор сцен
я его качал меня он только пугает))
може кто добрый напишет пост о юнити?
+1
Если ты о гифках по ссылке на LD игру, то там написано же что vap сам написал свой инструментарий для анимации с редактором. Вообще если нужен редактор 2d анимации именно внутри unity — есть 2dtoolkit и есть Smooth Moves. Мы же вообще импортируем наши готовые анимации из флэша в XML и обрабатываем в юнити стандартными средствами. Все-таки флэш аниматора значительно проще найти чем спеца, который готов разбираться с Smooth Moves.
0
из своего опыта — я начал мобильную разработку на Marmalade SDK — наверно единственное известное мне решение, которое генерирует на выходе бинарник для ARM процессора — без всяких виртуальных машин, сборщиков мусора — в общем без всего того, что не очень хорошо для производительности — тем не менее следующий мобильный проект делаю на AIR+Starling и пока (по сравнению с мармеладой) испытываю только положительные эмоции — Starling API гораздо проще и удобнее для 2D, чем у мармелады — конечно производительность не самое сильное место AIR (тут тебе сборщик мусора и целая куча неявно создающихся временных динамических объектов) — но не все игры интенсивно используют CPU — к тому же разве в юнити нет виртуальной машины и сборщиков мусора — то есть все тех же «пожирателей» CPU?
0
Ну я рассматривал скорее комплексное решение и для мобильных платформ и для PC/MAC (плюс все прочие платформы которые ты получаешь с юнити в нагрузку). Если речь только о версии для мобильных или мобильные + web, то AIR+Starling очень даже конкурентный вариант. В общем думаю надо исходить из требований каждого конкретного проекта.
0
iOS/Android/PC/MAC — Adobe AIR это все может — я бы даже сказал что PC/MAC тут у AIR еще меньше проблем — мощности PC/МАС с головой хватит для большинства инди игр — если конечно в планах еще и консоли захватить… вот тут AIR конечно не конкурент
0
Проблемы у AIR на PC/MAC есть. Проблемы с производительностью в больших разрешениях, проблемы с выбором качества для разных по мощности машин (тот же low level не сделать стандартными средствами без zinc). В общем я специально спрашивал есть ли игры на gog.com сделанные на AIR — единицы и те в низком разрешении в оконном режиме. Для Steam кроме intrusion 2 и no time to explain — других не знаю. И в обоих случаях разработчики огребли кучу гемора c AIR. Конечно можно использовать Stage3d и аппаратное ускорение для увеличения производительности, но все удобство редактора Flash IDE в этом случае пропадает и Юнити смотрится на фоне этой возни реально более комплексной и надежной альтернативой.
0
В Стиме еще Binding of Isaac на AIR, насколько я знаю. Тот же Machinarium еще.
Кстати, Machinarium некоторое время назад вышел на PS3 и Vita – значит ли это, что там тоже адаптировали AIR для разработчиков, или игру переписывали?
0
Я думаю в такой игре как Машинариум — 90% (если не больше) работы — это арт + скрипты квестов (которые скорее всего переписывать не пришлось), а переписать движек это уже мелочи
0
Конечно можно использовать Stage3d и аппаратное ускорение для увеличения производительности
что? что? удивлен! так зачем же писал на AIR без Stage3d и винить его потом в плохом быстродейсвии на больших разрешениях экрана? :) уверен был бы в Unity3d програмный рендеринг — он бы тоже тормозил :)
+2
Adobe Flash/Air работает хорошо и быстро в том случае, если используется Stage3D. Яркий пример www.fdg-entertainment.com/en/iOS/Bloody-Harry-iOS.html

А все, кто жалуются на низкую производительность Air — обычно делятся на три группы:
— используют старые версия AIR (я рекомендую всего последние беты катать)
— не используют Stage3D (Starling, ND2D и т.д.)
— просто перегружают всё на столько, что если бы это засунуть в том же software режиме на unity — он бы тоже помер.
0
Яркий пример
Как раз недавно прошел этот яркий пример. Почему-то игра имеет низкий framerate (визуально около 30) на iPad 3.
0
Спросил у автора игры на счет установленного в ней fps. Потому, что не может быть низкий fps у stage3d при таком объеме графики. Другое дело если там displaylist где-то над stage3d. тогда может что угодно :)
0
Спросил у автора игры на счет установленного в ней fps.
Спросил и что? Всмысле что он сказал?
0
Он еще ничего не ответил.

Глупо спорить о производительности, когда я не проводил анализ исходников и как устроена игра изнутри. Я слишком дотошный в этом плане и вижу сразу ошибки. Но без исходников игры — сетовать на Air нельзя. Автор еще не дал ответ. Вдруг у него просто 30 fps стоит там? Или Air версии старой. Или там поверх Stage3D интерфейс DisplayList (что слишком убивает fps).

Я сейчас работаю с unity3d над одним экспериментом. В 2D я не вижу преимуществ вообще никаких. Тупо одинаково. А тупо наваливать 200 particles и тестировать глупо. Они не используют ничего почти.
0
FPS понижают, чтобы игра не тормозила, ваш кэп. Попробую сегодня качнуть bloody harry на первый iPad. Вангую, что не заработает.
+1
Я играл только что на первом. Иногда подлагивает, но мне фпс показался достаточно комфортным. Мне больше качество графики смутило. Не знаю что там, жатые текстуры или 16битный цвет, но как-то мыльновато.
0
но в целом я понял суть — есть какой-то удобный редактор Flash IDE :) (которым я не пользуюсь и честно говоря боюсь его :) но матерые флешеры его очень любят) (и он со Stage 3d не работает) — мне же от Adobe AIR нужен только компилятор, всю графику я все равно рисую в отдельных редакторах — поэтому никаких неудобств не испытываю — кстати приемущество использования отдельных редакторов для графики в том что ты можешь перепрыгнуть на другую среду разработки кода — но привыкать к новым графическим редакторам не нужно — еще один положительный момент AIR — можно билдить под iOS на PC — для Unity по моему требуется MAC — правильно? понимаю не проблема купить — но это дополнительное врожение в будущее которое весьма переменчивое :)
0
Да, об этом и речь. Тесты быстродействия — это все удаленные от реальности материи. Как правило есть конкретная игра, которую надо сделать максимально быстро, с максимальным использованием имеющихся навыков. Плюс держать в голове перспективность технологий которые надо изучить дополнительно. Для нашей команды в настоящий момент портировать на юнити AS3 игру субъективно удобнее и эффективнее чем на AIR + Stage3d. Что касается перспектив — поживем увидим.
0
Почему ты решил, что Flash IDE не работает со Stage3D? Или что ты имеешь ввиду под этими словами?
Что касается билда под iOS — совершенно верно. На PC можно билдить под iOS. Единственное, что плохо — для билда Air под MacOS нужен установленный Flash CC на маке. У кого нет фин. возможностей — ставится виртуальная машина. Но и тут не каждая тачка запустит. Надо подбирать железо.

Друзья, о чем вообще спор? Все платформы хороши в умелых руках :) Тут как с женщиной. Если не получается — вряд ли проблема в женщине :)
0
Почему ты решил, что Flash IDE не работает со Stage3D? Или что ты имеешь ввиду под этими словами?
Тут довольно сложно понять кто, кому отвечает, но я так понял, что это вопрос мне. Я не работаю во Flash IDE и понятия не имею работает ли он со Stage3D или нет — мой коммент — это подведение итога, изначально я был удивлен: почему перешли на Unity, если игра уже написана на флеше. flazm говорит:
Конечно можно использовать Stage3d и аппаратное ускорение для увеличения производительности, но все удобство редактора Flash IDE в этом случае пропадает
+1
В общем-то странное утверждение flazm. Если не знать о примочках к старлингу, которые вроде как позволяют с костной анимацией 2D работать — проблем не вижу никаких. Короче говоря — кто как хочет, так и др… :)
0
в общем я не спорю :) просто хочется знать за что разные разработчики выбирают ту или иную среду — кто знает может мне тоже нужно :)
0
Ага, я прекрасно понимаю такие вопросы, потому что сам долго выбирал оптимальную для студии стратегию. Но тут надо отталкиваться не от технологии а от текущего проекта и планов на будущее.
0
мм
любопытно про планы на будущие.
Если вы делате игру параллельно (флеш и юнити)
и эта игра новая
то как можно прогнозировать успех игры и окупаемость такой двойной разработки.
я понимаю, если вы делаете сиквел успешной игры.

т.е мой вопрос, почему не сделать сначала флешку и посмотреть результат и уже потом делать порт на юнити — почему параллельно?
+1
Когда игра новая — таких гарантий естественно нет, да и кто сейчас дает гарантии на мобильном рынке? Но этот конкретный проект для нас — удачный материал чтобы изучить все тонкости импорта и обработки анимации из внешнего источника в юнити.
Причина номер 2 — не очень продуктивно по факту уже находить в апсторе украденные китайцами свои «успешные» игры и пытаться заставить их убрать эти версии. Так что мы просто принимаем гипотезу что новая игра будет интересна игрокам обоих рынков и делаем порт заранее.
0
но я AIR не рекламирую :) просто пытаюсь понять, чем действительно Unity так выигрывает у adobe AIR — пока что для себя из плюсов вижу некоторый выигрыш в производительности
0
Ну я тоже как бы не евангелист Юнити, просто если ты начинаешь разработку на этой платформе ты уверен, что всегда есть возможность выпустить PC/MAC раньше мобильных с минимальным геморроем. Или если игра выстрелит и ты захочешь выйти на XBox, PS, OUYA с минимальными доработками самой игры. Это конечно потребует инвестиции на начальном этапе (время на освоение среды и языка), но это инвестиции в будущее.
0
кстати Adobe AIR OUYA Native Extension — если кому интересно: ouyaforum.com/showthread.php?945-Adobe-AIR-Native-Extension-for-the-OUYA-Controller
0
Ну просто колоссальные продажи стимулируют: www.playground.ru/news/indi-razrabotchiki_dovolni_prodagami_igr_na_konsoli_ouya-41111/
0
Игру бы играл, что со мной бывает редко, но крайне не понравилось запоминать код, я понимаю что это ерунда, но мне кажется когда индустрия так сильно развратила игрока, это неправильно. Может лучше бы он за место чтения бумажки дёргал за выключатель или набирал автоматически.
+1
Ну отсутствие челенджа — тоже плохо. Это одна из основных миниигр, еще из первой части. Облегченный вариант кода с двумя нулями по бокам не так уж и сложно запомнить. Да и есть определенный смак в том чтобы вбивать пароли с бумажек кнопками клавиатуры. Замена на дверь и рычажок обескровила бы этот момент.
+1
интересный пост!
спасибо
я несколько раз нажимал на домик с котом, думая что это магазин)) это нарочно сделали?

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

По цитрусу у нас Хануман главный специалист ))
+1
Поддерживает обычный дисплейлист, блиттинг и стейдж3д. Не уверен насчёт минимального изменения, но всё же меньше чем переписывать полностью..:)
0
Интересный пост! Посмотрел так же игрушку «Truck Loader 4» — А как вы сделали эффект искр магнита, если не секрет?
0
Спасибо. Эффект искр тянем еще с первой части — это обыкновенный рендер в PNG последовательность, как и взрыв.
0
т.е. он делается в любой сторонней программе рендера эффектов и вставляется во флэш набором картинок.
+1
Можете подсказать ту программу в которой создаете эффекты, а потом рендерите в PNG?
+1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.