О том, что для серьезных проектов принято создавать дизайн-документ, знают почти все, кто так или иначе заинтересован возможностью сделать собственную игру. Однако мало кто из новичков в игровом дизайне самолично видел хоть один образчик, а потому в народе о нем бытуют ну очень странные представления.
Сегодня мы поговорим о том, зачем вообще нужен такой документ, каким он может быть и с чего начать его написание. Кроме того, речь пойдет о том, как своим дебютным проектом вызвать интерес у богатых мира сего.
Слово предоставляется Мареку Хефнеру, человеку, который по долгу службы регулярно рассматривает эти тексты и решает, какой из них порекомендовать западным издателям.
– Псмит
Скажу вам честно: я не сторонник мнения, будто дизайн-документ (далее – ДД) – это «половина всей работы». Мне даже случалось видеть успешные игры, написанные вообще без этого этапа; правда, последний такой пример встретился мне 4 года назад.
И тем не менее ДД – настолько важная штука, что просто диву даешься, сколько странных легенд о них ходит. Эти мифы поддерживаются даже вполне серьезной игровой прессой; порой ДД описывают так, что его можно перепутать с журнальным preview, бюрократическим отчетом «О динамике развития популяции долгоносика в полях Тютюкинского района» или страховым договором.
(Если задуматься – что тут удивительного? Если серьезные игроки порой верят, будто гейм-дизайнер – это человек, который делает игровую графику, когда на самом деле это – автор самой игры, ее геймплея…)
Конечно, ДД бывают разными, и единого их формата на сегодняшний день не существует; есть несколько «философских школ», и, если вы имеете в виду конкретного издателя для своей игры, неплохо бы разведать, что принято считать достоинствами ДД в этой компании. Однако ряд принципов сохраняется везде.
Я хочу рассказать не только о том, как надо делать ДД, но и о том, как лучше его не делать. А заодно развенчаю несколько очень популярных мифов и поделюсь соображениями о том, как проще всего произвести впечатление на издателя.
Миф первый. Чтобы договориться с издателем, достаточно подготовить ДД.
Если вы – начинающий разработчик, крайне желательно показать наглядно, что ваши программисты и художники на что-то годны. Другими словами – предъявить хоть какую-то демо-версию. Она может выглядеть очень по-разному: иллюстрировать возможности графического движка или, наоборот, почти без графики показывать геймплей, но без нее ваши шансы очень малы.
И все же без дизайн-документа – еще меньше.
Двуединство
Задумываясь о дизайн-документе, в первую очередь надо понять, что вы пишете как бы два документа в одном. Первый предназначен для вас самих, второй – для ваших потенциальных издателей и партнеров. И все же это должен быть один и тот же текст.
Издателю он нужен затем, чтобы убедиться в серьезности и продуманности ваших планов. Другими словами, ваш партнер хочет знать, понимаете ли вы, что и как собираетесь делать. Вам – чтобы ваши действия подчинялись четкому плану, в противном случае сроки вы сможете соблюсти только при исключительно благоприятном расположении звезд.
Часто начинающий разработчик пытается написать два документа. В одном он рассказывает издателю, какая у него будет замечательная игра, а в другом составляет реальные рабочие планы. Потом он искренне удивляется, когда от него начинают требовать буквального соответствия продукта «издательской» бумаге.
ДД должны прочесть – и внимательно! – все разработчики. Не только затем, чтобы выловить там возможные «дыры», а еще для того, чтобы все без исключения понимали, какую игру они делают.
Вообще-то ему действительно нужно два документа: издатель сперва захочет ознакомиться с кратким перечнем достоинств проекта, и только потом – с подробным ДД. Только не сделайте ошибки и не попытайтесь выдать вашу рекламку за ДД; вас тут же перестанут считать серьезным человеком.
Прежде чем переходить к ДД, поговорим об этой самой рекламке; ведь если она написана плохо, шансы на то, что ваш проект вообще удостоится внимания, падают до нуля.
Ознакомительный текст
Не пытайтесь описать в этом тексте все величие своего замысла. С самого начала помните, что объем этого текста – не больше странички, а хороший тон предписывает ограничиться 2/3 страницы – примерно 2 000 знаков.
Начните с названия игры и ее жанровой принадлежности (ее надо описать максимально четко: даже если вы собираетесь слить в экстазе все существующие жанры, придется выделить главный и указать поджанр. Например: пошаговая стратегия. Если очень неймется, добавьте свое «с элементами ролевой игры», но вообще-то для этого еще будет место).
Это интересно: восточноевропейские, немецкие и английские издатели предпочитают названия, которые ни на что не похожи, а заокеанские – такие, которые перекликаются с уже известными широкой публике. Не случайно «Демиурги» прижились на Западе под псевдонимом Etherlords… Ходовые схемы для Америки – 2 слова плюс "of” или "and”. А то, что вы на самом деле хотите сказать об игре, вы скажете после двоеточия…
Далее в одном абзаце, 1-3 предложениями, скажите, чем ваша игра будет наиболее привлекательна. Здесь ваша главная задача – указать качественные, а не количественные отличия. Если у вас будет не 50 видов войск, а 150, вы еще успеете об этом сообщить. И не надо писать, что у вас будет самый умный ИИ: все равно вам никто не поверит. Пишите в первую очередь об устройстве самой игры, а не о ее технической реализации.
Наконец, третий абзац стоит посвятить объяснению, почему вашу игру купят. Тут нужно изящно намекнуть издателю, что ваша игра чем-то похожа на популярные проекты и при этом лучше их и больше соответствует нарождающейся тенденции рынка.
Это ошибка: ни в коем случае не предлагайте издателю присоединиться к волне, которая уже на спаде. Не стоит рекламировать соответствие моде позапрошлого года. Что-что, а моду на рынке издатели знают хорошо.
Далее укажите, какой предполагается срок и общая сумма затрат на проект.
(Это означает, между прочим, что, даже если ваш партнер по каким-то своим причинам не требует у вас дизайн-документа – чего не бывает на свете? – из этого не следует, что ДД у вас может не быть. Потому что наука знает только два способа определить сроки проекта: по ДД и путем «рулетки». Причем во втором случае рулетка обычно оказывается русской.)
Если у вашей команды есть заслуживающий упоминания послужной список – это будет следующим пунктом. Если нет, кстати, задумайтесь, не следует ли его создать. Сегодня это легче, чем пять лет назад… Впрочем, об этом чуть ниже. Если имеется готовая демо-версия (хорошо бы это было так!) – скажите об этом.
Оставшееся место посвятите достоинствам проекта. Так и озаглавьте. Вот здесь вы уже можете упомянуть и о блистательной графике, и о 150 родах войск, и о прочих вкусностях. Сделайте это в виде списка, по одному преимуществу на строчку, и говорите лаконично, как истинные спартанцы. В некоторых случаях можно упомянуть, что именно это сегодня в моде (только убедитесь, что это и впрямь так, и не пишите банальностей, вроде "в наше время на рынке ценится трехмерная графика”).
Миф второй. Чем больше расхвалите свой проект – тем лучше.
Главное, что на самом деле оценивает издатель, обдумывая перспективы сотрудничества с дебютантами, – это их чувство реализма. Но и в самоуничижение не впадайте – зачем кому-либо проект без достоинств?
Миф третий. Издателя интересует графика и прочие модные штучки, а вовсе не ваши идеи геймплея.
Подумайте: зачем тогда ему вообще иметь дело с вами, а не с зарекомендовавшими себя профессионалами? От новичков ожидают в первую очередь оригинальных идей, а не серых клонов.
Дешевый способ прославиться
Миф четвертый: издатели рассматривают серьезно только ту команду, которая уже сделала хоть одну игру.
Если вы и в самом деле считаете, что ваша самая сильная сторона – идея и дизайн игр, то у вас есть отличная возможность заработать себе несколько хвалебных строчек в резюме (а если вы предпочитаете программирование или рисование – то, быть может, лучше попытать счастья в какой-то из имеющихся фирм, предложив им свои услуги?).
Я имею в виду изготовление модификаций и карт к существующим играм. Здесь можно с блеском проявить свои таланты игрового дизайнера, заработать награды вроде «Модификация месяца» и гордо предъявлять их потом в знак своей компетентности и способности довести дело до конца.
В наше время большинство приличных игр обладает средствами для расширения руками игроков. Хорошие стратегии почти всегда снабжены редактором карт, а то и кампаний, для многих боевиков имеются редакторы уровней, ну а о могучих редакторах игрового мира для Neverwinter Nights и Morrowind слышали, наверное, все.
Конечно, хорошую карту, а тем более – кампанию или ролевой модуль, не сделаешь за один вечер… но на хорошую игру понадобится много больше времени. Не пожалейте сил, это окупится.
Не делайте шуточных модов, разве что собираетесь поразить мир очередным «Штырлицем» (а может, лучше не надо?).
Доведите вашу работу до конца. Если издатель, не дай Бог, увидит на сайте, где лежит ваш модуль, примечание «альфа-версия», он с высокой вероятностью решит, что это – признак неумения доделывать свои начинания. И тогда ваша реклама ударит бумерангом вам же в лоб.
Есть и второй способ, как ни странно – менее популярный: сделать приличную сетевую игру на основе Flash или Java, и предъявить издателю высокую посещаемость сайта с нею. Но это, во-первых, менее надежно, а во-вторых – требует изучать еще и эти технологии.
Это важно: для издателя ценнее, если модификация сделана вашей командой, нежели вами одним. Но это не значит, что можно просто дописать ваших сотрудников в список авторов; могут ведь поинтересоваться, что именно делал здесь аниматор или программист ИИ…
А кстати, что мы собрались делать?
Разговор о том, как сделать ваш проект интересным – тема совсем другой статьи, мы сейчас говорим о дизайн-документах. Но все-таки пара слов не помешает.
Одна из самых важных задач – соблюсти баланс между глобальностью и примитивностью.
Если ваш проект будет претендовать на звание «убийцы Half-Life 2», или пытаться завоевать рынок онлайновых игр, или обещать 300-часовую ролевую кампанию – ваши шансы резко снижаются просто из-за роста сроков и денег. Кроме того, даже если издатель согласится, подумайте, нужно ли вам это? Не забудьте, что с компанией, у которой есть уже изданная игра, договор заключается на совсем другие суммы. Может, ваш будущий мегахит лучше продать подороже, а тропинку к этому протоптать чем-нибудь попроще?
Но если ваша заявка демонстрирует глубочайшее смирение, и очевидно, что на проекте крупными буквами будет написано: «малобюджетный», то велика вероятность, что издатель не сочтет нужным тратить на нее время и силы.
Я упомянул, что не стоит пытаться первым проектом прорываться на онлайновый рынок. Значит ли это, что не всякий жанр годится для дебюта?
Да, значит. По крайней мере, они годятся по-разному.
Action. Делать заявку на боевики (хоть шпионские, хоть обычные) есть смысл только тогда, когда на руках у вас – прообраз графического движка, выдающий чертовски убедительные картинки. Если вы только планируете его создать – лучше не надо. Скорее всего, вам просто не поверят. Тут могут помочь разве что уровни, сделанные для одного из хитовых боевиков. Но – только в том случае, если графически и в игровом смысле они безупречны…
Ролевая игра. Здесь для убедительности крайне желательно предъявить модули собственного изготовления. Главное, в чем будет сомневаться ваш издатель, – это в работоспособности команды: ведь ролевые игры требуют намного больше сил, чем, к примеру, стратегии. Докажите ему, что вы умеете доводить работу до конца.
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% англоязычных издателей вообще не будут рассматривать текст, написанный на пиджин-инглиш. Я отнюдь не шучу.
Вместо заключения
Этот текст можно было бы, подражая Карнеги, озаглавить так: «Как завоевывать деньги, оказывать влияние на их обладателей и, получив деньги, не пожалеть об этом».
Напоследок хочу сказать вот что: не считайте, что издатели глупее вас, и не пытайтесь обходиться с ними, как продавец сувениров с иностранным туристом. Конечно, вы вправе мне не поверить, потому что я нахожусь на другой стороне баррикад, – но я вас предупредил.
Американец закончил бы этот текст примерно так: «Это работает! У меня это сработало!».
Я закончу немного иначе:
– На мне это сработало.
