Советы новичкам от опытного геймдизайнера
Прежде, чем начать рассказывать правила составления ГДД, давайте определимся, кто же такой геймдизайнер и какова его роль в команде. Ближайший аналог геймдизайнера в искусстве — это режиссёр. Он не играет в фильме, не занимается светом и декорациями и даже не держит камеру, но при этом именно он решает, как должен выглядеть фильм, чтобы он доносил зрителю те ощущения, которые хочет режиссёр. Также и геймдизайнер очень часто не умеет рисовать и программировать, но обязан уметь вызывать у игрока нужные ощущения.
Поэтому его можно назвать мозгом команды, тем, кто всегда контролирует то, что делают все остальные. Даёт задания и принимает работу. Поэтому главное умение геймдизайнера — находить общий язык со всеми в команде и делать так, чтобы они производили именно то, что есть в его голове. Поэтому в идеале нужно, чтобы каждый проект вёл один хороший специалист. О том, насколько трудно такого найти — это уже совсем другая тема. Просто давайте держать в голове, что эта статья — про хорошего геймдизайнера или того, кто хочет им стать.
Вы, наверное, заметили, что среди обязанностей геймдизайнера я не упомянул ГДД. Потому что в идеальном сферическом мире он не нужен. Там геймдизайнер всегда держит в голове описания всех фич, никогда не болеет, не увольняется и ему не нужно ни перед кем отчитываться. Геймдизайнерский документ игры — это вспомогательный документ. Страховка студии от пропажи геймдизайнера, памятка о том, что он хотел сделать, ведь разработка может подчас растягиваться во времени по не зависящим от него причинам, и памятка для специалистов о том, что они должны сделать, если вдруг отвлеклись.
Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.
Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.
Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.
Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.
Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.
Оглавление
В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном.
В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.
Вступление
Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.
Базовый геймплей
Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в match-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а match-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно его.
Для Wolfenstein это прежде всего ходьба и стрельба. В этот раздел стоит включить и управление базовым геймплеем. Смотреть мышкой, ходить вперёд-назад-влево-вправо, стрелять на левую кнопку, на три кнопки забиндить скиллы, а ещё одна — ульта, при попадании по персонажу у него отнимаются жизни, потом респаун и так далее.
На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.
Важно описать всё не красиво, а точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. «Не ошибается тот, кто ничего не делает» — отличная фраза для такой ситуации, потому что не реально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.
В первые три-четыре года работы геймдизайнером и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом: «Нормально?». Это значительно повышает их качество и снижает время, потраченное на разбирательства.
На минутку вернувшись к теме хорошего геймдизайнера, могу сказать, что он ежесекундно должен ставить себя на место других людей и задавать себе вопросы: «Что мне понятно из этого экрана?», «Что будет понятно обычному геймеру?», «Куда бы я нажал, если бы открыл это меню в первый раз?», «Как может человек интерпретировать эту иконку?» и ещё около миллиарда таких же. Главный же вопрос гейм-дизайнера (если уходить в дебри) это «Почему?» . От «Почему PUBG такой популярный?» до «Почему эта фича, которую я придумал, будет востребованной?».
HUD или интерфейс базовой игры
Head-up display — вся информация, которую видит человек, играя в шутер от первого лица. Здоровье, патроны, маркеры на экране и тому подобное. В других жанрах его аналог можно называть по-разному, но в любом случае это то, что видит игрок во время базового геймплея. Это одна из самых важных вещей в игре — игрок должен понимать то, во что играет, но при этом оно не должно отвлекать его от геймплея.
На самом деле искусство создания хорошего HUD — это огромная наука, специалистов в которой очень мало. Лучше всего составлять его совместно с арт лидом и быть готовым, что переделывать его наверняка придётся.
Интерфейсы и главное меню
Этот раздел статьи я хочу начать с рассказа о том, что такое мокап. Или варфрейм. В индустрии очень часто одни и те же сущности в разных студиях называются по-разному и если у вас что-то из того, что я называю в статье, называли по-другому — это проблема отсутствия единого профессионального словаря. Итак, это — схематичный набросок, сделанный в графическом редакторе человеком, максимально далёким от рисования. Здесь не стоит задача сделать красиво, здесь стоит задача сделать понятно. Чтобы художник без лишних вопросов гармонично расставил кнопки и всё остальное.
Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё, что угодно. Хоть карандашом на бумаге рисовать и фотографировать. Вместо картинок — прямоугольники, кружочки, стрелки. Минимализм.
Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.
Дальше идут мокапы всех окон, начиная с главного меню, и заканчивая самым маленьким окошком с кнопкой «Ок» . Не забывайте про то, как из них выходить! Под каждым мокапом должно быть краткое и понятное описание каждой кнопки и другого элемента окна и что они делают. Лайфхак для сложных экранов: возле каждого элемента поставить кружок с числом, а снизу пронумерованные пункты.
Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.
Остальные фичи
Дальше мы просто бьём проект на мелкие составляющие и описываем каждый в своём разделе. Туториал, инвентарь, диалоги, глобальная карта, прокачка — всё, что у вас есть. Описывается всё так же, как и базовый геймплей. К каждой из фич в раздел стоит запихнуть мокап того, что с ней связано.
Функциональные разделы
В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.
Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml-файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.
Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.
Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.
Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.
Чего НЕ должно быть в ГДД?
Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: «Пушка стреляет». Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.
Референсов. Картинки делают файлы неподъёмно большими, а те в свою очередь уменьшают их размер, поэтому их лучше заливать в папку на дропбокс, свн или гугл диск. Отдельную папку для каждой сущности, естественно. Видео лучше заливать на ютуб и давать прямые ссылки.
Текстов. Выделите под них отдельный файл, желательно xml, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.
Литературных описаний — никто не оценит.
А что дальше?
После того, как вы написали все ТЗ и лид программистов уверенно сказал «Нормально», вы переходите на главную часть работы геймдизайнера — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.
Не забывайте, что всё, описанное в этой статье — не нормативы (хотя если вы заберёте их себе и сделаете нормативами — я против не буду), а результат моей многолетней работы на позиции геймдизайнера. Никто не мешает вам сделать лучше.
#Руководства
- 28 фев 2020
-
14
Как написать дизайн-документ для игры
Оставьте надежду, если вы разрабатываете игру без диздока, потому что она вряд ли доживёт до релиза. Объясняем, зачем и как составлять диздок.
vlada_maestro / shutterstock
Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Дизайн-документ (сокращённо — диздок) — это документ, в котором содержится вся информация о создаваемой игре. Он нужен, чтобы команда, которая будет работать над проектом, понимала, что в итоге должно получиться.
Правильно составленный диздок позволяет избежать ситуаций, когда вы хотите создать песочницу с открытым миром, а левел-дизайнеры всё время присылают локации для коридорного шутера.
Подготовкой диздока занимается гейм-дизайнер — человек, который решает, какой будет игра. Но это не значит, что после составления диздока гейм-дизайнер больше не нужен: он контролирует процесс и принимает новые решения, если во время разработки что-то меняется.
В этой статье вы узнаете, что может быть в диздоке, а что там не нужно, как его составить и какие инструменты для этого использовать.
На мой взгляд, нет инструмента лучше чем Google Docs — он бесплатный, позволяет всем иметь актуальную версию документа, добавлять комментарии, предлагать правки и так далее.
Обычно я создаю папку для проекта и добавляю в неё всё: сам диздок, папку с референсами, технические задания и прочее.
Если нужно составить какую-то схему, то я пользуюсь бесплатным сервисом draw.io. В нём можно создавать что-то подобное:
Для подготовки референсов я использую GIMP (графический редактор с открытым исходным кодом) или просто делаю скриншоты и записываю экран.
- набор референсов;
- технические задания;
- сценарий игры;
- эскизы уровней и персонажей;
- фразы вроде «Боевая система как в Dark Souls, создание персонажа как в The Sims 4, разрушаемость как в Minecraft».
подробное описание всех аспектов игры. Для удобства его можно разбить на разделы: общая информация, геймплей, сюжет, визуал и так далее. В общем разделе можно написать следующее:
- Платформы: ПК, консоли или мобильные устройства.
- Технологии: будете ли вы использовать готовый движок или напишете свой.
- Язык: русский, английский.
- Аудитория: краткое описание людей, для которых делается игра. Полное описание можно вынести в специальный раздел.
- Жанр: нелинейное 3D RPG с открытым миром.
- Настроение: мрачное, светлое.
- Эмоции: какие чувства должна вызывать игра. При этом можно попытаться воодушевить игроков мрачной игрой или заставить почувствовать обречённость в светлой.
- Возрастное ограничение: увидев, что у игры рейтинг 18+ (или A в системе ESRB), дизайнеры спецэффектов сразу поймут, что вы ожидаете от них кровь, а не радугу.
- Количество пользователей, режим: будет ли игрок один или же в команде с другими игроками. Нужно ли подключение к интернету.
- Время, место и длительность для игры: где и как долго человек должен играть в вашу игру, чтобы получить те эмоции, которые вы хотите передать. Например, можно играть три минуты в метро или очереди или засесть на несколько часов вечером у себя дома.
- Главная игровая механика: краткое, но ёмкое описание того, чем будет заниматься игрок. В Mirror’s Edge главные механики — это бег и преодоление препятствий, а в Papers, Please — вершение судеб.
Можно добавить и другие пункты, лишними подробности не будут.
Все игровые механики важно описывать очень точно. Например, вы можете указать, что игрок будет сражаться с врагами, убивать монстров и захватывать замки. Под это описание подходят как Heroes of Might and Magic, так и World of Warcraft, а они сильно различаются.
Как будет происходить захват замков, зачем игрок будет это делать, как он будет управлять игрой в процессе — всё это нужно подробно описать.
Кнопка E — взаимодействие с предметом или персонажем.
Взаимодействие с предметом или персонажем: игрок наводит курсор на объект и нажимает клавишу E. Тип взаимодействия зависит от типа объекта:
- персонаж — разговор (см. раздел Диалоги);
- персонаж-торговец — открытие окна торговли (см. раздел Торговля);
- предмет без владельца — подобрать предмет в инвентарь;
- предмет с владельцем — украсть (см. раздел Кражи);
- интерактивные объекты — запуск события (см. раздел События).
При этом на разделы нужно прикреплять ссылки, чтобы членам команды было удобно ориентироваться в диздоке.
Сами же взаимодействия можно оформить в виде таблицы:
Карта содержит в себе действия, которые выполняет игрок, когда запускает игру. Тут отлично подойдут диаграммы:
На такой карте удобно отметить места, где нужно собирать статистику, подгружать из интернета дополнительные данные, выводить предупреждения и так далее. Вы даже можете составить отдельную диаграмму для каждого этапа игры.
В разделе с визуалом можно описать, какой вы видите игру: стиль объектов и текстур, шрифты, эффекты и так далее. Сюда же можно добавить, чего вы хотите добиться. Рассмотрим на примере пользовательского интерфейса.
Элементы игры:
- Полоса здоровья — красная полоса разрешением 250 × 50 пикселей. Расположение в верхнем левом углу экрана.
- Полоса энергии — синяя полоса разрешением 250 × 50 пикселей. Расположение в верхнем левом углу экрана.
- …
Визуальная часть должна создавать ощущение сказки, чтобы всё способствовало погружению в фэнтезийный мир игры. Интерфейсы нужны иммерсивные (например, при открытии инвентаря персонаж снимает рюкзак с плеч, расстёгивает — и игрок видит его содержимое). Графика может быть немного мультяшной, но реалистичной.
Необходимо проработать следующие элементы:
- индикатор здоровья;
- индикатор энергии;
- индикатор перегруженности…
В первом примере у дизайнеров не будет возможности использовать фантазию, поэтому они просто сделают то, что вы написали. И, скорее всего, это будет плохо. Во втором примере вы говорите им, чего хотите добиться (полного погружения), и приводите примеры (инвентарь). Дальше дизайнеры могут сделать всё, что посчитают нужным. В том числе они могут и вовсе отказаться от интерфейсов, заменив индикаторы анимацией персонажа: если он ранен, начинает хромать, перегружен — горбится.
Постарайтесь как можно подробнее описать, чего вы хотите, добавив ссылки на референсы, но доверьтесь дизайнерам: обычно у них лучше развито чувство стиля.
Какими должны быть уровни в вашей игре? Вы хотите, чтобы игрок исследовал мир или пытался найти нужную дверь? Посмотрите, как сделаны уровни в других играх, и проанализируйте, какой опыт вы получаете, когда их проходите.
Например, в игре Hitman из любой части локации всегда есть более одного выхода. Это позволяет игроку самостоятельно решать, куда ему идти и как добиваться своих целей.
Это самая сложная часть, потому что от гейм-дизайнера требуется хорошее знание математики. Баланс нужен для того, чтобы прохождение игры не превращалось в избиение младенцев, потому что игрок нашёл слишком сильное оружие. Ну или чтобы игрок сам не становился младенцем, потому что потратил время на прокачку небоевых навыков.
Будьте готовы, что во время разработки вам придётся переделать баланс, потому что тесты показали, что он работает не так, как вы ожидали.
В этом разделе нужно проработать игровой ИИ: как он должен себя вести, что должен уметь делать. Поведение ИИ должно быть понятным и предсказуемым. Даже если вы планируете добавить персонажей, которые могут слететь с катушек и начать всё крушить, игрок должен быть в состоянии понять, почему так происходит.
Если вы планируете ИИ, который будет реагировать на другие игровые системы, то можно составить таблицу, аналогичную той, что была в разделе про игровые механики.
Как уже говорилось выше, диздок — это не сценарий игры. В разделе про сюжет не нужно прописывать историю игрового мира. Достаточно описать сеттинг и важные особенности или моменты, вокруг которых будут вертеться игровые события.
Также в этом разделе можно описать основных персонажей и путь, который они проделают, — что-то вроде синопсиса к фильму.
Конечно, тут всё индивидуально: сюжет игры Pacman можно записать и в диздок, но если вы работаете на Дэвида Кейджа, то я желаю вам запастись терпением и купить несколько терабайт на Google Drive.
Каждая деталь важна, если вы хотите, чтобы члены вашей команды поняли, какой вы видите игру. Поэтому нужно стараться описать всё предельно точно и подробно.
Даже если вы создаёте игру в одиночку, всё равно составьте диздок — так вы яснее будете видеть, как развивается проект.
Если вы не уверены, что сможете воплотить свои фантазии в жизнь, то пройдите наш курс по геймдизайну. Вы научитесь не только придумывать игры, но и освоите современные инструменты для их разработки.
Научитесь: Профессия Геймдизайнер с нуля до PRO
Узнать больше
Как написать диздок
Время на прочтение
6 мин
Количество просмотров 119K
Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.
О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.
Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.
Почти всегда это вики-движок. Наиболее популярен Atlassian Confluence, но можно встретить и MediaWiki, как правило, с множеством плагинов и используемый в «старых» компаниях, и DocuWiki для небольших pet-project’ов или для маленьких студий. Поэтому готовность работы с документацией крупных проектов стоит начинать с умения работать с принятым на проекте вики-движком. То, что описывается как “диздок”, обычно заменено тремя отдельными документами в вики:
- Концепт-документ – краткое изложение самой идеи игры. Вида «У нас будет онлайн-игра про запуск и перехват ядерных ракет с бесконечным геймплеем, зрелищными спецэффектами и асинхронным PvP!». В нём описывается идея и основные составляющие игрового процесса (очень кратко), а также пара самых ключевых USP («unique selling point», то, что «продаст» идею игроку и уникально на рынке).
- Vision – это уже более развернутый документ, описывающий то, что хочется получить в итоге. Не сам игровой процесс, а всю игру, как конечный бизнес-продукт.
- Feature List (может быть обёрнут в другие документы в зависимости от модели разработки) – список с кратким описанием фичей, того, из чего состоит игра. К примеру, сборка ядерных ракет, аркадный перехват, асинхронное PvP, клановая система, система достижений, и так далее, как правило, со ссылками на отдельные документы с подробным описанием геймдизайна (об этом далее). Также в нем каждой фиче выставляется приоритет, стоимость и последовательность разработки.
Концепт-документ прост и используется для «закладывания фундамента» последующей документации, а также для того, чтобы новый сотрудник, инвестор или журналист могли быстро понять суть проекта.
Теперь переходим к Vision. Этот документ уже масштабнее, и обычно включает в себя следующие элементы:
- Краткое описание игры. Здесь уже не только основная идея, а игра в целом.
- Жанр игры.
- Целевая аудитория и исследование рынка.
- Примеры подобных игр на рынке и отношение к ним: конкуренты они или нет, есть ли пересечение аудитории, заимствование или противопоставление идей.
- USP (Unique Selling Points) игры – то, что выделит игру на рынке, и что использует маркетинг для привлечения трафика / новых игроков.
- «Формула успеха» – какие элементы игры будут самыми качественными / важными. Это может быть революционная графика, честная физика и т.д. Здесь в отличие от USP нужна не уникальность, а качество.
- Составляющие геймплея, вкратце.
- Сеттинг и стиль игры. Например, жестокий киберпанк в жёлто-серых тонах, светлое эпичное фэнтези в аниме-стиле, только куда подробнее и с примерами арта;
- Бизнес-модель, в том числе монетизация.
Последовательность и цели написания здесь очевидны: написав концепт-документ, геймдизайнер определяет основную идею. Далее в Vision он описывает, как и почему эта идея будет работать: на какой аудитории, за счет каких элементов проект будет пользоваться успехом, и как он будет зарабатывать деньги. При этом, написание концепта и Vision – итеративный процесс. Написав концепт, можно попробовать продать предложенную в нем идею (инвестору, начальству, на крайний случай – самому себе) и улучшать его до тех пор, пока идея не будет продана. Написав Vision, можно оценить, есть ли у игры шансы на популярность и коммерческий успех, и перерабатывать его, меняя USP, сеттинг, стиль и прочие переменные, пока не будет хоть какая-то уверенность в результате.
Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.
Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.
Конечно же, написание диздока на этом уровне сильно зависит от конкретной фичи – это может быть как вики-документ из 10 строк, так и целый раздел с десятком вложенных документов, прикрепленными таблицами с расчетами и ссылками на собранную статистику с серверов игры.
Однако в любой крупной компании нужно сочетать три вещи:
- Шаблоны. Да, шаблоны и творчество могут казаться трудно совместимыми, но если на проекте несколько геймдизайнеров, и каждый пишет, как ему вздумается, продюсерам и исполнителям это радости не добавит.
- Связи с другими документами, фичами и задачами. Каждый диздок – это не просто сферический текст в вакууме. Он входит в какую-то группу (например, PvP-фичи), ссылается на другие документы, содержит в себе список задач (в JIRA/Bugzilla/Trello/GitHub/…), оценки готовности, ссылки на отчеты тестеров и результаты плейтестов.
- Собственно, фан и геймплей! За всеми слоями структуры диздока важно не потерять то, что игра все-таки должна быть интересной и увлекательной, фича должна работать в плюс всей игре, а не просто выполнять оторванную от общей идеи задачу.
Что же стоит описать в диздоке? Помимо просто описаний самой фичи, есть немало других элементов:
- Автор и статус (черновик, в работе, сделано, отказались, устарело). Когда на вики сотни диздоков, и за долгие годы работали десятки геймдизайнеров, без этих простых разделов понять, какой диздок актуален, затруднительно.
- Текущая задача. Что хочется получить. К примеру, обеспечить игроков развлечением, пока тренируются войска в казармах.
- Причины возникновения задачи и необходимости решения. Важный пункт, наличие которого спасает от фичей «чтобы круто было» или «у конкурентов есть». Последнее – бич многих геймдизайнеров, когда фичи копируются подчистую, даже несмотря на то, что многие их элементы в разрабатываемой игре лишние, не будут работать или работают в минус, даже если у конкурента это USP и приносит огромный доход.
- Краткое описание решения. Чтобы можно было охватить общую идею.
- Развернутый дизайн. Подробное описание реализации.
- Ожидаемое поведение игрока, типовая сессия. Нужна для того, чтобы ответить на вопрос «А как в это играть?» с позиции игрока. Без этого легко получить фичу, которая вроде бы и имеет смысл, но игроки на форумах пишут “И что это вообще такое?”.
- Место фичи в игре и связь с другими фичами. Очевидно, фича должна поддерживать и дополнять другие фичи или общий геймплей игры, а не повторять или подавлять их собой.
- Задачи на реализацию и ассет лист. Список того, что нужно сделать, чтобы фича заработала: какие функции на уровне кода, что нарисовать художнику, нужно ли написать тексты реплик персонажей сценаристу и т.д. Иногда это составляет продюсер, но нередко и сам геймдизайнер.
- Требуемая статистика. Какую информацию собирать и анализировать с плейтестов и серверов. Как много времени игроки проводят в геймплее фичи? Ездят ли они на лошадях или автомобилях в фиче о средствах передвижения, стреляют ли из Сайги или Вепря в ближнем бою шутера?
- Требуемое тестирование (+ edge cases). На что QA-отделу обратить особенное внимание при проверке фичи. QA могут такое составлять и сами, но нередко только геймдизайнер может сходу сказать, что «если вдруг игрок эксплоитами типа сложения эликсиров наберёт 1000 навыка Торговли, то сможет продать товар дороже, чем купил, и сломает всю экономику! Поэтому нужно убедиться, что такое невозможно даже теоретически».
- Deployment и оперирование. Раздел для оператора. Как описать фичу в patch notes? Нужно ли выложить о ней статью в энциклопедию игры? Требуется ли что-то отобрать у игроков и выдать компенсацию для запуска фичи?
- Планы на будущее. Собственно, все идеи, которые могут улучшить фичу в будущем.
Конечно, этот список может меняться в зависимости от фичи, работодателя и степени срочности написания дизайна. Тем не менее, там, где это нужно и возможно, желательно не забывать о таких пунктах. Как правило, после всех этих пунктов диздока, геймдизайнера ждёт последний пункт… комментарии! Большинство вики-движков имеют такую функцию, и немало коллег — от других геймдизайнеров до программистов и тестеров — с радостью поделятся своими соображениями по поводу вашего геймдизайна.
На этой радостной ноте моя краткая статья заканчивается. Надеюсь, она была вам интересна. И можно переходить к комментариям!
07.02.2020
Тысячи людей мечтают однажды создаться собственную игру. Но будет ли она успешной или провалится ещё на стадии проекта? Во многом это определяется качеством написанной документации.
Геймдизайн-документ (диздок) — это детальное описание ключевых аспектов разрабатываемой игры. В этой статье преподаватели ВШБИ НИУ ВШЭ, авторы образовательных программ “Менеджмент игровых проектов” и “Основы создания игр”, поделятся своим опытом создания дизайн-документов для игровых проектов.
Зачем нужен диздок
Благодаря геймдизайн-документу каждый член команды видит “картину целиком”, что значительно облегчает понимание текущих задач на проекте. Кроме того, в диздоке фиксируются все доработки и правки, возникающие в процессе разработки. Написанием документации занимаются геймдизайнеры при поддержке всех ключевых специалистов (от программистов до технических художников).
При работе с небольшими проектами геймдизайн-документы обычно создаются в виде отдельного файла. Для крупных разработок используются специальные облачные хранилища с десятками отдельных ТЗ (технических заданий). Например, sunwiki, confluence или корпоративный сервис от Google.
Что пишут в диздоках
Как правило, геймдизайн-документ содержит всю необходимую информацию по проекту. Ниже мы перечислим самые основные пункты.
- Оглавление. На первой странице обычно описывают иерархию и структуру проекта. Здесь же находятся ссылки на все важные файлы и разделы, что существенно упрощает поиск информации о конкретной фиче (особенности проекта);
- Вступление. Здесь пишем краткое описание проекта: название, платформу, используемые технологии и целевую аудиторию игры;
- Геймплей. В этом разделе даем четкое и подробное описание игрового процесса. Важно! Сразу согласуйте описанные механики с командой программистов, чтобы избежать проблем в будущем;
- Интерфейс. В первую очередь описываем, что игрок видит во время кор-геймплея (базовой игры). Важно не засорять экран лишней информацией в этот момент. Дайте пользователю необходимые данные, но проследите, чтобы они не отвлекали от игрового процесса. Этот пункт геймдизайн-документа пишется совместно с командой художников;
- Мокап интерфейсов и главного меню. На этом этапе создаются графические наброски (схемы) всех игровых окон и интерфейсов. Они нумеруются, и под каждый экран пишется краткое описание;
- Игровые фичи. В этом разделе описываются ключевые механики: обучение, инвентарь, диалоги, глобальные карты, прокачка и другие. Обязательно создание мокапа для каждой фичи;
- Функциональные разделы: балансировка игры, панель администратора (необходимая для многопользовательских проектов), сборщик статистики (для f2p-игр), а также описание минимально играбельной версии игры (прототипа) для проверки востребованности ее базового геймплея.
Что не стоит писать в диздоке
Чтобы не перегружать информацией геймдизайн-документ, не стоит включать туда следующие пункты:
- Описание анимаций. Их следует описывать в отдельных задачах для аниматоров. Например, если речь идет о шутере, старайтесь указывать конкретное действие оружия с учетом особенностей движка и визуального стиля проекта;
- “Тяжелые” референсы. Как правило, примеров нужно много и «весят» они прилично. Лучше всего хранить картинки в отдельных папках, а на видео давать ссылки;
- Тексты и литературные описания. Под них лучше завести отдельные xml-файлы, которые будет удобно использовать программистам.
После написания диздока, он согласуется внутри команды. Особенно важно найти общий язык с программистами, на которых лежит задача по реализации задуманных механик.
После чего наступает следующая стадия разработки: пишется детальная документация по каждой фиче, ставятся задачи в таск-трекере и ведется работа с комментариями, возникающими по ходу создания игры.
Как написать идеальный дизайн-документ
Об этом вы сможете узнать, пройдя обучение по программе “Менеджмент игровых проектов” и “Основы создания игр” в ВШБИ НИУ ВШЭ в Москве. Вместе с опытными преподавателями создадите собственную игру, узнаете нюансы разработки, правила создания программной логики и механики.
Полученные знания пригодятся молодым специалистам, которые решили связать свою жизнь с индустрией компьютерных игр! По итогам обучения наши выпускники создают захватывающие проекты и участвуют в создании AAA-проектов от лучших российских студий.
Хотите стать геймдизайнером? Посмотрите лекцию нашего преподавателя Константина Сахнова!
Еще больше информации вы найдете на канале
МИП ВШБИ на YouTube. Подписывайтесь и не пропускайте свежие записи с открытых мероприятий ВШБИ НИУ ВШЭ.
← Назад к списку
2 октября 2018
2.10.18
14
11K
Содержание:
1. Теория (что такое дизайн-документ, из чего он состоит);
2. Практика (пример рабочего дизайн-документа);
3. Итоги (видеоигра, сделанная по дизайн-документу).
«Слово „трудность“ совершенно не должно существовать для творческого ума»
Г. Лихтенберг.
Вступление,
которое связывает текст с предыдущей частью
и вносит в него лёгкую философскую нотку
Вооружившись знаниями из первой части и потренировавшись в составлении концепт-документа «на кошках», самое время переходить к дальнейшей работе! На очереди – дизайн-документ. Иногда его ещё называют «диздок», реже – «ДД», а особые языковые садисты именуют «ГДД» (вероятно, от английского Game Design Document) и «Вижн» (от английского Vision – подразумевается «ви́дение игры»). Пожалуйста, не будьте языковыми садистами.
ЧАСТЬ №1.
Теория,
которая могла выглядеть сплошной стеной текста,
если бы не две картинки
Дизайн-документ – полное описание будущей видеоигры. От своего предшественника, концепт-документа, отличается максимально возможной детальностью и проработкой каждого затрагиваемого аспекта – это и механики, и уровни, и сюжет, и интерфейс, и вообще всё, что должно быть в игре. В определённом смысле дизайн-документ можно назвать подробным планом, в котором указано, что надо делать, но не указано кем и как (для этого существуют другие документы).
Дизайн-документ составляют для упрощения работы и повышения её эффективности. Большинство видеоигр включают в себя такое количество компонентов и взаимосвязей, которое не влезет ни в одну голову. А ведь есть ещё коллеги, они нуждаются в актуальной информации и если не смогут найти её «на бумаге», то начнут постоянно задавать вопросы. При вербальном обмене информацией сначала что-то забудется, затем вспомнится то, чего не было, потом перепутается всё, что уже есть, – и так снова и снова. Результаты обычно не радостные:
а) многократные переделки одних и тех же элементов;
б) дублирование работы;
в) хаос во взаимодействии с коллегами;
г) постепенное разноплановое изменение общей структуры и, как следствие, нарушение целостности готовой видеоигры.
Разработка игры без документации
С помощью дизайн-документа всего вышеперечисленного легко избежать или, по крайней мере, снизить до терпимого минимума. Ответственным за эту работу назначается игровой дизайнер (он же геймдизайнер, иногда – гейм-дизайнер (от английского game designer) – в общем, название профессии распространённое, но не устоявшееся в написании). Он необязательно будет один – всё зависит от сложности разрабатываемой игры. Так, например, над документацией ролевой игры количество трудящихся игровых дизайнеров может считаться не в «человеках», а в отделах. Небольшие же аркады, головоломки, платфомеры, «сайд-скроллеры» и прочие им подобные видеоигры менее требовательны, и для их разработки порой достаточно не только одного игрового дизайнера, но и вообще одного человека.
Как и в случае с концепт-документами, при составлении диздока опираются не на официальные правила типа ГОСТа (их просто нет), а на здравый смысл и проверенные временем и опытом общие рекомендации.
В дизайн-документ крайне желательно добавить следующую информацию:
1. Данные для идентификации игры.
а) название (рабочее или итоговое – разница не принципиальна);
б) жанр (если он есть – ведь не все игры создаются по шаблонам);
в) тип графики (двух- или трёхмерная);
г) стилистика;
д) платформы (персональные компьютеры, консоли, планшеты-телефоны с указанием операционных систем).
2. Пользовательские настройки.
Из названия логично следует, что в данном пункте указываются те настройки, которые доступны игроку и могут быть им изменены. Уровень звука и музыки, включение субтитров, смена разрешения игрового экрана, выбор языка, «горячие» клавиши и клавиши управления для клавиатуры, мыши, геймпада.
3. Интерфейс.
Схематичное изображение всех окон меню с указанием активных элементов – кнопок, переключателей, полос прокрутки – и действий, которые происходят при их использовании. Часть работы может быть делегирована специально обученному человеку – дизайнеру интерфейсов (больше известен под модным наименованием UI/UX-дизайнер). При разделении обязанностей на совести игрового дизайнера остаётся назначение действий, а дизайнеру интерфейсов поручается двигать элементы туда-сюда для достижения лучшей эргономики и внешнего вида.
4. Уровни.
Практически в каждой игре есть уровни. Выглядят они по-разному: ветвистые коридоры, локации со свободным перемещением, постройки из фигур, сменяемые подложки заднего фона, – но они есть, а значит, их существование должно быть учтено, подсчитано и описано. Отображаются схематичным образом с указанием ключевых элементов: здесь пол, там лава, слева тайник, справа пропасть, за дверью головоломка, место появления персонажа отмечено крестиком, монстры обозначены ноликами.
Бывает и такое, что уровни в игре есть, а подвести их под общую схему не получается. На выручку придёт обычное текстовое описание. Даже самые процедурно-генерируемые уровни из всех процедурно-генерируемых имеют правила – их-то и нужно указать:
а) как собирается уровень и из чего (типы поверхностей – почва, дорожки, мосты, энергетические платформы, ледяные кубы);
б) какие пассивные объекты привязаны к поверхностям (камни бочки, тумбы, стенды);
в) при каких условиях появляются активные объекты (существа, оружие, бонусные очки, пакеты здоровья).
Типы уровней
5. Игровые объекты.
То, что располагается на уровнях, и то, с чем игрок может взаимодействовать. Объекты, на которые можно запрыгнуть, подлезть под них, обойти, упереться лбом (кроме стен уровня). Объекты, которые можно толкнуть, собрать, перетащить, выбросить, уничтожить или пораниться при столкновении. Одним словом – список. В него скрупулёзно вносится всё до последнего пикселя. Если у объектов есть характеристики и свойства, они тоже указываются (вес, количество единиц здоровья, изменение чего-либо при активации – добавление патронов или брони, уменьшение энергии). И чем больше таких вот характеристик, тем менее понятно будет выглядеть список, если делать его в виде простого перечисления. На помощь придут лучшие друзья игрового дизайнера – таблицы.
6. Сюжет.
История мира, описания персонажей и монстров, диалоги, задания – всё, что относится к литературно-художественному тексту.
7. Система звуков и музыки.
Заполнение данного пункта может вызвать проблемы у игровых дизайнеров, начисто лишённых музыкального слуха, но кое-какие действия выполнить придётся. Указать количество музыкальных композиций и, по возможности, их жанровую принадлежность. Перечислить объекты, которые должны издавать звуки, и дать краткое описание: звук падающего камня, звук лазерного выстрела, звук сменяемой обоймы, звук мотора.
При необходимости добавляются данные о персонажах, которых необходимо озвучить: количество, половая принадлежность, возраст, особые приметы (акцент, хрипение).
В некоторых видеоиграх звуки и музыка являются не дополнением, а частью или основой игрового процесса: ритм-игры; представители жанров «стелс» и «хоррор», где важно слушать и слышать. Здесь важно составить и расписать систему от и до: какие действия должен совершать игрок при прослушивании музыки, какая погрешность допускается при ошибочных действиях; на каком расстоянии затихают звуки, каков радиус слышимости у персонажей.
8. Система сохранений и загрузок.
Сохранения условно можно разделить на два типа – автоматические и ручные. Разница между ними в том, что первые происходят при заданных разработчиком условиях и без вмешательства игрока (например, через расположенные на уровне контрольные точки), а выполнение вторых зависит исключительно от игрока – человек должен нажать кнопку «Сохранить», иначе достигнутый им прогресс будет утерян. К типу системы добавляется список объектов и значений, которые должны сохраняться и загружаться.
9. Система социального взаимодействия.
Социум – это люди, и варианты игрового общения с ними должны найти отражение в дизайн-документе. Хороший пример – массовые многопользовательские онлайн-игры, сама их суть сводится к постоянному взаимодействию – и ради достижения целей, и так, из любви к искусству. Однако не ММО едиными! Социальная сторона одиночных видеоигр может выражаться таблицами рекордов, достижениями, локальным и кооперативным мультиплеером, обменом предметами.
10. Система ролевых элементов.
РПГ (от английского RPG – role-playing game) – видеоигра, в которой нужно отыгрывать роли. Абсолютно любые роли – важен сам факт, а не конечный набор. Механики отыгрыша создают относительную свободу действий, вариативность игровых элементов и способствуют многократным повторным прохождениям с отличающимся результатом. Подобные возможности вызывают у игроков настолько большой интерес, что другие жанры нередко заимствуют элементы РПГ для собственного улучшения и развития.
Примеры ролевых элементов:
а) выбор персонажей и прокачка их характеристик;
б) взаимодействие с игровым миром и влияние на него;
в) «деревья» навыков и диалогов (выбор пути развития);
г) свобода перемещения.
При работе с системой ролевых элементов стоит учитывать, что каждый новый вариант развития значительно повышает сложность её составления и последующего тестирования.
*** На этом основные пункты заканчиваются. Какие-то из них могут оказаться лишними, о других не упомянуто в силу их меньшей распространённости, третьи пока ещё не существуют. Главное, что нужно понимать: чем больше информации об игре упорядочено и записано в дизайн-документ, тем проще будет работать. И речь идёт не столько о игровом дизайнере (хотя проще будет и ему, безусловно), сколько о его коллегах – это те самые люди, которые превращают документацию в рабочий продукт.
Забота о коллегах проявляется и в поддержании чистоты: в дизайн-документе нет места заметкам, размышлениям, сомнениям, неточностям, двояким толкованиям, шуткам (если они не являются частью сюжета). Лишнее должно оставаться в черновиках.
Уже не теория,
ещё не практика
Дизайн-документ – это, в основном, текст и цифры (расчёты, формулы, графики). Инструменты для работы соответствующие – текстовые редакторы и электронные таблицы.
1. Локальные редакторы и таблицы (например, «Ворд» и «Эксель»).
К достоинствам можно отнести расположение файлов (к ним всегда есть доступ) и удобство работы (полный набор возможностей, оформление, простота использования). К недостаткам – сложности с получением доступа у других людей, проблемы навигации (диздок не всегда представляет собой один большой файл, чаще он разбит на логические части, каждая часть – в отдельном файле, и если все они – локальные «вордовские» и «экселевские» документы, то ориентироваться в них непросто).
2. Облачные редакторы и таблицы (например, «Гугл документы», «Яндекс.Диск»).
Плюсы и минусы предыдущего пункта меняются местами. Доступ к облачным документам легко выдать любому количеству людей, проблема навигации исчезает благодаря гиперссылкам и их более удобному использованию. Заплатить за это придётся урезанными возможностями оформления и вечным удалённым доступом (нет интернета? заблокировали учётную запись? увы).
3. Корпоративные редакторы и таблицы (например, решения на основе вики-движка).
Объединение двух предыдущих пунктов – облачный инструмент, который находится в локальной сети.
Пара слов,
которые влезли без очереди
Конечно же, каждый человек волен вести документацию так, как велит его творческая натура. Однако единообразие и умеренная серьёзность ещё никому не вредили.
Норм таблицы
Не норм таблицы
ЧАСТЬ №2.
Практика,
которая поможет закрепить теорию
ДИЗАЙН-ДОКУМЕНТ
1. Название.
«За грибами!»
***
2. Жанр.
Платформер.
***
3. Вид игрового пространства.
Двухмерная графика (2D), вид сбоку.
***
3. Сюжет/История.
Жил в одной канализации Слизнячок. Однажды он спал и увидел во сне своё любимое лакомство – грибы. И был среди них король – огромный и, безусловно, вкуснейший гриб из всех. Слизнячок проснулся и отправился на поиски.
***
4. Игровые объекты.
4.1. Персонаж.
Внешний вид: слизень.
Возможности:
а) передвижение влево и вправо,
б) прыжок,
в) подтягивание (автоматическое, при взаимодействии с углами поверхностей).
Движение с небольшим скольжением – при остановке персонаж продолжает двигаться, плавно замедляясь. Падение нерегулируемое.
Скорость передвижения и высота прыжка персонажа в течение игры может меняться (смотри пункт №4.2, «Игровые поверхности»).
Жизнь имеет количественное выражение:
а) базовое значение: 3 единицы,
б) максимальное значение: 5 единиц.
Жизнь увеличивается при взаимодействии с некоторыми предметами (смотри пункт №4.3, «Предметы»).
Жизнь уменьшается при взаимодействии с существами (смотри пункт №4.4, «Существа»). При уменьшении количества жизни, персонаж переносится в начало текущего уровня, в точку появления (смотри пункт №4.3.4, «Труба», подпункт «А»).
4.2. Поверхности:
4.2.1. Кирпич.
Основная поверхность, находится во всех уровнях.
4.2.2. Вода.
Уменьшает скорость и высоту прыжка персонажа.
4.2.3. Движущаяся платформа.
Персонаж может стоять на платформе, двигаться и не падать во время движения.
4.3. Предметы.
4.3.1. Маленький гриб.
Прибавляет +100 очков к общему счёту (при соприкосновении с персонажем).
4.3.2. Большой гриб.
Существует в единственном экземпляре, в последнем уровне.
Прибавляет +2000 очков к общему счёту (автоматически при завершении игры).
4.3.3. Комок слизи.
Прибавляет 1 единицу жизни и +50 очков к общему счёту (при соприкосновении с персонажем).
4.3.4. Труба.
На каждом уровне расположено две трубы:
а) точка появления персонажа – декоративный элемент, условно ведёт на предыдущий по счёту уровень;
б) активный элемент, загружает следующий по счёту уровень (при соприкосновении с персонажем).
4.3.5. Кирпич-кнопка.
Активируется при соприкосновении с персонажем, в зависимости от заданных условий выполняются следующие действия:
а) исчезновение объектов,
б) падение объектов,
в) активация точек возрождения существ (смотри пункт №4.4, «Существа»).
4.3.6. Кирпич-ловушка.
Разрушается при соприкосновении с персонажем или любым существом (смотри пункт №4.4, «Существа»).
4.4. Существа.
Оказывают на персонажа одинаковое воздействие: при столкновении с ними персонаж получает урон (отнимается 1 жизнь). Делятся на три типа: неподвижные – всегда находятся на одном месте, позицию не меняют; подвижные – двигаются по заданным траекториям; боссы – движения и атаки индивидуальны.
4.4.1. Неподвижные существа.
4.4.1.1. Арматура.
4.4.1.2. Разбитая бутылка.
4.4.1.3. Ядовитое облако из спор.
4.4.1.4. Змея.
Особенности:
– всегда находится в углублении, в водной среде (на 2/3).
4.4.1.5. Паук.
Особенности:
– всегда висит на потолке,
– стреляет паутиной, при попадании в персонажа паутина останавливается сама и останавливает персонажа (снижает скорость до 0), время жизни выстрела – 2 секунды, перезарядка выстрела – 2 секунды.
4.4.1.6. Иглобрюх (рыба с шипами).
Особенности:
– вытягивает шипы только при приближении персонажа.
4.4.1.7. Бронзовый шар.
Часть активируемой ловушки (смотри пункт №4.3.5, «Кирпич-кнопка»). Как существо, действует на персонажа только в момент падения, после – работает как поверхность.
4.4.2. Подвижные существа.
4.4.2.1. Летучая мышь.
Особенности:
– летает;
– двигается от точки к точке в вертикальной плоскости (патрулирует).
4.4.2.2. Крыса.
Особенности:
– двигается от точки к точке в горизонтальной плоскости (патрулирует);
– за персонажем не бегает;
– других существ не атакует;
– провалы в поверхности не перепрыгивает.
4.4.2.3. Комар-альбинос.
Особенности:
– летает;
– движется от точки к точке в горизонтальной плоскости (патрулирует).
4.4.2.4. Паук-охотник.
Особенности:
– висит на потолке в режиме ожидания, падает вниз, когда обнаруживает персонажа под собой;
– если персонаж находится рядом – преследует; если персонаж отходит дальше радиуса преследования – двигается от точки к точке в горизонтальной плоскости (патрулирует);
– провалы в поверхности перепрыгивает.
4.4.2.5. Жук-рогач.
Особенности:
– летает;
– двигается по замкнутому ломаному маршруту (патрулирует).
4.4.2.6. Злая рыба.
Особенности:
– встречается только в водной среде;
– движется от точки к точке в горизонтальной плоскости (патрулирует).
4.4.2.7. Газовый пузырь (рыба).
Особенности:
– встречается только в водной среде;
– движется от точки к точке в вертикальной плоскости (патрулирует).
4.4.3. Боссы.
4.4.3.1. Червяк.
Количество единиц жизни: 4. Для нанесения боссу урона, необходимо нажать на кирпич-кнопку в полу (находится рядом с боссом). После нажатия с потолка падает объект (кирпич), который отнимает у босса 1 единицу жизни. При потере жизни у босса включается активная фаза.
Вида атаки и активные фазы:
а) стрельба – стреляет всегда, пока не находится в активной фазе;
б) активная фаза №1 – кричит, вызывая падение объектов (кирпичей) с потолка, каждый объект при столкновении с персонажем отнимает у него жизнь;
в) активная фаза №2 – прыгает (длина прыжка – случайная, в заданном диапазоне), перед каждым прыжком выбирает направление (прыгает в сторону персонажа);
г) активная фаза №3 – перемещается с повышенной (в два раза от обычного значения) скоростью от одной стены зала к другой.
Каждая фаза длится 10 секунд, после завершения фазы №2 босс возвращается на своё место прыжками, после завершения фазы №3 – ползком, с обычной скоростью.
Базовое место босса – на шляпке большого гриба, затем, при начале сражения, он его меняет (точка рядом с грибом) и возвращается в новую точку после фаз №2 и №3.
В случае получения персонажем урона босса относит на базовую точку (на шляпку гриба), количество жизней восстанавливается, обнуляется прогресс пройденных фаз.
***
5. Игровые уровни.
5.1. Основные.
Количество уровней в игре – 24. Последний – уровень с боссом.
Общая карта уровней
5.2. Уровень между уровнями.
Переходная локация, в ней персонаж автоматически перемещается по канализационной трубе. Направление трубы учитывает точку входа в предыдущем уровне и точку выхода в следующем: персонаж может перемещаться справа налево, слева направо, падать вниз.
Схема движения в уровне между уровнями
***
6. Заставки.
Заставки можно прервать нажатием левой или правой кнопок мыши, клавиши перевода строки (Enter).
6.1. Начало новой игры.
При нажатии на кнопку «Новая игра» персонаж просыпается, поднимается, подползает к люку (кнопка «Новая игра») и прыгает в него, после чего происходит загрузка уровня №1.
6.2. Финальный уровень.
Персонаж заползает в большой зал, камера плавно приближается и фокусируется на его лице – глаза увеличиваются, становятся круглыми. Камера переносится вперёд, плавно отдаляется, чтобы показать огромный гриб, затем поднимается и показывает сидящего на грибе босса. Камера быстро переносится к персонажу, фокусируется на его лице – персонаж прищуривается. Заставка заканчивается, начинается игра.
6.3. Победа над боссом.
После победы камера фокусируется на лице персонажа, персонаж облизывается, уровень завершается, происходит переход в главное меню.
***
7. Настройки игры.
7.1. Изменение уровня громкости музыки (от 0 до 100),
7.2. Изменение уровня громкости звуков (от 0 до 100),
7.3. Выбор разрешения игрового окна (все поддерживаемые монитором пользователя разрешения),
7.4. Выбор языка (смотри пункт №9, «Языки и локализация»),
7.5. Включение/выключение полноэкранного режима,
Расположение и типы – смотри пункт №13, «Меню», схема №3 «Окно опций», пункты 5.1. и 6.1.
***
8. Управление.
Осуществляется с помощью мыши и клавиатуры. Мышь используется для вызова меню и навигации по нему. Клавиатура используется для управления персонажем, клавиши клавиатуры могут быть переназначены игроком.
Базовое назначение клавиш управления движением персонажа:
а) движение вправо – стрелка вправо,
б) движение влево – стрелка влево,
в) прыжок – стрелка вверх.
Базовое назначение остальных клавиш:
а) включение/выключение таймера – клавиша «Т» (в английской раскладке),
б) включение/выключение паузы – клавиша «Выход» (Escape), эта клавиша не может быть переназначена.
***
9. Языки и локализация.
Базовый язык – русский.
Перевод:
а) английский.
б) украинский,
в) казахский,
г) белорусский.
***
10. Сохранения.
Сохраняются следующие параметры:
а) количество жизней персонажа (смотри пункт №4.1, «Персонаж»);
б) количество очков (смотри пункт №4.3, «Предметы»);
в) время прохождения уровней (смотри пункт №11, «Таймер»);
г) количество пройденных уровней (смотри пункт №5, «Игровые уровни»).
Пункты «а», «б» и «в» сохраняются при логическом завершении игры: выходе в главное меню, проигрыше (0 жизней), победе (победа над боссом). Пункт «г» сохраняется при переходе с одного уровня на другой, а также в последнем уровне при победе.
Сохранения записываются и отображаются в таблице рекордов (смотри пункт №12, «Таблица рекордов»).
***
11. Таймер.
Таймер учитывает время нахождения в каждом уровне. Таймер начинает работать при начале новой игры или при запуске любого из уровней. При переходе на следующий уровень таймер продолжает работать, выдавая общее время нахождения в игре.
Таймер останавливается при нажатии на паузу. Таймер не работает в уровне между уровнями, в главном меню и во время заставки перед финальной битвой. Таймер обнуляется при выходе в главное меню.
Таймер имеет вид 00”00’00.00 – учитывает часы, минуты, секунды, сотые доли секунды.
***
12. Таблица рекордов.
Таблица рекордов локальная. Состоит из 10 строк и 6 столбцов. Изначально все места в таблице рекордов заняты условными призёрами.
12.1. Столбцы таблицы рекордов.
а) место,
б) имя,
в) количество набранных очков,
г) время, затраченное на прохождение,
д) количество оставшихся жизней,
е) количество пройденных за раз уровней (пример: если прохождение начато с 10 уровня и закончено на 14, то количество уровней – 4).
12.2. Просчёт результатов таблицы рекордов.
Сначала учитываются очки (больше – лучше). Если очки равны, то сравнивается затраченное время (меньше – лучше). Если и время равно, то идёт сравнение оставшихся жизней (больше – лучше), а затем – уровней (больше – лучше).
Сравнение данных игрока и позиций в таблице рекордов начинается с десятого места и заканчивается первым.
12.3. Список призёров.
Место №1.
– имя: Улитка Зоя,
– количество набранных очков: 12000,
– время, затраченное на прохождение: 01:56:40.00,
– количество оставшихся жизней: 1,
– количество пройденных уровней: 24.
Место №2.
– имя: Поросёнок Георгий,
– количество набранных очков: 11100,
– время, затраченное на прохождение: 01:40:00.00,
– количество оставшихся жизней: 3,
– количество пройденных уровней: 21.
Место №3.
– имя: Стрекоза Матильда,
– количество набранных очков: 10050,
– время, затраченное на прохождение: 00:50:00.00,
– количество оставшихся жизней: 3,
– количество пройденных уровней: 24.
Место №4.
– имя: Дичь Оксана,
– количество набранных очков: 8200,
– время, затраченное на прохождение: 01:31:40.00,
– количество оставшихся жизней: 5,
– количество пройденных уровней: 23.
Место №5.
– имя: Сверчок Жан-Жак,
– количество набранных очков: 6750,
– время, затраченное на прохождение: 00:43:20.00,
– количество оставшихся жизней: 2,
– количество пройденных уровней: 18.
Место №6.
– имя: Гусь Василий,
– количество набранных очков: 5600,
– время, затраченное на прохождение: 00:21:40.00,
– количество оставшихся жизней: 0,
– количество пройденных уровней: 14.
Место №7.
– имя: Рыбка Изольда,
– количество набранных очков: 4050,
– время, затраченное на прохождение: 00:21:50.00,
– количество оставшихся жизней: 0,
– количество пройденных уровней: 11.
Место №8.
– имя: Сурок Леонид,
– количество набранных очков: 2700,
– время, затраченное на прохождение: 00:12:10.00,
– количество оставшихся жизней: 0,
– количество пройденных уровней: 7.
Место №9.
– имя: Богомол Вячеслав,
– количество набранных очков: 2100,
– время, затраченное на прохождение: 00:10:15.00,
– количество оставшихся жизней: 2,
– количество пройденных уровней: 5.
Место №10.
– имя: Гусыня Василиса,
– количество набранных очков: 1300,
– время, затраченное на прохождение: 00:16:40.00,
– количество оставшихся жизней: 5,
– количество пройденных уровней: 3.
***
13. Меню.
13.1. Главное меню.
Представляет собой интерактивный экран, в котором привычные кнопки действий имеют вид тематических объектов, вписанных в окружение. Внешний вид главного меню: фон – канализация, разветвлённая бетонная дорожка, ограда, ниже уровня бетонной дорожки – зелёно-коричневая жижа.
Схема №1. Главное меню.
Обозначения:
1. Канализационная вода.
2. Бетонная дорожка.
3. Бетонная дорожка, находится ниже уровня воды (смотри пункт 10).
4. Персонаж. Он спит, его сон зациклен: после того, как персонаж просыпается, тут же засыпает опять. От его головы отходит облако, в нём персонаж двигается и видит перед собой гриб гигантских размеров, после чего просыпается. (смотри описание персонажа, находящегося в главном меню).
5. Кнопка «Начало игры» – канализационный люк, открывает уровень №1.
6. Кнопка «Выход из игры» – ступени, открывает окно выхода из игры.
7. Кнопка «Опции» – железный щит (доска объявлений), открывает окно настроек.
8. Кнопка «Рекорды» – деревянный щит (доска объявлений), открывает окно рекордов.
9. Кнопки «Начать уровень» (с 1 по 18) – железные бочки с цифрами (от 1 до 18, соответственно).
10. Кнопки «Начать уровень» (с 19 по 24) – железные бочки с цифрами (от 19 до 24, соответственно): кнопки уровней 19 и 23 погружены в воду наполовину, кнопки уровней 20, 21, 22 погружены в воду полностью, кнопка уровня 24 не погружена в воду.
Отображение кнопок «Начать уровень» происходит при открытии соответствующих уровней (в момент появления персонажа на новом уровне). При первом запуске игры ни одна из кнопок «Начать уровень» не отображается.
Схема №2. Окно рекордов.
Обозначения:
1. Название – «Таблица рекордов».
2. Наименования параметров:
2.1. Место,
2.2. Имя,
2.3. Очки,
2.4. Время,
2.5. Жизней осталось,
2.6. Уровней пройдено.
3. Список параметров, 10 мест.
3.1. Количество символов в местах – 2,
3.2. Количество символов в имени – 20,
3.3. Количество символов в очках – 4,
3.4. Формат времени – 00:00:00.00 (часы, минуты, секунды, сотые доли секунд),
3.5. Количество символов в жизни – 1,
3.6. Количество символов в уровнях – 2.
4. Кнопка «Закрыть», закрывает окно рекордов.
Схема №3. Окно опций.
Обозначения:
1. Кнопка «Настройки», открывает окно настроек внутри текущего окна (смотри пункты 5 и 6).
2. Кнопка «Управление», открывает окно со списком клавиш управления внутри текущего окна (смотри пункты 5 и 6).
3. Кнопка «Авторы», открывает окно со списком авторов внутри текущего окна (смотри пункты 5 и 6).
4. Названия: «Настройки», «Управление», «Работали:» – выбор названия зависит от текущего окна (смотри пункты 1, 2, 3).
5. Внутреннее окно – бумажный лист, его содержимое меняется (смотри пункты 1, 2, 3):
5.1. Если выбраны «Настройки», то в окне отображаются:
– ползунок «Громкость музыки»,
– ползунок «Громкость звука» – смотри пункт №7, «Настройки»;
5.2. Если выбрано «Управление», то в окне отображаются:
– сменные клавиши управления (4 штуки),
– несменная клавиша паузы (1 штука) – смотри пункт №8, «Управление»;
5.3. Если выбраны «Авторы», то в окне отображается список авторов.
6. Внутреннее окно – бумажный лист, его содержимое меняется (смотри пункты 1, 2, 3):
6.1. Если выбраны «Настройки», то в окне отображаются:
– выпадающий список «Изменить разрешение»,
– выпадающий список «Изменить язык»,
– переключатель «Полноэкранный режим»;
6.2. Если выбрано «Управление», то в окне отображаются подписи к клавишам правления (5 штук) – смотри пункт №8, «Управление»;
6.3. Если выбраны «Авторы», то в окне отображается список авторов.
7. Кнопка «Закрыть», закрывает окно опций.
Схема №4. Окно подтверждения выхода из игры.
Обозначения:
1. Изображение двери.
2. Кнопка «Выход из игры» – дверная ручка.
3. Кнопка «Назад» – ступени, возвращает в главное меню.
13.2. Внутриигровое меню.
Меню отображается на уровнях.
Схема №5. Внутриигровое меню.
Обозначения:
1. Отображение жизни персонажа – иконка и количество в цифрах (1 символ).
2. Отображение игровых очков – иконка и количество в цифрах (4 символа).
3. Таймер – формат 00:00:00.00 (смотри пункт №11, «Таймер»).
4. Кнопка «Опции» (смотри схему №6 «Внутриигровое окно опций») – вызов окна опций ставит игру на глобальную паузу.
Схема №6. Внутриигровое окно опций.
Обозначения:
Идентично окну опций из схемы №3, но с исключениями:
1. Смотри пункт 1 схемы №3.
2. Смотри пункт 2 схемы №3.
3. Исключение: кнопка «Авторы» из схемы №3, пункт 3, отсутствует.
4. Смотри пункт 4 схемы №3.
5. Смотри пункт 5 схемы №3, исключение: отсутствует информация из пункта 5.3., об авторах.
6. Смотри пункт 6 схемы №3, исключение: отсутствует информация из пункта 5.3., об авторах.
7. Исключение: кнопка «Закрыть» из схемы №3, пункт 7, отсутствует.
8. Кнопка «В главное меню», открывает главное меню (завершение игры).
9. Кнопка «Продолжить», убирает внутриигровое окно опций (продолжение игры).
***
14. Звуковое оформление.
14.1. Музыка
14.1.1. Композиция для главного меню.
14.1.2. Композиция для безводных уровней.
14.1.3. Композиция для водных уровней.
14.1.4. Композиция для битвы с боссом.
14.2. Звуки
14.2.1. Нажатие кнопок в меню – переключатель полноэкранного режима, нажатие на люк в меню (начало новой игры) и нажатие на ступени (вызов окна подтверждения выхода из игры).
14.2.2. Нажатие на рекорды в меню (удар по дереву).
14.2.3. Нажатие на опции в меню (удар по стальному листу).
14.2.4. Нажатие на бочку в меню (глухой удар по стальной бочке).
14.2.5. Нажатие на дверь (скрип открываемой стальной двери).
14.2.6. Движение слизня.
14.2.7. Прыжок слизня.
14.2.8. Падение слизня.
14.2.9. Попадание слизня на угол.
14.2.10. Отнятие жизни слизня.
14.2.11. Взятие гриба и сердца.
14.2.12. Звук падающей воды из трубы.
14.2.13. Звук ядовитых спор.
14.2.14. Движение змеи.
14.2.15. Звук выстрела паука.
14.2.16. Движение паука-охотника.
14.2.17. Движение жука-рогача.
14.2.18. Движение комара-альбиноса.
14.2.19. Движение летучей мыши.
14.2.20. Движение крысы.
14.2.21. Движение Червяка.
14.2.22. Прыжок Червяка.
14.2.23. Выстрел Червяка.
14.2.24. Нанесение урона Червяку.
14.2.25. Крик Червяка.
14.2.26. Шум и удары падающих кирпичей, общий треск и грохот.
14.2.27. Нажатие кирпича-кнопки.
14.2.28. Разрушение кирпича-ловушки.
14.2.29. Падение бронзового шара.
14.2.30. Падение трубы (14 уровень).
ЧАСТЬ №3.
Игра,
которая покажет итоги проделанной работы
Бесплатно, без смс и рекламы:
Скачать игру в магазине «Майкрософт».
Скачать игру с «Дропбокса».
P. S.
Продолжение: С чего начинаются видеоигры (ч. 3): общая информация о процессе разработки.
