Исправление багов и добавление в игру нового противника.
Много времени прошло после предыдущего девлога. Просто мне тяжело дается рисование, много над ним размышляю, плюс не заставляю себя рисовать, если не хочется. Вот и получается, что вдохновение может не приходить долго, но зато когда придет, все делается быстро и сразу. Хотя даже так у меня были перебои после каждого мини этапа, нарисовал спрайт, и сразу затуп над анимацией, нарисовал анимацию передвижения, и сразу затуп над анимацией смерти и т.д.
По багам. Выявлены они были в ходе плейтестов, пока что только 3 штуки. Всех ликвидировал. Заняло это целых 10 минут 😎. Даже табличку с багами начал заполнять, так как это первые баги выявленные не мной, и я не мог исправить их вот прям сразу.
Билд новый будет уже, наверное, к следующему дневнику разработки. Надо по вашим же просьбам поработать над темпом игры, балансом, а это займет некоторое время. Ну и снова наступает скучный и странный этап отрисовки нового персонажа.
Мой канал, там гораздо больше размышлений, и более подробно расписан каждый шаг разработки:
В главное меню добавлена музыка, а на поле битвы добавлены монетки!
Признаюсь, я не осилил создание музыки, все таки я больше по коду/движку/геймдизайну. Именно поэтому я обратился к музыканту и заказал у него тему для главного меню. Лично мне все понравилось, поэтому будем работать дальше. Буду постепенно заказывать темы по ходу создания новых уровней, ну и думаю саунд-дизайн в целом тоже переложить уже в руки того, кто это умеет делать.
Рекомендую взять у меня билд и прочувствовать лично на вашем же ПК.
А вот про монетки щас распишу. После убийства противника с него падает монета. Пока что она падает со всех противников со 100% вероятностью, позже это скорее всего будет изменено, но это не точно. Монеты в будущем можно будет выменивать у торговца на разные предметы. Но это все еще будет, а пока что вот так вот.
Да, дело идет медленно, но пока что я просто так чувствую. Последнее время я не так активно занимаюсь игрой, и не заставляю себя делать это через силу, не хочу чтобы желание пропало, и очень не хочу, что бы оно пропало вообще, на все будущие игры.
Если просто банально посчитать, я потратил час на первую версию монетки, час на вторую, которую вы видите, еще полтора часа на кодинг и добавление в игру, и еще час на адаптацию под windows. Итого 4,5 часа на фичу. При чем код пишу масштабируемый, в будущем не будет проблем с новыми фичами. И вот это все сделано по сути за один день почти. Еще два дня я занимался другими делами. Я стараюсь не винить себя за это, но будто в глубине души я понимаю, что этот девлог должен был выйти два дня назад, и щас уже в игре должен был быть новый противник или торговец.
Короче, таков путь, не вините себя, если что-то не сделали, или наоборот сделали. Как заплачено, так и нахуячено, а мне никто не платит, соответственно да.
Ну и билды я обновил, пишите кому надо, скину, есть для windows и macOS.
Итак, это мой небольшой... Да на самом деле довольно большой! Рассказ как я делал из своего телефона контроллер. Небольшая предыстория. Решил я сыграть в Broforce с друзьями и тут понял, что если я притащу свой ноутбук с игрой, то поиграть с комфортом мы не сможем - нет столько контроллеров. В mvideo геймпады для xbox или ps стоили около 5 тысяч рублей. Можно было и китайские купить, которые обещали нормально работать при подключение к компьютеру, но... Но отсутствие доверия к качеству и жалось не то что к 5 тысяч, а к 700 рублям удавили возможность покупки на корню. И тут мы задумались, а можно ли сделать собственный мобильный контроллер. Конечно же мы нашли готовые проекты в google play, но они шли с вшитой рекламой и могли начать портить игровой процесс в самый неудобный момент. Так родился интересный проект для реализации. Был ли у меня опыт с Godot? Нет. Разработчик или хотя бы хоть сколько-то программист? Нет. Удивительно, что можно сделать при беспардонном упорстве и наличии гугла. Проект я в итоге сделал. Потом забил на него. А недавно вспомнил! И решил переделать :) Эта и все последующие статьи как раз пересказ процесса ПЕРЕСОЗДАНИЯ мобильного контроллера. Кусочек результата старого проекта ниже:
Зачем вообще переделывать, а не дорабатывать готовое? Я решил серьезно углубиться в Godot и реально сделать свой проект, игру. Ту в которую я бы хотел сыграть. Все же гнаться за мечтой, даже детской, это несколько романтично, возвышено и тупо. Меня устраивает. Старый контроллер имел серьезные проблемы в самой своей базе. Так же его переработка хороший способ убить сразу несколько зайцев. Структура проекта "Контроллер" осталась старой.
Сервер на Python - принимает подключение телефона, получает нажатия и передает их драйверу ViGEmBus. Сервер поддерживает подключение до 4ех человек;
Контроллер на Godot (далее по тексту клиент) - подключается к серверу, передает ему нажатия. Для хобби-прототипа сильно париться не хотелось. У клиента всего 2 сцены - настройки и сам контроллер;
ViGEmBus - драйвер для эмуляции виртуальных игровых контроллеров в операционных системах Windows. К сожалению, поддержка этого чуда прекратилась, и что будет теперь, мне не ясно. Скорее всего рано или поздно настанет момент, когда драйвер перестанет быть совместим с играми или новой версией ОС. Но пока что наслаждаемся.
Чертовы кнопки
Бесплатные картинки для кнопок взял с https://itch.io/game-assets/free/tag-gamepad. Набор приличный, на любой вкус. Со стиками было проще всего - не стал создавать велосипед и загрузил Virtual Joystick от MarcoFazio через AssetLib. А вот кнопки делал через узел TouchScreenButton - в документации Godot этот узел как раз предназначен для обработки на сенсорных устройствах. Загрузил текстуры для кнопок ииии... И границы текстур оказались слегка больше, чем ожидалось.
К стикам это не относится, так как они созданы через другую сущность Control. Пока не забивайте этим голову.
В общем Godot правильно определяет границы - я ведь не обрезал прозрачные лишние части. Вроде и черт с ним, но ведь нажатия будут обрабатываться неправильно - в местах пересечений будет срабатывать несколько кнопок. Вариантов была два (по крайней мере о которых я прочитал):
Обрезать кнопки в редакторе убирая пустоты;
Забить на TouchScreenButton и создавать области вручную через Area2D и CollisionShape2D.
Будучи здравомыслящим(?) человеком, я выбрал второй вариант. Чтоб больше страданий было, хех. Если пошагово, то создавалось все это дело следующим образом:
Для 4ех левых кнопок был создан отдельный узел Node2D (CrossButtons1);
Для каждой кнопки создан узел Area2D (UpArea);
Для Area2D были созданы Sprite2D (UPsprite) - отображение кнопки, и CollisionShape2D (для него я уже поленился название выдумывать) - зона обработки нажатия.
Для узла CrossButtons1, в который входят кнопки, добавляем скрипт со следующим текстом:
зашел сюда по быстрому сделать кнопку? Хотел скопировать текст, а тут картинка? Уж прости, картинка красивее текста выглядела.
Строка 4 нужна для привязки функции обработки нажатия к нашей области Area2D (UpArea). Строки 8 и 10 ловят нажатие и отпускание кнопки. Это все супер, но как будто лень писать подобный код для каждой новой кнопки. Благо, действительно есть способ попроще.
Пробегаемся по всем подузлам нашего Node2D (CrossButtons1), находим те, что принадлежат типу Area2D и подключаемся функцию _on_button_input для обработки всех кнопок в Node2D. Для нашей задачи главное понимать, какая кнопка была нажата - получаем через button.name.
Замечательно, но что если мы хотим, чтобы картинка кнопки менялась при нажатии? Вышеописанные методы уже не сработают, придется работать с каждым Area2D узлом отдельно. В целом ничего страшного. Делаем все те же шаги, что раньше, но создаем скрипт для узла Area2D. В него грузим картинки состояний.
Строки 12 и 15 для переключения состояния/картинки при обработке нажатия.
Заключение
Все что осталось - томная работа по повторению процесса для создания всех нужных кнопок. В следующей части добавлю новую сцену, ввод текста и сохранение данных в json формате. И немного работы сети. У-о-о-т. Спасибо за чтение. Дельные замечания и советы приветствуются, ибо в плане создания подобного я ещё профан.
Поведение противников, переработка слоев и меню паузы.
Когда я начал добавлять противников в игру, возникло сразу несколько проблем. Точнее парочка возникла, а остальные я не замечал. Все они связаны со слоями. Игра 2д, но я пытался создать иллюзию того что игрок может быть перед деревом, а может быть и за ним. Так было с каждым элементом ландшафта. Это работало так: есть условное дерево-родитель от которого наследуются все остальные деревья, у родителя есть скрипт, который проверяет, если игрок выше, то выходим на передний план, то есть прибавляем +1 к слою, в ином случае уходим на задний план, то есть -1 к слою.
Так это работало до определенного момента, как раз пока я не начал добавлять противников. Ведь противники тоже должны иметь возможность заходить за дерево или ходить перед ним. Я учел этот момент. Но потом обнаружил, что за деревом может быть игрок, а перед ним противник. А потом я столкнулся с ситуацией когда множество деревьев в одной точке работают некорректно. Таким образом один несчастный скрипт дерева был на абсурдные 120 строк кода.
В один момент я психанул и начал думать как это исправить (На самом деле я напиздел, я просто психанул и ушел пить кофе, идея пришла сама по себе). В общем вместо всех этих проверок элементы ландшафта просто при запуске сцены получают свою координату Y и делают ее слоем. Всё. Вот так просто получается целая куча слоев. Карты не бесконечные, не большие, поэтому в производительности это не упадет. А вот игрок обновляет свой слой постоянно. 120 строк магическим образом превратились в просто 2 строки.
Чуть позже я столкнулся с новой проблемой касаемо слоев, но решил все еще одной строкой. Что в любом случае лучше, чем первое решение, которое к тому же не работало как надо.
Потом я приступил к поведению противников, что бы они преследовали игрока, атаковали, наносили и получали урон. Спустя где-то пол часа, когда были настроены все сцены, написан код, я запустил игру и получил вот такой забавный "душ" из снарядов для слайма.
Да, работы еще вагон и маленькая тележка, но процесс мне пока что только в радость, так что со временем все станет выглядеть лучше.
Дальше планирую набросать баланс-табличку, что бы понимать, что именно я хочу что бы игрок ощутил от процесса, и полировать что уже есть. Например, когда противники умирают, у них еще какое-то время остаются тени, хотя сам спрайт уже начал исчезать, таких мелочей еще много можно найти.
Пару недель назад я закончил делать первый уровень своей первой игры и сегодня я хочу рассказать об идеях, лежащих в основе этого уровня. Ничего сенсационно нового, скорее наоборот ретро во всех его проявлениях. Если вы съели собак в создании игр, то можете смело закрывать статью, а если нет, то приглашаю вас к прочтению =)
Когда ты гуру геймдизайна (Знакомьтесь: Дэйв)
Про уровень.
Идейно донельзя простой - главный герой падает вниз пещеры попутно уворачиваясь от летящих камней - кусков этой самой пещеры. Собирает монетки, чтобы пополнить счетчик сокровищ и кушает еду, чтобы пополнять счетчик здоровья.
Идейно донельзя простой уровень
Падение
Разделим слона это на игровые составляющие. Самая главная составляющая - само падение. У нас условный герой, условно бесконечно перемещается в пространстве.
С подобными уровнями/играми мир уже знаком. Это и Subway Surfers...
Subway Surfers
...и Jetpack Joyrid...
Jetpack Joyrid
...и даже диназаврик гугла.
Dinosaur Game
Игры с бесконечными уровнями обычно объединяет одно - они нам врут. В них никто никуда не бежит/летит. Главный герой буквально находится на месте и иногда подпрыгивает, а мир несется на него. Уверен, что перечисленные примеры именно такие =)
Спроецируем это на нашу игру.
Наш гном делает вид, что падает, но на самом деле он просто перемещаться по экрану в разные стороны, в пределах координат x [0:320] / y [0:240] . А вот весь мир вокруг него летит вверх. Отодвинем немного камеру.
Отодвинули немного камеру.
Внутриигровые объекты появляются буквально чуть ниже экрана и летят наверх. Снизу генерируется рисунок задника, еда, монетки и прочее. Все летит наверх, пока наш герой загнан в тесный квадрат. Ах да, наверху эти объекты долетают до определенной координаты и удаляются. Наш герой не должен лететь бесконечно вниз, а объекты не должны лететь бесконечно вверх.
Кажется, что герой летит вниз, но нет - весь мир летит вверх. Это буквально магия кино - кругом обман, но красивый(ИМХО).
Логика появления объектов.
По умолчанию, условно бесконечные уровни проще всего создавать из паттернов. Паттерн - заранее подготовленный кусок уровня. Эти куски поставляются один за другим в определенном или псевдослучайном порядке. Еще можно создавать уровень через алгоритм появления объектов, но алгоритм жесток для написания. Если не учесть все аспекты, то уровень основанный на алгоритме будет периодически заводить игрока в тупик, а иногда становится слишком простым(Возможно это только для меня так).
В общем, пошел я по пути создания паттернов на основе алгоритма. Тут следует сделать важное уточнение - мой уровень конечный и длится 2 минуты, поэтому в финале я прописал уровень целиком. Т.е. создал паттерны и раскопировал их, поменяв некоторые элементы и в конце создал карту всего уровня. Но это в конце...
А с чего же начал? Разделил экран на условные линии с объектами. После чего прикинул условия на появления объектов в этих линиях.
Линии с объектами.
Т.е. условно линии с объектами идут вверх(это не красные, а то, что разделено красными). 20 линий - 2 экрана -1 паттерн возникновения объектов. На первых двух экранах мы встречаем камни с сложностью 1/2, т.е камень на 2 линии. На третьем и четвертом экранах мы встречаем камни с периодичностью 1(один камень на линии). К 11 экрану выходим на сложность 2.5. Если посмотреть первые 16 экранов, то можно увидеть следующую сложность:
1- 2 экраны | сложность 0.5
3- 4 экраны | сложность 1.0
5- 6 экраны | сложность 2.0
7- 8 экраны | сложность 3.0 (усложнение)
9-10 экраны | сложность 2.0 (откат)
11-12 экраны | сложность 2.5 (выход на стандарт)
13-14 экраны | сложность 2.0 (смена направления камней)
15-16 экраны | сложность 2.5 (возвращение к стандарту)
и т.д.
Разнообразие вносится типом камней, они бывают маленькие и большие. Часть из них летит вверх, а часть летит вниз. Короче bullet hell адаптированный под сеттинг игры.
Подобные условия, как на камни, прописаны и на еду и на монетки. Полный список условий на экраны выглядит следующим образом:
Мне тут пришла мысль. В геймдизайне часто желтый цвет - цвет сокровищ и одновременно цвет - указывающий на путь персонажа в игре. Возможно это пошло давно, именно из игр, где требовалось подбирать монетки и этим одновременно прокладывать себе путь к концу уровня. Таким образом первые разработчики игр могли убить двух зайцев одновременно...
Снизу примеры из более свежих игр.
Например первая миссия uncharted 2, по желтому цвету сразу можно догадаться о маршруте главного героя по поезду.
Uncharted 2: Among Thieves
horizon zero dawn тоже не стал исключением, здесь по желтому можно определить путь на этого робота.
Horizon Zero Dawn
Т.е. в своей игре я не просто расставлю монетки на пути, я подскажу игроку маршрут. Этот принцип так же ляжет в основу построения уровня. Так же я добавлю возможности обхода - поощрение в виде кристаликов, которые дают большее количество очков сокровищ. маленький отход и цветовая поощряемая сложность.
маршрут построен
И конечно же периодически, должно быть предательство игрока, чтобы маршрут по монеткам не воспринимался как само собой разумеющееся правило, даже если большую часть игры оно так и есть.
Почти каждый вариант с взятием монетки ведет к потере жизни, временное предательство
Второй ингредиент готов, теперь поговорим об очках здоровья и о еде.
Еда и очки здоровья
Еда это еще одна древняя игровая фишка. Она не только способ пополнить здоровье, но и способ разнообразить уровень. Интереснее собирать и еду и сокровища, а не только сокровища.
Вот только с едой тоже есть проблемы. Если еды сделать слишком мало, то весь уровень сведется к сбору монеток и как способ разнообразия - еда себя особо не проявит. Если еды сделать слишком много, то пропадет сложность, ведь на каждую ошибку мы сразу восстановим себе здоровье.
Как же сделать так, чтобы и еды было много и сложность осталась?
Надо уменьшить пользу от еды и вот, что я придумал...
У нас есть 5(выбрано экспериментальным путем) очков здоровья - крупных сердечек. За каждую ошибку я отнимаю у игрока полное, крупное сердечко(округляя в меньшую сторону). Но вот за каждую съеденную еду я восполняю не целое сердечко, а часть.
Пример, когда два полных сердечка и одно не полное
Углубимся в математику сердец =)
У игрока на самом деле 15 очков здоровья. Каждые три очка дают полноценное сердечко. Т.е. на рисунке сверху 8 очков - два сердечка по 3 и одно на 2. За каждую съеденную еду я даю игроку еще 1 очко. Т.е. у игрока станет 9 очков - три крупных сердечка.
Вот как-то так
Но вот отнимаю у игрока за ошибку я всегда до крупного сердечка.
Т.е. при трех крупных сердечках, сердец станет два. При двух крупных и одном маленьком сердец останется одно. Т.е. логика получения урона получается следующая:
15 очков здоровья >> 12 очков здоровья
14/13/12 очков здоровья >> 9 очков здоровья
11/10/9 очков здоровья >> 6 очков здоровья
8/7/6 очков здоровья >> 3 очков здоровья
5/4/3/2/1 очков здоровья >> 0 очков здоровья (смерть)
И вот тут немного поиграемся. Мы любим игроков, а значит должны пойти им на встречу и сделать более лояльным получение урона на малых очках здоровья.
5/4/3/2 очков здоровья >> 1 очков здоровья
1 очко здоровья >> 0 очков здоровья (смерть)
А за поедание еды всегда +1 очко.
И вот еще одна механика придумана.
Сложность и пасхалка
Те, кто чуть знаком с разрабатываемой мной игрой знает - я делаю графический стиль в 1bit/2bit/3bit/4bit/5bit графике. Переключение происходит по нажатию одной кнопки или через настройки.
пример в 1bit
Здесь тоже таится маленький нюанс. Для всего уровня есть единая карта, но вот вычитывание карты происходит чутка по разному для разных цветовых палитр. Чем более бедная палитра, тем больше сложность, тем больше вероятность появления дамажущего объекта:
1 bit - 100%
2 bit - 95%
3 bit - 90%
4 bit - 85%
4 bit - 80%
Это тоже некоторая отсылка - раньше игры меньше заботились о чувствах игрока, были чутка сложнее(ИМХО), а значит сложность в менее битных режимах пусть будет выше. К тому же такой подход дает немного разное прохождение на высокобитной графике.
Итого
Загоняем персонажа в рамки экрана. Разрезаем уровень на полоски, добавляем объекты с определенной периодичностью в определенные места. Добавляем монетки, как маршрут игроку. Добавляем алгоритм для очков здоровья и расставляем по уровню еду. И делаем это все в блокноте =) Вот пример того, что получается:
И читать удобно если привыкнуть... "Я уже даже не вижу код. Я вижу блондинку, брюнетку, рыжую." (с) Матрица
Игра потом вычитывает файл и построчно заполнит уровень.
А вот как получилось. Немного скриншотиков...
Ах да, говорят раньше жаловались на рандом в музыкальных плейлистах. Чтобы избавиться от жалоб, рандом сделали менее рандомным и людям сразу понравилось. Для построения своего уровня я использовал тот же метод. Почти все здесь сделано ручками, но по алгоритму. Выглядит как рандом но это абсолютно не так )
На самом деле это не все фишки геймдизайна, которые я использовал в этом уровне, но наверное основные =)
П.С. Статья была написана с целью поделиться, что даже маленькая игра, маленький ее фрагмент - целый мир с большим количеством задумок, законов, механик и т.д. Это по своему красиво =)
Как всегда, буду рад видеть Вас в моем ТГ канале. Там я чуть чаще выкладываю фрагменты из своей игры и другие материалы)
Доброго времени суток! Смотрю, многим зашли мои прошлые дев-влоги, так что продолжу делиться историей разработки. Сегодня — о первом знакомстве с движком Godot и о том, как я переносил туда всю функциональность своей браузерной RPG.
После пары месяцев с HTML, CSS и JavaScript
Я решил: хватит мучиться — пора переходить на движок. Перейти на Godot было непросто. Увидел, как один разработчик делает там свою игру, и подумал: «Почему бы не попробовать самому?»
На старте я почти ничего не понимал. Узлы, инспектор, дочерние сцены, инстанцирование — всё это было для меня тёмным лесом. И это я ещё про интерфейс молчу. Сам язык GDScript до сих пор знаю лишь на уровне, достаточном для ориентации и исправления ошибок.
Перенос из браузерки
Перекинуть весь функционал напрямую из JavaScript в GDScript было невозможно. CSS-стили и HTML-верстку тоже не скопируешь. Всё пришлось делать с нуля. Каждый элемент интерфейса, каждый кусок логики я собирал при помощи ChatGPT — вместе с его багами и потерями контекста. Со временем научился сам размещать элементы на сцене, выстраивать структуру и править код.
План перехода
Без плана было бы нереально. Я составил список шагов:
Перенести все скрипты и функционал.
Перетащить стили и интерфейс (CSS → сцены, HTML → структура).
Перерисовать визуал под новый формат.
Проверить, чтобы игра запускалась.
Пока не перенесены все скрипты, игру не проверить — один файл проект не запустит.
Первый запуск
Когда я наконец собрал всё и запустил игру — получил тонну ошибок. ChatGPT адаптировал 18 JS-файлов (каждый по 300–800 строк), но допустил множество ошибок. Перенос шёл постепенно, по одному файлу. Процесс поиска и исправления багов выглядел так:
Копировал ошибку из консоли.
Отправлял её в GPT вместе с контекстом.
Получал исправленный вариант.
Если не работало — откатывался и повторял.
Если код умещался в 100 строк — чат справлялся. Если больше, он терял нить, создавал новые баги, и приходилось возвращаться к прошлым версиям. Так продолжалось почти месяц.
Немного цифр
Для понимания масштаба работы:
18 JS-файлов (300–800 строк каждый) → GDScript
15 CSS-файлов (gamestyle.css — 600 строк) остальные поменьше
6 HTML-страниц
74 картинки
Это было только начало. Сейчас проект вырос до:
56 скриптов
40 сцен
291 картинки
Визуал — вечная стройка
Параллельно с кодом шла постоянная переработка визуала. Где-то переносил интерфейс из браузерки, где-то перерисовывал элементы, потому что старый стиль переставал нравиться. Иногда делал заглушки, чтобы хотя бы протестировать функционал. Перерисовка визуала — процесс бесконечный, думаю, многие разработчики игр это понимают.
Что дальше
После переноса я начал улучшать старые механики и внедрять новые. Дальнейшие посты будут уже не такими сумбурными: каждый будет посвящён конкретной системе или механике — инвентарю, карте, боевой системе, оптимизации.
А пока — несколько скриншотов версии после полного переноса из браузера.
Итог
Переход с браузерной игры на Godot стал серьёзным вызовом. Каждый день я сталкивался с ошибками, уставал, откатывался, но шаг за шагом собирал свой мир.
Игру нельзя просто переписать с одного языка на другой. Её нужно написать заново.
Баги не исчезают. Они просто переходят в следующую версию🐺
Подписывайтесь на мой телеграм канал, там помимо дев-влогов я выкладываю арты из игры, и просто по фану рисую с нейронками, залетай если тебе интересный нейросети и контент сделанный с помощью них: t.me/neirosea
Самый первый запукск годота, тут я думал сделать игру платформером, но быстро ушел от этой идеи:)
Следующие 5 скринов уже на движке годот после переноса большинства механик и визуала из браузерки(система инвентаря с драг энд дроп)
Просто деревня, основной хаб игры
Карта, с локациями, тут их 4 если кто не понял, в каждой есть свой моб
Но что было в карте тогда и сейчас, совершенно разный вид игры, сейчас я полностью переработал карту и локации, в будущих постах увидите:)
Система прокачки героя, простенькая, но даже такую было сложно создать а потом еще и перенести на годот
Таверна, сейчас кажется уже странной что в окошке целое помещение, так что от этого дизайна я тоже уйду к полноценной локации, с кайфушной музыкой и атмосферой:)
Хочется поделиться еще скринами из создания, но многие затерялись, да и пост будет слишком уж длинной простыней:)
В Telegram-канале как-то наткнулся на пост про создание игр с нейросетями. Уже не помню, в каком именно, но у меня щёлкнуло: я тоже хочу! Думал об этом уже лет пять, но раньше всё казалось невозможным — нужно учить языки, разбираться в движках и т.п. А тут — ChatGPT. Интересно же.
Я зашёл, спросил: «Мы можем создать игру?» Он, конечно, согласился. И всё закрутилось.
Сначала я прикидывал, что вообще хочу. Тогда был хайп на кликалки вроде хомяка и Notcoin. Захотел сделать свою, но с RPG-элементами: прокачка, клики, монетки, и, в идеале — хоть как-то монетизировать.
Я описал идею, и мы начали вместе думать. Знаний — ноль. Не понимал, где писать код, как собираются игры... На все вопросы отвечал чат.
Оказалось, Telegram-игра — это по сути браузерка на HTML/CSS/JS. HTML — структура, CSS — стили, JS — логика. Если где-то ошибаюсь в терминологии — не судите строго, я только начал учиться.
Telegram-игра: первые шаги
На старте всё было в новинку. ChatGPT не всегда держал контекст, скрипты получались громоздкими, каждая механика — в отдельном .js-файле по 400+ строк. Всё писал в Блокноте, сохранял, открывал в браузере, правил — и так по кругу.
Потом нашёл Notepad++, стало немного легче. Потом открыл для себя Visual Studio Code — и вот тогда реально почувствовал кайф от нормальной работы с кодом.
Чуть позже случайно открыл DevTools (F12) в Chrome и понял, что можно прямо в браузере менять элементы, а потом копировать результат в VS Code. Удивительно, но таких фишек мне ни одна инструкция не подсказывала — сам нашёл, сам удивился.
CSS и адаптивность
Стили — отдельная история. Всё выглядело как одна гигантская простыня, где изменение одного блока ломало всё вокруг. Понемногу разобрался, но осознал: адаптировать игру под Telegram внутри браузера — не мой путь. Слишком сложно для текущего уровня.
В итоге решил: временно отказываюсь от Telegram-бота. Перехожу на полноценную браузерную игру. Там хотя бы контроль больше.
Браузерная RPG: теперь серьёзно
Подумал: ну 2D-RPG — что может пойти не так? На деле — почти всё старое перекочевало: верстка, стили, адаптивность. Но теперь я уже ориентировался лучше, поэтому работал системнее.
Проект занял около двух месяцев. Он не стал финальной версией, но именно он лёг в основу моей текущей игры на Godot. Скрипты не переносил — язык другой — но визуал, логика, структура перешли почти целиком.
Была мысль переделать всю игру на движке, но быстрее оказалось начать с нуля и использовать старую игру как черновик и референс.
Для первой игры — это был мощный апгрейд. Я реально понял, насколько сложна масштабная браузерка. Много кода, много взаимосвязей. Это не просто “написал скрипт и игра готова”.
Однажды открыл DevTools у одной крутой браузерной игры — в HTML было 3000+ строк. И это только одна вкладка. А их там десятки. В тот момент я чётко понял: я туда больше не полезу.
Что дальше?
После RPG я сделал сайт для своей игры. Опыт с браузерной версией помог — знал, куда лезть, где искать решения, и всё вышло.
Сейчас весь фокус — на Godot. Новый движок, новые механики, свои баги и свои грабли. Следующие посты будут уже про мою основную игру, над которой я работаю каждый день.
Дополнительные материалы и скрины — оставлю в комментариях под этим постом. Заглядывайте.
Не важен тот, кто не падал. Важен тот, кто встал.
Первые два скрина, из моей попытки в телеграм игру(бота)
Следущие 4 скрина, уже браузерная игра полноценная, не для тг
И последние 4 скрина, это уже база с которой я начал переходить на новый движок(Godot)
