Вопрос «сколько стоит разработка мобильной игры» неудобный не потому, что на него нет ответа. Ответов слишком много. Можно уложиться в десятки тысяч долларов, а можно войти в проект с похожей идеей и очень быстро дойти до бюджета, который уже требует отдельной защиты перед партнёрами, издателем или инвестором.
Главная ошибка здесь простая: искать некую «среднюю цену по рынку». Она почти ничего не даёт. Цена определяется не самой идеей, а тем, какой продукт вы на самом деле собираетесь делать: прототип механики, MVP для проверки удержания и монетизации, коммерческий релиз или уже живую игру с обновлениями, аналитикой, закупкой трафика и операционной поддержкой.
Если вы founder, PM, маркетинг- или бизнес-менеджер, вам обычно нужен не абстрактный прайс, а рабочая рамка. Какой проект вы реально можете потянуть. Где бюджет раздувается быстрее всего. Что обязательно должно попасть в смету, а что можно отложить без самообмана. Ниже — именно такая рамка.
В двух словах: простая 2D-игра или puzzle-MVP может стартовать от десятков тысяч долларов. Casual или idle с ads и IAP почти всегда требует большего. Midcore 2D/3D — это уже другой уровень риска, сроков и координации. А multiplayer или server-driven mobile game дорожает не постепенно, а рывками. Эти рывки и надо понимать в первую очередь.
Короткий ответ: сколько стоит разработка мобильной игры в 2025
Если не прятаться за общие слова, ориентиры по рынку выглядят так.
| Тип проекта | Срок | Команда | Ориентир бюджета | Что обычно входит |
|---|---|---|---|---|
| Прототип / простой 2D MVP | 1–3 месяца | 3–5 человек | $15k–$50k | Core loop, базовый UI, минимум контента, без тяжёлого backend |
| Casual / idle с ads + IAP | 3–6 месяцев | 5–8 человек | $40k–$120k | Монетизация, аналитика, мета, баланс, подготовка к soft launch |
| Midcore 2D/3D | 6–12 месяцев | 8–15 человек | $120k–$400k+ | Контент, прогрессия, много экранов, сложный UX, глубокий production |
| Multiplayer / server-driven | 8–15+ месяцев | 10–18+ человек | $180k–$600k+ | Backend, авторизация, матчмейкинг, live features, DevOps |
| Live game после релиза | Постоянно | Отдельный контур | 10–25% от dev-бюджета в квартал и выше | Контентные обновления, A/B-тесты, аналитика, операции, саппорт |
Важно: это не прайс-лист и не обещание результата. Это сценарные вилки. Они нужны, чтобы вы не вели разговор о бюджете вслепую. Даже внутри одного жанра стоимость разработки игры может отличаться в разы — из-за графики, объёма контента, наличия backend, требований к монетизации, числа платформ и модели запуска.
Почему у двух похожих идей бюджеты отличаются в разы
Почти любая идея на раннем этапе звучит компактно. «Хотим match-3, но посвежее». «Нужна idle-игра под рекламу». «Нужен мобильный PvP, только без лишнего масштаба». На питче всё это может выглядеть сопоставимо. В смете — уже нет.
Возьмём два примера. Первый — 2D puzzle без онлайна, с ограниченным набором уровней, понятной сессией и аккуратным asset-based production, то есть производством на основе готовых или частично готовых ассетов. Второй — внешне тоже мобильная игра с короткими сессиями, но там уже кастомный стиль, магазин, прогрессия, события, балансные итерации, аналитика, серверная логика и планы на регулярные обновления. На словах разница будто бы не драматичная. В производстве — это два разных класса продукта.
Вот откуда берётся путаница вокруг темы «сколько стоит создать мобильную игру». Люди сравнивают идеи, а не контуры реализации. Но бюджет считает не идея. Его считают по scope, ролям, этапам, рискам и количеству вещей, которые придётся не просто сделать, а поддерживать после релиза.
Если упростить до жёсткого, но полезного вывода: стоимость разработки мобильной игры — это цена вашей определённости. Чем больше в проекте тумана, тем выше шанс, что деньги уйдут не в качество, а в переделки.
Что сильнее всего раздувает бюджет мобильной игры
Есть несколько зон, где бюджет растёт особенно быстро. Не на 10–15% за «небольшое улучшение», а скачком. И почти всегда эти скачки недооценивают в самом начале.
- 3D-контент и кастомный арт. Дороже становится не только картинка, а весь контентный конвейер: модели, текстуры, риги, анимации, VFX, оптимизация, UI в едином стиле.
- Multiplayer и backend. Синхронизация, авторизация, матчмейкинг, хранение данных, защита от читов, логирование, нагрузка, DevOps.
- Объём контента и мета-игра. Уровни, герои, предметы, экономика, прогрессия, события, офферы, магазины, награды.
- Soft launch, аналитика и UA. Когда игра выходит на реальный трафик, внезапно выясняется, что «работает» ещё не значит «окупается».
- Live ops после релиза. Если проект должен жить дольше запуска, релиз — это не финиш, а смена режима расходов.
Почему именно здесь бюджет взрывается быстрее всего? Потому что это не отдельные задачи, которые можно просто «добавить в конец». Это системные решения. «Давайте потом прикрутим онлайн» часто означает «потом перепишем архитектуру». «Сделаем стиль чуть дороже» означает, что арт-пайплайн, скорость продакшна и требования к устройствам уже стали другими. «Нужны ивенты» — значит, вам нужны не только ивенты, но и инструменты, аналитика, баланс, операционный ритм команды.
Самая дорогая разработка игры — не та, где сразу выбрали высокий бюджет. Самая дорогая — та, где проект начали с дешёвой версии правды, а потом по дороге стали доклеивать к ней реальные требования.
Из чего складывается стоимость разработки игры: основные статьи бюджета
Снаружи смета часто выглядит как одна строка: «разработка». Внутри проекта всё намного приземлённее. Стоимость разработки игры складывается из разных слоёв работ, и код — только один из них.
| Статья затрат | Что включает | Когда дорожает особенно быстро |
|---|---|---|
| Discovery / GDD | Жанр, core loop, scope, монетизация, требования | Когда проект стартует без приоритетов и критериев успеха |
| UI/UX | Флоу, экраны, интерфейсы, onboarding | Когда механик и экранов становится много |
| Клиентская разработка | Core gameplay, логика, интеграции, оптимизация | Когда проект перегружен фичами и платформенными нюансами |
| Backend | Авторизация, данные, матчмейкинг, серверная логика | Когда есть PvP, социальные функции или server-driven-экономика |
| Арт и анимация | 2D/3D-ассеты, анимации, VFX, стиль | Когда нужен кастомный визуал и большой объём контента |
| QA | Тестирование, регресс, устройство-специфика | Когда проект выходит на несколько платформ и содержит много систем |
| PM / production | Планирование, координация, контроль сроков и scope | Когда команда распределённая или смешанная |
| Аналитика / SDK | События, атрибуция, продуктовые метрики, SDK | Когда важны retention, монетизация и soft launch |
| Публикация и release prep | Сборки, требования стора, материалы, интеграции | Когда проект запускают на iOS и Android одновременно |
Поэтому вопрос «сколько стоит сделать мобильную игру на Unity» сам по себе слишком узкий. Unity может упростить кроссплатформенную основу, но он не убирает расходы на контент, QA, оптимизацию, стор-специфику, аналитику, продуктовые итерации и post-launch работу. Движок влияет на смету, но не спасает от неверного scope.
Что можно отложить, а на чём экономить опасно
Сокращать бюджет можно по-разному. Один путь — осознанно урезать scope, чтобы быстрее проверить гипотезу. Другой — вырезать фундамент и просто перенести проблемы на потом. Внешне оба варианта выглядят как экономия. По факту это противоположные вещи.
| Можно отложить до MVP | Лучше не резать | Почему |
|---|---|---|
| Часть контента, вторичные режимы, косметика, сезонные события | Базовая аналитика, UX-каркас, техархитектура | Без этого вы не поймёте, что именно сломано и что чинить |
| Расширенную мету и дополнительные экраны | Core loop и onboarding | Если пользователь не понимает и не чувствует ядро игры, остальное неважно |
| Часть кастомного визуала | QA и production-контроль | Дешёвый старт без дисциплины быстро становится дорогим |
Это не сухая бухгалтерия. Это вопрос контроля над проектом. Когда вы понимаете, что именно должен доказать первый этап, бюджет перестаёт быть тревожной кучей цифр. Он превращается в инструмент: вот что мы проверяем сейчас, вот что сознательно переносим, вот по каким признакам решаем — идти дальше или остановиться.
Стоимость по типу проекта: 5 сценариев, в которых читатель узнаёт себя
Самый полезный способ считать бюджет — не «игра вообще», а типовой сценарий. Так быстрее становится ясно и сколько стоит разработка мобильной игры, и какой формат запуска для вас вообще разумен.
Сценарий 1 — сколько стоит сделать простую 2D мобильную игру или MVP
Это не «дешёвая полноценная игра». Это проверка гипотезы. Хороший MVP существует не для красоты презентации, а чтобы быстро ответить на неприятный вопрос: в этой механике вообще есть игра, или только идея о ней?
Обычно сюда попадают puzzle, simple arcade, hypercasual-подходы и другие проекты, где можно сфокусироваться на одном core loop. В scope входят рабочая игровая сессия, базовый UI, ограниченный объём контента, минимально нужная аналитика, иногда подготовка к тестовому запуску. Не входят — тяжёлый backend, большая мета, сложная кастомизация, регулярные live-события и контент на месяцы вперёд.
Здесь и кроется самая частая ошибка. Под видом MVP пытаются сразу сделать половину коммерческого релиза: магазин, прокачку, коллекции, ивенты, несколько режимов, глубокую экономику. В этот момент проект теряет главную силу MVP — скорость проверки. И стоимость разработки мобильной игры начинает расти ещё до того, как подтверждена базовая ценность продукта.
Если у вас ограниченный бюджет, этот сценарий часто разумнее любого «сразу делаем полноценно». Не потому, что так безопаснее психологически. Потому что так выше шанс сохранить деньги на следующий шаг, если гипотеза окажется живой.
Сценарий 2 — сколько стоит casual или idle-игра с ads + IAP
На словах такой проект выглядит проще midcore: короткие сессии, понятные механики, умеренная графическая нагрузка. Из-за этого его часто недооценивают. А потом оказывается, что стоимость разработки игры здесь сильно завязана не на визуальную сложность, а на экономику продукта.
Как только вы говорите «монетизация через рекламу и внутриигровые покупки», проект уже тянет за собой баланс, точки возврата, офферы, воронку прогрессии, сегментацию пользователей, аналитику поведения, иногда A/B-тесты и почти всегда soft launch. Нужна не просто игра, которая запускается. Нужна игра, которая удерживает, возвращает и монетизирует так, чтобы закупка трафика имела смысл.
Типичный бытовой сценарий выглядит так. Команде кажется, что можно быстро собрать idle-проект на готовых ассетах и проверить спрос. Через несколько месяцев выясняется, что игроки быстро выгорают, рекламные вставки ломают ритм сессии, офферы показываются слишком рано, а экономика не держит интерес. Формально продукт есть. По бизнесу — нет. Приходится переделывать основу. Дешёвый вход оборачивается дорогим циклом исправлений.
Если ваша цель — коммерческий mobile-проект, а не просто релиз, casual/idle надо считать именно как продукт с monetization loop, а не как «простую игру». Иначе смета почти наверняка окажется заниженной.
Сценарий 3 — сколько стоит midcore 2D/3D-игра
Здесь рост бюджета уже редко бывает линейным. Дело не в одной дорогой функции, а в плотности взаимосвязей: больше механик, длиннее прогрессия, больше экранов, больше типов контента, выше требования к UX, балансу, тестированию, координации команды.
Снаружи midcore часто обманывает. Кажется: это же не AAA, значит всё ещё подъёмно. Но для мобильного рынка midcore — это уже серьёзный production. Особенно если проект 3D. Там быстрее дорожает не только арт, но и каждая итерация: правки тяжелее, оптимизация сложнее, QA объёмнее, требования к целостности опыта выше.
Midcore обычно оправдан там, где у вас уже есть сильная гипотеза по аудитории, понимание монетизации и готовность финансировать не только разработку, но и путь к масштабированию. Если гипотеза ещё рыхлая, этот класс проекта слишком часто превращается в дорогой способ покупать неопределённость.
Сценарий 4 — сколько стоит multiplayer или server-driven мобильная игра
Если вы хотите понять, где бюджет растёт быстрее всего, вот этот участок. Multiplayer, social и server-driven проекты почти никогда не дорожают «понемногу». Они меняют сам характер разработки.
Появляется отдельный слой расходов: backend, синхронизация состояний, матчмейкинг, хранение данных, рейтинги, обработка обрывов связи, безопасность, защита от читов, логирование, масштабирование, DevOps, нагрузочное тестирование. И это ещё до полноценного live ops после релиза.
Очень показательная ловушка: «Сейчас сделаем core, а онлайн добавим потом». Если онлайн, кооператив или PvP завязаны на core loop, отложить их без последствий обычно нельзя. Позже вы будете не добавлять функцию, а ломать и пересобирать архитектуру. То есть платить дважды.
Именно поэтому вопрос «сколько стоит сделать мобильную игру с мультиплеером» надо задавать не как вопрос про одну фичу. Это вопрос про другой класс продукта. С другими рисками. С другими сроками. С другой стоимостью поддержки после релиза.
Сценарий 5 — MVP, vertical slice, полноценный релиз и live game: что именно вы считаете
Многие споры о бюджете возникают не потому, что кто-то ошибся в цифрах. Просто одна сторона считает прототип, вторая — MVP, третья в голове уже видит коммерческий релиз. А кто-то вообще подразумевает live game с контентным планом на квартал.
Чтобы не спорить о воздухе, полезно развести эти форматы заранее.
| Формат | Для чего нужен | Что обычно не входит |
|---|---|---|
| Прототип | Проверить механику и core loop | Полировка, широкая мета, рынок |
| Vertical slice | Показать качество, стиль, ощущение продукта | Полный объём контента и экономики |
| MVP | Проверить удержание, монетизацию, ранние метрики | Большой контентный запас и зрелый live ops |
| Полный релиз | Выходить на рынок как продукт | Постоянные post-launch операции как отдельный контур |
| Live game | Развивать и удерживать проект после релиза | — |
Чем раньше вы фиксируете этот уровень готовности, тем точнее становится разговор о том, сколько стоит разработка игры. И тем меньше шанс, что подрядчик и заказчик окажутся вежливо согласны словами, но считают вообще разный результат.
Как жанр, графика, движок и платформы меняют стоимость разработки
Жанр — это не ярлык для презентации, а прогноз нагрузки на производство. У puzzle одна логика затрат. У idle — другая. У battler, strategy, social casino или action с real-time элементами — своя. Где-то основной счёт приходит за контент, где-то за баланс, где-то за backend, а где-то за UX и тестирование.
С графикой ещё нагляднее. 2D не всегда автоматически дёшево: если стиль полностью кастомный и требует большого числа анимаций, смета тоже может заметно вырасти. Но 3D почти всегда разгоняет бюджет сильнее. Модели, текстуры, анимация, риггинг, VFX, работа со сценой, оптимизация под устройства — всё это делает стоимость разработки мобильной игры выше и менее гибкой к изменениям по ходу проекта.
С движками полезно не романтизировать. Unity часто остаётся рациональным выбором для большого класса mobile-проектов, особенно когда важна кроссплатформенная база. Unreal может быть оправдан для отдельных визуально сложных задач, но не является универсальным ответом на mobile. Godot в некоторых случаях тоже подходит, но сам по себе не решает вопросов команды, пайплайна, поддержки и коммерческой зрелости проекта. Дороже или дешевле бывает не движок. Дороже или дешевле бывает весь набор решений вокруг него.
То же касается платформ. Кроссплатформенность действительно может снизить часть затрат на основу. Но она не отменяет отдельного тестирования, адаптации интерфейсов, работы с SDK, публикации, платёжных сценариев и стор-специфики на iOS и Android. Фраза «сделаем сразу на две платформы почти без доплаты» звучит приятно, но в реальном production почти всегда оказывается слишком оптимистичной.
Сколько стоят этапы геймдев-процесса: от GDD до soft launch
Когда бюджет считают по этапам, им проще управлять. Когда считают одним большим числом — им обычно только пугают. В мобильной разработке этапы нужны не ради бюрократии, а чтобы ловить дорогие ошибки тогда, когда они ещё не стали катастрофой.
Обычно путь выглядит так: сначала discovery и GDD, где фиксируются жанр, core loop, аудитория, монетизация и границы scope. Потом прототип, который отвечает на вопрос, есть ли в механике игра. Дальше pre-production: архитектура, пайплайн, ключевые UX- и контентные решения. Затем production — основной объём клиентской разработки, арта, интеграций, контента. После этого идут QA и release prep, где продукт стабилизируют и подгоняют под требования платформ. Затем soft launch — ограниченный запуск, чтобы проверить удержание, CPI, раннюю экономику и поведение пользователя на реальном трафике. И уже после этого начинается live ops, если игра действительно должна жить как сервис.
На бумаге иногда хочется срезать ранние этапы, чтобы быстрее перейти к «настоящей разработке». На практике это один из самых дорогих самообманов. Не проговорили scope в discovery — получите переделки в production. Плохо проверили механику — сделаете красивую, но пустую игру. Пропустили soft launch — рискуете выйти в рынок с продуктом, который не умеет удерживать и не окупает трафик.
Где выгоднее остановиться и проверить гипотезу до полного релиза
Для многих команд зрелый вопрос звучит так: не «сколько стоит мобильная игра целиком», а «какой следующий этап нам выгодно купить сейчас». Иногда ответ — прототип. Иногда vertical slice, если нужно показать качество издателю или инвестору. Иногда MVP, если уже пора проверять retention и монетизацию. А иногда полная разработка действительно оправдана — но только потому, что ядро проекта уже достаточно подтверждено.
Это важный сдвиг. Он возвращает вам контроль. Вы перестаёте покупать мифическую «игру под ключ» и начинаете покупать конкретную проверку конкретного риска.
Сроки, команда и модель разработки: почему «дешевле» часто значит «менее предсказуемо»
Когда считают стоимость разработки игры, есть соблазн смотреть только на ставку исполнителей. Но низкая ставка сама по себе не делает проект выгоднее. Если сроки расползаются, команда буксует, а артефакты плохо стыкуются между собой, итоговая цена почти всегда становится выше.
| Модель | Плюсы | Минусы | Когда подходит |
|---|---|---|---|
| In-house | Максимальный контроль, накопление компетенций внутри | Найм, управление, высокий постоянный burn rate | Если проект долгий и есть ресурс строить команду |
| Аутсорс-студия | Выстроенный production, QA, PM, предсказуемость | Ставка может быть выше на входе | Если важны сроки, управляемость и цельный контур |
| Фриланс-команда | Ниже стартовый чек, гибкость по ролям | Слабее ownership, выше риск разрывов и пересборки | Если scope очень узкий и есть сильный внутренний продюсер |
| Гибрид | Можно сохранить ключевые компетенции у себя и усилить внешне | Сложнее координация | Если внутри уже есть человек, который реально держит продукт |
Отдельно стоит сказать про фриланс. Да, он действительно может быть дешевле на входе. Но именно здесь чаще всего рождается скрытый налог на координацию: разные стандарты кода и арта, пропавшие исполнители, слабая документация, провалы по ownership, несостыковки в пайплайне. На старте вы экономите. Потом платите сроками, переделками и нервами.
Это не означает, что фриланс всегда плох. Это означает другое: если у вас нет сильного внутреннего продюсирования, фриланс редко даёт предсказуемую стоимость разработки мобильной игры. Он даёт низкий порог входа. Это не одно и то же.
Скрытые расходы, которые ломают смету после «почти готово»
Один из самых неприятных моментов в геймдеве наступает, когда игра вроде бы уже есть, а бюджет всё ещё не закрыт. Команда устала, ожидания были другими, а деньги продолжают уходить. Обычно это не форс-мажор. Просто изначально считали «разработку», а не продукт.
Скрытые расходы почти всегда всплывают в одних и тех же местах: аккаунты разработчика и платформенные комиссии, серверы и облачная инфраструктура, DevOps, аналитика и атрибуция, CRM и A/B testing, креативы для рекламы, ASO, локализация, soft launch-закупка трафика, саппорт пользователей, контентные обновления после релиза.
По отдельности эти строки не выглядят пугающе. В сумме они меняют картину радикально. Поэтому бюджет разработки мобильной игры без расходов на выход в рынок и поддержку — это не полная стоимость продукта, а стоимость изготовления сборки.
И здесь полезно быть жёстким к себе. Если в смете нет post-launch строки, это не значит, что её не будет. Это значит, что вы решили увидеть её позже.
Как считать окупаемость: почему бюджет разработки без маркетинга — неполная картина
Окупаемость мобильной игры считают не в момент, когда билд загружается в стор, а в момент, когда продукт начинает возвращать деньги с учётом всего пути до рынка. Разработка — только часть этого пути.
Базовая логика простая: расходы на производство, soft launch, UA, post-launch поддержку и платформенные издержки сравниваются с тем, что игра способна вернуть через LTV — пожизненную ценность пользователя. Между ними стоят retention, CPI, ARPU или ARPDAU, конверсии в платежи и качество монетизации. Не обязательно строить тяжёлую финансовую модель ещё до прототипа. Но без этой рамки говорить о бюджете честно не получится.
Именно здесь видно, почему слишком дешёвый запуск иногда оказывается самым дорогим. Сэкономили на аналитике — не понимаете, где отваливается пользователь. Сэкономили на onboarding и UX — проседает retention. Сэкономили на тесте монетизации — трафик не окупается. В результате приходится переделывать core loop уже после того, как потрачены деньги и на разработку, и на рынок.
Если вам сейчас уже тесно в общих вилках и нужен более предметный переход от сценариев к расчёту, логично открыть разбор сколько стоит создать мобильную игру. Он полезен в тот момент, когда вы уже выбрали класс проекта и хотите считать по жанру, платформам, монетизации и формату запуска, а не по усреднённым цифрам.
Как не ошибиться с бюджетом: вопросы, которые стоит решить до разговора с подрядчиком
Перед обсуждением сметы полезно остановиться и зафиксировать несколько вещей. Не ради формальности. Ради того, чтобы не покупать лишнее и не спорить потом о том, что вообще должно было получиться.
Во-первых, какой у проекта реальный жанр и core loop. Не референс на уровне «хотим как…», а что именно делает игрок с первой минуты. Во-вторых, что вам нужно на первом шаге: прототип, vertical slice, MVP или релиз. В-третьих, как игра будет зарабатывать: реклама, IAP, гибридная модель или что-то ещё. Дальше — нужен ли backend с самого начала, сколько контента должно быть на старте, какие платформы и рынки приоритетны, и какой бюджет вы готовы закладывать после релиза, а не только до него.
Если на эти вопросы нет ответа, оценка всё равно будет сделана. Но это будет не управляемая смета, а аккуратное приближение. А значит, реальная стоимость разработки игры выяснится позже — обычно в тот момент, когда менять уже больнее и дороже.
В каких случаях разумнее заказывать не «игру целиком», а поэтапную оценку и roadmap
Есть момент, после которого читать общие советы уже мало. Обычно он наступает тогда, когда вы узнали свой сценарий, увидели зоны перерасхода и хотя бы примерно понимаете, что хотите проверить первым этапом.
В этот момент следующая разумная задача — не искать ещё одну среднюю цену по рынку и не спорить о том, сколько стоит разработка игры для ПК или mobile «в среднем». Полезнее собрать персональную оценку: по жанру, монетизации, платформам, backend, объёму контента, составу команды и расходам после релиза. Именно так появляется roadmap, а не просто красивая цифра в письме.
Если вы дошли до этой точки, логичный следующий шаг — перейти к странице, где оценка раскладывается на практические параметры проекта: сколько стоит создать мобильную игру. Это уже не про абстрактную «цену под ключ», а про разговор о составе работ, сроках, рисках, DevOps, аналитике и той точке, где гипотезу действительно стоит проверять.
Это и есть зрелый способ считать проект. Не покупать туман. Не мерить амбицию чужими референсами. Не путать запуск сборки с запуском бизнеса.
Вывод: разумный бюджет — это не минимальная цена, а контролируемый scope
Когда спрашивают, сколько стоит сделать мобильную игру, на самом деле почти всегда спрашивают о другом: сколько стоит получить управляемый шанс на продукт. И ответ зависит не от одной цифры, а от того, насколько честно вы определили формат запуска, состав сметы и момент, когда гипотезу надо проверять, а не украшать.
Выигрывает не тот, кто нашёл самую низкую ставку. Выигрывает тот, кто понял, где его проект дорожает быстрее всего, сократил лишний scope, оставил фундамент и выбрал правильный следующий этап — прототип, vertical slice, MVP или полный релиз.
Если статья помогла вам увидеть свой сценарий, не останавливайтесь на «примерно понятно». Зафиксируйте scope, соберите вопросы по монетизации и платформам, отметьте, где вам нужен backend и что придётся поддерживать после релиза. А дальше переводите идею в расчёт. Именно с этого момента начинается не просто разработка мобильной игры, а нормальное владение проектом.
