Советы по составлению концепт-документа игрового проекта от Андрея Чан

Андрей Чан

Специалист по запуску и оперированию продуктов / Publishing Product Director в компании Wargaming.net

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

Сегодня я хотел бы составить некий пример документа с информацией, которая будет интересовать вашего паблишера и\или продюсера, который будет этого паблишера искать.

Concept Document

Это самый первый документ, который потребует паблишер. Как правило, диздок его интересует гораздо меньше.

Это может быть как Word документ, так и красивая презентация. Важно, чтобы там были рассмотрены следующие пункты:

Название игры

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

Нужно правда понимать, что до выхода на рынок, любое название – рабочее. Не нужно к нему привязываться.

Жанр

Здесь не нужно быть кратким, но и не нужно составлять огромную мешанину жанров.

“RPG” – плохо. Слишком мало информации.
“Side view point-and-click action RPG” – хорошо.

“Смесь РПГ, экшена и стратегии, с уникальной боевкой и элементами match-3” – плохо. Непонятно, что главное, что второстепенное и куча лишней информации.
“RTS с элементами RPG и turn—based битвами” – хорошо. Понятно, что это все таки стратегия, а экшен и рпг тут в походовых боях.

Сеттинг

Здесь лучше сначала указать кратко и емко, что нибудь типа “Post—Apocalyptic Dystopia”, а потом раскрыть тему.

“Человечество изгнано с Земли механическими существами из другого мира. В последней попытке отбить Землю, люди посылают андроидов уничтожить машин.
Так, начинается война андройдов и машин… Война, которая откроет давно забытую правду о этом мире.”

Описание игры

Здесь мы описываем саму игру и цели игрока.

Добавьте немного про сюжет и визуальную составляющую и дело в шляпе.

Целевая аудитория

USPs (Уникальное Торговое Предложение)

Как я уже писал в предыдущих ревью: Что уникального предлагает ваша игра? И помните, мы говорим о предложении, а не о функции.

Например если взять M&Ms – “Тает во рту, а не в руках” – несомненно, были конфеты которые не таяли в руках и до M&Ms. Но только M&Ms сделал это предложение уникальным.

Development Roadmap

Когда вы начали работу? Какие Milestones уже позади, а какие впереди?

Когда прототип, альфа, бета?

Таймлайн с датами – must have!

Команда

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

Подробное описание игры

Всегда хорошо иметь в конце слайды или страницы с более подробным описанием игры. Что-то типа очень высокоуровнего диздока.

В заключение

Вот так примерно выглядит Concept Document. Он легко трансформируется в презентацию для Паблишера, в Питч, в Product Description – как бы не называлось то, что потребует паблишер, к которому вы обратились.

В идеальном мире, это документ начинает пилиться в самом начале, вместе с диздоком, или как часть диздока.

Потом, уже после законченного прототипа, начинает делатся Marketing Requirements Document, Launch Strategy, Legal Review, Business Case, Production Plan… Но нам это пока не нужно =D

P.S.

Ну и как напутствие – если проект не прет и вы завязли в рутине, то возможно стоит вернуться к истокам и пересмотреть core геймплей и основную идею игры?
Конечно, на это нужны силы и воля, но зачастую это просто необходимо сделать. Так делают огромные компании, разом фиксируя убыток за год или два разработки – а это десятки миллионов долларов.

Но просто нельзя это рассматривать как убыток. Зайти в тупик или непролазную чащу и вернуться к развилке – это часть пути к релизу удачного продукта.

Источник

Как написать дизайн-документ для игры

Оставьте надежду, если вы разрабатываете игру без диздока, потому что она вряд ли доживёт до релиза. Объясняем, зачем и как составлять диздок.

Дизайн-документ (сокращённо — диздок) — это документ, в котором содержится вся информация о создаваемой игре. Он нужен, чтобы команда, которая будет работать над проектом, понимала, что в итоге должно получиться.

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

Подготовкой диздока занимается гейм-дизайнер — человек, который решает, какой будет игра. Но это не значит, что после составления диздока гейм-дизайнер больше не нужен: он контролирует процесс и принимает новые решения, если во время разработки что-то меняется.

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

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Какие инструменты использовать для создания диздока

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

Обычно я создаю папку для проекта и добавляю в неё всё: сам диздок, папку с референсами, технические задания и прочее.

Если нужно составить какую-то схему, то я пользуюсь бесплатным сервисом draw.io. В нём можно создавать что-то подобное:

Для подготовки референсов я использую GIMP (графический редактор с открытым исходным кодом) или просто делаю скриншоты и записываю экран.

Диздок — это не:

Диздок — это

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

Можно добавить и другие пункты, лишними подробности не будут.

Описание игровых механик и управления

Все игровые механики важно описывать очень точно. Например, вы можете указать, что игрок будет сражаться с врагами, убивать монстров и захватывать замки. Под это описание подходят как Heroes of Might and Magic, так и World of Warcraft, а они сильно различаются.

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

Кнопка E — взаимодействие с предметом или персонажем.

Взаимодействие с предметом или персонажем: игрок наводит курсор на объект и нажимает клавишу E. Тип взаимодействия зависит от типа объекта:

При этом на разделы нужно прикреплять ссылки, чтобы членам команды было удобно ориентироваться в диздоке.

Сами же взаимодействия можно оформить в виде таблицы:

Источник

Как я писала геймдизайнерскую документацию на свою игру

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

Определяем задачи и цели

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

Концептируем

Для краткого описания игры достаточно сделать Vision-документ – о том, что это такое и как это делается есть статья на хабре: вот она. По ходу подготовки проекта идей становилось все больше и больше, и необходимо было объяснить ключевые фичи и дать более детальное представление о механиках игры, поэтому я остановилась на следующей структуре своего дизайн-документа, который по сути и составил весь проект.

Концепция игрового проекта

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

Игровые элементы

Игровые элементы – это все то, с чем игроку предстоит взаимодействовать тем или иным образом в игре. Персонаж игрока (или несколько персонажей в случае мультиплеерного режима игры), неигровые персонажи, враги, а также определение и список объектов и предметов – все это описано в общем виде и для удобства разделено на группы и категории (например, для предметов – к какой группе относится, где встречается, каковы возможные типы взаимодействия с предметом, и т.д.).

Игровые механики

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

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

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

Дизайн окружения

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

Вот, например, небольшой коллаж из артов с моего любимого deviantart.com, которые я подобрала в качестве референсов:

Проводим анализ

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

Геймплей моего игрового проекта сильно опирается на кооперативное прохождение двумя игроками. Поэтому исследование рынка игр проводилось для сегмента игр на ПК и консолях, с режимом мультиплеера для двух-четырех человек. Были проанализированы пользовательские отзывы выборки игр в Steam, рейтинги на metacritic, статьи популярных игровых порталов, таких как pcgamer.com.

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

Выводы и материалы

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

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

Если у вас есть вопросы по теме — задавайте, отвечу в комментариях.

Источник

Как написать диздок

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

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.

Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.

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

Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.

Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.

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

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

Источник

Дизайн-документ

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

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

Слово предоставляется Мареку Хефнеру, человеку, который по долгу службы регулярно рассматривает эти тексты и решает, какой из них порекомендовать западным издателям.

Скажу вам честно: я не сторонник мнения, будто дизайн-документ (далее – ДД) – это «половина всей работы». Мне даже случалось видеть успешные игры, написанные вообще без этого этапа; правда, последний такой пример встретился мне 4 года назад.

И тем не менее ДД – настолько важная штука, что просто диву даешься, сколько странных легенд о них ходит. Эти мифы поддерживаются даже вполне серьезной игровой прессой; порой ДД описывают так, что его можно перепутать с журнальным preview, бюрократическим отчетом «О динамике развития популяции долгоносика в полях Тютюкинского района» или страховым договором.

(Если задуматься – что тут удивительного? Если серьезные игроки порой верят, будто гейм-дизайнер – это человек, который делает игровую графику, когда на самом деле это – автор самой игры, ее геймплея…)

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

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

Миф первый. Чтобы договориться с издателем, достаточно подготовить ДД.

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

И все же без дизайн-документа – еще меньше.

Двуединство

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

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

Часто начинающий разработчик пытается написать два документа. В одном он рассказывает издателю, какая у него будет замечательная игра, а в другом составляет реальные рабочие планы. Потом он искренне удивляется, когда от него начинают требовать буквального соответствия продукта «издательской» бумаге.

ДД должны прочесть – и внимательно! – все разработчики. Не только затем, чтобы выловить там возможные «дыры», а еще для того, чтобы все без исключения понимали, какую игру они делают.

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

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

Ознакомительный текст

Не пытайтесь описать в этом тексте все величие своего замысла. С самого начала помните, что объем этого текста – не больше странички, а хороший тон предписывает ограничиться 2/3 страницы – примерно 2 000 знаков.

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

Это интересно: восточноевропейские, немецкие и английские издатели предпочитают названия, которые ни на что не похожи, а заокеанские – такие, которые перекликаются с уже известными широкой публике. Не случайно «Демиурги» прижились на Западе под псевдонимом Etherlords… Ходовые схемы для Америки – 2 слова плюс “of” или “and”. А то, что вы на самом деле хотите сказать об игре, вы скажете после двоеточия…

Далее в одном абзаце, 1-3 предложениями, скажите, чем ваша игра будет наиболее привлекательна. Здесь ваша главная задача – указать качественные, а не количественные отличия. Если у вас будет не 50 видов войск, а 150, вы еще успеете об этом сообщить. И не надо писать, что у вас будет самый умный ИИ: все равно вам никто не поверит. Пишите в первую очередь об устройстве самой игры, а не о ее технической реализации.

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

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

Далее укажите, какой предполагается срок и общая сумма затрат на проект.

(Это означает, между прочим, что, даже если ваш партнер по каким-то своим причинам не требует у вас дизайн-документа – чего не бывает на свете? – из этого не следует, что ДД у вас может не быть. Потому что наука знает только два способа определить сроки проекта: по ДД и путем «рулетки». Причем во втором случае рулетка обычно оказывается русской.)

Если у вашей команды есть заслуживающий упоминания послужной список – это будет следующим пунктом. Если нет, кстати, задумайтесь, не следует ли его создать. Сегодня это легче, чем пять лет назад… Впрочем, об этом чуть ниже. Если имеется готовая демо-версия (хорошо бы это было так!) – скажите об этом.

Оставшееся место посвятите достоинствам проекта. Так и озаглавьте. Вот здесь вы уже можете упомянуть и о блистательной графике, и о 150 родах войск, и о прочих вкусностях. Сделайте это в виде списка, по одному преимуществу на строчку, и говорите лаконично, как истинные спартанцы. В некоторых случаях можно упомянуть, что именно это сегодня в моде (только убедитесь, что это и впрямь так, и не пишите банальностей, вроде “в наше время на рынке ценится трехмерная графика”).

Миф второй. Чем больше расхвалите свой проект – тем лучше.

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

Миф третий. Издателя интересует графика и прочие модные штучки, а вовсе не ваши идеи геймплея.

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

Дешевый способ прославиться

Миф четвертый: издатели рассматривают серьезно только ту команду, которая уже сделала хоть одну игру.

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

Я имею в виду изготовление модификаций и карт к существующим играм. Здесь можно с блеском проявить свои таланты игрового дизайнера, заработать награды вроде «Модификация месяца» и гордо предъявлять их потом в знак своей компетентности и способности довести дело до конца.

В наше время большинство приличных игр обладает средствами для расширения руками игроков. Хорошие стратегии почти всегда снабжены редактором карт, а то и кампаний, для многих боевиков имеются редакторы уровней, ну а о могучих редакторах игрового мира для Neverwinter Nights и Morrowind слышали, наверное, все.

Конечно, хорошую карту, а тем более – кампанию или ролевой модуль, не сделаешь за один вечер… но на хорошую игру понадобится много больше времени. Не пожалейте сил, это окупится.

Не делайте шуточных модов, разве что собираетесь поразить мир очередным «Штырлицем» (а может, лучше не надо?).

Доведите вашу работу до конца. Если издатель, не дай Бог, увидит на сайте, где лежит ваш модуль, примечание «альфа-версия», он с высокой вероятностью решит, что это – признак неумения доделывать свои начинания. И тогда ваша реклама ударит бумерангом вам же в лоб.

Есть и второй способ, как ни странно – менее популярный: сделать приличную сетевую игру на основе Flash или Java, и предъявить издателю высокую посещаемость сайта с нею. Но это, во-первых, менее надежно, а во-вторых – требует изучать еще и эти технологии.

Это важно: для издателя ценнее, если модификация сделана вашей командой, нежели вами одним. Но это не значит, что можно просто дописать ваших сотрудников в список авторов; могут ведь поинтересоваться, что именно делал здесь аниматор или программист ИИ…

А кстати, что мы собрались делать?

Разговор о том, как сделать ваш проект интересным – тема совсем другой статьи, мы сейчас говорим о дизайн-документах. Но все-таки пара слов не помешает.

Одна из самых важных задач – соблюсти баланс между глобальностью и примитивностью.

Если ваш проект будет претендовать на звание «убийцы Half-Life 2», или пытаться завоевать рынок онлайновых игр, или обещать 300-часовую ролевую кампанию – ваши шансы резко снижаются просто из-за роста сроков и денег. Кроме того, даже если издатель согласится, подумайте, нужно ли вам это? Не забудьте, что с компанией, у которой есть уже изданная игра, договор заключается на совсем другие суммы. Может, ваш будущий мегахит лучше продать подороже, а тропинку к этому протоптать чем-нибудь попроще?

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

Я упомянул, что не стоит пытаться первым проектом прорываться на онлайновый рынок. Значит ли это, что не всякий жанр годится для дебюта?

Да, значит. По крайней мере, они годятся по-разному.

Ролевая игра. Здесь для убедительности крайне желательно предъявить модули собственного изготовления. Главное, в чем будет сомневаться ваш издатель, – это в работоспособности команды: ведь ролевые игры требуют намного больше сил, чем, к примеру, стратегии. Докажите ему, что вы умеете доводить работу до конца.

RTS. Это – едва ли не самая легкая задача, но об этом в курсе и издатель. А еще он не забудет, что имя таким проектам – легион, и выделиться среди них непросто. Убедите его, что вы предлагаете действительно нечто необычное – и золотой ключик у вас в кармане.

Глобальная или тактическая стратегия. Тоже вполне под силу, однако тут очень рекомендуется предъявить образчик геймплея. А это значит, что вы должны хорошо разбираться в разных типах таких стратегий.

Менеджер. Не советую, даже если у вас на руках очень увлекательная тема. В наши дни такие проекты индустрия просто-таки мечет, как лягушка – икру.

Квест. В России сложился стереотип, что квест – это дешевая поделка начинающих разработчиков. Что он будет продаваться исключительно в России. В общем, если вам хочется просто «зацепиться» за место, сделать себе какое-никакое имя, а крайне низкая оплата вашего труда первое время (до первого продукта) вас не смущает – это хороший путь.

Cимулятор. Сложный вопрос… В общем-то, к нему относится все то, что сказано об action-играх, да еще надо добавить, что жанр редкий, элитный… В общем, пожалуй, не для дебюта.

Логическая игра. Тут все просто, поверить в ваши силы нетрудно, но… и цена такому проекту, как правило, грош. Славу заработать можно, разбогатеть – едва ли.

Онлайновая игра. Бесплатные или условно-бесплатные стратегические игры через интернет – хороший выбор, но сами по себе они богатств не обещают, только демонстрируют издателям вашу профессиональную пригодность. Ну, а за игры вроде Lineage II – то есть ролевые или action-игры с современной графикой – я категорически не советую браться дебютантам. Это совершенно неподъемная задача для студии без реального опыта, а рынок сегодня пересыщен.

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

Напоследок – пара слов о теме. Я уже говорил, что не надо цепляться за позавчерашнюю моду. Это в первую очередь относится даже не к жанрам, а к темам. Например, сегодня будет изрядной глупостью предлагать игру по Второй Мировой: уже сейчас от игр о ней слегка подташнивает, а через год (когда вы смогли бы, теоретически, ее закончить) она будет работать лучше патентованного рвотного.

Хорошо, если ваша тема будет иметь привязку к России, Украине или другим территориям бывшего СССР, но при этом, если вы надеетесь когда-либо попасть на международный рынок, она должна быть понятна за рубежом. О казаках знают все (так уж сложилось), а вот ваши фильмы или книги (особенно современные) известны немногим.

Что должно быть в ДД?

Миф пятый: в ДД нужны концепции игры, остальное разработается потом.

ДД – это ваш план работы, причем работы от начала и до конца проекта. А это значит, что все основные задачи должны в нем находиться, и не только задачи, а и приблизительные методы решения. В частности:

Схема игры. Что должен делать игрок, какова конечная цель, что мешает ее достижению.

Интерфейс. Подробно описанная функциональная часть (что можно делать, каким образом – меню, мышь, горячие клавиши, кнопки…).

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

Программные механизмы и алгоритмы. Какими характеристиками будут обладать графический движок, ИИ, сетевой код, интерфейс, редактор карт, звук…

Графика. Сколько и каких вам понадобится моделей, анимаций, двумерной графики, роликов, обоев (да, и их тоже стоит запланировать заранее). Здесь крайне желательны (может, лучше сказать – необходимы) хоть какие-то наброски, concept art, по которым можно почувствовать визуальный стиль игры.

Звуки и музыка. Темы, вид и способ отображения звуков, набор звуковых эффектов.

Сюжет. Общая сюжетная канва, план кампаний (помиссионно!), основные задания и т.п. – в зависимости от жанра. Каждая из предполагаемых карт должна быть запланирована здесь.

Игровой мир. Основные персонажи / монстры / виды войск с параметрами и примерным расположением / способом добычи и производства.

Cотрудники, зарплаты, сроки и план работы.

Чего может не быть в ДД?

Миф шестой: в ДД вносится абсолютно все устройство игры, и ничего изменить уже нельзя.

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

Также не стоит считать, будто все виды моделей вы действительно запланировали изначально (но к этому нужно стремиться!). Гарантированно вам понадобится на самом деле еще немало их – увеличьте число в полтора раза…

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

Миф седьмой: ДД оценивается в первую очередь по объему.

На удивление живучая легенда, причем особенно популярна она почему-то в России. Многие российские дебютанты убеждены, что стоит им выложить на стол переговоров пачку из 800 листов – и поле боя останется за ними.

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

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

Конечно, если вы предлагаете ДД из 10 страниц (а игра при этом называется не «Тетрис»), даже у самого доброжелательного издателя зародятся сомнения.

Миф восьмой: очень важно описать в ДД устройство и происхождение мира.

Вот это – исконно восточноевропейский миф, за пределами Чехии, Польши, России и Украины я с ним не сталкивался. Не ведаю, почему, но в наших палестинах очень модно начинать работу над игрой примерно так:

В начале времен великий дракон Фокуспокус создал небо и землю. Его сын Уксусмускус отпилил ему кусочек хвоста и сделал Солнце…

После чего широкими мазками набрасываются взаимоотношения персонажей (в духе «ее зовут Маша, она любит Сашу, а он любит Дашу и только ее») – и это сдается как сценарий квеста. А то и, прости Господи, ролевой игры…

Между тем понять по этому тексту, о чем игра, невозможно в принципе – тут надо гораздо больше рассказать о персонажах и, главное, об их отношениях с героем – а вся история про Уксусамускуса может смело отправляться в корзину.

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

По разделам

С чего начать?

Тут, опять же, существует немало «школ», большинство рекомендует начинать со схемы игры. Я, однако, хочу предложить другой путь: начните с интерфейса.

Почему? Потому, что интерфейс, как ничто иное, поможет вам самим почувствовать ту игру, которой пока еще нет. Описывая его, вы сразу определите возможности, которые есть у игрока, и отвечать на все остальные пункты станет намного легче.

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

Что происходит при активации того или иного контроля, тоже надо тщательно расписать. Исчезает ли окно меню – или остается на экране? Сразу ли перемещается солдат, или только по подтверждающему щелчку в ту же точку? Чем определяется скорость движения (если игра пошаговая; в противном случае это – вопрос игровой механики)?

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

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

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

Это важно: даже не надейтесь, что вы весь интерфейс правильно опишете с первой попытки. К этому пункту вы вернетесь еще сто раз за время написания ДД, а потом внесете изменения на стадии тестирования готовой игры…

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

Механика

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

Никогда не забывайте описать, как все происходящее отображается на экране. Мало сказать, что стрела попадает при таких-то условиях; опишите, как именно она летит. Зачем? А иначе будет, как в Baldur’s Gate, где, помнится, стрелы и огненные шары бодро заворачивали за угол в погоне за целью.

(Как это вышло? Да очень просто. Было постановлено, что попадание определяется в момент выстрела. Но игра-то в реальном времени, и, пока стрела или заклинание летят, цель запросто может спрятаться за углом или деревом. А между тем уже просчитано: стрела попала в цель, и хиты уже сняты. Пробивать здания навылет разработчики запретили, следовательно. )

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

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

Для примера процитирую маленький фрагмент фазовой последовательности старой-престарой сетевой стратегии VGA Planets:

Добровольная передача кораблей

Отправка грузов на корабли с планет

Сбрасывание невидимости спецприбором корабля «Локи»

Действие тахионных полей

Появление новых аборигенов

Обработка перегрузки кораблей

Передача груза по транспортным лучам

Прием груза с планет кораблями

До и после этого еще много десятков таких строк.

Зачем такая точность? Она очень существенно влияет на ход игры. И «профессионалы» VGA Planets знали эту последовательность наизусть. Вот, например: отправка грузов с планет на корабль происходит существенно раньше приема груза кораблем. А между ними затесалось исполнение миссии грабежа (при которой топливо с кораблей автоматически утягивалось судами расы пиратов). Корабль без топлива беспомощен, и если бы последовательность была иной, от пиратов не было бы защиты. А так есть шанс – в начале хода отправить немножко топлива с планеты на корабль, и оно придет уже после того, как грабеж закончится…

Программные механизмы

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

Главное правило: пишите здесь о том и только о том, о чем имеете представление. Не надо в главе об ИИ утверждать, что «здесь будут использованы методики нейронных сетей, логического программирования и экспертных систем». Если ваш ДД, не дай Бог, после этого отдадут на рецензию профессиональному программисту – он из вас кнедлики сделает.

– А что делать, – спросите вы, – если об устройстве ИИ у меня пока что общее представление?

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

Миф девятый. Чем круче будут эти механизмы – тем лучше.

Конечно, «навороченный» графический движок не помешает ни одному проекту. Но оправдает ли он затраты? Не факт. Если «Героев меча и магии» осчастливить глубочайшим 3D со всеми мыслимыми спецэффектами, главным результатом будет рост системных требований, а игра лучше не станет. Вырастут не только требования – а еще затраты и время на разработку.

А если вы действительно новичок в игровой индустрии – в то, что ваш движок переплюнет Half-Life 3 и Unreal 3, просто не поверят.

Не говоря уже о том, что написанное вам же потом реализовывать.

Графика и звуки

В этих разделах решаются две задачи: перечисление необходимых рисунков, моделей, мелодий etc. – и предоставление образцов.

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

Миф десятый. Вся игра от начала до конца должна быть сделана силами команды.

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

Есть и другие части проекта, которые зачастую делают третьи лица: ролики, мелодии… Не стесняйтесь этого. Это – вполне нормальная и общепринятая практика.

Сюжет и игровой мир

Здесь самый здравый подход – отделить «беллетристику» от «схем».

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

Чтобы показать ключевых героев наглядно, очень полезно показать несколько их реплик.

Сроки и затраты

Главное – сроки и затраты должны быть результатом точных расчетов, а не «прикинуты на пальцах». Последнее – верный путь к краху.

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

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

Не забудьте заложить в план время на тестирование. Это обычно около 25% времени разработки.

Безусловно, вам необходим запас времени: всегда обнаруживаются неучтенные задачи, трудности, ошибки. Сколько процентов надо на это накидывать? Популярно мнение, что надо умножать сроки на 2. Это не лишено смысла. Минимальный, абсолютно необходимый запас – 30% срока, без этого за дело не берутся даже при составлении банальнейшего дополнения к игре. Но начинающим точно нужно больше.

Этот запас надо встраивать не в финальный срок (дописывая в конце «три месяца на непредвиденные трудности»), а в каждый этап проектирования. Например, если вы считаете, что на 50 монстров вам понадобится 4 месяца – пишите 6. Вам ведь нужно будет отчитываться за каждый этап…

С затратами все достаточно легко: просто сосчитайте зарплаты сотрудников и время их работы. Но не забудьте накладные расходы, вроде техники, офиса, интернета…

Немного косметики

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

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

Особенно это важно, когда вы готовите ДД для представления иностранному партнеру. 90% англоязычных издателей вообще не будут рассматривать текст, написанный на пиджин-инглиш. Я отнюдь не шучу.

Вместо заключения

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

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

Американец закончил бы этот текст примерно так: «Это работает! У меня это сработало!».

Источник