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

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

Особенностью этого проекта было то, что он был построен на движке Enigma от Nival (на этой же технологической базе был сделан и первый «Блицкриг») и являлся, говоря строго, не полноценным продуктом, а «тотальной конверсией» (разновидность игровых модов, при который вся «родительская» игра визуально изменяется и камуфлируется так, что получившийся результат лишь отдаленно на нее похож). Разработка «Сталинграда» шла прямо в поставляемом с «Блицкригом» редакторе, и поначалу никаких технических изменений команда не вносила, потому что даже не имела для этого программистов. Единственный случай технических работ на проекте «Сталинград» был связан с судьбоносными «двумя неделями программиста», которые достались мне от щедрот между большими апдейтами сайта для игровой индустрии The Daily Telefrag (не путать с современным сайтом DTF). Нужно сказать, что распорядился я этой «серебряной пулей» просто феерически удачно, но узнал об этой своей удаче лишь много лет спустя. Дело в том, что меня всегда бесила «фича» простреливаемости зданий в «Блицкриге» – это не давало создать классные танковые дуэли, когда танки выезжают из-за угла, стреляют и затем задним ходом пятятся (как игрок в серию Close Combat я очень уважаю такую тактику). Ну и я дал задачу нашему единственному программисту это дело исправить, а он взял и исправил всего за две отведенные недели. Поскольку движок «Блицкрига» был не в «полном 3D» (ландшафт карт был трехмерный, но на нем стояли плоские спрайты зданий и объектов), мы привязались к условной «площади зданий», задаваемой в редакторе спрайтов, и таким образом получили желаемую вещественность и непрозрачность для снарядов крупных объектов. Эта фича была запакована в файлик с алгоритмами поведения искусственного интеллекта юнитов для игры, и достаточно быстро о ней узнали мододелы. А затем именно этот «сталинградский» файл был использован в десятках модов, созданных за годы огромным сообществом поклонников франшизы. Всем хотелось иметь у себя эту фичу, а для этого надо было раздобыть заветный файлик, а значит – приобрести «Сталинград». Так игра почти случайно стала популярна в комьюнити «Блицкрига» на много лет вперед.

Как сделать хорошую игру, Способ № 22: И все-таки скажите «нет» фичакрипу. Точка. Отправьте его в wish-list, адд-он, сиквел. В общем, куда подальше. Почти всегда бесконтрольное раздувание функциональности – это то, что гарантированно ухудшит вашу игру.

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

Говоря проще, как проконтролировать, что все делается правильно?

На самом деле у вас есть не так уж и много направлений, с которых вы можете приступить к этой задаче. Перечислим основные:

• система отчетности (принимающие решения управленцы должны быть своевременно проинформированы обо всех важных процессах, идущих в проекте);

• работа с коллективом (собрания, прозрачность команд, one-on-one и т. д.);

• личные усилия (регулярный мониторинг производящегося контента, будь то арт или код);

• ротации проектного персонала (практика, которая часто незаслуженно забывается, суть в том, что приходящие на проект новые люди часто вскрывают старые проблемы).

Когда говорят об изменениях игровых проектов, часто используют термин «пивот», означающий следующее:

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

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

Здесь опять можно привести морскую аналогию: типовой стартап – это драккар викингов, который из-за гибкости своего корпуса может выдержать морские волны и привести небольшую сплоченную команду стартапа к богатым берегам. А большой игровой проект – это океанский лайнер (ну ладно, будем реалистами, обычно это частный пароходик-лесовоз), ему достаточно сложно разворачиваться, и он конструктивно не приспособлен для ударов волной в борт – его просто перевернет. Часто именно это и случается, и, когда руководитель довольно сообщает коллегам по индустрии «мы сделали пивот и формируем новый план разработки, сроки сдвинутся на год», за этим стоит безрадостная картина: перевернутое или севшее на мель судно и команда, уныло бродящая по берегу и собирающая остатки груза. Запустить процесс «пивота» всегда можно, но если руководство само не контролирует этот процесс, то всегда рискует получить полную остановку производства и все сопутствующие с этим системные проблемы.

Я не помню ни одного примера, когда попытка разрабатывать игры по «технологии стартапов» приводила к хорошим результатам. В самом неприятном случае в результате выглядящих (на первый взгляд) не очень радикальными изменений была выброшена полуторалетняя работа команды из 50-ти человек. Контент на целый игровой проект А-класса просто исчез!

А что же нужно в таком случае делать?

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

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

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