ivan221100

Я не могу назвать неудачной игру той концепции, которую выбрал для разработки первой (ссылка на первую часть истории будет где-нибудь тут). Хочу лишь сказать, что просто из-за недостатка времени не потянул весь объем работы, который предстояло выполнить. Когда я ненадолго отошел от разработки в целом, мне попалась ещё одна реклама. Игра из неё показалась мне такой же увлекательной и интересной, но в то же время сильно более легкой в реализации (как же я ошибался). Именно её я и взял как основу для своего следующего проекта.

Дальше – больше

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

В начале уровня вам выдается один юнит первого уровня, рандомно расположенный на сетке (вы сразу можете его перемещать), и один кристалл. Когда ваш герой разбивает кристалл, из него появляется ещё один герой тоже первого уровня (герои могут быть как дальнего боя, так и ближнего), а на сетке спавнится ещё один кристалл. Если у вас появилось два одинаковых героя, вы можете объединить их, увеличив их силу (минимум в 2,5 раза) и освободив место на сетке. Объединение происходит посредством перетаскивания одного героя на другого.

Когда у вас появляется два героя пятого уровня с одинаковым типом атаки (ближнего или дальнего) — можно объединить их в уникального юнита. Причем на выбор дается два варианта: средние характеристики, но шанс на успех равен 100%, или же очень высокие характеристики, но шанс на успех равен только 50%. В случае неудачи на месте объединения спавнится герой первого уровня.

Первый прототип

Ну что ж, идея понятна, нужно приступать к работе. Начал я с рабочего прототипа: условно набросал сетку и путь движения мобов. При слиянии кубики (герои) просто меняли цвет. В целом всё работало адекватно, и пришло время прикручивать ко всему этому визуал.

Как мне показалось, органично в этом всём будет смотреться пиксельная стилизация, и я начал отрисовывать героев. Тут на сцену и выходит Figma, о которой я упоминал в первой части своего рассказа. Да, не смейтесь, рисовал абсолютно всё я в Фигме. Несмотря на обилие софта для пиксель-арта, я выбрал именно её, потому что имел базовые знания по работе там. За стандартный пиксель я принял квадрат 10x10 реальных пикселей и принялся отрисовывать всё, что мне нужно.

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

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

Поговорим о главном

Первой такой механикой стал раздел улучшений в главном меню. Стоп, главное меню? Когда кор-механика (слияние и эволюция) была готова, я принялся делать так, чтобы проект в принципе соответствовал понятию «игра». То есть чтобы её можно было перезапускать, выбирать уровни, изменять громкость в настройках и делать все те базовые вещи, о которых мы даже не задумываемся.

Тут я познакомился с понятием, которое впоследствии сильно упростит мне разработку чего-либо — звучит оно как «дизайн-документ». Оказалось, что, если визуализировать все свои мысли и идеи хотя бы на листе бумаги, многие нюансы всплывают еще до начала полноценного кода. После текстового описания всего, что только приходило в голову, я принялся рисовать интерфейсы всех экранов в Figma.

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

На удивление, работа шла быстро, осложнения вызывала только куча разных модификаторов, которые постоянно прикручивались к формуле урона. И речь идет не о таких простых вещах, как, к примеру, шанс критической атаки при каждом ударе. Нет, речь идет о горении, кровотечении, замедлении. Некоторые эффекты наотрез отказывались суммироваться. Допустим, вот есть у вас герой ближнего боя, на котором надет меч, который с определённым шансом заставляет врага замедлиться при нанесении урона. И есть герой дальнего боя со стрелой, которая с определенным шансом поджигает врага. С моим скудным опытом в программировании это классифицировалось как «сложности».

Процесс шел медленно, но верно, и по истечении пары недель у меня на руках была уже полностью рабочая игра. В ней была реализована система глав (уровней), полностью работающий магазин и ветка улучшений. Также были отрисованы 40 карт, которые в игре чередовались каждые 5 уровней (первые пять уровней — лето, вторые — осень, третьи — зима и т. д.).

Особенности портирования

Когда у вас на руках есть что-то напоминающее продукт, хочется посмотреть на то, как это будет работать на реальном устройстве. Поэтому дело планомерно подходило к портированию на платформы, которые изначально и подразумевались как основные для моих игр — iOS и Android.

К сожалению, в своем быту я не нашел достаточно современных устройств на Android (единственным рабочим оказался LG L5, который когда-то довольно долго служил мне верой и правдой), поэтому вариантов не оставалось — делаем сразу на iPhone.

Там тоже не без нюансов, но обойти их мне показалось сильно проще. Дело в том, что вы не можете экспортировать свой проект из Godot в формате IPA. Для этого нужно какое-либо железо от Apple с установленным Xcode. Благо, макбук был найден в ближнем окружении, и работу это сильно не затормозило.

В процессе тестирования уже на реальном устройстве были выявлены мелкие баги. Например, хитбокс персонажа в главном меню не пропускал тапы и свайпы для смены глав (на компьютере я просто крутил колесико мыши в этом месте), а в меню улучшений плашки блокировали возможность скролла — он срабатывал, только если ты умудрялся попасть пальцем ровно между двух плашек. Ниже добавил скриншоты интерфейса и игрового процесса.

Затем в том же ближайшем окружении были найдены и относительно свежие Android-устройства, что позволило протестировать исправленную версию игры уже на них.

В процессе портирования я удивился, что реализация экспорта оставляет желать лучшего в обоих вариантах. Для порта на iOS вам нужен компьютер от Apple, а при порте на Android нужно пройти несколько кругов геморроя с дебаг-ключами. Но всё это было побеждено, и игра успешно работает на всех заявленных операционных системах.

Но то, что выяснилось дальше, поставило целесообразность разработки игр подобного рода под большое сомнение.

Продолжение следует…

Тот самый момент, когда, сидя в очереди, ты во что-то играешь и в рекламе между уровнями неожиданно видишь очень интересный геймплей. Там какой-нибудь чумной доктор или дровосек под твоим управлением начинает бегать и добывать ресурсы. Когда ты приносишь эти ресурсы на базу, тебе выдают монеты, на которые ты тут же строишь укрепления от ломящихся со всех сторон врагов. И в этой интерактивной рекламе такой геймплей тебя цепляет, и, конечно же, ты нажимаешь кнопку «Скачать» в сторе — почему бы и нет?

А когда загрузка заканчивается, ты выясняешь, что реально такого геймплея в игре не так уж и много (раз в 5–10–15 уровней, нужное подчеркнуть), а иногда бывает, что и вообще нет. Чаще всего случается так, что игра оказывается самым обычным градостроительным «симулятором», где уже на второй день время возведения одной постройки увеличивается с 10 секунд до 1,5 суток. Может, конечно, я потратил недостаточно времени на поиск такого проекта, но было принято решение: сделать свою игру! Отсюда я и начну свою историю.

Немного о себе

Не судите строго, я тут первый раз. Всем привет, зовут меня Ваня, я студент 5 курса института. Обучаюсь по технической специальности, и термин «разработка» применим в моей жизни разве что к написанию управляющих программ для станков с числовым программным управлением (ЧПУ). Сюда можно добавить ещё и то, что около пяти лет назад я познакомился с Figma и с тех пор активно пользуюсь ею чуть ли не в бытовых задачах, но до Фигмы в этой истории нам еще предстоит дойти. Также по мелочи на любительском уровне занимаюсь видеомонтажом и много чем ещё. Ну а мы двигаемся дальше.

Выбор движка и помощника

Итак, опыта в геймдеве ноль, а планы амбициозные, поэтому я начал выбирать игровой движок. UE сходу показался очень большим и, по факту, избыточным по своим мощностям. Unity отпал из-за недавних изменений в их политике распространения — я не углублялся и просто сразу скипнул его. И тут я наткнулся на Godot: он оказался бесплатным и в целом достаточно удобным для использования.

Но как быть дальше? Начал я смотреть обучающие видео по Godot, чтобы разобраться хотя бы в базовых моментах. На этапе скриптов было принято решение, что код будет писать нейросеть, а я уже в процессе буду разбираться, что к чему. В качестве нейросети был выбран Gemini 3.1 Pro. Тут каких-то особых мук выбора не было: просто в какой-то момент у меня появилась подписка AI Pro от Google, которая позволяет не сильно париться о лимитах в чате. Например, при использовании DeepSeek меня очень сильно калило то, что в самый неподходящий момент вылезает сообщение: «Достигнут лимит сообщений, начните новый чат».

Первый блин комом

Сразу после старта разработки я осознал, что был чересчур амбициозен, потому что объем работы предстоял просто титанических масштабов. Дело в том, что пусть в Godot и достаточно просто собирать свою игру, а Gemini довольно лихо справляется с написанием скриптов — всё рано или поздно упирается в визуал. А если быть точным, то в 3D-модели.

По долгу профессии, на которую я обучаюсь, я очень близко знаком с 3D-моделированием (ниже вы увидите что-нибудь из моих работ). Но в 3D-моделировании для производства и для игр есть колоссальные отличия. В первом случае весь процесс происходит в так называемых CAD-системах (AutoCAD, SolidWorks, Компас-3D, Inventor и т. д.), где модель, по сути, описывается математическими формулами и максимально приближена к реальному объекту. Грубо говоря, для того чтобы получить условное зубчатое колесо, вы сначала нарисуете его в CAD-системе, затем на базе своей 3D-модели напишете управляющую программу (УП), загрузите УП и заготовку в станок и только после этого, с учетом ещё тысячи и одного нюанса, у вас получится желаемый результат.

Полигональное моделирование же призвано просто передать узнаваемую форму, не привязываясь к четким математическим значениям. С полигональным моделированием я, на удивление, познакомился сильно раньше, чем вообще поступил в технический институт. Программа называлась Cinema 4D (а еще был софт для рендера Octane, ради которого мне даже пришлось копить на GTX 980 Ti), и я очень хотел делать красивые ролики с графикой. Обучение началось у меня, как и у всех, со всяких бубликов и прочего, но я достаточно быстро перешагнул к более сложным вещам и стал воспроизводить формы актуальных на тот момент айфонов. Проектов, как и скриншотов с тех пор, к сожалению, не сохранилось, но я и не рассчитываю на то, что вы поверите мне, — всё-таки к делу это мало относится.

Вернемся к делу. Поскольку воды с тех пор утекло немало, я решил попутно освоить что-то новое, и на ум мне пришел Blender. Забавным мне показалось то, что, когда я открыл на ютубе обучающие уроки по Blender, я увидел — внимание! — всё тот же пончик. Оказывается, несмотря на разный софт, учатся люди примерно на одном и том же. И на том спасибо, что при обучении моделированию в CAD-системах не было ничего про пончик. А хотя…

Снова пончик делать я не стал, а решил сразу набивать руку на более сложных формах. Так сложилось, что с детства меня влекли автомобили, и именно на них я стал набивать руку. Поскольку для моей игры нужны были low-poly модели, кузова машин я начал делать именно в этой стилистике (я предвижу ваш диссонанс и непонимание того, как автомобили могут быть задействованы в этой игре, и у меня есть ответ: никак).

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

После того как первый домик был готов, пришло понимание, что процесс этот трудоемок и, ввиду моей студенческой жизни и близящегося диплома, столько свободного времени я не имею. Внизу прикладываю фотографии игрового билда, до которого сделанный домик так и не добрался. Реализована система сбора бревен и их продажи на "лесопилке" за монеты. Курс: 1 бревно = 1 монета. Так же была сделана система магазина, которы сначала нужно построить за монеты. На скриншотах среди стандартных моделей Godot вы можете увидеть сделанное мной бревно, которое является одним из добываемых ресурсов в этой игре.

Продолжение следует…

Ссылка на вторую часть истории