матч 3 игры что это
Разработка match-3 игры: F.A.Q.
Жанр матч-3 игр известен уже давно. Интерес пользователей к нему растет, и качественные продукты быстро поднимаются в топ. Это, в свою очередь, ведет к появлению новых рабочих мест, где требуются специалисты с опытом работы над матч-3 играми.
Наш выпускник образовательной программы “Менеджмент игровых проектов”, который сейчас работает ведущим геймдизайнером компании Game Garden над играми этого жанра, подготовил краткий FAQ по разработке матч-3 игр. Материал составлен на базе частых вопросов от соискателей.
Создание уровней матч-3 – с чего начать?
Начать лучше с поиска референсов. Важно не просто прогонять уровни один за другим, а делать реинжиниринг игры.
При изучении референсов для каждого проекта нужно составить таблицы с данными и записывать в них следующую информацию:
Каталог механик и номер миссии, в которой механика встречается впервые.
Какие механики используются в каждой миссии.
Например, механика по сбору конфет впервые встречается в 5-й миссии, а механика по ломанию ящиков в 10-й.
В референсах следует следить за кривой сложности. Главным показателем сложности стоит выделить номер попытки, с которой игрок в среднем проходит уровень.
Сложные миссии, как правило, проходят с 5-й попытки, простые с 1-й.
Кривая сложности должна варьироваться от простой к сложной.
Наиболее успешные кривые могут отличаться в зависимости от ЦА. Взяв референсы, желательно играть в них по несколько человек. Каждый участник должен выписывать, с какой попытки он прошел ту или другую миссию. Чем больше участников, тем точнее получается кривая сложности.
При составлении кривой сложности мы сравниваем таблицы референсов между собой. Подбираем вариант, наиболее близкий либо по ЦА, либо другим критериям. Например, можно учитывать успешность проекта.
На основе полученных данных составляется кривая сложности проекта. Эта кривая и будет ТЗ для миссий.
Далее определяем каталог механик, которые должны использоваться в проекте, их очередь (когда какая будет представлена игроку).
Тут нужно исходить из интереса игрока и простоты освоения. Самые простые ставим в начало и чередуем с более интересными и сложными.
Сверяем их с кривой сложности. Нам важно добиться, чтобы у миссии, где механика встречается впервые, сложность была наименьшей, так как эта миссия – обучающая.
За чем важно следить при создании уровня?
Архитектура уровня очень сильно влияет на общее ощущение от его прохождения. Чем больше поле, тем больше вариантов матчей и возможности для проявления личного опыта в игре. Чем поле меньше, тем матчей меньше, и все напрямую зависит от удачи. Также маленькое поле сильно влияет на количество решафлов, что негативно влияет на общее ощущение от прохождения.
Формируется правило: следим за тем, чтобы было как можно меньше вынужденных ходов на поле. Всегда должно быть несколько вариантов.
Пример хорошей реализации коридора (Farm Heroes Saga)
В матч-3 миссиях не должно быть слишком узких коридоров. Иначе многое начинает зависеть от везения, а не от скилла игрока.
Важно использовать контрастные цвета фишек на уровне. Нельзя в одном уровне ставить коричневые стены, коричневые фишки, коричневые орехи, коричневое печенье. Нужно следить за тем, чтобы у игрока не было визуальной каши в глазах. Смотря на поле, он должен четко разделять цели, а не теряться в поисках. Поэтому следует подбирать правильные цвета под каждый уровень.
Что важно при введении новых механик?
Здесь есть 2 принципа:
Если гейм-дизайнерское чутье вас подвело, а референсы соврали, на помощь приходит аналитика. Нужно проанализировать уход игроков:
Механики должны быть наводящими. Ключи открывают замки, эскимо едят пингвины, рыбок просят котята.
Как понять, хороший ли уровень получился? Какие есть ключевые показатели успешности уровня?
Следует обратить внимание на следующие моменты:
По аналитике следим за тем, чтобы сложность уровня соответствовала запланированной по кривой сложности.
Большой разброс означает, что соотношение «удача/скилл» на уровне полностью на стороне первой, а прохождение превращается в обычную лотерею. Гораздо лучше использовать правило 70% удача / 30% скилл, при этом игроку будет казаться, что от его скилла зависит чуть ли не 50% успешного прохождения уровня. Если посмотреть на проблему глубже, то при везении игрок быстро пройдёт уровень, а иначе игрок может составлять десятки комбинаций наверху, не имея возможности ничего изменить внизу. Чаще всего такие проблемы встречаются в миссиях с множеством узких коридоров.
Рандом. Честный или нет?
Однозначного ответа на этот вопрос нет. Кто-то использует честный рандом и все 100% зависят от случайности. Кто-то выставляет каждой фишке свой вес в рандоме. Кто-то вручную подгоняет сиды (число затравка) под определенные уровни.
Выбор за вами! Главное, на каждом уровне вы должны использовать не больше 5-6 фишек разных цветов. Чем больше фишек разных цветов вы используете, тем меньше вероятность матчей на поле. Чем меньше разных цветов, тем больше матчей.
Если вы уже разрабатываете матч-3 игру попробуйте поставить на уровне всего 2 типа фишек, сделайте один ход и посмотрите за бешеной, практически бесконечной динамикой уровня 😉
Какой баланс?
Баланс – это драматургия. Герой – наш игрок-то проигрывает, то выигрывает. То в гору, то с горы. Он борется, справляется с трудностями, которые для него приготовила игра.
Одно из интересных правил – заставить игрока проиграть уже в первую сессию, чтобы бросить ему вызов. Проигрыш хоть и огорчит игрока, но подстегнет на дальнейшую игру.
Fuuu-фактор. Что это, и как его считать?
Fuuu-фактор – соотношение количества попыток прохождения без выигрыша с количеством попыток с несколькими ходами до победы. Получается следующая формула: Fuuu-фактор равен количеству попыток без выигрыша/кол-во попыток с несколькими ходами до победы.
Чем получившееся значение меньше, тем лучше.
Fuuu-фактор нужен для вовлечения игрока в кор-геймплей. Для создания чувства «чуть-чуть, и я бы прошел».
Именно такие уровни игрок будет перепроходить снова и снова, ведь он был так близок к победе.
Любопытным аналогом является… Кто бы мог подумать, Dark Souls!
Мы бьем босса, но проигрываем. Опять бьем и опять не хватает одного-двух ударов. И так раз за разом… «Вот-вот, и я бы сделал это».
Вспомните какие-нибудь топовые матч-3 игры, когда оставался один ход до конца уровня, и вам его как раз не хватало. Вы проигрывали. Именно из-за этого последнего хода вы и делали покупку +5 ходов за харду, чтобы все таки «добить» уровень.
Депутаты тоже любят играть.
В матч-3, как и в других играх, очень важно следить за показателями проекта и аналитикой. Вы всегда должны чувствовать игрока, стараться понять его и вовремя тянуть за свои геймдизайнерские ниточки. Сделали уровень, дайте поиграть в него своим мамам – фанаткам Homescapes. Они уж точно скажут, насколько вы плохой человек 😉
Спасибо за помощь в составлении статьи Филиппу Круглякову. Подробнее про работу с балансом в Match-3 играх читайте в его статье у нас на сайте.
Если вам интересно больше узнать про геймдизайн, создать и запустить свою игру, или пойти на работу в игровую компанию, то приглашаем на наши образовательные программы «Менеджмент игровых проектов» и «Основы создания игр». У нас часто проходят и однодневные открытые мероприятия, узнать о которых можно на странице анонсов.
Поляков Григорий – ведущий геймдизайнер, компания Game Garden.
Пять самых интересных игр в механике Match 3
Bejeweled
Jewel
Quest
Сокровища
Монтесумы
Эта игра, как и Jewel Quest, завязана на поиске сокровищ. Теперь
в центре истории, датируемой 1935 годом, оказывается студентка Эмили Джонс. Она
проходит практику в испанском музее и натыкается на оригинальную каменную
экспозицию. В найденных древних рукописях сообщается, что это карта, ведущая к
долине, которая дает богатство и недюжинное здоровье. Собственно, ради таких
вещей любой уважающий себя искатель сокровищ даже ухом не поведет (сколько
можно искать одно и то же?), но Эмили решает найти реликвию.
Puzzle Quest
Техномагия
Стоит отметить, что игра не только
условно-бесплатная. Она позволяет обменивать игровую валюту на премиумную, так что при некоторой настойчивости «Техномагия» не будет требовать никаких материальных вложений вообще, позволяя при этом пользоваться всеми преимуществами, покупаемыми за реальные деньги.
Полноценная многопользовательская RPG, только сражения происходят составлением
объектов в один ряд, а не размахиванием мечей.
Жанр Match 3 постепенно уходит на мобильные устройства. Здесь он чувствует себя наиболее комфортно. Не всегда есть время на прохождение GTA, Assassin’s Creed, The Elder Scrolls и прочих хитов высшего класса. А головоломки всегда под рукой, они не требуют к себе внимания, нет нужды следить за хитрыми сюжетными ходами и привыкать к управлению. И поэтому они столь популярны.
Match-3 Framework – это «просто»
Один из наших новых проектов, которые мы сейчас разрабатываем — игра в жанре Match-3. В этой статье расскажем о некоторых интересных технологических решениях, которые мы для нее используем. Речь пойдет о разрабатываемом фреймворке для Match-3 игр (M3Engine) и прилагающемся к нему инструментарии.
Идея создания подобного фреймворка возникла не вчера и уходит глубоко в историю проекта. Казалось бы, что может быть проще создания Match-3 игры?! Было предпринято несколько подходов к реализации, каждый из них был уникален в своем ключе, но обладал теми или иными недостатками. В конечном итоге мы пришли к решению, которым здесь и поделимся.
Основными целями, которые мы преследовали при создании этого фреймворка, были:
Рис 1. Общая идея Match-3 фреймворка
Философия M3Engine держится на следующих постулатах:
Основу M3Engine составляют два больших модуля (есть и другие, но их оставим за пределами этой статьи): Model и Logic. Модель (Model) описывает игровые сущности, их свойства и структуру уровня. Логика (Logic), или поведение, представляет собой набор интерфейсов (и реализацию для основных механик) для создания геймплея. Но обо всем по порядку, и начнем с самого начала, а именно – модели.
Модель и данные
Disclaimer: для простоты восприятия часть сущностей в этой и последующих частях будет упущены или упомянуты вскользь без объяснений.
Самая простая сущность в модели — это уровень (Level). Уровень содержит информацию о геометрии поля/доски (Board) и его содержимом, условиях выигрыша (Targets) и поражения (Restrictions), настройках рандомизации, а также данные о балансе.
Рис 2. Базовые сущности модели: уровень и его компоненты.
В свою очередь доска (Board) представляет собой набор тайлов (Tile) на бесконечной координатной сетке, элементы (Element), располагающиеся на этой доске, генераторы элементов, телепорты и многие другие сущности, которые, как правило, располагаются на самой доске во время игры. Для отображения видимой части доски используется механизм вьюпорта (Viewport). Вьюпорт прицепляется к определенным точкам на поле, которые называются вьюпоинтами (Viewpoint). Во время игры вьюпорт может перемещаться от одного вьюпоинта к другому, что позволяет создавать уровни на несколько экранов.
Рис 3. Игровая сетка и тайл.
Тайлом называется клетка игровой доски (рис. 3). Они могут быть игровыми и неигровыми. На игровой тайл можно разместить бóльшую часть элементов, с которыми игрок будет иметь возможность взаимодействовать. Неигровые тайлы используются для размещения элементов геймплея, с которыми пользователь напрямую взаимодействовать не может. Тайлы размещаются в ячейках сетки доски. В M3Engine предусмотрен механизмы открепления (detach) тайлов от ячейки и прикрепления к ячейкам доски (attach). Таким образом имеется возможность реализации механик смены тайлов (со всем содержимым) местами. Элементы в свою очередь так же не имеют жесткой привязки к тайлам, так как могут между ними свободно перемещаться.
Элементы, цели и ограничения могут быть разных видов и обладать различными свойствами, которые влияют на их поведение. Для этого мы ввели понятие игровой сущности (Entity) и ее типа (EntityType). Типы сущностей и их свойства описываются в конфигурационном файле, который называется модель данных. Благодаря этому вводить новые элементы и цели уровней (один из самых часто используемых способов внедрения механики) стало очень просто и быстро.
Рис 4. Сущности и их типы.
Сам M3Engine предоставляет набор встроенных свойств для определения базовых возможностей элементов. Например, способность элемента к движению по полю, восприимчивости к урону, способность свапаться в соседнюю клетку и др. При этом, имеется возможность добавлять новые свойства.
Поскольку в одном тайле может находиться множество элементов, то для определения результативного значения свойства необходимо использовать суперпозицию (Superimposition, мат). В общем случае это выглядит так:
За упорядочивание элементов в тайле отвечает специальное свойство — диапазон занимаемых слоев (LayerRange). Благодаря этому происходит регулирование сочетания элементов в одном тайле.
Таким образом мы имеем довольно гибкую систему сущностей, в которую можно легко добавлять новые элементы на поле, цели уровня и добавлять свойства уже существующим элементам.
Логика и поведенческая модель
Поведенческая модель игры представляет собой конечный автомат, который определяет игровой процесс. На схеме ниже представлены состояния и переходы между ними (некоторые состояния упущены для простоты восприятия).
Рис 5. Конечный автомат состояния игры.
Конечный автомат инкапсулируется в сущности, которую мы называем Игровой Логикой (Logic). Игровая логика также обладает контекстом (LogicContext), который содержит модель игры, данные уровня, очередь исполняемых сценариев и шину событий для сообщения между компонентами.
Игровые состояния (LogicState) можно добавлять, убирать и настраивать переходы между ними. У каждого состояния есть три основных метода:
Атомарные действия, посредством которых сценарий изменяет и манипулирует данными, называются Actions. Примерами экшенов могут служить: MoveElementAction, DamageElementAction, SwapAction, и т. д. Изначально мы полагали, что действий будет очень много, но, как показала практика, новые действия добавляются крайне редко. Чаще всего приходится реализовывать новые системы и сценарии.
Реализация новых механик таким образом сводится к следующему порядку действий:
Редактор
Disclaimer: Скриншоты интерфейса редактора показаны на тестовом проекте с использованием стокового арта.
Одной из целей было создание удобного инструментария для работы дизайнеров уровней. Благодаря тому, что сам Match-3 движок построен независимо от каких-либо библиотек и фреймворков для рендеринга, мы были довольно свободны в выборе UI фреймворка для редактора и его общей архитектуры. Как следствие – редактор является кроссплатформенным и поддерживает macOS, Windows и Linux.
Рис 6. Взаимодействие редактора уровней, игры и M3Engine.
Редактор уровней для работы с уровнями использует проекты, которые синхронизируются между членами команды посредством git. Это позволяет использовать один билд редактора для разных игр. Структура типичного проекта выглядит следующим образом:
Рис 7. Пример структуры проекта для редактора уровней.
Для переключения между различными проектами редактор имеет окно выбора проекта (рис. 8). Здесь можно выбрать проект, который открывался до этого, либо новый с файловой системы. По умолчанию редактор откроет последний используемые проект.
Рис. 8. Окно выбора проекта редактора уровней.
После выбора проекта запустится основное окно редактора (представлено на рис. 9).
Рис. 9. Основное окно редактора уровней.
Интерфейс главного окна состоит из следующих компонентов:
Редактор также позволяет редактировать модель данных игры. Он дает возможностьсоздавать новые и редактировать уже имеющиеся элементы: редактировать свойства элемента, его состояния (грейды), форму, занимаемые слои, и задавать текстуру для редактора.
Рис. 10. Окно редактирования элементов.
Для проверки играбельности уровня редактор предоставляет запуск уровня в двух режимах:
Заключение и дальнейшее развитие
Разрабатываемый нами фреймворк для игр жанра Match-3 имеет большой потенциал и уже сейчас полностью интегрирован в одну из будущих игр компании на Unreal Engine 4. В M3Engine уже заложена поддержка как основных механик жанра, так и более интересных. Благодаря выстроенной архитектуре, разработка одной механики в ядре не занимает много времени. Само ядро легко встроить в любой, совместимый с C++ игровой движок, а редактор не имеет никакой привязки к какому-либо движку. Редактор уровней позволяет создавать дизайнерам новые и интересные уровни и даже в какой-то степени менять свойства элементов.
Несмотря на большой прогресс и огромную проделанную нами работу, M3Engine есть куда расти. Вот всего лишь несколько направлений развития (не исключают друг друга):
Match-3, сюжет и 2 профессии
В статье речь пойдет о создании нарратива для казуальных игр, в частности для проектов match-3. Описываемые ниже методы применялись в разработке нескольких мобильных и браузерных игр с целью улучшить качество повествования истории в них и повысить retention.
Проработав 3 года с лишним в компании Broccoli Games, я набралась некоторого опыта создания историй для игр «три в ряд». Хочу поделиться им с остальными, потому что искренне верю: развитие профессий «игровой сценарист» и «нарративный дизайнер» зависит только от нас самих. Чем больше мы делимся своим опытом и решениями, тем быстрее развивается индустрия.
Как-никак рост игрового рынка в России стремительно растет, причем почти половина дохода приходится на free-to-play игры [1]. Эта модель монетизации становится намного привлекательнее для игровых разработчиков из-за низкого входного порога на рынок и высокого дохода.
Но вот что плохо. Если в платных полноценных играх хоть как-то понятны правила нарративного дизайна, драматургии, то в F2P-проектах теория блуждает в потемках. Поэтому сейчас нам важно делиться любыми наработками, которые показали хороший результат.
Чтобы понять, о какой компании идет речь, вот немного вводных:
Это не реклама (!), а для общего понимания.
Конечно, описанные ниже способы, которые мы использовали в Broccoli Games, не догма. И вряд ли кто-то из матёрых сценаристов и нарративщиков увидят что-то сверхновое. Это лишь опыт компании, и мой в частности. Описанные ниже приемы вырабатывались на протяжение производства нескольких будучи реализованных проектов. «Разработка часто набирает обороты ближе к своему завершению, когда создатели игры наконец-то понимают, на что похоже их детище и как оно играется.»[2]
В играх компании Broccoli Games всегда разрабатывался полноценный сюжет. Это пошло с тех времен, когда мы производили внутриигровые ивенты в главном проекте. Игроки отчаянно их ждали и «негативили», когда не успевали пройти. Сейчас в мобильных проектах запущены такие же полноценные истории с началом и концом.
Итак, обычный порядок действий, когда мы начинали разрабатывать новую историю:
Проблемы, с которыми столкнутся герои истории, должны логично объясняться, чтобы в диалогах героев прослеживалась мотивация. Игроку должно быть интересно решать эти проблемы через квесты и продвигаться по сюжету.
По структуре сюжета у нас всегда выходил классический «трехактник»: экспозиция, борьба и развязка [4]. Ни больше, ни меньше. Со временем стало понятно, что в играх лучше не затягивать с экспозицией. В нашем случае сюжет разбавляется геймплеем, а не дополняется, поэтому приходится как можно раньше вводить игрока в главный конфликт.
С трансформацией персонажей было сложнее. Наша главная героиня Вика — постоянная, для нее невозможно в каждой истории придумывать внутреннюю боль. Поэтому мы переключались на других героев. Но и они, в основном, были постоянными. Не скажу, что это плохо, скорее необходимость. Когда игрок постоянно переключается от кор-механики к мете и наоборот, ему сложно удержать в голове все моменты истории, в том числе развитие персонажей.
Антагонисты. Изначально нашей целевой аудиторией были пользователи ОК, которые плохо воспринимают негатив. Поэтому в сюжеты мы часто вписывали героя, ставшего не по своей воле или нечаянно антагонистом. А потом старый добрый happy end, где антагонист становится хорошим.
Как правило, все квесты мы разделяли по объектам. Например, в приключенческой мобильное игре на локации у нас были: хижина вождя, школа, больница, дом рыбака, алтарь и т.д. Каждому этому объекту придумывалась своя проблема.
Разбивка квестов по объектам нужна также для построения разветвленной системы квестов. Так игроку будут одновременно выдаваться разные квесты на разных локациях. И он сможет продвигаться по сюжету «своим путем».
Примерно так схематично выглядело наше дерево квестов для истории:
Конечно, разветвления в дереве не дают игроку права выбора, он так или иначе пройдет все задания. Но складывать кусочки сюжета он может по-разному. Получается такая псевдо-нелинейная история.
Например, игрок может сначала искать пропавшего персонажа на острове и получать какие-то зацепки, но все еще не понимать, что за страшное бедствие произошло. Или он может сначала помогать вождю, узнавая подробности о произошедшем, а потом искать пропавшего героя. В итоге, игрок все равно соединит события вместе, но может получить разный нарративный опыт. Как мы знаем от Томаса Грипа нарративом игры считается именно то, что происходит с игроком во время прохождения. [5]
Не утверждаю, что все игроки в «три в ряд» прямо-таки переживают за героев, но небольшая доля таких зрителей есть. Поняла это по редким комментариям игроков, любящим оценивать сюжет.
Перед тем как начать их писать, обычно я составляла диалоговый сценарий. Он особенно помогает, когда диалоги пишутся на пару с другим сценаристом или их настраивает другой гейм-дизайнер. Выглядело это примерно так:
Также лучше сразу прописать все нарративные элементы (см.пункт ниже), которые помогут показать историю.
Написав более 1500 диалогов, я вывела для себя несколько правил:
Тут можно добавить еще много пунктов, но самый главный — вычитывать тексты! В большом объеме текстов легко ошибиться в логике повествования. Но самое обидное — это опечатки. Их может сделать даже филолог с красным дипломом, победивший в национальном чемпионате по русскому языку. Поэтому: вычитать, потом еще раз вычитать, потом еще два раза, потом отдать на вычитку всей команде, а потом снова вычитать. А лучше всего иметь редактора.
«Какой еще нарративный дизайн в match-3?», — спросите вы. «А вот ого-го какой!», — скажу я в ответ.
Такие нарративные элементы, которыми можно разбавить диалоги, я обнаружила за время работы:
Мне кажется, прожженные нарративные дизайнеры приведут здесь еще кучу других механик для match-3, помогающих показывать сюжет, а не рассказывать.
Все написанное выше приведено здесь ради того, чтобы поделиться опытом и решениями. Возможно, кому-то будет полезно. Методология, выработанная в одной игровой компании, может не подойти другой. Но при этом сложится общее понимание структуры работы над казуальными проектами.
Интересно узнать, как разрабатываются истории в других игровых студиях. Призываю всех сотоварищей делиться информацией, дабы повысить уровень теоретической базы game studies.[7]
Если в статье есть ошибки/опечатки/неточности, пожалуйста, киньте в меня конструктивным тапком.
1. Elagina D. Distribution of the gaming market revenue in Russia in 2019, by segment [Электронный ресурс] // statista. — Режим доступа: https://newzoo.com/insights/articles/newzoo-games-market-numbers-revenues-and-audience-2020-2023/
2. Шрейер, Дж. Кровь, пот и пиксели. Обратная сторона индустрии. — Бомбора, 2019 г. — 368 с.
3. Словарь русского языка: В 4-х т. / РАН, Ин-т лингвистич. исследований; Под ред. А. П. Евгеньевой. — 4-е изд., стер. — М.: Рус. яз.; Полиграфресурсы, 1999
4. Филд, С. Киносценарий: основы написания. — Эксмо-Пресс, 2016 г. — 384 с.
5. Grip T. Making Storytelling a Fundamental Part of the Gameplay Experience [Электронный ресурс] // GDCvault. — Режим доступа: https://newzoo.com/insights/articles/newzoo-games-market-numbers-revenues-and-audience-2020-2023/
6. Станиславский, К. С. Работа актера над собой в творческом процессе переживания. Дневник ученика. — Прайм-Еврознак, 2008 г. — 480 с.