Баг-репорт (bug report) представляет собой технический документ, в котором указывается информация об ошибке в работе программного обеспечения. Его заполнением занимается тестировщик. Затем документ отправляется разработчикам, чтобы они исправили имеющиеся недочеты.
Да, большая часть внешних репортов будет не валидна вследствие того, что внешние тестеры еще плохо знакомы с продуктом. Но даже такие ошибки требуют от гейм-дизайнеров ответов (а давая ответы, они лучше понимают структуру своей игры и иногда выходят на новые ошибки, пропущенные тестерами), от программистов – реакции, от художников – исправления мелких недоработок. В общем и целом, вся команда начинает шевелиться немного быстрее.
Разбавим общую теоретическую часть несколькими примерами. В предыдущем абзаце я не зря упомянул о том, что при правильно организованной разработке серьезных сложностей на этапе выхода игры не будет. Прозвучит вульгарно, но «нормально делай – нормально будет» или, другими словами, если качеством игрового контента озаботиться сильно раньше релиза, то каких-то особых подвигов, может быть, и не понадобится.
Системная работа с качеством контента начинается с системы его приемки. Звучит страшно, но на самом деле все упирается в структуризацию потоков производимого контента и квалификацию лиц, принимающих по нему решения. В моем случае не очень показательный кейс в том, что я могу объединять в себе эти роли (на других проектах настраивать систему и принимать контент будут, скорее всего, разные люди). У меня искусствоведческое образование, я сам имею богатый опыт классического рисунка и в целом могу говорить с художниками на их языке. Это в итоге привело к тому, что я сам занимаюсь арт-дирекшеном своих проектов до тех пор, пока не появляется возможность нанять профильных специалистов. Но и после этого я обычно не отпускаю вожжи, проверяя весь создаваемый контент.
Как сделать хорошую игру, Способ № 29: проверяйте лично весь контент, который вы можете квалифицированно оценить. Тут не может быть компромиссов, и это точно не то направление, где можно делегировать. Принцип простой: разбираетесь в чем-то (коде, арте, нарративе, продвижении) – проверяйте все, что делает данный отдел, ЛИЧНО. Опять же, проверять – это не значит парализовать работу отдела своим вторжением в работу линейных специалистов (возвращаемся в главу, где были описаны смертные грехи управленца).
Вот как была построена система приемки визуального контента на платформе интерактивных новелл Series. По разным направлениям (арт, игровой дизайн, спецэффекты, анимации) существовали закрытые чаты, там присутствовали руководители по направлениям, руководитель проекта и генеральный продюсер. В чат выкладывается либо эскиз для утверждения, либо уже близкий к финалу результат. Мы или выбираем голосованием из предложенных вариантов, либо обсуждаем корректировки (обычно они не по качеству – команды в целом высокого уровня, – а по конкретным моментам типа цвета, соответствия драматургии и так далее). Раз в неделю один из менеджеров проекта выкладывает весь сделанный за отчетный период арт на специальную доску, где я его отсматриваю отдельно. Таким образом весь производимый контент проходит приемку, проверку и утверждение. Ситуации, когда ребята что-то забыли, и я увидел одного из сотен персонажей впервые лишь в собранной версии Series, были крайне редки.
Ключевой момент в этой системе – все контролировать, но при этом не мешать работать отделам и решать возникающие проблемы минимально затрагивающими линейных специалистов способами. Впрочем, пришел к такому неинвазивному методу я далеко не сразу, поэтому расскажу еще одну забавную историю аж из времени разработки «Сталинграда».
С качеством контента я тогда работать совсем не умел, и оно было у меня только одной категории – первой. Получив от аутсорсеров тестовые версии юнитов, я поехал к ним в офис и прямо там тыкал каждого художника в чертежи танков, цветовые образцы камуфляжей и прочую специальную литературу. Напуганные моим военно-историческим напором художники дрожали и норовили спрятаться под стол. Немецкую зенитку Flak-88 я принимал восемнадцать (восемнадцать!) раз – она все время не попадала в немецкий цвет «фельдграу». Возражений, что она занимает на экране три с половинкой пикселя, я не принимал – это были неправильные розовые пиксели, а мне были нужны аутентичные. В конце концов перед нами извинились и заменили художника, оказалось, что у него легкий дальтонизм и эту пушку он видит слегка розовой, а не по-германски серо-фиолетовой. Возможно, благодаря такому подходу (в том числе) «Сталинград» удался, но все-таки, оглядываясь назад, хочу заметить, что, если есть возможность управлять качеством без таких эксцессов – лучше это сделать.
Пользуясь случаем, расскажу тут немного о том, как же ловко и с пользой для бюджета манипулировать качеством контента в игровых проектах. Итак, качество игровых ассетов, конечно, имеет первостепенную важность, но его, что называется, надо уметь готовить. Мне до сих пор приходится периодически повторять одну банальность – безграничное качество возможно только за безграничный бюджет и в безграничные сроки. Так что все, что мы производим, есть искусство возможного и плоды с дерева компромиссов, которое регулярно поливается кровью ретивых арт-директоров. Но как при этом выдержать марку и не навалить в штанцы пользователю кучу негодного арта? На этот случай есть у нас один приемчик, стопроцентный вариант! У вашего проекта наверняка есть рыночные референсы и конкуренты, а у них есть определенный интегративный уровень качества. Ваша задача – хорошо изучить конкурентов и на входе в игру всеми силами выдержать уровень ВЫШЕ СРЕДНЕГО по рынку. Пользователь ведь оценивает игру в целом, не размениваясь на детали. Он не может, не хочет и не будет выделять каждый ваш прекрасный ассетик, рожденный кричащим в творческих муках концептером, заботливо принятый шершавыми добрыми руками моделлеров и обструганный до состояния Буратино ласковым рубанком лид-артиста. В голове у игрока двухфазный переключатель «ну чо за говно – вау как круто», и он неизбежно щелкнет в одно из этих положений уже в первые пять минут игры. Дальше сдвинуть этот переключатель будет очень сложно, там встроена инерция от бога (то есть от эволюции). Мозг уже атрибутировал поступившее ему из внешней среды новое явление и второй раз вставать со стула не намерен. Поэтому первые минуты игры – решающие, в первом ряду вашей игры должны стоять все самые-самые прекрасные арты, с начищенными до блеска пряжками и сверкающей улыбкой в три ряда зубов. Дальше и до ретеншена седьмого дня уже нужно держать определенный баланс между качеством и количеством (эмпирически 70 на 30, где большая часть – объективно хороший и годный контент). Ну а все остальное, как говорится, может быть отдано на аутсорс голым землекопам (речь, конечно, о зверушках вида Heterocephalus glaber, а не о специалистах по проведению земляных работ).
Вообще, если говорить не только об арте, то вопрос качества игровой продукции разбивается на следующие составляющие:
• аппаратная совместимость;
• производительность;
• визуальное качество;
• игровой мир;
• жанровые точки фокуса;
• качество игрового процесса.
А теперь расскажу о каждой из составляющих отдельно.
Аппаратная совместимость, или поддержка устройств, – это основа, потому что, если игра не работает на пользовательском устройстве, о каком уровне качества мы вообще говорим? Необходимо поддерживать (игра запускается и работает с приемлемой производительностью) около 75 % общего парка устройств на платформе. Необходимо выбрать «нижнюю границу» по поддерживаемым устройствам и учесть различные сложные кейсы (ситуации, когда формально устройство выше выбранной границы, но по факту из-за его технических особенностей не соответствует выбранным критериям).
Как сделать хорошую игру, Способ № 30: уровень качества контента в игровом проекте настраивается пропорционально частоте его появления и задачам удержания. Невозможно сделать всю игру на топовом уровне качества – она будет разрабатываться бесконечное время. А вот грамотно выстроить контент так, чтобы на критичном для пользователя участке удержания весь контент был топовым, – вполне реально. Проблемы качества контента – это обычно проблемы новичков, основная аудитория может смириться много с чем.
Производительность, то есть быстрота работы игры, измеряемая обычно в FPS (кадры в секунду). Необходимо опираться на минимально приемлемое значение FPS для вашего продукта (в зависимости от платформы и жанра), при котором возможна комфортная игра. Это значение необходимо получить эмпирически в результате тестирования на различных устройствах.
Визуальное качество, которое разделяется на качество динамического и статического контента. К первой категории, как можно догадаться, относится все, что движется (персонажи, монстры, эффекты). Ко второй категории весьма логичным образом относится статичный контент локаций и не анимированная двухмерная графика. Как раз о модерировании производства этого контента мы и говорили в начале главы.
Игровой мир – это уже чуть более сложная категория, потому что кроме контента в чистом виде сюда входит еще и его дизайн как ландшафтный, так и игровой, то есть локации, составляющие игровой мир. Часто встречается, что контент (модели) сделан хорошо, но это не складывается в интересный геймплей. Основные принципы, которыми можно руководствоваться при определении уровня качества:
• Тщательность проработки в сравнении с конкурентами.
• Адекватность масштаба игровому процессу – размер локаций/мира не является целью, всегда стараемся не делать «пространство без геймплея».
• Рациональность развития локаций (считаем, что добавление небольшого, обоснованного сюжетом и механиками участка локации равносильно добавлению новой локации и при этом экономически выгодно).