Дисклеймер
Доброго времени суток, ребята. Это моя первая статья вообще и первая в цикле статей о том, как я решил создать игру в жанре Tower Defence. Данный текст я пишу как человек неопытный и только исследующий сферу, так что он может показаться вам интересным, если вы уже давно профессионал в сфере и хотите узнать, с чем сталкиваются новички сейчас, а так же если вы только начинаете свой путь и хотите пройти его, учась на чужих ошибках.
Теперь, когда с дисклеймером покончено, давайте перейдём к теме.
О чём статья?
Tower Defence не самый популярный игровой жанр на данный момент, но вряд-ли у кого-то повернётся язык назвать его малоизвестным. Базовые механики строительства и улучшения башен, крипы, которых нельзя допускать к выходу с уровня – всё это наверняка вызывает в вашей голове образы старых игр, будь то “Защита Асгарда” или, прости Господи, карты для Warcraft’а третьего. Даже те, кто не знают о жанре Tower Defence наверняка играли в такие игры, просто не зная этого..
Отчасти, известность жанра связана с простотой механик, что является плюсом и для казуальных игроков, и для разработчиков. Как правило, игры жанра всегда довольно просты и не требуют от игрока значительной концентрации внимания – игру всегда можно поставить на паузу и подумать о дальнейших действиях.
Тем не менее – не стоит думать, что TD не могут ничем удивить. У некоторых представителей встречаются довольно интересные механики: несколько путей следования для противников, возможность изменения ландшафта, система приоритетности противников для башен. И это не говоря о том, что можно придумать относительно эффектов для самих башен, будь то банальные заморозки и отравления или что поинтереснее. В общем, в действительности здесь есть где разгуляться, и если вы хоть на секунду задумались, когда читали перечисления механик – значит я прав.
В настоящем цикле статей мы рассмотрим разработку Tower Defence под названием Defence the Kernel, поговорим о видении игры, геймплее, инструментах разработчика, процессе создания игры на разных этапах и о релизе. В этой же статье мы рассмотрим концепцию игры и выберем программные средства.
Концепция игры
Если с жанром игры всё понятно, то сеттинг остаётся под вопросом. Наиболее частым выбором среди TD является фентезийный сеттинг, чуть реже встречается научная фантастика. Яркими примерами являются Element TD 2 и Axon TD: Uprising, разработанный одной командой Element Studios. В качестве сеттинга для нашей игры были выбраны научная фантастика и постапокалипсис. Предыстория вкратце довольно классическая и вы уже могли догадаться: искусственный интеллект(научная фантастика) восстал и уничтожил большую часть населения земли(постапокалипсис). Простая сюжетная завязка, какая и нужна подобным играм, не так ли? Всё немного сложнее – игроку придётся примерить на себя роль оборонительной вычислительной единицы комплекса машин, защищающего Главное Ядро от остатков человечества. Да, верно, в этой игре мы выступаем на стороне злодея, пытающегося окончательно утвердить свою власть. Более подробно с предысторией можно ознакомиться в группе нашего проекта: Defence the Kernel: TD (vk.com). Теперь давайте обсудим схему и элементы геймплея будущей игры.
Геймплей
В связи с наличием у игры сюжетной завязки и, как следствие, сюжета, игра нуждается в системе сохранений, которая позволит сохранять прогресс в отдельных сохранениях с возможностью загружать их, тем самым менять актуальное состояние игры. Чаще всего в Tower Defence либо нет сюжета, либо он является линейным, что исключает потребность в подобной системе сохранений – весь прогресс сохраняется автоматически, а игра не может быть сброшена или начата с нуля. Это не наш случай, так как мы планируем реализовать нелинейный сюжет. Продвижение же по сюжету будет происходить посредством диалогов, происходящих в начале уровня и в конце.
Так же мы планируем реализовать в игре режим бесконечной игры, в рамках которого игроку придётся продержаться как можно дольше против непрекращающихся волн противников, и онлайн режим, где два игрока будут выстраивать оборону совместно, в общем пространстве.
Рассмотрим механики игры: помимо очевидного строительства, улучшений и т.д. мы подумали, что было бы интересно добавить следующие механики:
-
Технологии – дерево технологий, где каждая технология открывает новые возможности и башни, а изучается посредством траты специальных очков изучения. Открытие новой технологии напрямую связано с открытием предыдущих и не может быть произведено раньше. Состояние дерева технологий является индивидуальным для каждого прохождения – технологии, изученный в прошлом прохождении не переходят в новое.
-
Общие технологии – та же механика технологий, но действует глобально, а не в рамках отдельных прохождений. В ней сохраняются все когда либо изученные технологии и применяются для режимов бесконечной игры и онлайн игры.
-
Система приоритетов для башен – возможность для каждой башни указать приоритет от 1 до 9 для каждого противника на уровне, что в свою очередь будет влиять на то, какой противник будет выбран башней для ведения огня.
-
Типы урона – разделение башен на несколько классов приводит к идее о разделении урона на разные типы. Например: термальный, кинетический и электромагнитный. Эти типы урона могут по разному влиять на разны противников, что сподвигнет игрока подбирать башни грамотнее, исходя из того, какие противники преобладают на уровне.
Таково наше видение игры на данный момент.
Программные средства
Первое, что нужно выбрать для разработки – это движок. В связи с опытом разработки на Unity был выбран именно он, так как переучиваться – дело не быстрое, а проект не требует ничего сверхъестественного, что нельзя реализовать в Unity. В данном случае это простое решение.
Для создания саундтреков к игре была выбрана FL Studio, как довольно популярная и хорошо зарекомендовавшая себя программа.
Создание 3D моделей мы осуществляем в такой программе, как Blender 3D. Она удовлетворяет всем требованиям проекта на данный момент и у нас есть опыт работы с ней.
Итого
К чему мы пришли в этой статье? Мы успели рассмотреть концепцию игры, сюжетную завязку, сформировали список механик для дальнейшей реализации и определились с программными средствами для реализации вышеописанного. Неплохое начало – теперь можно приступать к реализации, но возникает вопрос – что должно быть следующим шагом? После составления такого грубого наброска игры нам следует определиться с примерной архитектурой, вместо того чтобы бросаться с места в карьер и начинать писать код. В следующей статье именно этим мы и займёмся – сформируем несколько схем взаимодействия базовых элементов игры, и рассмотрим следующие части: сцены, переходы, система сохранений, настройки и т.д. В общем, займёмся поверхностным проектированием.
