Как я собрал Telegram-бота и игру с Codex

Я поставил себе два челленджа.

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

Второй — попробовать сделать полноценную игровую механику, причем не просто UI-игрушку, а что-то с 3D, сценой, камерой, эффектами и состояниями персонажей. Я не разработчик в классическом смысле, поэтому для меня это был хороший способ проверить, насколько далеко можно уехать с Codex, если у тебя есть продуктовая голова, дизайн-насмотренность и нормальное понимание, что именно ты хочешь получить.

В итоге получился Telegram-бот, который принимает фото чека, скрин банковской транзакции, PDF или просто текст операции, вытаскивает из этого сумму, дату, мерчанта, позиции в чеке, предлагает категорию и сохраняет трату. А поверх этого я привязал игру «Катись и дерись», чтобы учет расходов не был тупой таблицей, а стал живым циклом с прогрессом, дофамином и возвращаемостью.

Логика такая: сначала можно добавить один чек сразу. Потом включается игровая механика — чтобы сканировать дальше, нужно поиграть. За каждые 9000 метров в гонке или за каждые 3 победы в файтинге открывается новый скан. Так полезное действие, то есть учет расходов, связывается с игровым действием: проехал, победил, заработал прогресс, получил возможность снова распарсить чек.

Как я начинал работу с Codex

Первый промпт у меня почти всегда довольно тупой, потому что я не пытаюсь с первого раза написать идеальное ТЗ как инженер. Я скорее описываю человеческим языком, что хочу получить, а дальше смотрю, что Codex предлагает. Потом уже отрезаю лишнее, уточняю, развиваю нужное и постепенно сужаю задачу.

Я не стал активно пользоваться plan mode. Не потому что он плохой, а потому что сам могу распланировать продукт и архитектуру на уровне логики. У меня уже был опыт, когда я включал code review и за час сжирал дневной лимит токенов, поэтому в этом проекте я старался делать сам всё, что могу: разложить фичи, понять последовательность, решить, что важно сейчас, а что можно отложить.

То есть Codex для меня был не “сделай мне весь проект с нуля магией”, а скорее рабочий напарник: я задаю направление, он предлагает реализацию, я проверяю глазами дизайнера и продуктового человека, потом корректирую.

Базовый бот

Первый слой проекта был достаточно простой: Telegram-бот на Python + Aiogram.

Он принимает входящие материалы: фото чеков, скрины банковских операций, PDF и текстовые сообщения. Дальше через OpenAI идет OCR и структурирование: бот пытается вытащить дату, сумму, мерчанта, список позиций, если это чек, и предложить категорию. После этого всё сохраняется в PostgreSQL.

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

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

Почему появилась игра

Самая интересная часть началась после того, как я решил, что один только бот для расходов — это скучно. Учет расходов сам по себе быстро превращается в обязанность, от которой легко отвалиться.

Поэтому я решил привязать к нему игру.

Сначала это была гонка: машина едет вперед, собирает монеты, считает дистанцию, скорость, опыт. Дальше появилась идея: если машина едет бесконечно, почему она в какой-то момент падает или останавливается? Я показывал игру дома и Олегу, и логичный вопрос “почему машина падает после примерно 15000 метров?” привел к идее добавить битву за топливо.

Типа бензин закончился — значит, на заправке начинается драка. Так в проекте появился файтинг.

Это сразу хорошо легло в общий сеттинг: ретрофутуризм, synthwave, киберпанк, неоновая трасса, закат, драка в стиле аркадных файтингов. Получилась связка: едешь, собираешь монетки, набираешь дистанцию, попадаешь в боевую сцену, побеждаешь, получаешь прогресс, открываешь новые сканы чеков.

3D-гонка на Three.js

До этого я уже пробовал делать 3D-игру через Codex на Godot, почти без дизайна и программирования. Как эксперимент это было интересно, но я понял важную вещь: заставлять Codex “рисовать 3D” с нуля — дорогая операция по токенам и не всегда предсказуемая.

Поэтому в этом проекте я пошел по пути переиспользования ассетов. Я взял готовые 3D-модели машины, монет и объектов в формате GLB и попросил Codex собрать сцену на Three.js по моим референсам. Референсы для визуального стиля я сам генерил через GPT: synthwave-окружение, неоновая трасса, ретрофутуристичный закат, игровая камера.

GLB-модели хорошо подтягиваются в проект и не требуют безумного количества токенов. Codex нормально справился с подключением моделей, размещением их в сцене, настройкой света, камеры, движения и эффектов.

Единственная вещь, с которой я реально долго возился руками, — это трамплин. 

Бесплатные ассеты трамплинов, которые попадались, были ибо тяжелыми, по 20–100 МБ, либо с кривыми текстурами и настройками. Я потратил дневной лимит на эксперименты, потом устал и просто сам нарисовал трамплин прямо в сцене. Это, наверное, единственный кусок проекта, который я прямо сделал руками как объект. После этого Codex уже нормально превратил его в рабочий элемент сцены, и мы пошли дальше.

Камера — место, где Codex реально удивил

Самая сильная часть Codex в игровой сцене оказалась не в “написать функцию”, а в том, что он хорошо понимает кинематографический язык.

Я не 3D-шник, мне сложно руками прописывать поведение камеры в разных игровых ситуациях. Но я мог объяснить словами: здесь камера должна зумиться на объект, тут должен быть переход в бой с боссом, тут нужно ощущение прыжка, тут столкновение, тут камера должна вести себя драматичнее.

И вот это сработало очень хорошо. Я буквально почувствовал себя режиссером: объясняешь сцену нормальными человеческими словами, а Codex переводит это в код. Он нормально делал переходы между режимами, поведение камеры в прыжке, поведение при столкновении, зум на объект, смену состояния гонка → бой.

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

Музыка и звук

Музыка и звук оказались самой простой частью.

Музыку я сгенерировал в Gemini. Раньше пробовал Suno, мне он очень нравится, но в этот раз решил попробовать другое. Потом с Codex сделал кроссфейд двух композиций между режимами: гонка и бой с боссом. Здесь мое участие было минимальным: я объяснил, что хочу плавный переход между музыкальными состояниями, а Codex спокойно это собрал.

В файтинге также добавились звуки ударов, попаданий, победы и поражения. Это сильно оживило сцену, потому что без звука файтинг ощущается плоско, даже если графика уже нормальная.

Файтинг и спрайт

Когда стало понятно, что игра уходит в ретрофутуризм, synthwave и киберпанк, я решил оформить боевую часть в духе Street Fighter.

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

Но дальше началась боль.

Я потратил еще один дневной лимит токенов на интеграцию этих спрайтшитов в сцену и очень быстро понял, что красивый спрайтшит не значит “игровой спрайтшит”. Части тела обрезались, иногда вылезали руки или ноги от соседних кадров, разные позы были не выровнены по фреймам, некоторые кадры были слишком сложные для стабильной игровой анимации.

В итоге я открыл Figma и собрал спрайтшит самостоятельно: ровная сетка, понятные фреймы, одинаковая логика расположения персонажа, меньше сложных поз. После этого всё заработало идеально.

Codex уже нормально нарезал новый спрайтшит на кадры и собрал анимации состояний: idle, walk, attack, hurt, victory и другие базовые состояния. То есть персонаж стал не просто картинкой, а набором кадров, которые переключаются по таймингам.

Этот опыт тоже важный: AI может быстро дать красивую графику, но для игры нужна дисциплина ассетов. Прозрачный фон, ровная сетка, одинаковый размер фрейма, предсказуемая точка опоры, простые читаемые позы. Иначе код будет технически правильным, но визуально всё будет разваливаться.

Экран статистики

Потом я сделал отдельный экран статистики, который открывается прямо в игре по тапу на XP.

Там отображаются средняя скорость, общая дистанция, zen-дистанция, прошлый заезд, количество боев и другие метрики. Это важный слой, потому что игра начинает ощущаться не как одноразовый прикол, а как система прогресса.

Плюс это связывает игровую часть с ботом и расходами: у пользователя есть не только траты и категории, но и свой прогресс внутри игрового контура.

Экономика

Следующая большая часть — экономика.

Сейчас схема такая: машина едет по трассе, собирает монетки, монетки копятся, дают опыт. Опыт также зарабатывается в битве с боссом, в файтинге и за пройденную дистанцию. Внутриигровая валюта должна связать всё воедино.

Пока это не полностью реализовано, но логика уже понятна: монетки можно будет тратить на апгрейд машины и персонажа, скины, визуальные обвесы, эффекты, возможно оружие и новые боевые стили.

Отдельно хочу попробовать криптомеханику: запустить монетку на какой-нибудь супердешевой платформе и добавить криптотранзакции. Я с этим еще не работал, поэтому мне интересно попробовать руками, не в теории, а в реальном маленьком продукте.

Что еще в планах

Дальше хочу докрутить несколько направлений.

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

Второе — Google Sheets export. Хочу, чтобы можно было одним действием выгрузить расходы и аналитику в таблицы: для личной отчетности или командной работы.

Третье — кастомизация. Скины для персонажа, тачки, визуальные эффекты, обвесы, возможно разные боевые стили.

Четвертое — экономика и монетизация: покупки за монетки и Telegram Stars, а потом эксперимент с блокчейн-валютой.

Стек

По стеку всё максимально прагматично:

• Python + Aiogram для Telegram-бота;

• PostgreSQL для хранения данных;

• aiohttp для игрового API;

• Three.js + JavaScript для клиента игры;

• GLB-модели для 3D-объектов;

• спрайтшиты для файтинга;

• Railway для деплоя;

• OpenAI для OCR и структурирования чеков/операций;

• Figma для ручной подготовки игровых ассетов;

• Gemini для музыки.

Как бы я описал роль Codex в этом проекте

Codex не заменил мне мышление и не сделал проект “одной кнопкой”. Скорее он стал техническим напарником, который позволил мне как дизайнеру и продуктовому человеку быстро проверять идеи в коде.

Я не писал идеальные промпты сразу. Я начинал грубо: “хочу бота, который принимает чеки и строит аналитику”, “хочу 3D-гонку в synthwave”, “хочу переход в боевую сцену”, “хочу, чтобы камера вела себя как в игре”. Потом смотрел на результат, правил, резал лишнее, добавлял конкретику.

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

Codex хорошо помог там, где нужно быстро собрать рабочий каркас, подключить библиотеки, сделать сцену, API, состояния, анимации, музыку, базу, команды. Но в местах, где нужна визуальная дисциплина — например, игровые спрайтшиты, — всё равно пришлось включать дизайн-руки и собирать аккуратно самому.

В итоге получилась рабочая штука: Telegram-бот для учета расходов и игра в одном контуре. Пользователь кидает чек, бот превращает это в данные, а дальше игра помогает не бросать привычку. Это пока MVP, но уже с понятной архитектурой, визуальной вселенной и направлением развития.