Иногда при разработке игр возникают сложности — появляются технические проблемы, дизайн оказывается красивым только в теории, решения, принятые на ранних этапах, приводят позже к трудностям. Такова реальность этого ремесла — в процессе создания бывают ошибки и неудачи.
Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?
Для человека естественно привязываться к результатам своего труда. При написании книг это называется «убийством любимых» — нам приходится избавляться от излишних пассажей и фраз, придуманных с любовью, но оказавшихся в результате избыточными или мешающими сюжету.
И в разработке игр тоже приходится учиться вырезать всё слишком амбициозное, неработающее и эгоистичное. Если этого не сделать… то, как мы увидим, проблема утянет за собой проект и может даже привести к катастрофическому финансовому положению компании. Особенно это справедливо, когда признание своей ошибки означает, что придётся вкладывать большой объём дополнительного труда.
Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.
Мы попросили дюжину разработчиков рассказать о своём опыте ошибок невозвратных потерь в проектах, над которыми они работали. Вот истории, которыми они захотели поделиться. Все они служат важным напоминанием о том, что каждый разработчик должен постоянно выполнять анализ затрат/выгод и совершать решительные действия в случае неприятных выводов.
Не видеть за деревьями леса
Сооснователь CloudGate Studios Стив Боулер вспоминает про обернувшуюся большими затратами попытку реализовать функцию, которой даже не должно было быть в игре, при разработке NBA Ballers: Phenom. Стив в то время работал аниматором в Midway.
«В то время новой и очень популярной „фишкой“ стал открытый мир», — вспоминает он. «Только что вышла Grand Theft Auto III и все стремились придумывать игры с открытым миром».
Первая часть Ballers была достаточно прямолинейной — просто уличные баскетбольные матчи один на один, каждый в своём собственном окружении, соединённые сюжетными катсценами. Боулер говорит, что сиквел должен был стать проходным проектом для заработка денег с новыми режимами игры и некоторыми дополнениями.
Но компания вместо этого решила заставить команду, которая никогда раньше не создавала открытые миры, реализовать их в лицензированной NBA игре про уличный баскетбол.
NBA Ballers: Phenom
«Каждый шаг в процессе разработки был провальным. Например, как только мы настроили систему вождения, вмешалась NBA и сказала, что игроки не должны никого давить на дороге, потому что NBA — это семейный бренд. Вместо того, чтобы отказаться от функции управления автомобилем, которая изначально была ненужной, команда потратила лишнее время на то, чтобы NPC научились отпрыгивать с дороги».
«Разработчики потратили кучу времени, пытаясь создать открытый мир, пока компания наконец не сдалась и не сделала его изометрическим. Теперь он больше походил на меню, в котором можно было ходить», — рассказывает Боулер. «И даже после этого он казался непродуманным; да и в целом изначально не стоило стремиться к его реализации».
Захватывающие катастрофы потерянного труда
Одна из учредительниц Interplay Ребекка Хейнеман сказала нам, что могла бы хоть целый день делиться кошмарными историями о невозвратных затратах, в которых она участвовала или которые видела. Однако она решила рассказать две самые любимые.
«Для игры Stonekeep компании Interplay было записано несколько часов видео с живыми актёрами. Съёмка происходила на открытом воздухе», — вспоминает она.
Но никто не задумался о дневном перемещении солнца, из-за которого тени при переходе от сцены к сцене резко скакали. «Разработчики считали, что смогут исправить графику за считанные дни, но 75 художникам потребовалось больше года, чтобы покадрово исправить все записи».
Stonekeep
Спустя десяток лет Ребекка издалека наблюдала за тем, как вмешательство издателя мешало её другу Марку Доктерманну в руководстве технической стороной разработки Medal of Honor: Airborne.
«Игра разрабатывалась на версии движка Quake III компании Ritual, но команде пришлось заменить его на движок Renderware, потому что EA купила эту компанию и хотела использовать движок для своих продуктов», — объясняет Хейнеман.
Доктерманн пояснил, что в тот год они переходили на консоли, а Renderware убедила EA в том, что Renderware 4.0 сможет предоставить инструменты и возможности «Next Gen». Проблема заключалась в том, что ещё ничего не было готово, и весь процесс обернулся величественной и затянувшейся катастрофой потраченного труда.
Примерно через 16 месяцев работы с движком Renderware разработчики наконец сдались и перешли на Unreal 3. На доделку игры потратили меньше года.
Medal of Honor: Airborne
Never gonna give you up
Разработчик The Banner Saga Stoic совершила ужасную ошибку, дважды попавшись в ловушку невозвратных затрат — в первый раз при портировании на консоли, а затем при создании отменённого в дальнейшем порта для Vita. Совладелец и технический директор студии Джон Уотсон признаёт свою ошибку — он думал, что, несмотря на несколько дедлайнов, сорванных компанией-разработчиком порта, они «уже почти закончили», а поэтому стоит только потерпеть.
Полный масштаб проблемы стал очевиден тогда, когда портирующая игру компания вышла из бизнеса после года работы над проектом. Уотсон рассказывает, что неудача с портом на консоли стоила около ста тысяч долларов, и хотя часть работы удалось использовать, когда разработку порта начала другая компания, эти 100k точно можно было потратить с большей пользой.
С проектом порта на Vita всё было сложнее. Изначально он должен был разрабатываться первой компанией в январе 2015 года, но проект подвис в воздухе, когда эта компания в мае схлопнулась.
«После этого кризиса и повторного запуска проекта по портированию на консоли новая компания не торопилась браться за порт для Vita», — говорит Уотсон. «Разработчики чувствовали, что The Banner Saga была большим риском с точки зрения производительности и требовала значительных изменений в GUI. Они считали, что разработка будет слишком дорогой и длительной, а значит, не оправдает себя. Поэтому мы решили перекрыть этому порту кислород. Но потом Sony поручила взяться за него ещё одной компании-разработчику портов».
Больше года эта третья команда, Code Mystics, боролась со сложностями собственного движка игры (который невозможно было протестировать, пока порт не достиг играбельного состояния). Когда им удалось запустить игру, её ужасная скорость на «железе» Vita заставила Stoic, Sony, Code Mystics и издателя игр для Vita Versus Evil принять обоюдное решение о прекращении проекта. Все они просто хотели заставить игру работать, но, по словам Уотсона, «этому просто не суждено было случиться».
The Banner Saga
Не замечая тревожных сигналов
Опытная программистка Гленда Адамс вспоминает многострадальный проект портирования игры на Mac в начале 2000-х. Портировали игру EA Need for Speed: Porsche, и с самого начала работы появилось множество дурных предзнаменований. EA отказалась передавать занимавшейся портом компании Aspyr некоторые части исходного кода игры.
«Мы договорились портировать весь доступный нам код, а затем EA должна была представить нам собственного программиста, чтобы тот написал Mac-библиотеку для тех частей, которые мы не могли увидеть», — объясняет Адамс.
Почти год команда пыталась работать, не имея возможности отладки огромной части кода (той части, которая была закрыта EA, плюс взаимодействующих с ней систем).
«Со временем мы поняли, что ничего не получится, и прервали работу, но принятие такого решения напоминало агонию», — продолжает Адамс. «И мы откладывали её намного дольше, чем нужно было. На самом деле, стоило сразу отказаться от проекта, как только мы увидели, с какими препятствиями нам предстоит столкнуться».
«Но поначалу мы испытывали оптимизм, потому что с точки зрения портирования мы работали поверх игры EA и могли заставить её работать».
Need For Speed: Porsche Unleashed
У дизайнера Puzzle Quest, Warlords Battlecry и Gems of War Стива Фокнера тоже есть похожая история, когда в самом начале сотрудничества разработчика и издателя игнорировались все «красные флажки». Фокнер вспоминает, как издатель заявил, что студия не уложилась в дедлайн и задержала оплаты посередине проекта.
«Мы начали тратить свои собственные средства, пытаясь дотянуть до следующего платежа», — вспоминает он. Вложенные средства казались инвестициями для получения дохода в будущем, так что мы считали это решение рациональным. Однако месяц спустя, после повторной сдачи части проекта, издатель заплатил только половину и предложил в качестве компенсации повышенный процент отчислений.
«В тот момент мне уже следовало осознать, что происходит, и просто покончить со всем этим», — говорит Фокнер. Теперь он понимает, что это был явный сигнал, свидетельствующий об огромных финансовых проблемах издателя. «Но я был моложе и наивнее», — рассказывает Стив. «Поэтому решил — мы своего добьёмся!»
«В течение следующих шести месяцев платежи становились всё меньше и реже, но мы продолжали их ждать. Сообщения о проваленных дедлайнах становились всё более странными и придирчивыми, но мы разбирались с ними. Мы увольняли работников, сокращали зарплаты, но продолжали выполнять этапы разработки, потому что к тому времени потратили на проект больше денег, чем сам издатель!»
Хуже того, на этом пути разработчики, вымотанные постоянными требованиями и финансовым стрессом, перестали играть в свою собственную игру. «Из свежего взгляда на знакомую тему игра превратилась в чудовище Франкенштейна, которое никому не было интересно», — говорит Фокнер. «Но мы этого не замечали».
И даже когда платежи совершенно прекратились, компания продолжала работать над игрой ещё шесть месяцев, после чего Фокнер наконец отменил проект. «Наша студия была разрушена, в ней осталось три сотрудника», — вспоминает он. «Нам удалось выжить и восстановиться, получив очень важный урок».
Инди-студии тоже могут запутать незамеченные или проигнорированные тревожные сигналы. Креативный директор Voxel Agents Саймон Джослин понял это на примере головоломки Toy Mania. Его студия потратила шесть месяцев на разработку этого проекта как игры в Facebook — сначала в команда был только Саймон, затем к нему присоединились художник и программист. Предупреждающие сигналы заключались в том, что игровой процесс разваливался ещё на этапе soft-launch, но Джослин решил продолжать работу ещё шесть месяцев.
Они собирали данные и пытались использовать их для улучшения игры и впечатлений от неё (маркетинговых материалов, качества работы в разных браузерах и т.д.), но не внимали тому, о чём предупреждали данные — игра по-прежнему не работала. Это привело к ещё большим напрасным усилиям — теперь геймплей изменился, а основная механика стала более сложной и менее доступной для пользователей.
«Спустя несколько месяцев неудачной работы игры в Facebook мы решили, что её определённо стоит переносить на мобильные», — рассказывает Джослин. Вся команда начала работать над мобильной версией и потратила несколько месяцев, оптимизируя её под аудиторию Android. «Разумеется, она потерпела неудачу и на мобильных».
Как избежать кошмара
Некоторым разработчикам удалось найти способ избежать или снизить влияние ошибки невозвратных затрат. Например, Боулер рассказывает, что в его нынешней студии CloudGate разработчики обычно меняются задачами, когда кто-нибудь натыкается на проблему, которую не может решить. Это помогает им быть «жестоко честными» о том, что не работает, и не терять ориентации. Джослин из Voxel Agents научился следовать своему чутью и создавать дизайн на бумаге, и только потом создавать дешёвые прототипы, чтобы иметь чёткое видение будущего. Это не может полностью избавить от кошмаров невозвратных трат, но помогает в решении проблем.
Соосновательница Funomena и продюсер Journey Робин Ханике может рассказать множество историй о кошмарах, которых удалось избежать благодаря дешёвым прототипам и открытой и честной атмосфере в команде. «В большинстве моих историй всё заканчивалось нормально», — рассказывает она. «Просто они ещё долгое время казались невозвратными тратами».
Journey
И для thatgamecompany, и для Funomena спасением был маленький размер команды. Когда thatgamecompany упорно стремилась реализовать в Journey механику ползания по стенам, команда постоянно итерировала идею на маленьких прототипах, и не переходила слишком рано к полной разработке механики.
В результате отказ студии от этой идеи и переход на систему с шарфом и флагами пошёл на пользу игре. «То же самое произошло с ранними прототипами ползания и складывания в Wattam и с системами физической и музыкальной обратной связи, которые мы разрабатывали для Luna», — говорит Ханике.
«Я думаю, что дизайнер должен экспериментировать и учиться на своих ошибках. Жизнь слишком коротка, чтобы держаться за плохие идеи, однако инновации требуют мужества и времени для превращения плохого в хорошее».
Автор: PatientZero
