Если вы не можете полюбить игру, полюбите ее аудиторию

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

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

Но, возможно, вы не смогли найти ту часть игры, которую могли бы полюбить, и это из-за того, что вы, к примеру, не являетесь ее целевой аудиторией. В этом случае, не воспринимайте ее как игру для себя – воспринимайте ее как то, чем она является на самом деле – игрой для определенной аудитории. Вспомните о том, как вы когда-то долгое время готовились, чтобы сделать особенный подарок человеку, который вам дорог. Вспомните свое возбуждение, когда вы смотрели на выражение лица этого человека, когда он открывал и видел этот подарок. Предвкушение этого момента заставило вас вложить так много мысленной энергии в выбор подарка, упаковку и саму презентацию. Вы тщательно создавали этот момент, потому что вы любите этого человека и хотите наблюдать моменты, когда он счастлив. И что же делало его таким счастливым? Просто подарок? Конечно, нет. Его сделало счастливым то, что вы любите его настолько сильно, что создаете особые моменты только для него одного. Этот момент излучает любовь, которую вы в него вложили, и ее лучи проникают прямо в сердце. Если вы сможете взять такую любовь и вложите ее в игру, которую создаете для своей аудитории, то эта игра будет излучать лучи этой любви, которые будут попадать прямо в сердце вашей аудитории. Они станут считать игру особенной, как только увидят, что кто-то по-настоящему заботится о том, какие впечатления от игры они получают, а осознание того, что кто-то о тебе заботится – это очень особенное чувство. Дизайнер не может его подделать – оно идет изнутри. Как сказал когда-то великий иллюзионист Генри Терстон:

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

Если даже это не работает, и если вы понимаете, что вы не только не любите свою игру, но и не испытываете особых чувств к ее аудитории, остается только одна вещь: Притвориться. Звучит так, как будто я лицемерю. Разве я только что не сказал, что любовь невозможно подделать? Но что-то странное происходит, когда мы притворяемся, что любим что-то – сквозь оболочку притворства начинают пробиваться ростки настоящей любви. Вам когда-либо доводилось быть частью группы, которой иногда нужно было выполнять откровенно скучные задания? Скажем, целый день убирать дом. Все боятся этого момента и постоянно ворчат, когда он наступает. Затем кто-то говорит наполовину шутливо: “Ну же, давайте, это должно быть улетно! Сейчас так повеселимся!”. Отовсюду слышится саркастичный смешок, и, только шутки ради, все приступают к работе, притворяясь, что “это весело”. И только благодаря этому притворству, уборка вскоре действительно становится веселой – и, по иронии судьбы, все начинают любить ее. Если вы не знаете, как полюбить что-то, просто спросите себя, какие вещи делал бы тот, кто действительно любит вашу игру, и сами начинайте делать эти вещи. Вы, возможно, будете приятно удивлены теми трансформациями, которые произойдут внутри вас.

Линза #88: Линза Любви

Чтобы воспользоваться этой линзой, спросите себя:   ● Я люблю свой проект? Если нет, как я могу это изменить? ● Все члены команды любят этот проект? Если нет, как это можно изменить?

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

Совместный дизайн

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

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

● Будете иметь больше идей

● Сможете быстро отмести бесполезные идеи

● Сможете посмотреть на игру с разных точек зрения

● Заставите всех членов команды относиться к вашему дизайну, как к своему собственному

Если вся команда участвует в дизайне, ваша игра будет сильнее, и все будут приступать к применению ее дизайна с уверенностью в том, что они его понимают. Это очень важно, потому что далеко не все решения по дизайну принимаются заранее. Сотни небольших решений принимаются постоянно – если не дизайнерами, то программистами, художниками и другими людьми, работающими над вашей игрой. Если все эти люди имеют полное и одинаковое понимание дизайна игры, все эти маленькие решения будут идти на пользу дизайна, и проект получит ту прочность и то единство, которых он не смог бы достичь при любых других обстоятельствах. Это не редкость, когда разные люди, участвующие в проекте, считают свой вклад самой важной частью игры – и это нормально. Это лишь означает, что многие члены команды считают некоторые элементы игры своей собственностью, и поэтому испытывают чувство ответственности по отношению к ним. Один из способов усилить это чувство – избегать “чрезмерной конкретности” в дизайне. Если вы оставите некоторую недосказанность в техническом проекте вашей игры, желательно, в тех частях, в которых вы не уверены, это заставит разработчиков, работающих над программной составляющей вашей игры, подумать о том, каким должен быть ее технический проект, и, в итоге, придумать, как лучше всего его составить. Поскольку они наиболее часто работают с этой частью игры, у них иногда вырабатывается инстинктивное понимание технической документации – и если их идеи окажутся действительно стоящими, и вы добавите их в игру, они будут чувствовать настоящую гордость за те элементы игры, которые они считают своими собственными.

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

1 Изначальный мозговой штурм:Как можно больше людей должны быть вовлечены.

2 Независимый дизайн:Члены главной дизайн группы придумывают идеи независимо друг от друга.

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

4 Презентация дизайна:Главная дизайн команда отчитывается о своем прогрессе перед всей командой, готовится выслушивать комментарии и критику. Это часто превращается в мозговой штурм, который запускает очередной круг повторяющегося цикла.

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

Командная коммуникация

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

1 Объективность. Это условие идет первым, потому что оно не соблюдается чаще всего. В порыве дизайнерской страсти, очень просто привязаться к одной идее, которая пришла вместе с внезапным озарением. Но если эта идея не нравится остальным членам команды, куда она вас приведет? Никуда, если вы собираетесь развязать войну мнений и внутренних чувств. Инструмент, который может спасти вас – Линза #12: Линза Постановки Проблемы. Он может дать вам ту объективность, которая вам нужна. Все обсуждения должны строиться на том, как хорошо дизайн идеи решает поставленные проблемы. Личные предпочтения по поводу этих идей не имеют значения – главное, чтобы эти идеи решали проблемы. Никогда не говорите об идеях как “моя идея” или “идея Сью” – говорите объективно: “Идея космического корабля”. Это не только поможет отделить идеи от личностей (сделав их достоянием команды), но и сделает их более четкими. Другой хороший прием – формулировать альтернативы как вопросы. Например, вместо того, чтобы говорить “А – это плохо. Мне больше нравится Б”, просто скажите “А что если мы сделаем Б вместо А?”, что позволит группе вместе обсудить положительные и отрицательный стороны А и Б. Это тонкое различие, но практически всё, что касается управления командной коммуникацией – это тонкие понятия. Если вы, как дизайнер, сможете выработать в себе привычку быть объективным, все будут без колебаний обращаться к вам с вопросами по дизайну, потому что они будут знать, что застрахованы от неудобной ситуации, когда вы самостоятельно “выносите решения” по дизайну – они получат лишь честный, объективный и полезный фидбек. Позже люди захотят, чтобы вы участвовали во всех обсуждениях дизайна, потому что, благодаря вашей объективности, ваше присутствие в комнате сможет помочь понизить градус дискуссии между людьми с менее объективным отношением к делу. А самое лучшее то, что когда все чувствуют объективность, каждая идея воспринимается всерьез, что может подтолкнуть даже самых застенчивых членов команды высказывать свои идеи, так что много идей, которые, в ином случае, остались бы в тени чьей-то неуверенности, выйдут на свет.

2 Ясность. Это простое условие. Если в коммуникации нет ясности, значит, стоит ожидать непонимания. Когда вы что-то объясняете, спросите у людей, понимают ли они, о чем вы говорите. Если это возможно, проиллюстрируйте ваши идеи. И если кто-то говорит что-то неясное, никогда не притворяйтесь, что вы его понимаете. Потому что если все члены команды не будут иметь единого видения дизайна, на какую осмысленную коммуникацию можно рассчитывать? Но понимание друг друга – это только половина ясности, другая половина заключается в точной подаче конкретной информации. Есть большая разница между тем, чтобы сказать продюсеру “Система боя будет готова к четвергу” и “Я вышлю вам по электронной почте описание интерфейса для пошаговой системы боя на 3-5 страниц в четверг в 5 часов вечера”. В первом случае вы оставляете много места для недопонимания, в то время как во втором – предоставляете конкретные детали о вашей работе, практически нивелируя вероятность недопонимания.

3 Перманентность. ЗАПИСЫВАЙТЕ ВСЁ! Советую вам это очень настойчиво. Вербальная коммуникация имеет кратковременный эффект – она порождает много недопонимания и легко забывается. Те моменты, которые были записаны, может легко проверить любой член команды. Используйте все доступные вам средства сохранения информации – записные книжки, электронные письма, форумы, списки рассылки, файлы, вики, печатные документы и т.д. Убедитесь в том, что кто-то один на собрании всегда делает записи, которыми он сможет впоследствии поделиться со всеми остальными членами команды. Когда вы делаете рассылку по теме дизайна, убедитесь в том, что вы разослали это письмо всей команде. Так, вы, вероятнее всего, не забудете ни об одном из членов вашей команды, и даже не дадите им почувствовать, что о них забыли.

4 Комфорт. Знаю, что этот пункт звучит немного глупо. Что связывает комфорт и коммуникацию? А вот что: Когда людям комфортно, их ничего не отвлекает, и они общаются более свободно. Убедитесь в том, что у вашей команды есть тихое место для общения, с правильной температурой, достаточным количеством стульев и большой письменной поверхностью; короче говоря, физически комфортное место. Также вы должны убедиться в том, что члены команды не голодны, не испытывают жажду или переутомление. Коммуникация с людьми, которые испытывают физические неудобства, ужасна. Но одного физического комфорта не достаточно – они должны также испытывать эмоциональный комфорт, что приводит нас к следующему пункту.

5 Уважение. Мы уже говорили о том, что если вы хотите стать хорошим дизайнером, вам нужно научиться хорошо слушать. Но чтобы правильно слушать, вам нужно уважать человека, которого вы слушаете. Люди, которые не чувствуют, что их уважают, обычно говорят мало, а когда все-таки говорят, то пытаются скрыть свои настоящие чувства, потому что боятся неправильной трактовки своих слов. Люди, которые чувствуют, что их уважают, говорят свободно, открыто и честно. Уважать людей просто, если вы помните о том, что это нужно делать. Просто всегда относитесь к ним так, как вы бы хотели, чтобы относились к вам. Не перебивайте их и не закатывайте глаза, даже если вам кажется, что они говорят полную ерунду. Всегда пытайтесь быть вежливыми и терпеливыми. Говорите что-то хорошее, даже если приходится немного приврать. Помните, что остальные люди больше похожи на вас, чем наоборот, – найдите, что у вас общего, потому что всегда легче уважать человека, который похож на тебя. Если ничего не получается, про себя повторите мантру: “Что, если я не прав?” Если вы каким-то образом оскорбили или обидели другого человека, не торопитесь защищать то, что вы только что сказали. Лучше поспешите извиниться, и сделайте это как можно более искренне. Потому что, если у вас получится всегда уважать членов вашей команды, вы гарантированно получите их уважение в ответ. А когда все чувствуют уважение, ничто не препятствует их эффективному общению.

6 Доверие.Без доверия достичь уважения невозможно – если я не верю тому, что ты говоришь и делаешь, откуда я могу знать, что ты меня уважаешь? Доверие не появляется само по себе – его нужно постепенно выстраивать. По этой причине качество коммуникации значит меньше, чем ее количество. Люди, которые видят друг друга каждый день, постоянно разговаривают, постоянно решают проблемы вместе, постепенно узнавая, как они могут доверять друг другу, и в каких случаях. В группе, состоящей из людей, которые едва знают друг друга, и встречаются только раз в месяц, нельзя говорить ни о каком доверии. Это та сфера, где цифровая коммуникация недостаточно хороша – во время общения лицом к лицу происходит что-то особенное, позволяющее нам принимать подсознательные решения о том, кому мы можем доверять, и когда. Самый простой способ узнать, кто и кому доверяет в вашей команде – посмотреть, кто сидит на обеде вместе. Большинство животных очень выборочно относятся к партнерам по трапезе, и люди не являются исключением. Если художники едят отдельно от программистов, вероятно, что у вашей команды есть проблема с коммуникацией. Если команда Xbox обедает отдельно от команды Playstation, это может быть признаком проблемы с портированием. Предоставьте вашей команде как можно больше возможностей быть вместе и общаться друг с другом, даже если это общение не связано с вашим проектом, ведь, чем больше члены вашей команды общаются (о чем угодно!), тем больше они узнают, можно ли друг другу доверять – именно поэтому так мало игровых студий предоставляют своим сотрудникам отдельные кабинеты – вместо этого их всех усаживают в просторные залы, где они просто обречены ежедневно общаться друг с другом лицом к лицу.

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

8 Приватность. Быть честным не всегда легко, потому что правда бывает болезненной. И несмотря на то, что мы все надеемся оставаться объективными в вопросах дизайна, иногда просто невозможно избежать проявления личной гордости и эго во время рабочего процесса. Говорить о таких вещах при всех бывает трудно, а, подчас, невозможно. Люди более склонны делиться своими переживаниями во время разговора с глазу на глаз, чем на людях. Старайтесь по возможности находить время для личных разговоров с каждым из членов дизайн команды – они с удовольствием поделятся с вами своими идеями и обсудят те проблемы, которые им неудобно обсуждать на людях. Эти разговоры с глазу на глаз также могут помочь вам расположить людей к себе и заслужить их доверие: больше доверия ведет к большему количеству честного общения, которое формирует больше доверия и т.д.

9 Единство. Во время процесса дизайна могут возникать многочисленные мнения и конфликты о том, что для игры правильно. Это вполне естественная ситуация. Когда все заканчивается, команда обычно приходит к решению, которое устраивает всех. Помните: там, где есть два человека, может возникнуть несогласие. Если один из членов команды слишком сильно настаивает на определенном дизайн решении, вы должны относиться к нему с достаточным уважением, и работать с ним, пока не сможете прийти к осмысленному компромиссу. Спросите его, почему это решение настолько важное для него, и, возможно, благодаря его объяснению все остальные члены команды тоже поймут, почему оно настолько важное. Если с этим не получилось, лучше все просто спросить у этого человека: “Что мне нужно сделать, чтобы ты был в деле?”. Возможно, у вас не получится сразу уладить вопрос с отличиями во мнении, но если чего-то и нельзя делать, так это игнорировать их. Так же, как один неработающий цилиндр может вдвое сократить производительность мотора и, в итоге, привести к поломке, так и один член команды, который не согласен с вашим дизайном, может ослабить всю команду или даже развалить ее. Последняя цель коммуникации – это единство.

Линза #89: Линза Команды

Чтобы убедиться в том, что ваша команда работает как хорошо налаженный механизм, спросите себя:   ● Эта команда подходит для этого проекта? Почему? ● Командная коммуникация происходит объективно? ● Командная коммуникация происходит ясно? ● Членам команды удобно друг с другом? ● В команде преобладают настроения всеобщего доверия и уважения? ● Эта команда способна объединяться вокруг единых решений?

Дизайн и разработка игры – это сложные процессы. Если вы не имеете много талантов, а ваш проект не крошечный, вы не сможете сделать игру без команды. Люди намного важнее идей, потому что, как сказал Эд Кэтмул из Pixar, “Если вы дадите хорошую идею посредственной группе, они ее испортят. Если вы дадите посредственную идею хорошей группе, они ее исправят”.

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

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

Глава 24

Команда иногда общается посредством документов

Миф о Геймдизайн Документе

Многие начинающие геймдизайнеры и другие мечтатели имеют очень интересное представление о том, как работает процесс создания игры. Не имея ни единого представления о Правиле Цикла, они уверены в том, что для дизайна игры требуется гениальный геймдизайнер, который сидит в одиночестве перед клавиатурой и печатает свой гениальный Геймдизайн Документ (ГДД). Когда этот шедевр подойдет к завершению, нужно будет только передать его команде умелых художников и программистов, и ждать, пока они воплотят это революционное видение в жизнь. “Если бы только”, подумает расстроенный потенциальный геймдизайнер, “я мог узнать правильный формат ГДД, я бы тоже мог стать профессиональным геймдизайнером! У меня полно идей – но без этого волшебного шаблона я никогда не смогу делать игры”.

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

ВОЛШЕБНОГО ШАБЛОНА НЕ СУЩЕСТВУЕТ!

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

Для чего нужны документы

Дизайн документы выполняют два предназначения: памятьи коммуникация.

Память

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

Коммуникация

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

Типы игровых документов

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

Рис. 24.1

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

Design

1 Game Design Overview(Обзор дизайна игры).Документ, описывающий основные цели и особенности игры, который может занимать всего несколько страниц. Этот документ обычно пишется для начальства команды, чтобы те, не углубляясь в детали, могли понять, что представляет собой ваша игра, и для кого она предназначена. Обзорный документ может быть полезен и для всей остальной команды, потому что помогает им представить полную картину игры.

2 Detailed Design Document (Рабочий проект). В этом документе детально описывается механика игры и ее интерфейс. Данный документ обычно выполняет две цели: позволяет дизайнеру помнить все мельчайшие идеи, которые приходят ему в голову, а также помогает ему передавать эти идеи программистам, которые должны писать по ним код, и художникам, которые должны заставить эти идеи хорошо выглядеть. Поскольку данный документ редко показывается людям, не связанным с проектом, он редко бывает упорядоченным. Достаточно того, что этот документ может разжечь дискуссию, и никому не даст забыть о важных деталях. Это обычно самый длинный документ, который, кстати, редко кто доводит до ума. На полпути к окончанию проекта, об этот документе часто забывают – к этому моменту сама игра содержит большинство важных деталей, а те, которых в игре еще нет, обычно распространяются между членами команды при помощи неформальных средств, таких как электронные письма или короткие записки.

3 Story Overview(Обзор истории). Во многих играх для написания основного повествования и диалогов нанимают профессиональных писателей. Эти писатели обычно работают удаленно, то есть находятся далеко от всей остальной команды. Геймдизайнеру иногда бывает необходимо составить короткий документ, описывающий сеттинги, персонажей и действия, которые будут иметь место в игре. Бывает и такое, что писатели отвечают собственными интересными идеями, которые изменяют весь дизайн игры.

Engineering

1 Technical Design Document(Технический дизайн документ). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, отправку информации по сетям и за другие исключительно технические моменты. Обычно никто вне команды программистов не думает об этих деталях, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать все эти моменты в одном документе, так, чтобы когда к команде присоединялись другие люди, они сразу понимали, что и как должно работать. Так же, как и Рабочий проект, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры.

2 Pipeline Overview. Большая часть сложностей, сопряженных с программированием игры, связана с правильной интеграцией элементов арта в игру. Существует множество “можно и нельзя”, которым должны следовать художники, если они хотят, чтобы их арт правильно отображался в игре. Этот документ обычно составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

3 System Limitations (Системные ограничения). Дизайнеры и художники часто не имеют ни малейшего представления о том, что возможно, а что невозможно в той системе, материал для которой они создают (или они просто притворяются). Для некоторых игр программисты создают специальные документы, в которых дают четкое представление о границах системы, которые нельзя пересекать – о количестве фигур, одновременно показанных на экране, количестве сообщений об обновлениях за секунду, количестве одновременных взрывов на экране и т.д. Часто эта информация подается более детально, но если вы обозначите ее (желательно, в письменном виде), это может впоследствии сохранить вам много времени, к тому же подобные документы могут положить начало дискуссиям, на которых часто находятся креативные решения, позволяющие выйти за эти границы.

4 Art Bible (Библия арта). Если несколько художников собираются работать над одной игрой, то для того, чтобы создать единый целостный вид этой игры, им нужна некая инструкция, по которой можно было бы следить за соблюдением этой целостности. Библия арта – это документ, который и является подобной инструкцией. Это могут быть листы с персонажами, примеры окружения, примеры использования цвета, примеры интерфейса, а также всё остальное, что определяет внешний вид каких-либо элементов игры.

5 Concept Art Overview (Обзор концепт-арта). В команде есть много людей, которые должны понимать, как будет выглядеть игра еще до того, как работа над проектом стартует. Это достигается посредством концепт-арта. Но одного арта недостаточно – лучше всего использовать его в дизайн документе, поэтому часто художники работают вместе с дизайнерами, чтобы определиться с набором изображений, по которому можно будет увидеть то, как весь арт будет выглядеть в контексте дизайна игры. Эти ранние изображения можно увидеть везде – в Обзоре дизайна игры, в Рабочем проекте, или даже в технических документах, в которых они используются для того, чтобы лучше проиллюстрировать тот внешний вид игры, которого нужно достичь посредством технологий.

Management

1 Game Budget(Бюджет игры). Как бы сильно нам ни хотелось просто “работать над проектом от начала до конца”, экономическая реальность игрового бизнеса редко позволяет нам это делать. Обычно от команды требуется определиться со стоимостью разработки еще до того, как они будут полностью понимать, нам чем им придется работать. Стоимость проекта зачастую определяется посредством документа: часто это таблица, предназначенная для систематизации рабочего процесса по созданию игры. Данная таблица заполняется оценками сроков, которые переводятся в доллары. Продюсер или проект менеджер не могут сами высчитать эти цифры, поэтому им нужно поработать отдельно с каждой частью команды, чтобы максимально точно провести расчеты. Часто этот документ пишется одним из первых, поскольку без него трудно будет получить финансирование проекта. Хороший проект менеджер должен работать с этим документом на протяжении всего проекта, чтобы быть уверенным в том, что проект не выходит за границы того бюджета, который был озвучен.

2 Project Schedule (Расписание проекта). В хорошо отлаженном проекте этот документ обновляется наиболее часто. Мы знаем, что процесс дизайна и разработки игры сопряжен с большим количеством неожиданностей и непредсказуемых изменений. Тем не менее, без определенного планирования не обойтись – в идеале, это должно быть планирование, которое можно изменять, по крайней мере, раз в неделю. В хорошем расписании проекта перечислены все задачи, которые нужно выполнить, время, за которое это нужно сделать, а также люди, которые отвечают за выполнение каждой из задач. Желательно, чтобы в этом документе учитывался тот факт, что один человек не может работать больше сорока часов в день, а также то, что некоторые задачи нельзя начать, пока не будут выполнены предыдущие задачи. Иногда это расписание ведется в электронной таблице, а иногда – при помощи более специфичных утилит для проект менеджеров. Если вы работаете над средним или крупным проектом, резонно нанять отдельного специалиста, который будет вести этот документ.

Writing

1 Story Bible(Библия истории). Можно подумать, что история в игре определяется исключительно писателями (если таковые имеются), которые работают над проектом, но часто бывает так, что каждый из членов команды вносит осмысленные изменения в сюжет. Разработчику движка может показаться, что определенный элемент истории будет слишком сложно реализовать в техническом плане, и в связи с этим он может внести предложение об изменении этого элемента. У художника может быть интересная визуальная идея для абсолютно новой части истории, которую писатель даже не мог себе представить. У геймдизайнера может появиться новая идея для концепта геймплея, которая может потребовать изменения истории. Библия истории, в которой четко описывается все, что возможно, и что невозможно в мире вашей игры, упрощает задачу для тех членов команды, которые хотят внести свой вклад в игру, и, в итоге, помогает создать сильный сюжет, который будет хорошо интегрирован с артом, технологией и геймплеем.

2 Script(Сценарий). Если неигровые персонажи вашей игры будут разговаривать, их диалоги должны вытекать из определенных событий! Эти диалоги часто записываются в сценарий, который может быть как отдельным документом, так и дополнением к Рабочему проекту. Очень важно, чтобы геймдизайнер проверял все диалоги из-за высокой вероятности того, что некоторые реплики в диалоге могут противоречить правилам геймплея.

3 Game Turotial and Manual(Учебные пособия к игре). Видеоигры бывают сложными, и игрокам нужно как-то учиться в них играть. Внутриигровое обучение, интернет страницы и печатные учебные пособия – самые распространенные средства обучения. Текст этих пособий очень важен – если игроки не могут понять вашу игру, тогда как они смогут получать от нее удовольствие? Детали дизайна вашей игры скорее всего будут меняться, вплоть до последнего момента разработки, поэтому важно быть уверенным в том, что кто-то постоянно проверяет этот текст и вносит в него все актуальные правки.

Игроки

1 Game Walkthrough(Прохождение игры). Разработчики – не единственные, кто пишет документы об игре! Если игрокам нравится ваша игра, они будут писать свои собственные документы и выкладывать их для открытого чтения. Если вы будете изучать то, что ваши игроки пишут о вашей игре, вы сможете узнать в деталях, что им нравится, а что – нет, какие части игры слишком сложные, а какие слишком простые. Конечно, к тому времени, когд