|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Заключенные Баблвилля – Смягчение рисковРиск #1: Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется. Игровую механику можно часто представить в упрощенной форме. Пусть программист сделает абстрактную версию вашей механики, например в 2D, с простыми геометрическими фигурами вместо анимированных персонажей. Вы вполне можете получить рабочую версию игры за неделю или две и сразу же понять, интересна ли ваша механика. Если нет — вы можете изменять упрощенный прототип столько, сколько нужно, пока он не станет достаточно интересным, и уже после этого приступить к разработке 3D-версии. Вскоре вам придется проходить еще больше циклов, и если вы будете грамотно использовать Правило Цикла, то сможете получить различные преимущества. Вы можете не согласиться с этим подходом, потому что написание 2D кода для прототипа, который игрок никогда не увидит – это трата времени. Тем не менее, это позволит вам сохранить больше времени на последующих этапах, потому что вы сможете раньше приступить к написанию правильного варианта игры, а не бесконечно писать и переписывать неправильные варианты. Риск #2: Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников. Если будете ждать, пока художники закончат всю свою работу и смогут ответить на этот вопрос, вы можете попасть в весьма затруднительное положение. Если движок не справляется со своей задачей, вам нужно просить художников все переделать так, чтобы графика не перегружала движок или же просить программистов, чтобы те потратили еще больше времени на доработку движка (или, скорее всего, обе эти вещи). Чтобы смягчить риск, создайте приблизительный прототип, который может только показывать приблизительное количество графических элементов на экране, что позволит вам узнать, сможет ли движок их поддержать. В прототипе нет геймплея; он нужен исключительно для тестирования технологических лимитов. Если вы видите, что движок справится, то отлично. Если видите, что нет, то у вас есть возможность приступить к поиску решения проблемы до того, как вся графика уже готова. Опять же, это исключительно “одноразовый” прототип. Риск #3: Согласно нашему изначальному видению, для игры нам потребуется тридцать разных домов – создание большого количества различных интерьеров и анимированных персонажей может занять больше времени, чем мы предполагали. Если половина разработки закончена, а вы вдруг понимаете, что у вас недостаточно художников для того, чтобы сделать всю работу, вы обречены. С самого начала попросите художника создать один дом и одного персонажа, чтобы у вас было представление о том, сколько времени это может занять. Если это занимает больше времени, чем вы можете себе позволить, сразу же меняйте дизайн – может быть, вам и не нужно так много домов, а некоторых персонажей и интерьеры можно использовать повторно. Риск #4: Мы не уверены, что людям понравятся наши персонажи и история. Если вас это действительно волнует, то нельзя ждать, пока персонажи проявят себя уже в готовой игре. Так какой же прототип мы создаем здесь? Художественный прототип – для этого можно обойтись и без компьютера – просто доска для объявлений. Попросите художника сделать приблизительный концепт иллюстрации к игре или провести тест-рендер ваших персонажей и настроек. Попробуйте визуально воспроизвести последовательность событий в вашей игре, чтобы понять, как они будут развиваться. Когда закончите, покажите это все людям (желательно, чтобы это были представители вашей ЦА) и проследите за их реакцией. Вам нужно понять, что им понравилось, что не понравилось, и почему. Возможно, они в восторге от внешнего вида главного героя, но его поведение в игре им не по душе. Может быть, вы хорошо раскрыли образ злодея, а вот история получилась скучной. Это все можно легко узнать и без самой игры. Каждый раз, когда вы это делаете, вы проходите очередной цикл, то есть делаете еще один шаг вперед к вашей идеальной игре. Риск #5: Вполне возможно, что выйдет какой-то фильм о парашютных трюках, и издатель захочет, чтобы наша игра была на тему этого фильма. Возможно, этот риск звучит абсурдно, но подобные вещи происходят постоянно. Если это случается в середине проекта, это катастрофа. И подобные вещи нельзя игнорировать – нужно учитывать каждый риск, который может поставить ваш проект под угрозу. Поможет ли в этом случае прототип? Скорее всего, нет. Смягчить этот риск вам поможет либо эффективный менеджмент, либо специфический дизайн вашей игры, тематику которого можно легко изменять, если возникла такая необходимость. Можно даже включить в план создание двух разных игр - основная идея в том, чтобы моментально реагировать на риски и принимать меры по предотвращению угрозы для вашего проекта. Оценка и смягчение рисков – это очень полезный подход, а также Линза #14.
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |