Ознакомительная версия. Доступно 26 страниц из 130
по окончании майлстоуна, чтобы обсудить проект друг с другом. Проведя внутренние обзоры, команда эффективнее достигает согласия и понимания в отношении того, что хорошо работает в игре и в процессе разработки, а какие проблемы им еще необходимо решить. Каждый отдельный член команды или группа смогут также лучше понять взгляды своих товарищей на игру.
Если команда слишком велика, чтобы проводить внутренние обзоры со всеми присутствующими, проведите несколько встреч по отдельным направлениям (арт-группа, инженерная группа и т. д.) А также с междисциплинарными группами, состоящими из представителей каждой дисциплины. Глубокая специализация в определенной дисциплине и совместное, синергетическое мышление очень ценны на каждом майлстоуне.
Проведение обзора майлстоуна
Проведение обзора майлстоуна требует некоторой подготовки от команды разработчиков и, в частности, от их руководства. Если проект хорошо продвигается, работа, проделанная для достижения каждого майлстоуна, непринужденно согласуется с работой, необходимой для проведения обзора. От людей, которые представят работу на обзор, потребуется кое-что сделать дополнительно, однако не так много.
Начать подготовку к обзору майлстоуна можно с выделения на него некоторого времени. Обзор короткой игры может занять всего пятнадцать – двадцать минут. А обзор большой игры – целый день или дольше. Выберите удобный конференц-зал или аудиторию с хорошей видео- и аудиоаппаратурой и запаситесь водой – будет много разговоров, и во рту пересохнет. Затем команде разработчиков (или их руководителям) надо подготовиться к презентации своей работы – что именно нужно подготовить, мы сейчас обсудим.
Затем должна быть собрана группа для рассмотрения проекта. Эта обзорная группа даст советы о том, что работает, а что нет в намеченном дизайне игры. В игровой индустрии эта группа зачастую полностью состоит из заинтересованных сторон проекта, людей, которые вкладывают деньги в создание игры. Мы рассмотрим это более подробно в разделе «Представление проекта заинтересованным сторонам».
Обычно также присутствуют руководители студии, другие члены руководства и разработчики студии. Также могут быть привлечены люди из-за пределов студии – совет директоров или консультанты. Процесс обзора идет куда лучше, если люди, рецензирующие игру, сами являются разработчиками и знают все тонкости процесса создания игр. На учебных курсах, где разрабатывается несколько игр, однокурсники, инструктор и студенты-ассистенты станут отличными членами обзорной группы.
Когда наступит дата и время проведения обзора майлстоуна и все соберутся, начнется обзорный процесс. Типичное собрание по обзору майлстоуна проходит примерно так.
1. Разработчики кратко представляют свою игру и подводят итог того, на каком этапе проекта они сейчас находятся.
2. Представляется демоверсия игры или ее плейтест перед обзорной группой.
3. Процесс комментирования начинает старший член обзорной группы.
4. Затем подключаются другие члены обзорной группы и делятся своими мнениями. Между ними может завязаться оживленная беседа.
5. Когда время, отведенное для обзора, истекает, разработчики игры благодарят группу за отзывы.
6. В случае, когда рассматривается сразу несколько проектов, например на ежеквартальной деловой встрече или занятии по разработке игр, мы переходим к следующему проекту.
Давайте внимательнее рассмотрим этот процесс.
1. Разработчики кратко представляют свою игру и подводят итог того, на каком этапе проекта они сейчас находятся.
1. Команда, как правило, представляет свою игру в виде презентации.
2. Представьте проект под его текущим названием. Если это только рабочее название, сообщите об этом.
3. Члены команды описывают, кого они считают аудиторией игры. Можно использовать простое позиционирующее утверждение, с которым мы работали в главе 7: «Возможная аудитория нашей игры – это…»
4. Команда кратко описывает текущее состояние проекта. Они могут описать важную часть работы, которая была недавно завершена, или тот контент, который они готовы представить уже сейчас. Если команда достигла майлстоуна или превысила его требования, об этом сообщают. Если команда не достигла майлстоуна, говорят, чего не хватает.
5. Следует описать все известные проблемы с игрой, включая те серьезные проблемы, которые бросятся обзорной группе в глаза. В зависимости от характера проблемы обзорная группа решит, давать рекомендации или не тратить время на уже известную проблему.
6. При необходимости члены команды сообщают, какую обратную связь они хотели бы получить.
7. Эта начальная часть обзора, посвященная презентации, должна быть как можно короче – мы хотим начать знакомство с игрой как можно быстрее.
2. Представляется демоверсия игры или ее плейтест перед обзорной группой.
1. В зависимости от игры и ее состояния, команда либо покажет игру, поиграв в нее самостоятельно, либо попросит плейтестера сыграть в нее перед группой рецензентов.
2. Часто лучше демонстрировать игру, когда она находится в относительно раннем состоянии, с уже известными проблемами, о которые будут спотыкаться новые игроки. Также лучше продемонстрировать игру, когда есть уже много контента, с которым захочет ознакомиться обзорная группа.
3. Иногда в игре могут быть неожиданные повороты или финал, которые команда не захочет раскрывать, опасаясь «испортить» впечатление. В то время как конечная аудитория игроков должна быть защищена от спойлеров, обзорной группе нужно быть полностью в курсе структуры игры: они смогут помочь, проанализировав увиденное.
4. При первом просмотре игры обзорная группа может принять решение воздержаться от комментариев до конца демонстрации. Однако, лучше ознакомившись с конкретной игрой в ходе подобных встреч, члены обзорной группы могут начать давать свои комментарии «вживую», во время плейтеста.
5. Такое живое комментирование одним типам игр подходит лучше, чем другим. Если живые комментарии влияют на то, как другие члены обзорной группы воспринимают игру – например, в особенно напряженной или эмоциональной сцене, – лучше воздержаться от комментариев до конца показа.
3. Процесс комментирования начинает старший член обзорной группы.
1. В студии первым дает комментарии старший из присутствующих, не являющийся членом команды разработчиков, – президент студии или дизайн-директор. В учебной аудитории первым может начать преподаватель. Это поможет
Ознакомительная версия. Доступно 26 страниц из 130
