Основы геймдизайна

Что такое игровая механика? Когда я только начинала углубляться в геймдизайн, понятие «игровая механика» было для меня одним из самых непонятных. С одной стороны, интуитивно понятно, что в игре есть механика парирования или механика стрельбы из лука, а с другой стороны, сложно дать чёткое определение, что это такое. Базово игровая механика — это минимальный набор правил и взаимодействий, объединённый общей идеей. Этот набор правил можно реализовать в игре отдельно от всего остального, но при этом уменьшение количества правил сделает механику бессмысленной или превратит её в нечто другое. В книге “Игровая механика: продвинутый игровой дизайн” механики игр делят на 5 категорий: - Физика. Физические правила игры, включая движения объектов, физику и тайминги. - Внутренняя экономика. Правила, касающиеся ресурсов игры: монет, здоровья, выносливости и других. - Механики прогрессии. Правила, связанные с продвижением персонажа по игре, условия победы и поражения. - Механики тактического маневрирования. Правила, определяющие размещение юнитов на поле. - Механики социального взаимодействия. Правила, касающиеся взаимодействия игроков между собой. Возьмём классическую игру «Змейка». В ней есть механика движения (относится к физике), механика роста (относится к прогрессии), механика проигрыша (тоже относится к прогрессии) и механика получения очков (относится к экономике). Социального взаимодействия в "Змейке" нет, но в современных мобильных играх его можно встретить, например, в виде системы подарков друзьям. С другой стороны, боевая система — это механика? Логически она тоже представляет собой набор правил, объединённых общей идеей, но боевая система — это, скорее, набор механик. То есть сущность более высокого порядка, как и, например, вся игровая экономика.Что интересно, механики не привязаны к конкретным реализациям. Ту же самую «Змейку» можно реализовать в пошаговом режиме или даже имитировать на бумаге, превратив в настольную игру. Конечно, возрастающую скорость имитировать будет сложно, но всё остальное вполне возможно. Поэтому многие теории можно тестировать без компьютера и программиста — прямо на листочках бумаги. Нужно ли выделять правила в механики, если можно просто писать набор правил для игры? Можно писать и просто набор правил. Механики — это удобный способ структурировать их. Например, если хочется посмотреть, что будет в игре, если убрать из неё двойной прыжок, становится очевидно, какие правила нужно исключить. А если с двойным прыжком возникает проблема, видно, в каких именно правилах стоит искать её причину. Как предпочитаешь проектировать игру — как набор правил или набор механик?

Что такое геймдизайн-документ, и зачем он нужен? Он же ГДД, или по-простому диздок. Википедия предлагает такое определение: ГДД — это детальное описание разрабатываемой компьютерной игры. Определение хорошее, но прилагательное “детальный” можно и опустить. Скетчи на салфетках или разрозненные заметки тоже могут выступать диздоком. Всё зависит от того, какие цели преследует этот документ. Основные цели, с которыми может помочь диздок, это: — Выступление справочником. Самый тупой карандаш, как известно, лучше самой лучшей памяти. Поэтому все механики, которые ты придумал для игры и ещё не реализовал, удобно хранить в одном месте. Никто не может запретить называть такой список дизайн-документом. — Структурирование идеи. Идея в голове всегда выглядит божественно настолько, что непонятно, как можно сделать лучше. Мозг всегда стремится заполнить пробелы, и поэтому, пока идея варится в голове, её минусы не видны. Перенос идеи на бумагу помогает увидеть слабые места и структурировать разрозненные мысли в единую концепцию. Улучшение коммуникации. Если в проекте работаешь forever alone и делаешь игру чисто в стол, то этот пункт может быть не нужен. В остальных случаях, особенно когда нужно составить техническое задание художнику или музыканту, удобно иметь под рукой детальное описание игры. Иначе без подробного тз результат хз. — Реклама. Немножко похожий на предыдущий пункт, но связан с коммерческим производством. Геймдизайн-документ легко превращается в пресс-релизы или документы для сотрудничества с издателем. — Аргумент в спорах. Даже если спорить приходиться максимум со своей шизой. Мозг легко забывает и заменяет кусочки памяти на новую придуманную реальность. А вот написанное рукой остаётся неизменным, и, посмотрев в документ, можно вспомнить, например, что ты хотел сделать суровый пост-апокалиптический выживач, а, значит, радужные пони могут быть в ней неуместны. Пользы от документа много, но минусы тоже есть. Собственно, он один: его надо писать. И мало того, что надо один раз собраться с духом и описать всё в игре, но и в дальнейшем придётся его регулярно обновлять. Игры — это очень быстро меняющаяся структура, и в истории есть много случаев, когда изначальная идея игры менялась чуть ли не во что-то противоположное, но от этого игра становилась только лучше. Правильного и неправильного варианта ГДД не существует, хотя геймдизайнеры любят спорить до хрипоты, что их вариант самый верный. Диздок — это инструмент, который должен быть удобен всем в команде и выполнять свою цель. Поэтому существует много форматов, как его вести, и можно выбрать наиболее подходящий для себя. Например, есть такие варианты: — Обычный документ, онлайн или бумажный. Может содержать такие блоки: концепт, какое впечатление должна производить игра, примерное описание графики или готовая графика, основные механики, ключевые точки сюжета, анализ аудитории, технические детали. Я включала в свои диздоки ещё и план разработки для удобства, но его можно хранить и отдельно. — Блок схемы. Удобно для наглядной демонстрации логики механик, квестов, а также для показа интерфейсов: что происходит, если игрок выбирает то, а что это. — Вики. Формат удобен перекрёстными ссылками, так что при чтении об одной механике, можно сразу перейти и узнать про всё связанное. Если для референса смотреть на готовые ГДД известных игр, в которых сотни страниц, то может стать страшно. Но всегда можно начать с чего-то небольшого, например, написать концепт игры из трёх предложений, а потом расширять документ по мере накопления проблем или частых вопросов от команды. Плохой диздок всегда лучше его отсутствия! А если вдруг у тебя есть полезные инструменты или структуры, которыми пользуешься при написании дизайн-документа, то обязательно напиши про них :)