Читаем Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение полностью

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


В = (8 + 10) × 6 = 108 человеко-часов


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

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

Простейший план

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

Простейший план начинается со списка задач в электронной таблице, в которой мы перечислим то, что необходимо завершить на этапе продакшена. Лучший способ это сделать – перечислить объекты и персонажей, которые войдут в игру, окружение игры и все то, что мы упоминаем в таблице макродизайна. Этот список можно составить, просто скопировав все эти данные из таблицы макродизайна и вставив в другую таблицу.

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

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

Простой план для каждой задачи

Теперь, когда у нас есть список задач в таблице, мы на шаг ближе к простому плану. Нам надо добавить некоторую информацию к каждой задаче.

Добавьте в электронную таблицу еще четыре столбца, как показано на рис. 19.1. Над списком задач добавьте заголовок «Задача». В соседнем столбце напишите «Приоритет». Рядом – «Расчетное время». А затем «Ответственные члены команды».


Приоритет

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

То, что нужно игре, но что при необходимости можно сократить, будет приоритетом второго уровня

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

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

Многим гейм-дизайнерам очень трудно отнести какую-либо из своих задач не к приоритету первого уровня. Представление о будущей игре соединяется в нашем воображении с некой идеальной кристаллической целостностью – все ее части кажутся одинаково важными; ни одна из них не может существовать без других. Как мы можем присвоить какой-то задаче приоритет второго или третьего уровня?


Рис. 19.1. Начало простого плана


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

Перейти на страницу:

Похожие книги

Исторические информационные системы: теория и практика
Исторические информационные системы: теория и практика

Исторические, или историко-ориентированные, информационные системы – значимый элемент информационной среды гуманитарных наук. Его выделение связано с развитием исторической информатики и историко-ориентированного подхода, формированием информационной среды, практикой создания исторических ресурсов.Книга содержит результаты исследования теоретических и прикладных проблем создания и внедрения историко-ориентированных информационных систем. Это первое комплексное исследование по данной тематике. Одни проблемы в книге рассматриваются впервые, другие – хотя и находили ранее отражение в литературе, но не изучались специально.Издание адресовано историкам, специалистам в области цифровой истории и цифровых гуманитарных наук, а также разработчикам цифровых ресурсов, содержащих исторический контент или ориентированных на использование в исторических исследованиях и образовании.В формате PDF A4 сохранен издательский макет.

Динара Амировна Гагарина , Надежда Георгиевна Поврозник , Сергей Иванович Корниенко

Зарубежная компьютерная, околокомпьютерная литература / Учебная и научная литература / Образование и наука