Геймдизайн: как это делается, часть вторая

Страница 1 из 3

Статья написана для журнала Game.EXE. Публикуется с любезного разрешения редакции.

Гейм-дизайн: как это делается, часть первая >>

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

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

Сегодня мы пойдем дальше, попробовав узнать, как гейм-дизайнер добивается сбалансированности игры, как воплощает свои гениальные идеи в сухих цифрах, как борется за чистоту идей с коллегами, издателями, руководством и даже игроками. Кстати, неужели такая творческая работа, как дизайн игр, укладывается в жесткие рамки сроков, описывается служебными обязанностями и контролируется еженедельными отчетами? Очень интересно!

Ну а на прощание подлинные авторы нашей многотомной книги поделятся сокровенным: итогами прожитого и планами на будущее…

ГЛАВА СЕДЬМАЯ
В КОТОРОЙ КОЛЛЕКТИВНЫЙ АВТОР ПОКАЗЫВАЕТ, КАК ПОЛЕТ ДИЗАЙНЕРСКОЙ ФАНТАЗИИ СОЧЕТАЕТСЯ С ПРОИЗВОДСТВЕННЫМ ПРОЦЕССОМ. А ЧТО ПРОИСХОДИТ С ПЕРВОНАЧАЛЬНОЙ ИГРОИДЕЕЙ В ХОДЕ ЭТОГО ПРОЦЕССА? КАК ОН ВООБЩЕ ОРГАНИЗОВАН? КОГДА ПРОГРАММИСТЫ НАЧИНАЮТ ПИСАТЬ КОД? КОГДА И В КАКОЙ ОЧЕРЕДНОСТИ К ПРОЕКТУ ПОДКЛЮЧАЮТСЯ ЕГО УЧАСТНИКИ? КТО И КАК РАСПРЕДЕЛЯЕТ ЗАДАЧИ? ТОТ, КТО РАЗ ЗА РАЗОМ СВОДИТ РЕЗУЛЬТАТЫ ВОЕДИНО, - КАК ОН УДЕРЖИВАЕТ ВСЕ В ГОЛОВЕ? ЕСЛИ ОТСТУПИТЬ ОТ ПЛАНА - ЭТО НОВЫЙ ПОВОРОТ ИЛИ СХОД С РЕЛЬСОВ?..

В прежние времена авторская концепция не противоречила производству: последнее не было формализованным, идею игры целиком держали в своих головах несколько человек, не имевших коммуникационных проблем и не объединенных в иерархию, предполагающую распределение текущих задач и контроль за исполнением. Проблема оценки рисков не могла присниться никому даже в самых страшных снах. Да, Гейб Ньюэлл и тогда (Half-Life), и почти сейчас (HL2) мог жать на RESET, презревая риск и потраченные человеко-часы, - но только потому, что, как и разработчики древности, рисковал своими деньгами. Архаизм как победа Первоначального Видения над реалиями индустрии.

Которые сегодня таковы: время - дорогое, сроки - жесткие, риски - смертельные (на кону - чужие кровные). Коллективы творческих людей (каждый со своими мыслями!) ныне многочисленны, и кому-то волей-неволей пришлось стать немножко надсмотрщиком над товарищами. Продюсеры обзавелись убеждениями, игроки - предпочтениями. Конкурентов расплодилось видимо-невидимо, многие из них повадились говорить новые слова в жанрах, ставящие Идею игры в разработке под сомнение. Теперь Идея заключает алхимический брак с реальностью на загадочной стадии прототипирования, подвергается суровым испытаниям, то есть плейтестам, а иногда даже подмораживается до востребования...

Андрей "КранК" Кузьмин
Директор, KranX Productions

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

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

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

Александр Мишулин
Креативный директор, Nival Interactive

Дизайнерская идея всегда будет масштабнее реализации, хотя бы потому, что вообразить мы себе можем гораздо больше, чем сделать, по самым разным причинам. С другой стороны, для бизнеса хорошо, чтобы задуманное и продукт отличались не на порядок. Сейчас у нас это получается. Есть такой термин - feature creep, это страшный враг гейм-дизайнера. У этого монстра есть несколько форм, и самая распространенная выглядит так: "А давайте сделаем еще и...". Более сложные формы завязаны на коллектив, когда один человек что-то говорит "в воздух", второй подхватывает, третий модифицирует, идея разрастается как снежный ком и становится большой проблемой для ведущего дизайнера. Существует замечательное заклинание - Creeping Doom, вот это как раз по адресу... Понятное дело, есть feature creep от издателя, который говорит "нужно добавить еще и это", и все молодые дизайнеры (все молодые команды) страдают этим заболеванием в ужасной форме, потому что нет опыта борьбы с подобными вещами. Именно это приводит к появлению "гигантских вселенных" с двадцатью одинаково плохо сделанными "фишками". Впрочем, не без исключений. Например, есть тренд, могущий появиться в индустрии в процессе разработки игры, который придется поддержать и который уже не будет "крипом". Иногда на середине проекта возникают вещи, которые заставляют крепко задуматься, связываться с ними или нет.

Вспомним Halo. Эта игра породила новое поколение консольных шутеров, в которых у главного игрока есть быстро восстанавливающийся щит. После Halo все консольные шутеры взяли этот принцип на вооружение. Это правильная, хорошая идея, это тренд. Шутеры становятся более динамичными, игроки не должны стоять на одном месте, как это было в первом Medal of Honor - тире с переставляемыми мишенями. Повторюсь: это тренд, и если ты в него не вписался, тебе будет плохо - потому что он хорошо работает.

А есть то, что называется Next Big Shiny, Следующая Сияющая Фишка. Тот же gravity gun, который из Half-Life 2 отправился в путешествие по нескольким шутерам. На мой взгляд, это не тренд. Как пришелец, так и ушелец. В HL2 он пришелся к месту, в псионических шутерах тоже, а вот его копии... Другой вариант: дизайнеры придумывают слишком много всего, и чтобы бороться с этим, на самых ранних этапах разработки создаются документы, описывающие масштаб игры - как бюджетный (сроки и объемы требуемых ресурсов), так и геймплейный (основные игровые возможности). Понятно, что это динамический процесс, и если какую-то деталь игры реализовать не удалось, всегда можно передоговориться; но это сложный процесс, и он намеренно сделан сложным, чтобы издатель получал ту игру, которую заказывает.

Далее. Мы дошли до этапа, когда в произведенное можно играть, в объеме одной миссии. Это "альфа". И она, представьте, не играется. Бывает и такое. Чтобы избежать подобного, опытные и богатые издатели и разработчики вроде EA и Maxis сделали эдакий обратный шаг к играм, основанным на идеях. Прототипирование. Прототипирование на ранних стадиях очень полезно. Если мы заняты проектом с необычным геймплеем, его нужно смоделировать на чем угодно - на бумаге, на кубиках. Живет на кубиках - будем аккуратно его дорабатывать. Не живет - до свидания; денег и ресурсов потрачено чуть - не жалко. Не обязательно быть большой компанией, чтобы заниматься прототипированием. Большие команды могут таким образом кидать кости.

"Мы сделали двадцать прототипов. Вот эти три ничего - они пойдут дальше, будем их дорабатывать". Из трех остается один, лучший, он и получает бюджет. Если я не ошибаюсь, Уилл Райт говорил, что Spore в ее нынешнем виде выросла из 120-го прототипа.

Илья Стремовский
Гейм-дизайнер, Nival Interactive

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

Да, можно придумать все, что за эту пятилетку было выпущено во всех жанрах. Но потом ты садишься, считаешь и понимаешь, что воплотить в игре все сразу невозможно. И тогда идея начинает эволюционировать. В случае "Нивала" одна гигантская идея трансформировалась в две поменьше - "Блицкриг" и Silent Storm. Да, обе игры выросли из одной задумки и одного проекта. Потом начинается поиск издателя, который предъявляет собственные требования. Так, панцеркляйны появились в Silent Storm из-за увлечения нашего продюсера миниатюрами в сеттинге стимпанк. В момент, когда родилась эта мысль, игра предполагалась сатирической, комиксовой по духу и панцеркляйны там смотрелись органично. Затем была разработана первая версия графического стиля, и стало ясно, что мы можем и хотим двигаться в сторону большей достоверности. Этот вектор, имевший начало в графике, повлек изменения во всех остальных областях, и использование фантастических наработок пришлось ограничить последними этапами игры... И это только основные вехи, но понятно, что эволюция происходит под влиянием самых разных сил. Как внутрипроектных, так и внешних, включая выход других игр, на которые нельзя не реагировать. Начало программирования - это, конечно, пора экспериментов. Но обычно оно остается за рамками проекта, на этапах технологических демо или подготовки к производству. Самые волнующие и рискованные эксперименты в программировании должны заканчиваться с началом основных работ по проекту.

Петр "Amicus" Прохоренко
Гейм-дизайнер Lesta Studio

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

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

Начало программирования - это старт производства игры. Основные черты дизайна к этому моменту должны быть как минимум обрисованы, а как максимум - подробно задокументированы. Эксперименты будут, это 99,9-процентная вероятность для любого сложного проекта. То, что эти эксперименты будут увлекательными, совершенно не факт. На практике это довольно мучительный процесс выработки оптимальных решений для каждого нового проекта, проходящий в условиях ломки сроков, выползания игры за рамки выделенного бюджета, кранчей, овертаймов и прочих девелоперских радостей. Для сложных и больших проектов нет бюджетов, которые они не могли бы превысить, и нет планов, которые оставались бы нерушимыми. Уважаемые читатели могут самостоятельно изучить "историю успеха" любой известной отечественной игры и в скупых postmortem-строках вроде "мы встретили ряд неожиданных трудностей, поэтому пришлось потратить лишние полгода на доводку баланса" найти подтверждение моим словам.

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

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

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

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

Андрей "КранК" Кузьмин
Директор, KranX Productions

Этапы работы над проектом описаны в нашем внутреннем KranX Productions KodeX. Вряд ли открою Америку. Сначала идет фаза Генезиса, которая рождает концепты. Если совет "генетиков" дает добро, начинается препродакшен и сразу определяется основной силовой скелет будущего проекта: продюсер - гейм-дизайнер (GD) - проект-менеджер (PM). С помощью ведущих направлений (арт, технологии, сценарий) они производят прототипирование (как минимум ментальное в виде дизайн-документа) по нескольким параллельным веткам с целью минимизации рисков (это архиважно). Результаты вдумчиво оцениваются, и, если все OK, начинается собственно производство. Технологическое демо, демо играбельное, "альфа", "бета", постпродакшен. Там свои строгие законы. Майлстоуны. PM постепенно высасывает у всех участников (особенно ведущих) лишний мозг через небольшие отверстия, тщательно проделанные продюсерами. GD в это время распят на кресте изменений в проекте и непрерывно принимает муки творчества, старательно молясь.

Если его не закрепить таким образом - игра будет делаться долгие годы. В общем, PM создает ритм из лид-пакетов, а GD - натягивает амплитуду волны. Продюсер крутит ручки и мощно запитывает агрегат...

Александр Мишулин
Креативный директор, Nival Interactive

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

Петр "Amicus" Прохоренко
Гейм-дизайнер Lesta Studio

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

Андрей "КранК" Кузьмин
Директор, KranX Productions

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

Петр "Amicus" Прохоренко
Гейм-дизайнер Lesta Studio

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

Александр Мишулин
Креативный директор, Nival Interactive

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

Петр "Amicus" Прохоренко
Гейм-дизайнер Lesta Studio

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

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

Александр Мишулин
Креативный директор, Nival Interactive

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

Андрей "КранК" Кузьмин
Директор, KranX Productions

Один человек может очень многое, но не все. Потому что он не Солярис. Уверен, что десять-двадцать слаженно работающих партнеров способны сделать куда больше для эволюции мира, чем сотня наемных рабов. Игра склеивается прежде всего в голове. А потом уже в байтах и пикселях. Если наоборот - это ахтунг. Важно иметь скелет игры и постепенно облагораживать его мясом и кожей. Если скелета нет - есть риск получить кучу экскрементов.

Дмитрий Лисица
Гейм-дизайнер Primal Software

Один человек может эффективно контролировать 5- 7 подчиненных. Если кажется, что можно больше, это способно привести к неочевидному сразу падению качества работы. При разработке игры нужны "приемщики": продюсер, тестеры, а также те специалисты, которые используют в своей деятельности продукты чужого труда: так, data manager, собирающий юнит из отдельных частей, может проконтролировать результат работы моделлеров и текстурщиков; скриптовик, делающий ролик на движке, видит также достижения data manager’а, собравшего юниты. Разные люди - разные способы деятельности. Кто-то делает все сразу (таких энтузиастов особенно много в начинающих командах), кто-то стал узким специалистом и ему нужно обеспечить материалы для работы, поставляемые другими людьми.

Андрей "КранК" Кузьмин
Директор, KranX Productions

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

Александр Мишулин
Креативный директор, Nival Interactive

Мы все делаем по плану. Если отклоняемся от плана? Что ж, достойная игра не исключена и в этом случае. Более того, отклонения - это, к сожалению, скорее норма для индустрии. Но чем больше отклонение, тем сильнее нужен план, чтобы в конце концов выйти на прямую дорогу.

Петр "Amicus" Прохоренко
Гейм-дизайнер Lesta Studio

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

Дмитрий Лисица
Гейм-дизайнер Primal Software

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

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

 
  стр. 1 из 3  

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

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

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

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