Technical Design Document: что, зачем и как

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

Анатолий Ахмедов
Работает в компании Creat Studios с 2003 года. Участвовал в проекте American Chopper. Был ведущим программистом на проектах American Chopper 2 и Coded Arms Contagion
.

Вступление

На КРИ-2007 мне довелось побывать на докладе Дмитрия Долгова "Outgoing mail: Техническая переписка с разработчиками", где он перечислял технические проблемы, с которыми сталкиваются разработчики с точки зрения издателя. И весьма большая их часть (проблемы preproduction) относилась к типу: "Этого можно было избежать, если бы подумали заранее". На вопрос, насколько распространенна практика написания технического дизайн-документа (далее - ТДД), позволяющего избежать многих проблем, докладчик ответил, что среди российских разработчиков такая практика не распространена. Это навело меня на мысль, что статья на тему ТДД будет как минимум не безынтересна отечественному геймдевелоперу.

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

Конечно, все, кто успешно выпускал проект, умеют такие проблемы решать. Можно подрезать кустики и убрать заборчики, можно притормозить игрока и добавить motion blur. Но все это оборачивается многими дополнительными часами работы, напряжения нервов и мозгов. Все эти проблемы можно было решить задолго до этого, на этапе preproduction. Конечно, решение все равно бы потребовало и много часов работы (правда, не за одну оставшуюся неделю), и напряжения мозгов. Зато позволило бы сэкономить на нервах множества людей, и сдать проект, если и не в срок, то хотя бы с меньшей задержкой и большим качеством. По моему скромному, но твердому убеждению, это вполне является оправданием времени, которое придется затратить на написания технического дизайн-документа.

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

Эта статья ориентирована на три категории людей:

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

Часть первая: Что

Если верить Интернету, то (на момент написания данной статьи) термин Technical Design Document еще не получил четкого определения. По-крайней мере, поиск в Google и Wikipedia на эту тему ответа не дает. Более распространен термин просто Design Document, как некое общее описание архитектуры программного проекта. Можно считать, что для игры Design Document состоит из двух частей: первая часть, функциональная - это Game Design Document, описывающий, что есть в игре, как оно работает и зачем оно нужно; вторая часть - техническая, описывающая, как оно может быть сделано. Вот эта часть и есть Technical Design Document. И если за первую часть ответственен ведущий геймдизайнер на проекте, то вторая часть обычно является задачей ведущего программиста.

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

Как нет единого определения ТДД, так нет и единого подхода к его содержанию. Мне попадались требования от Sony по ТДД, которые представляли собой список из 26 вопросов, на которые разработчик должен дать ответы. Также я видел ТДД к одной хорошей игре - в нем было порядка 300 страниц. И практически все задачи на проект были подробно расписаны, разбиты на подзадачи, приведены их риски. И каждая подзадача была оценена в часах! Там даже пасхальные яйца (Easter eggs) были расписаны таким образом. В общем, объем и степень детализации ТДД каждый определяет для себя сам, с учетом желания, навыков и формализованности процесса разработки. Например, ТДД на Coded Arms Contagion был объемом 55 страниц и содержал общее описание реализации тех фич, представления о которых мы имели на момент его написания. Что-то было расписано менее подробно, что-то более, если фича казалась технически сложной. На его написание потребовалось два программиста (ведущий и старший программист) на полтора месяца и еще несколько программистов привлекалось на неделю. Суммарно где-то 4 человекомесяца.

Содержание ТДД также меняется от проекта к проекту. Но есть некоторое количество пунктов, которые в той или иной степени встречаются во всех случаях. Это:

  • Краткое описание игры
  • Hardware requirements целевой платформы (minimal hardware requirements для PC)
  • Список third party products, которые будут использованы
  • Список тулзов, которые будут использованы при разработке (source control, preview, editors и т.д.)
  • Архитектура АИ, физики, сети, если есть
  • Описание реализации пользовательского интерфейса и управления (без них, вроде, еще ни одна игра не обошлась)
  • Что будет использовано для проигрывания звуков и музыки
  • Описание возможностей графического движка
  • Список каких-то выделенных фич данной игры и описание их реализации
  • Карта памяти (или памятей, если, например, для графики используется отдельная область)
  • Требования к asset (моделям, уровням, текстурам, и т.п.)

Дополнительно в ТДД может включать:

  • список майлстоунов,
  • оценки сложности задач,
  • описание архитектуры движка и базовых объектов в нем,
  • описание скриптов, спецэффектов, системы частиц,
  • способы отладки,
  • структуру интерфейса,
  • стандарты кодирования,
  • прочие технические стандарты, принятые на проекте (например, что где должно лежать)
  • форматы файлов,
  • описание системы сборки проекта, инсталлятора, локализации и т.д.

Полезно также включить в ТДД список тестов для основных элементов системы. Это позволит сразу выявить те моменты реализации, которые станут проблемными на стадии тестирования игры. Например, если в игре есть сетевая компонента, как ее надо будет тестировать? Для примера в приложении я приведу содержание ТДД на Coded Arms Contagion.

Часть вторая: Зачем

Для чего может понадобиться ТДД? В первую очередь, технический дизайн-документ может потребовать заказчик. Как доказательство компетентности команды и технической осуществимости проекта. Если эта единственная причина, то, возможно, стоит ограничиться формальным документом, перечисляющим достоинства вашего движка и технологии, а также то, как хорошо вы это вставите в игру. На American Chopper 2 ТДД выполнял именно эту роль. Такой документ пишется на этапе preproduction, после чего о нем можно благополучно забыть.

Но это не единственный и не главный довод за написание ТДД. Я позволю обрисовать себе нескольким часто возникающих проектных ситуаций, в которых наличие ТДД могло бы помочь:

  • Художники отдают полную сцену, и выясняется, что количество полигонов/объектов/текстур превосходит возможности движка. Что делать? Либо переделывать геометрию, либо оптимизировать движок. И тот, и другой варианты требуют дополнительной работы и не очень приятны. Но, возможно, такая необходимость не возникла, если бы ограничения на полигонаж были фиксированы, доведены до художников и записаны в известном месте, чтобы о них не забывали.
  • Геймдизайнер решает, что будет очень интересно, если в следующей миссии мы будем сражаться против сотен врагов в красивых тропических джунглях. Почему бы и нет? А потому, что еще в начале проекта было решено, что все уровни будут закрытым пространством с не более чем 10 одновременно видимыми противниками. "Разве было такое?!" - спрашивает геймдизайнер, уже мысленно бегающий по джунглям. "Было!" - возвращает его на землю программист, указывая на лежащий под source control документ.
  • Продюсеры очень любят выкручивать руки, задавая следующие каверзные вопросы: "Ну зачем тебе 4 человека, что сделать эту маленькую игру? Вот опиши мне, чем они будут заниматься все эти месяцы? Вы вполне справитесь вдвоем". Можно, конечно, попытаться переспорить продюсера, который, скорее всего, значительно превосходит программиста в коммуникационных навыках. А можно привести в качестве аргумента технический документ, объемом в несколько десятков страниц. В котором будет подробно описано, чем таким будут заниматься эти 4 человека, и почему вам, возможно, потребуется пятый. Вряд ли продюсер будет доказывать по каждому пункту этого документа, что вам хватит двух человек.
  • Как работает та или иная подсистема? Почему она так сделана? Каким требованиям должны удовлетворять asset для игры? Как назло, эти вопросы возникают у разных людей в разное время. Можно терпеливо изо дня в день отвечать очередному подходящему человеку на интересующие его вопросы. А можно давать ссылку на документ, где это уже описано.
  • Решено, что в игре будут стенсильные тени для персонажей. Программист дает оценку в две недели и начинает их реализовывать. Потом возникает замечательная идея: а почему бы не поставить такие же тени для домов? Ведь все необходимое уже готово. Сказано – сделано. Через месяц в игру вставляются первые небоскребы и, что мы видим – сквозь тени просвечивает асфальт. Большим количеством полосок толщиной в один пиксель. Вывод: не хватает точности z буфера для таких больших объектов. И памяти на увеличение этого буфера тоже не хватает. И к уже потраченным двум неделям прибавляется месяц попыток подобрать такой алгоритм сдвигов, чтобы тени накладывались корректно, не пропадали и не пересекали здания. Вот тут и встает вопрос: а может, не стоило делать тени для зданий? А может, можно было так позиционировать небоскребы, чтобы игрок никогда не заезжал в их тень? И сразу предупредить, что это задача не на две недели? Можно, если внедрение стенсильных теней было продумано, а его возможности и ограничения где-нибудь записаны.

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

Согласованность ограничений. Написание подобного документа нужно, чтобы избежать поздних переделок арта и/или неожиданной необходимости оптимизировать движок. С начала линейного производства необходимо фиксировать набор требований и ограничений, накладываемых на asset. Технический дизайндокумент служит тем обязательным к прочтению документом, где это перечисляется. Наличие единого документа также позволяет избежать проблем вида: "а я не знал, что такое есть…", "а я не нашел…" и т.д.

Информированность о движке. Описание возможностей и ограничений подсистем игры позволяет бороться с фичекрипом (feature creep). Или, по крайней мере, информированность геймдизайнеров о том, что можно, и что нельзя, избавит вас от фичекрипа в проблемных областях. Если в ТДД черным по белому написано, что вы используете только простейшую физику, то у вас не появится минигейм, связанный со сложными конструкциями из пружин, резинок и веревок.

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

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

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

 
  стр. 1 из 2  

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

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

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

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