Как ошибка невозвратных затрат может разорить разработчика игр

Original author: Rich Moss
  • Translation
image

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.

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

Не видеть за деревьями леса


Сооснователь 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», — говорит Ханике.

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

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 16

  • UFO just landed and posted this here
      +3
      Где-то мне попадалась такая мысль, что если бы в разработке софта было так легко все спроектировать заранее, то огромное количество софта никогда бы не увидела свет. Так как разработчики ужасались бы от списка работ и потенциальных проблем и никогда не брались бы за разработку.

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

      Автор очередной вечной альфа-ерли-аксцесс-игры
        0

        Легко говорить. А что делать остальной части команды, пока геймдизайнеры и программисты делают прототип? В отпуск за свой счёт? Нет, пусть вместе работают. Зато если прототип взлетит, уже будет часть контента.

          0
          Кто эти остальные? Арт и для прототипа нужен то.
            0
            «Арт и для прототипа нужен то». Не пойму что вы хотите сказать. Если имеется ввиду «тоже», то нет, арт для прототипа не нужен. Игра вообще может быть без арта. Миллионы людей играют в шахматы, карты, тетрис, сапёра и кучу других игр практически без арта.
              0
              Миллионы людей играют в шахматы, карты, тетрис, сапёра и кучу других игр практически без арта.

              Они просто берут уже готовый арт из предыдущих игр)

                0
                Там и риски меньше. Игра то известная. Вот только чем игра будет выделяться среди сотни таких же?
            • UFO just landed and posted this here
                0
                По моему опыту эффективно инди проект без стартового капитала, позволяющего нанять нужных спецов в любой момент времени, может начать либо программист либо (реже) художник. Сперва долгое время в одиночку пилится прототип, пиарится на всяких там геймдевру, постепенно привлекает внимание и людей, которые затем становятся членами команды. Проблема в том что это абсолютно ковбойский метод разработки — без долгосрочных планов, без какой-то там разработки геймдизайна. Планов серьезных у тебя нет так как ты не знаешь, будешь ли делать дальше или бросишь через два дня. И ты лучше потратишь время на написание кода, а не дизайн-документа и глубокое продумывание. Так как с готовым кодом шансы найти команду гораздо выше, так как геймдев ресурсы и так уже завалены темами с концептами игр, авторы которых потратили все время и энтузиазм на концепцию и дизайн и так и не дошли до собственно создания игры. И на таких уже никто всерьез внимания не обращает.

                А в итоге через некоторое время и получается, что работы сделано уже много, бросать жалко, а по сути до релиза игра все так же далека.
                  0
                  Инди, шминди… Инди — уже давно не значит «два с половиной человека», а вполне себе полноценная команда. Я давно в геймдеве, знаю что такое конвейерное производство, и знаю что такое отменённые прототипы. Хоть программисты как правило заняты допиливанием предыдущего проекта, но всё равно в итоге переходят на прототип нового, и новый проект в разгаре вполне себе отменяется либо кардинально переделывается во что-то новое, так что большая часть работы и программистов и всех остальных отменяется и выбрасывается в мусорку.
                  • UFO just landed and posted this here
                  0
                  большая часть команды это фриласеры с гибкой занятостью. по крайне мере у крупных проектов, где команда большая.
                  0
                  Хотя основой игры и является геймплей, создаваемый геймдизайнером, но если игра надеется выйти до Второго Пришествия, одновременно с геймдизайном создаются уровни и модели, пишется код и т.д.
                  Просто если создание моделей во много техническая задача (как минимум — всегда понятно что с моделью не так и как доделать), то уникальный и интересный геймплей в принципе не всегда можно реализовать. Более того, это субъективно и разработчики + 10 фанатов могут думать что всё удалось и всё идеально, менять = портить.

                  Альфа, бета и Early Access же захватили мир по несколько другим причинам. У меня лично как инди-разработчика нет другого варианта, если я хочу собрать обратную связь и доделать игру.
                  • UFO just landed and posted this here
                  0
                  Очень нужная статья. Об этом в универсистете не расскажут. Но вот это и есть проблемы в АйТи. Не алгоритмы, не инструменты, не парадигмы и не ресурсы ограничивают нас, а наша человеческая глупость иррациональность. Недавно читал (жаль не могу найти ссылку), когда захотели поменять фотографию мальчика на упаковке Kinderschokolade, было проведено маркетинговое исследование и маркетологи пришли к выводу, что делать этого не стоит. С этим результатом они пришли к начальнику, а он выслушав их, сказал «Давайте все равно поменям».

                Only users with full accounts can post comments. Log in, please.