Невозвратные затраты: когда стоит бросить проект?

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

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

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

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

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

Gamasutra связалась с несколькими разработчиками и попросила их рассказать об историях, связанных с невозвратными затратами в их проектах. Ниже представлены случаи, которыми они захотели поделиться. Это напоминает нам, что всем разработчикам всегда стоит анализировать затраты и прибыль, а также принимать сложные решения, основываясь на неприятных выводах.

Большое видится на расстоянии

Сооснователь CloudGate Studios Стив Боулер вспоминает траты, обусловленные желанием внедрить ненужную функцию во время разработки NBA Ballers: Phenom. Тогда он был аниматором в Midway.

«Открытый мир стал новой модой», — вспоминает он. «Grand Theft Auto III только что стала хитом, и все резко захотели игру с открытым миром».

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

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

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

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

Крушение поезда потерянной продуктивности

Основательница Interplay Ребекка Хайнеман говорит, что могла бы целый день рассказывать об ужасных историях с невозвратными затратами, но она выделяет среди них две любимые.

Она вспоминает: «Для Stonekeep, которую создавала Interplay, команда часами снимала актеров на улице». Но никто не подумал о движении солнца в течение дня, что означало, что тени неминуемо будут менять свое положение от одной сцены к другой. «Они думали, что смогут исправить это за несколько дней», но 75 художников больше года работали над исправлением съемки кадр за кадром.

Спустя десять лет она увидела, как её друг Марк Доктерманн получил удар исподтишка во время разработки Medal of Honor: Airborne.

«Игра сначала разрабатывалась на движке Quake III, но [им] пришлось заменить его движком Renderware, потому что EA купили компанию и захотели использовать его во всех проектах», — объясняет она. Доктерманн уточняет, что «это был год перехода на другую консоль, и Renderware убедили EA использовать Renderware 4.0, в котором обещали инструменты и функции “следующего поколения”. Проблема заключалась в том, что инструмент был недоделанным, поэтому вся ситуация превратилась в великое крушение поезда и потерю продуктивности на долгое время». После 16 месяцев с движком Renderware они отказались от него и перешли на Unreal 3. Они выпустили игру на год позже.

Never gonna give you up

Stoic, компания-создатель The Banner Saga, допустила невозвратные траты дважды: сначала со своим консольным портом, а затем с теперь отмененным портом для Vita. Сооснователь и технический директор студии Джон Уотсон признает, что даже после нескольких пропущенных дедлайнов от выполняющей портирование компании они верили, что все почти закончено и им стоит упорно продолжать.

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

Портирование проекта на Vita было более сложным. Изначально оно было поручено первой компании в январе 2015, но полностью встало, когда компания исчезла в мае. «После коллапса и нового старта портирования новая команда не хотела работать с Vita. Они думали, что у The Banner Saga возникнут проблемы с производительностью, и поэтому придется вносить значительные изменения в интерфейс. Они считали, что разработка будет слишком дорогой и долгой и не стоит того. Поэтому мы решили остановить проект». Но затем Sony перепоручили это другой компании.

Его третья команда, Code Mystics, почти год боролась со сложностями с кастомным движком игры, который нельзя было протестировать, пока порт не достигнет того состояния, в которое уже можно играть. Когда они запустили игру, её плохая производительность на Vita привела к тому, что Stoic, Sony, Code Mystics и издатель игр на Vita Versus Evil приняли решение отказаться от игры. Они хотели, чтобы игра работала, но теперь Уотсон признает, что «этому было не суждено случиться».

Игнорируя тревожные знаки

Ветеран Гленда Адамс вспоминает проблемное портирование игры на Mac в начале 2000-х. Это была игра EA Need for Speed: Porsche, и весь процесс с самого начала был наполнен тревожными знаками. EA отказались передать некоторые части исходного кода игры портирующей компании Aspyr.

«Мы согласились портировать код, который могли, а их штатный программист создавал Mac-библиотеку для частей игры, которые мы не могли видеть», — говорит Адамс. Почти год они пытались заставить проект работать без возможности убрать баги из большей части кода, которая включала не только то, что было скрыто, но и те системы, с которыми взаимодействовал скрытый код. «В итоге мы поняли, что этому не суждено произойти и бросили проект, но принять это решение было мучительно сложно», — продолжает она. «Мы продолжали гораздо дольше, чем стоило бы. На самом деле нам нужно было отказаться от проекта, как только мы увидели препятствия, с которыми нам предстоит столкнуться. Но мы думали, что заставим всё работать».

У дизайнера Puzzle Quest, Warlords Battlecry и Gems of War Стива Фокнера есть похожая история о том, как он не заметил тревожные знаки в начале отношений разработчика и издателя. Фокнер вспоминает, что издатель сказал, что его студия не успела к сроку и удержал платеж в середине проекта.

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

«В тот момент мне стоило понять, что происходит, и просто прекратить работу», — говорит Фокнер. Теперь он понимает, что это было знаком того, что у издателя были финансовые проблемы. «Но молодой и наивный Стив говорил: “Сделаем это!” и продолжил».

«За следующие полгода платежи стали меньше и доходили дольше, но мы продолжали за ними гнаться. Отчеты об ошибках стали странными и дотошными, но мы продолжали их исправлять. Мы сократили сотрудников, урезали зарплаты и продолжили гнаться за платежами, потому что теперь вкладывали в проект больше денег, чем издатель!».

Затем из-за странных запросов и ограничений в бюджете они перестали играть в собственную игру. «Из чего-то знакомого игра превратилась в странного Франкенштейна, и в неё не хотелось играть. А мы не заметили этого», — говорит Фокнер. И когда платежи от издателя совсем перестали приходить, они продолжили работать над игрой ещё шесть месяцев, пока Фокнер наконец не решил отменить проект. «Наша студия была разрушена, у нас осталось три сотрудника. Нам удалось выжить и восстановиться, но мы получили очень важный урок».

Инди-разработчики тоже могут не заметить или проигнорировать тревожные знаки. Креативный директор Voxel Agents Саймон Джослин при работе над головоломкой Toy Mania столкнулся со схожими проблемами. Его студия шесть месяцев разрабатывала эту игру для Facebook, сначала в проекте участвовал только он, а затем к нему присоединились художник и программист. Игра не показала хороших результатов во время софт-лонча, но Джослин решил поработать над ней ещё шесть месяцев.

Команда собрала данные и попыталась использовать их, чтобы изменить игру и опыт вокруг неё (маркетинговые материалы, работу в разных браузерах и т.д.), но она не заметила знаков того, что она по-прежнему не работает. Это привело к дальнейшим пустым усилиям по изменению геймплея, которые сделали основную механику игры еще более сложной. «После месяцев неудач на Facebook мы подумали: Что ж, нам определенно нужно сделать мобильную игру, раз эта не работает», — вспоминает Джослин. Большая команда занималась мобильной версией несколько месяцев, переделывая её для Android. «И, конечно, она тоже провалилась».

Как избежать кошмара

Некоторые разработчики нашли способы избежать или уменьшить невозвратные затраты. Боулер говорит, что в его студии CloudGate они меняются задачами, когда кто-то сталкивается с проблемой, которую не может решить. Это помогает им быть «откровенно честными» о том, что не работает, и оставаться на плаву. В Voxel Agents Джослин научился прислушиваться к своим чувствам и планировать дизайн на бумаге до создания прототипов. Это не предотвратит невозвратных затрат, но может помочь.

У сооснователя Funomena и продюсера Journey Робин Хюнике есть много историй о том, как она избегала неприятностей благодаря дешевым прототипам и откровенной среде в команде. «Многие вещи, в итоге, оказались вполне нормальными», — говорит она. «Они просто долго казались невозвратными затратами».

В thatgamecompany и Funomena спасением стала их маленькая команда. Когда thatgamecompany пыталась создать новую механику лазания в Journey, команда постоянно создавала вариации идеи на маленьких прототипах. Это пошло на пользу игре — в итоге студия решила отказаться от идеи и перейти на систему с шарфом и флагами.

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