Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…

Техуманитарный диздок

Однако что такое «диздок»? – может спросить читатель. В двух словах – это написанная «на бумаге» игра. К такому документу обращаются за информацией все участники команды разработчиков. Тут можно найти описание геймплейных механик, математические модели баланса, разветвлённый сюжет игры, указания музыканту, список звуков и визуальных эффектов… По крайней мере этому нас учат «классические» примеры диздоков. Самым известным из них в России является, конечно, документ «Месть курочки Рябы» из далёкого 2004-го года. А вот ещё один экземпляр заготовки диздока, намедни попавший мне на глаза на Reddit’е.

Как видите, структура у них крайне похожа – документ предназначен одновременно для всех и ни для кого. Он написан «техуманитарным» языком, который уже теряет смысл для программиста, но ещё недостаточно понятен для художника. К тому же колоссальный размер диздока ведёт за собой сложность навигации, чтения, поддержания текста в чистом и актуальном состоянии. Вам, должно быть, знаком термин «информационный шум»; участники команды будут сражаться именно с этой проблемой в поисках нужной информации. Если гранд-мастер гейм-дизайна 90-го уровня и сможет управляться с возникающими сложностями, то подумайте о новичках, какой диздок напишут они?

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

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

Зима, случайно попавшая в тренд

Много месяцев назад мне посчастливилось наткнуться на тёплую ламповую «adarkroom». Поиграв до утра и опоздав на работу, я вдохновился. Простые игровые механики и полное отсутствие графики послужили катализатором для воображения, раскрывшегося феерией красок в голове. Так родилась идея проекта «Survive the Winter», игры с простыми игровыми механиками и наличием графики. Ряд обстоятельств, правда, не позволил начать полноценную разработку, и идея была заброшена в комод.

За одним прекрасным обеденным перерывом я наткнулся на заданный на форуме вопрос. Неопытный разработчик попросил пример диздока, хотел разобраться, как проектировать игру. Ответы завсегдатаев состояли в основном из скудных попыток троллинга и ссылок на «Месть курочки Рябы». В тот день зародилась Идея. «Survive the Winter» – это фиктивная мобильная игра; она как бы есть, но её нет. Я решил воспользоваться старым концептом, и на его основе создать открытую документацию по созданию игры с нуля. «Ворох файлов в Google Docs, ряд макетов интерфейсов, а также щедрая россыпь тасков и технических заданий в Trello могут стать наглядным примером как для совсем зелёных новичков, так и для девелоперов с опытом», – вычурно подумал я, приступая к работе.

Являясь духовным наследником игры «adarkroom», «Survive the Winter» является вариацией «кликера». Последнее время этот жанр набирает всё большую популярность. Коллеги в интернет-издании «Цукерберг Позвонит» написали статью с анализом текущего состояния, а также возможных перспектив «кликеров».

Геймплей фиктивной игры

«Survive the Winter» основывается на менеджменте четырёх ресурсов: еды и дров на складе, сытости и тепла. Соответственно, от игрока требуется вовремя ходить на охоту, запасаться хворостом, кушать и разводить костёр. Временами происходят «события». Появляется окошко с текстом: «Среди зарослей орешника вы приметили затаившегося кролика. Привычным жестом вы натягиваете тетиву. Выстрелить?». После чего пользователь решает, как поступить. Например, ответив положительно, получает сообщение: «Предназначенная для охоты на оленя стрела насквозь пробивает крошечное тельце зверька и с треском врезается в сухую корягу», вместе с тем герой получает +5 единиц мяса. Эти «события» могут иметь самые разные последствия, начиная с получения дополнительного мяса и заканчивая травмой героя (дебафф, усложняющий игру). Они же постепенно раскрывают сюжет игры.

На первый взгляд может показаться, что проект маленький и несложный в разработке, даже если запланировать высокий production value (то есть исключительное качество продукта). Но так ли это? Разработчики часто недооценивают количество работы, идущее в небольшой по их меркам проект. Я считаю, что игра размера «Survive the Winter» является отличным способом достичь моей цели – показать людям ещё альтернативный пример диздока.

Большая документация маленького проекта

Откровенно говоря, я сам не ожидал, что документация разрастётся настолько широко. Посмотрите на полный список задач в Trello. Заметьте, там доступен горизонтальный скроллинг, открывающий новые столбцы. Отмечу, что уже был проведён препродакшн, то есть предварительная работа, поиск информации, исследования. Это избавляет нас от большей части задач по проектированию и гейм-дизайну. Теперь основной объём работы лежит на плечах программистов. Если бы задачи из подготовительного этапа остались на доске, то размер её был бы в полтора раза больше.

Документация ведётся с использованием двух сервисов: Google Docs + Spreadsheets и Trello. В Google Docs хранятся общие документы, такие как описание проекта или список фич. Там же спрятаны технические задания, на которые ссылаются карточки из Trello. Сам Trello используется как «бэклог», то есть склад всех доступных для работы задач. Пробежав глазами по Trello, любой специалист может наглядно увидеть проект целиком, визуально оценить прогресс команды, но в первую очередь такое отображение удобно для менеджера. Менеджером, замечу, может быть как продюсер, так и программист или любой другой ответственный специалист, если размер команды невелик.

Если вы работаете по гибким методологиям, то под «спринты» стоит создать отдельную доску, и в неё переносить задачи из «бэклога». Как следствие, можно будет наглядно оценить как общее состояние проекта, так и состояние текущего «спринта». Если объём работы для вашего проект заметно больше, чем для «Survive the Winter», то общая доска-«бэклог» может превратиться в помеху: все задачи не поместятся, вы начнёте в них путаться. Придётся поднять сервис таск-трекинга по типа Jira или Redmine. Тем не менее, для большинства инди-разработчиков Trello должен подходить идеально. В противном случае рекомендую внимательнее изучить размер проекта, вероятно, он слишком большой?

Спринт, аджайл, бэклог и другие сложные слова

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

«Спринт» является также прекрасным инструментом по поддержанию мотивации, ведь люди трудятся вместе ради достижения общей цели, – рабочего функционала в демо, – подбадривая друг друга, и к концу выделенного отрезка времени они получают осязаемый результат, что всегда приятно. Более того, даже если над игрой трудится один разработчик, «спринты» всё равно являются отличным мотиватором: разработчик не «пилит» какой-то абстрактный код, а реализует конкретную игровую фичу, которую можно будет пощупать непосредственно в «билде» игры. «Билд» же, в свою очередь, можно дать потискать друзьям и знакомым.

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

Тут же хочу заметить (и посыпать голову пеплом), что документация «Survive the Winter» в текущем её исполнении напоминает водопадную модель. Эта методология отличается тем, что заранее готовятся все задачи, после чего передаются исполнителям. Проект движется по предварительно выложенным рельсам, он становится негибким, любые изменения вносить сложно, – они буквально крошат его жесткую структуру, грозя массивными разрушениями, срывами сроков и выходом за рамки бюджета. Мне пришлось создать именно такую общую доску с задачами, спроектированными заранее и с особой тщательностью, чтобы наглядно показать разработчикам документацию целиком, как бы с высоты птичьего полёта.

Распределённый диздок

На доске-«бэклоге» карточки сгруппированы по смыслу и разложены по приоритету, чтобы самые важные были всегда на виду. Можно пойти ещё дальше и сгруппировать задачи по фичам. Иными словами, чтобы иметь фичу «событие» (помните, я рассказывал про бедного кролика, насквозь пробитого стрелой?), надо реализовать для неё всплывающее окошко, брать откуда-то текст, дать кнопки выбора варианта ответа на «событие», и так далее. То есть каждой отдельной фиче принадлежат несколько задач. Таким образом специалист сможет видеть, какая задача связана с какой, и какой общей целью они объединены. Поэтому важно создать несколько особых документов, отражающих каждую сферу проекта, то есть: программирование, графика, гейм-дизайн, звук и другие. Получается тесная интеграция с принципами гибких методологий разработки. Каждая фича представляет из себя спроектированный «на бумаге» функционал. В то же время каждый спринт стремится создать демо, в котором реализован цельный работающий функционал. В итоге всё служит достижению общей цели.

Тернистый путь проектировщика

Вы наверняка уже успели пощёлкать по задачам в Trello. В каждой вы видите выжимку информации, рассчитанную на конкретного специалиста. Если это программист, он получает больше технических описаний, если художник – больше описаний ощущений («от игры должно веять холодом!»). Создавая технические задания для разных специалистов, нужно стремиться понимать тип их мышления, знать, что для них важно, а что – пустые слова. Это следует всегда держать в голове. Документы надо создавать с высокой детализацией, чтобы специалист не тратил время, додумывая и заполняя пробелы за проектировщиком. В лучшем случае это ведет к фрустрации, в худшем окажется, что часть работы потом придётся переделывать.

Проектирование игры требует массу времени; важно не попасть в ловушку, считая, что составление задач и техзаданий – быстрый процесс, которым можно заниматься как бы между делом. При создании технических заданий для команды приходится глубоко анализировать игру, затем разбивать её на крошечные кусочки, давая им чёткое и однозначное описание, чтобы работать по такой задаче исполнителю было комфортно. Это долго. Занимаясь этим в свободное от работы время и в выходные, мне пришлось потратить около двух месяцев на «Survive the Winter».

Не меньше времени уходит на поиск информации. Многие задачи требуют предварительной подготовки, проведения исследований, фильтрования информационного шума. Например, при создании кроссплатформенной мобильной игры, описывая для художника техническое задание по рисованию иконок для приложения, нужно заранее перелопатить увесистые гайды от магазинов Apple, Android, Amazon и WP8 (самая замороченная платформа, очень много иконок и тайлов, но гайд грамотный). Вы не можете просто накидать в задаче ссылок, вам надо самостоятельно пойти и сделать из тонны текста выжимку, оставив исполнителю только важную для него информацию. Между тем, разбивая документацию на небольшие, но выполнимые задачи, хорошим тоном будет рассказывать команде, где и какая ещё информация доступна. Ведь всегда есть интересные и важные документы за пределами их обособленной задачи, запланированной на текущий спринт.

Заключительные мысли

Документация находится в постоянном состоянии Work in Progress. Это значит, что хоть основная работа выполнена и крепкий фундамент заложен, но хочется развивать и улучшать проект, добавляя новый контент и допиливая существующий. Если у вас есть пожелания или предложения – всегда рад услышать. Этот пример документации – не истина в последней инстанции. Автор допускает, что есть более продвинутые и гибкие методы работы, но в свободном доступе примеров нет. Я предлагаю свой вариант и призываю к обсуждению. Предполагается, что от этого выиграют все.

И ещё раз ссылки на всё:

• Список задач в Trello.
• Вся документация в Google Docs.
• Документ «Начать здесь», с которого можно начать знакомство с документацией.