Читать книгу - "Как делать хорошие игры. От идеи до запуска - Петр Прохоренко"

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

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

1. Состояние команды (то есть ее текущий КПД).

2. Системность подхода и предварительная подготовка.

3. Ресурсы на тестирование.

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

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

В моей практике добавление в проект «свежей крови» на этапах перед релизом или сразу после обычно оказывало очень хорошее влияние на динамику выполнения задач.

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

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

Баг-репорт (bug report) представляет собой технический документ, в котором указывается информация об ошибке в работе программного обеспечения. Его заполнением занимается тестировщик. Затем документ отправляется разработчикам, чтобы они исправили имеющиеся недочеты.

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

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

Системная работа с качеством контента начинается с системы его приемки. Звучит страшно, но на самом деле все упирается в структуризацию потоков производимого контента и квалификацию лиц, принимающих по нему решения. В моем случае не очень показательный кейс в том, что я могу объединять в себе эти роли (на других проектах настраивать систему и принимать контент будут, скорее всего, разные люди). У меня искусствоведческое образование, я сам имею богатый опыт классического рисунка и в целом могу говорить с художниками на их языке. Это в итоге привело к тому, что я сам занимаюсь арт-дирекшеном своих проектов до тех пор, пока не появляется возможность нанять профильных специалистов. Но и после этого я обычно не отпускаю вожжи, проверяя весь создаваемый контент.

Как сделать хорошую игру, Способ № 29: проверяйте лично весь контент, который вы можете квалифицированно оценить. Тут не может быть компромиссов, и это точно не то направление, где можно делегировать. Принцип простой: разбираетесь в чем-то (коде, арте, нарративе, продвижении) – проверяйте все, что делает данный отдел, ЛИЧНО. Опять же, проверять – это не значит парализовать работу отдела своим вторжением в работу линейных специалистов (возвращаемся в главу, где были описаны смертные грехи управленца).

Вот как была построена система приемки визуального контента на платформе интерактивных новелл Series. По разным направлениям (арт, игровой дизайн, спецэффекты, анимации) существовали закрытые чаты, там присутствовали руководители по направлениям, руководитель проекта и генеральный продюсер. В чат выкладывается либо эскиз для утверждения, либо уже близкий к финалу результат. Мы или выбираем голосованием из предложенных вариантов, либо обсуждаем корректировки (обычно они не по качеству – команды в целом высокого уровня, – а по конкретным моментам типа цвета, соответствия драматургии и так далее). Раз в неделю один из менеджеров проекта выкладывает весь сделанный за отчетный период арт на специальную доску, где я его отсматриваю отдельно. Таким образом весь производимый контент проходит приемку, проверку и утверждение. Ситуации, когда ребята что-то забыли, и я увидел одного из сотен персонажей впервые лишь в собранной версии Series, были крайне редки.

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

С качеством контента я тогда работать совсем не умел, и оно было у меня только одной категории – первой. Получив от аутсорсеров тестовые версии юнитов, я поехал к ним в офис и прямо там тыкал каждого художника в чертежи танков, цветовые образцы камуфляжей и прочую специальную литературу. Напуганные моим военно-историческим напором художники дрожали и норовили спрятаться под