Креативность по графику

Статья написана для журнала Casual Connect Magazine (Minna Magazine), подготовленного ассоциацией Casual Games Association. Текст любезно предоставлен ассоциацией.

За помощь в размещении статьи благодарим компанию CTXM.

Дженифер Буллард (Jennifer Bullard)
В игровой индустрии с 1998 года. Поработала в QA, занималась дизайном и продюсированием игр, в настоящее время занимает пост старшего продюсера в Aspyr Media, где под ее началом трудится команда из 25 разработчиков. Aspyr Media является разработчиком и издателем игр, и в портфолио компании имеется более 40 успешных проектов.

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

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

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

Расчет времени

Это очень хорошо - начинать новый проект с составления обдуманного и взвешенного плана действий, расписанного в том числе и по времени. Однако проблема заключается в том, что даже кажущийся на первый взгляд продуманным план со всеми временными рамками неожиданно может оказаться очень неопределенным. Ведь даже такие общепринятые термины, как месяц или день, могут оказаться не столь уж определенными. Сколько дней в месяце? 30? Совсем нет, в месяце может быть от 19 до 22 рабочих дней. А рабочая неделя - это всего 5 дней, и это в том случае, если на неделе нет никаких праздников.

Именно поэтому я считаю, что с самого начала лучше рассчитывать время по тому, как оно на самом деле "расходуется". Наиболее правильным подходом я считаю использование в качестве основной единицы измерения времени, необходимого для выполнения той или иной задачи, часы. К примеру, если кто-то говорит вам, что для выполнения данной задачи ему потребуется два дня, запишите их как 16 часов. Подумайте о том, что в восьмичасовом рабочем дне на самом деле около шести часов тратятся на работу как таковую, остальное время может расходоваться на встречи, кофе, путешествия по Internet или еще что-то такое. Это значит, что если программист говорит, что справится с работой за два дня, то скорее всего у него уйдет на нее 2.75 дня, почти 3.

Точно так же можно использовать недели вместо месяцев, когда речь заходит об установлении сроков для промежуточных результатов разработки (майлстоунов, milestone). Если вы работаете над проектом по заказу издателя с соответствующим "поэтапным" финансированием, тогда некоторые из "отчетных периодов" будут длиною в 4 недели, некоторые - в пять. Часто может оказаться полезным не считать пятую неделю как полноценную рабочую неделю - ее можно использовать для того, чтобы дать людям немного отдохнуть и разобраться с мелкими деталями. В среднем вы можете рассчитывать на три-четыре таких "бонусных" недели в году, и они могут оказаться очень кстати, если программа разработки довольно плотная и жесткая, а дизайн-документы очень объемные.

Шаг первый: помните о выходных

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

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

Шаг второй: планирование майлстоунов

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

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

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

От беты к голд-мастеру. В Electronic Arts, например, "бета" означает, что команда разработчиков уверена в том, что игра закончена и готова к тиражированию. Я бы рекомендовала после создания бета-версии сделать двухнедельную паузу, и потом только отправлять игру "на золото". В течение этих двух недель игра подвергается жесткому тестированию, хотя никаких доработок и исправлений ошибок и не планируется. Эти две недели надо рассматривать как возможность дополировать игру окончательно.

От альфы к бете. В Electronic Arts "альфа" означает, что весь внутриигровой контент уже имеется, все "фичи" уже реализованы, и человек может играть в получившуюся альфа-версию без особых проблем и частых "вылетов". Конечно, и ошибки, и "вылеты" будут случаться, но в общем и целом есть вполне играбельный продукт. В зависимости от проекта этот период времени может длиться от 4 до 12 недель.

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

  1. какие из реализованных возможностей игры не нужны и/или не работают, и их надо убирать
  2. какие дополнительные "фичи" надо ввести в продукт для того, чтобы разобраться с возникшими по ходу тестирования проблемами или просто для того, чтобы в общем сделать игру более интересной.

При этом важно определиться с тем, какие из новых возможностей действительно имеет смысл реализовывать, а от остальных надо оказаться. Если же выяснится, что игрушка переполнена багами, то лучше всего озаботится не добавлением нового контента, а исправлением ошибок и полировкой. Именно на этом этапе разработки необходимо определиться с тем, нужны ли какие-нибудь изменения в проекте для того, чтобы улучшить геймплей, или для корректировки временных рамок разработки. Период перехода от функциональной версии к "альфе" длится обычно от 4 до 8 недель - по большей части в зависимости от величины проекта.

Демо-версия. Чем раньше вы определитесь с тем, когда и кому будут предоставлены демо-версии игры, сколько их будет и как много усилий необходимо вложить в каждую из них, тем лучше. Если демки очень важны для вас как для команды разработчиков или для вашего издателя, то уделите каждой из них две недели как минимум. Если же вы делаете потенциально большой хит и показывать его будете на шоу вроде Electronic Entertainment Expo, то создайте в общем плане разработки специальный раздел и отведите от четырех до шести недель на создание и полировку демо-версии игры. Оно того стоит.

[16.03.2007]

Copyright © 2019 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение