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

Итак, поехали!

Небольшой экскурс в историю. Когда начались IT-разработки, на заре программирования, планирование использовалось водопадное. Так планировали в обычном бизнесе, в обычных проектах, которые не требовали программирования. Вполне логично, что этот подход применяли и в разработке софта, что приводило к многочисленным кризисах, банкротствам и провалам (почему — станет позже). Затем Барри Бим (о нем можно почитать тут) разработал новую, необычную «спиральную систему», которую вы видите выше (прочитать о ней на английском можно тут).

Она кардинально меняла подход к разработке софта и заключалась в том, что последовательное и линейное планирование (водопадное) заменялось на итеративное, где каждый виток спирали — это итерация. В первой спирали определялась концепция будущего продукта, организационные вопросы, составлялся список ключевых требований  ивыявлялись риски разработки, после чего создавался прототип. Затем начиналась вторая спираль, в которой анализировался прототип и ответы, проверялись риски, вносились коррекции и создавался следующий прототип — и так далее, пока не получен удовлетворительный результат, наилучшим способом минимизирующий все выявленные ранее риски (подробно об этом будет позже). Ничего не напоминает? Правильно, это напоминает agile scrum и итеративную разработку.

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

Что надо делать с рисками

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

Как их выявлять

Собраться всей командой на планирование по рискам. Это может быть даже мозговой штурм; задача — понять все узкие места проекта. Можно поделить проект на части: жанр, код, арт, сообщество, функционал, юзабилити, сюжет, геймплей (если это игра) и прочее. Можно каждую эту часть поделить на подчасти, например код на сервер, клиент, верстку. Арт на стиль, сеттинг (если это игра), моделинг, текстурирование (если это 3D), восприятие целевой аудиторией. Например, задача — сделать многопользовательскую космическую игру с видом верху, стрельбой в реальном времени и реалистичной физикой. Следует задать например такие вопросы: какие тут есть узкие места? Сколько будет одновременно игроков в одной локации, десять или тысяча (кстати, этот вопрос сразу же и ответ на то, зачем документировать архитектуру и дизайн до начала разработки — чтобы на этапе оценки рисков точно знать, что нужно получить в итоге)? Если будет 1000 человек в нужной локации, то как они поместятся на экране? Сколько будет передаваться информации и справятся ли современные интернет-каналы с нагрузкой? Справится ли сервер с нагрузкой? Справится ли физика на сервере, если все будут одновременно стрелять? Вопросов будет много, но нужно отличать те, которые серьезные и могут отразиться на успешности/провальности разработки от минорных. Все важные, ключевые вопросы должны составить небольшой список (большим он не будет, потому что серьезных рисков, которые могут завалить весь проект, на самом деле не так много).

Есть такая поговорка: знать врага — наполовину победить. Или как-то так. Но чем может помочь знание рисков? Просто для того, чтобы избежать проблем в будущем, чтобы работать аккуратно? Конечно нет. Чтобы обдумать, как из избежать или минимизировать? Частично, но не это главное. И вот мы приходим к самому главному в этой статье: как правильно прототипировать.

Грудью на амбразуру

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

Прототип — начинающий убийца

Вторым неприятным моментом прототипирования без предварительного анализа рисков будет то, что он будет разрабатываться сразу же для многих областей: и графики, и серверной нагрузки, и юзабилити, и геймплея, и еще кучи всего другого. То есть он будет отвечать сразу же на много вопросов… и делаться долго. Конкретные сроки зависят от задуманного проекта, но бывают прототипы, которые делаются и по полгода-году. Чем это чревато? Тем, что через полгода разработчик узнает, что игровой процесс не работает потому, что сервер не справляется с нагрузкой. Прототип ответил на вопрос и выполнил свою цель, но прошло уже полгода и надо что-то делать. Далее либо прототип становится убийцей из предыдущей статьи, либо он выбрасывается и начинается работа над альфой (или следующим прототипом). А что случится, если в следующий раз (еще через полгода) окажется, что геймплей и сервер работают хорошо, но движок не тянет графику?  Нужно будет переделывать графику. А потом окажется, что, наполнив мир тысячей астероидов, физика не справляется (а весь геймплей на ней построен). И так может происходить до бесконечности (а точнее, пока инвестору не надоест выкидывать деньги в бездонную трубу). Так что же делать?

Микропрототипирование

Давайте вернемся к списку рисков. Каждый риск — это вопрос, на который прототип должен дать ответ. Для того, чтобы получить нужные ответы, не надо тратить по полгода на что-то сложное; достаточно сделать прототип, решающий только какую-то одну задачу, дающий только один ответ. Например, на вопрос «что будет, если в локации будет 1000 игроков?» можно сделать локацию, наводненную тысячей кубиков, равных по размеру кораблям и просто летают по каким-то примитивным траекториям. Сразу же станет видно, будут ли они толкаться, помещаются ли они в сцену и если нет, то сколько влезает; как можно максимально отодвигать камеру, насколько можно ее приближать и так далее. Если вы видите, что когда в кадре пятьдесят кораблей, и они начинают толкаться, между ними не пролететь, то можно вовремя скорректировать геймплей. После этого прототип можно выбросить, или же частично использовать его для проверки, например, возможностей движка, заменив кубики на рандомные модельки, количество полигонов и текстуры которых примерно равны будущим кораблям.

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

Итеративное прототипирование

Возвращаясь к спирали Барри Бима, аджайлу и итерациям, а также к тому, зачем и почему они нужны. Каждая итерация — это прототип; каждое ее завершение — это ретроспектива, на которой анализируются результаты, полученные при помощи прототипа. Можно ли помещать 1к игроков в одну локацию, если они все будут стрелять? Если нет, то почему и что делать? Может быть, сделать зоны видимости определенного радиуса, и тогда нагрузка на трафик снизится в Х раз? Или может быть замедлить стрельбу, сделать ее более редкой но более сильной? Может быть сделать 90% пуль — лучами, которые в Y раз менее нагрузочны, чем летящие по физике пули? Тут может быть очень много решений но для того, чтобы их принять, нужно знать проблему. И лучше знать ее заранее. Ведь если вы будете писать игру год, и только по прошествии которого вдруг узнаете, что физика и трафик не справляются, вам придется переделывать фундаментальный геймплей. А на нем, вполне возможно, построено вообще все остальное: модели и текстуры, квесты, локации и все это, вероятно, тоже придется переделывать просто потому, что изначально не было сделано нужное исследование.

Резюме этого подпункта: каждый прототип должен отвечать на конкретный вопрос, желательно — один (иначе он может превратиться в убийцу). Не страшно, если прототип сделан быстро, криво и грязно — важно, чтобы он отвечал на вопрос, ради которого он делается. Кроме того, очень важным моментом является умение вовремя остановиться: именно тогда, когда получен ответ на поставленный перед началом создания прототипа вопрос. Ни до, ни после, а сразу же, как получен ответ. Если с этим есть сложности, перед началом итерации распечатайте вопрос большими буквами и повесьте на стену, а на скрамах (если вы их проводите) спрашивайте, получен ли ответ на поставленный вопрос.

Прототип на выброс

Очень важно уметь выбрасывать прототипы. Сделал — выкинул. Очень важно, в который раз повторю, не превращать быстрые прототипы в альфу; не давать им разрастаться (не давать им становиться убийцами). Если вы делаете альфу, то у вас уже должны быть все ответы на все предыдущие вопросы и должно быть понимание, что вы делаете альфу, а не прототип (и способы, подходящие для прототипирования, тут уже могут не подходить и быть вредоносными).

Это не значит, что надо выбрасывать все, что вы сделали. Что-то из прототипов наверняка будет полезно в работе над альфой: небольшие кусочки чистого кода, алгоритмы, функционал (геймплеи). Реже и почти никогда — графика, модели, арт, звуки.

Кстати есть одно замечание, сделанное, по-моему, Фредом Бруксом: «Чем менее опытна команда, тем сложнее ей выбросить прототип потому, что им кажется, что они провалили разработку» .

Документирование

Как справедливо было замечено к предыдущей статье, очень важно фиксировать в документации изменения в разработке и архитектуре. Я ни в коем случае не соглашусь, что до начала прототипирования не нужна документация и она возникнет по ходу создания прототипов. Документация нужна, потому что она формирует цели и ставит границы, в пределах которых вы будете двигаться. Это — рельсы для поезда разработки, наличие которых нужно изначально. И это не значит, что на этих рельсах не может возникнуть ответвлений, стрелок и прочих изменений маршрута: они должны возникнуть. Но отправная точка в виде базовой архитектуры должна быть, и именно ее будут проверять (и корректировать) микропрототипы.

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

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

Момент, когда нужно завершать прототипирование, наступает тогда, когда на все поставленные на самом первом планировании (планировании рисков) вопросы получены конкретные ответы, задокументированы и найдены методы решения этих проблем. Что делать дальше?

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

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

Что еще может пригодиться? Трезвая оценка сроков (вытекает из планирования), соответствующие бюджеты. Может быть для вашей игры (или продукта) потребуется подготовка еще чего-то — арта, моделей, музыки, интерфейсов. Тут все индивидуально. Может быть потребуется бизнес-модель для привлечения инвестиций — в этом случае то, что проведено исследование, снижены риски и вы обладаете нужной информацией вам может очень сильно помочь.

Вот и все, удачного прототипирования!

Источник: http://www.gamedis.ru/