Из монолога Петросяна
Недавно вышло аж несколько статей посвящённых так называемому «кранчу». Полное название этого термина, позаимствованного из английского языка — Cranch-time, и на самом деле он обозначает ту же вещь, что и более знакомое нам слово «аврал». А именно ситуацию, когда выясняется, что работу, которую нужно было сдать ещё вчера, никто ещё даже и не начинал, и в результате всем приходится вкалывать круглые сутки, чтобы сделать всё хотя бы как-то, хотя бы до того, как последуют меры со стороны начальства.
Думаю все мы сталкивались с подобным явлением. Где бы мы не работали (если только работа не ограничена просиживанием на месте от начала до обеда), или даже учились — всегда, когда нужно сделать что-то в срок, есть вероятность, что выбьешься из графика и в конце придётся навёрстывать работая не покладая рук в «свободное время». Но что интересно, несмотря на распространённость работы в авральном режиме, во всех отраслях такая ситуация всё-равно считается экстраординарной. Если подобное случается — значит возникла проблема, значит кто-то виноват и нужно принять меры, чтобы это не повторилось. Так рассуждают все и везде... кроме индустрии компьютерных игр!
При создании игр (и, в принципе, при разработке ПО вообще) аврал, или как принято там говорить «кранч» считается неизбежным, а некоторые вообще воспринимают его чуть ли не как норму. И на это есть целый ряд причин.
Ряд причин
Исходная причина, которая в свою очередь порождает и другие — это то, что разработка игр является процессом одновременно творческим и коммерческим. С одной стороны понятно, что разработчикам, как и писателям и художникам нужно вдохновение. И они не могут просто взять и придумать интересные идеи немедленно, даже если им приказать или пообещать кучу денег. С другой стороны игра — это товар, который необходимо подготовить к продаже к определённому сроку.
И сегодня релиз вовремя важен как никогда, ведь для того, чтобы проект заметили в море выходящих со всё увеличивающейся частотой игр, маркетинговая кампания начинается чуть ли не с самого начала цикла разработки. Игроков специально готовят, разжигают их интерес, создают игре имидж, и стоит хоть немного опоздать — люди «сорвутся с крючка» и уйдут играть во что-нибудь другое. Не все, конечно, но разница в прибыли может быть достаточной для итогового банкротства.
Вот и получается, что график разработки задаётся довольно жёстко, а в то же время вероятность того, что какой-то аспект игры придётся переделывать никуда не девается. Вот, например, история разработки шутера XCOM. Сделали необычных врагов, а оказалось, что большинству игроков сражаться с ними неудобно — непонятно ведь, когда ты наносишь врагу урон, а когда он тебе! А со стелсом ещё хуже — как понять, заметили тебя или нет, если вообще непонятно что враг делает? Пришлось переделывать сценарии миссий так, чтобы они больше соответствовали механике тактического шутера. И результат — команда вышла из графика. Значит нужно навёрстывать.
Вторая причина — это множество взаимосвязей между компонентами игры. Сама по себе она, конечно, не вызывает задержек. Но зато задержки, вызванные «исходной причиной», она способна увеличить на порядок... а то и больше.
Допустим в каком-нибудь экшене один из последних уровней получился слишком лёгким — враги там слишком быстро убиваются. Что делать? Можно уменьшить урон от оружия, но тогда предыдущие уровни станут сложней. А можно увеличить здоровье врагов — причём только на этом уровне. Но согласитесь — это будет странно смотреться, когда одни и те же враги будут «толще» на одном уровне, чем на остальных. Решение — переделать внешний вид врагов, чтобы игрокам было ясно, что они отличаются от тех, которые на остальных уровнях. Значит уже надо делать новую модель. Допустим, сделали. И даже оказалось, моделлер сделал модель так круто, что тестеры начали интересоваться — а почему эти клёвые чувачки появляются только на одном единственном уровне. Разработчикам приходится придумывать объяснение. Получаются уже правки в сюжете игры. И так далее.
Насколько далеко могут зайти подобные изменения — никогда заранее неизвестно. Достаточно лишь сказать, что изначально Diablo была пошаговой, а Quake планировался как action/RPG. И, разумеется, на все изменения — на то чтобы придумать решение возникшей проблемы и реализовать его, необходимо время. А когда в самый последний момент выясняется, что какая-то фича работает не так как надо, то не остаётся ничего иного, как запереть программистов на пару суток в офисе, чтобы всё исправить. Да, и такое реально было.
Плохое руководство — третью причину срыва графика разработки разработчики в интервью о кранче упоминают так часто, что можно подумать, будто это самая главная и самая масштабная проблема. И надо сказать, что у подобного мнения есть основания. Однако надо понимать, о чём именно здесь идёт речь. Ведь руководство — это обычно организация работ, выдача заданий, налаживание коммуникации между отделами. В уже упомянутой разработке XCOM-шутера руководители не решили во время проблему связи между двумя командами, находящимися в двух концах земного шара, и в результате разработка затянулась из-за многочисленных задержек. Но на самом деле, когда разработчики говорят о плохом руководстве, то имеют в виду другую проблему.
В ходе разработки игры 1313 её видение у команды несколько раз менялось. На одном из этапов было решено, что местом действия её будут нижние уровни планеты Коросант (из вселенной Звёздных Войн, если кто не в курсе), а героем станет рядовой «охотник за головами». И вот люди работают над дизайном игры, придумывают сюжет, создают персонажей, уровни, прорабатывают геймплей, уже что-то даже готово... Вдруг заявляется Джордж Лукас и говорит — «А теперь главным героем игры будет Бобба Фетт!». И шок разработчиков от этого заявления нельзя описать цензурными словами. Вы ведь понимаете, что далеко не все сюжетные ходы и взаимоотношения с персонажами, которые годятся для некоего неизвестного наёмника (который по сути - «чистый лист»), подходят Фетту. А если учесть вышеописанную причину №2, представляете какой объём переделок влечёт за собой подобное решение?! А сколько наработок, в которые сценаристы и художники вкладывали душу в результате отправляются в мусорку!
Конечно этот пример можно списать на общую хреновость ситуации с LucaxArts. Можно было бы. Если бы аналогичные ситуации не возникали сплошь и рядом. И в ААА-студиях (в особенности в них), и в начинающих командах новичков встречаются руководители, которые стремятся по тем или иным причинам внести изменения в проект, не задумываясь о том, какие сложности при этом могут возникнуть. «В моде регенерация здоровья? — Добавляем, и не важно, что у нас стелс, где это не нужно.» «Сейчас популярно аниме? — Срочно скажите моделлеру, чтобы сделал глаза персонажам побольше!», «Игрокам понравился Ведьмак? — Значит добавляем в игру чудовищ, эльфов и много сисек. — Что? Говорите в Ведьмаке главное не это?! — Мне лучше знать! Я руководитель, а вы заткнитесь и делайте RPG с сиськами, хотя мы вначале планировали делать квест.»
Кто виноват и что делать
Основная мысль, которую высказывали практически все, у кого брали интервью авторы прочитанных мной статей, заключалась в том, что сделать ничего нельзя. Вообще.
Если игра инновационна, то (по словам Уоррена Спектора, например) в принципе нельзя просчитать и учесть все возможные накладки. Если же, наоборот, люди делают обычный клон популярной игры для срубания бабла, то руководители такой команды явно не будут церемониться, если для поднятия популярности и прибыли на пару процентов надо будет напрячь разработчиков на пару недель сверхурочной работы (
Но есть один нюанс, из-за которого разработчики в одних командах относятся к практике кранча не так негативно, как в других. Если команда небольшая, а руководитель действительно ценит работу своих подчинённых и старается сделать всё от него зависящее чтобы избежать кризиса (а если всё-таки надо что-то переделать, то убедит каждого, что это необходимо) — то всем видно, ради чего собственно они так надрываются. А вот если человеку просто говорят, что он должен работать сверхурочно просто потому что так решили наверху — это воспринимается уже совсем по-другому.