Разработка игры. Нужно ли писать диздок?

     В поисках информации о разработке игр начинающий девелопер практически в 100% случаев сталкивается с мистическим и необъятным термином «диздок» (он же – дизайн-документ). Ни одна без исключений большая игра не делается без диздока. Диздоком нельзя пренебрегать! В диздоке сокрыт чуть ли не весь смысл разработки!

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

     Эта безумная практика активно мусолится многими «советчиками»: «Нужно писать диздок!»

     Так ли это? Ну, давайте разберемся, что такое диздок, и всем ли он нужен.

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

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

     Дальше проектировщики подробно описывают основные требования к реализации. Например, общий вес продукции, детали. Или материалы, которые нужно использовать при строительстве.

     На основании всей этой мозговой деятельности пишется проектная документация.

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

     А теперь стоит понять, для чего нужна такая подробность. Если вы обратили внимание, то при описании проектирования я использовал слово «команда». Это очень важный момент. Дело в том, что проектированием и непосредственно разработкой занимаются совершенно разные люди. Мало того, за реализацией каждого направления закреплены специалисты из различных областей. Например, один человек рисует модель, второй текстурирует, третий анимирует и т.д. Так вот, для того, чтобы разработчик понимал, какая перед ним ставится задача, и пишется проектная документация.

     Представим, что геймдизайнер задумал использовать в игре сплюснутый сверху мяч. Он должен быть бирюзовым и немного светиться. Он передает свою идею 3D моделеру. Моделер понимает, что нужно сделать мяч. И делает круглый объект. Дальше этот шарик передается художнику по текстурам со словами: «Ну такой, светло синенький». Текстура готова. Отдаем ответственному за подготовку материала и говорим: «Должно блестеть».

     В итоге, принимая работу, геймдизайнер рвет на себе волосы.

     Это очень упрощенный пример, который позволяет оценить сложность работы без диздока. Если вспомнить, что над некоторыми играми работают команды из 1000 и более человек, то необходимость диздока становится более чем очевидной. Степень свободы в проектной документации обычно варьируется. Иногда исполнителям предоставляется некое пространство для творчества, иногда, наоборот, требуется 100% соблюдение абсолютно всех указаний.

     Подытожив, мы получим основные функции, которые выполняет дизайн-документ:

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

     А теперь – внимание – вопрос: нужен ли диздок команде из 3-4 человек или, тем более, одиночке? Ответ плавает на поверхности. Написание проектной документации – это крайне трудоемкий процесс, который занимает огромнейшее количество времени (и счет зачастую идет не на дни, а на недели и месяцы). Таким образом, написание диздока повесит проект надолго. А если вы при всем при этом еще и не имеете большого опыта разработки игр и ни разу не писали проектную документацию, то на попытках написать диздок разработка, вероятнее всего, для вас и закончится.

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

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

     Конечно же, решение о написании диздока каждый принимает для себя сам.

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