Розробка мобільної гри Tower Defense за вашим сценарієм

Розробка мобільної гри Tower Defense: де втрачається баланс

Баланс у Tower Defense ламається раніше, ніж з’являється перший рівень, — на етапі чисел. Типовий перекіс економіки: дохід із хвилі зростає швидше за ціну наступної вежі, апгрейд окупається за один захід, і гравець перестає вибирати — він механічно закриває позицію.

Зворотний перекіс не кращий: якщо вкладення не повертається за дві-три хвилі, рівень перетворюється на стіну, яку беруть перебором, а не тактикою.

Баланс хвиль тримається на тому, що кожна нова вежа закриває конкретний тип противника, а не всі одразу. Щойно знаходиться універсальне рішення, наступні хвилі стають прохідними: гравець проходить їх на автоматі, напруга падає, і захист бази перестає бути завданням.

Ми перевіряємо це прогоном кривих — дохід, вартість, шкода за типами — і правимо не окрему хвилю, а крок зростання між ними.

Темп гри — третя точка відмови. Довгі паузи між хвилями, відсутність прискорення часу й перший захід, який ніде перервати, призводять до того, що друга сесія просто не починається: гравець закриває застосунок на середині й не повертається.

Тут важливі довжина забігу, швидкість наростання загрози та збереження прогресу між короткими входами в гру.

Тому розробка мобільної гри Tower Defense у нас починається не з інтерфейсу, а з прототипу рівнів на голих числах: сітка позицій, крива доходу, вартість і характеристики веж.

Прототип показують на реальних прогонах — видно, де економіка йде в перекіс, на якій хвилі гравець упирається в межу і який темп він витримує. Графіка, прогресія та мета-шар підключаються після того, як числа сходяться.

Що дає перероблене ядро хвиль і економіки

Раніше хвилі задавалися списком: склад, порядок виходу та нагорода — вручну, а крива складності трималася на підгонці на око. Будь-яка правка балансу ламала сусідні рівні.

Тепер хвиля описується параметрами — склад, темп виходу, запас міцності, нагорода — і крива рахується за формулою від номера хвилі. Один коефіцієнт перераховує прогресію узгоджено, без ручного перепроходження всіх рівнів.

Логіку бою та нарахування тримаємо на серверній стороні: Unity на клієнті відповідає за відображення та введення, а стан бою, економіка рівнів і нагороди рахуються авторитетно.

Підміна значень на пристрої не дає переваги, а розсинхрон між клієнтом і сервером перестає бути можливим за побудовою.

Економіка рівнів зведена до перевірюваного балансу: дохід за хвилю, вартість і темп апгрейдів сходяться так, що на кожному відрізку в гравця залишається щонайменше дві життєздатні стратегії.

Ми вимірюємо частку хвиль з єдиним виграшним рішенням і частку застрягань без зростання — обидва показники мають падати від ітерації до ітерації.

Окремо пішов клас відмов, пов’язаних із розсинхроном прогресу: закриття застосунку, обрив мережі або повторний вхід більше не відкочують прогрес і не нараховують нагороду двічі.

Контрольні точки після кожної хвилі, ідемпотентні нарахування та журнал бою відновлюють сесію з точністю до хвилі. Це видно за часом сесії: вона перестає обриватися на «стіні», а утримання гравців наступного дня зростає.

Як зібрати гру: власна команда, конструктор рівнів, студія

Варіанти розробки різняться не лише строком, а й тим, де лежить ризик. Якщо правила типові — вежі ставляться за сіткою, хвилі йдуть за розкладом — більшу частину завдання закриває готовий шаблон.

Щойно з’являється гібридний жанр, наприклад Tower Defense з прокачуванням героя або економікою, шаблон упирається у свої межі.

Змішаний шлях

На практиці частіше обирають гібрид: ядро та баланс пишемо під вашу механіку, а рівні збираємо в конструкторі — геймдизайнер додає хвилі без участі розробника. Так випуск не розтягується, а контент оновлюється силами вашої команди.

Оцінку починаємо зі списку механік, які не можна виразити шаблоном, і з перевірки прототипу — за ними видно, який варіант дасть грабельну збірку швидше.

Етапи розробки: від прототипу балансу до релізної збірки

Порядок робіт будується так, щоб крива складності перевірялася до того, як у проєкт вкладені арт, звук і контент.

Дисбаланс у Tower Defense дешевше зловити на прототипі із сірих блоків, ніж переробляти готові рівні: параметри хвиль, економіка веж і маршрути описуються таблицею, з якої рівень збирається автоматично, а не правиться вручну.

1. Розбір сценарію та ігрових припущень: фіксуємо, що гравець має відчувати на кожній хвилі, де припустима поразка, які розвилки сюжет вимагає обов’язково.

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

3. Прототип балансу: сіра геометрія без графіки, прогін хвиль симуляцією на великій кількості повторів, перевірка кривої складності та відсутності суворо домінантної вежі.

4. Бойова математика: узгоджуємо шкоду, запас здоров’я, швидкість і час перезарядки так, щоб у гравця залишалося вікно на помилку, але не на бездіяльність.

5. Перевірка на тестовій групі: дивимося, де гравці зливаються, скільки тримається сесія і які вежі не беруть узагалі, після чого правимо параметри, а не рівні.

6. Релізна збірка: оптимізація під слабкі пристрої, збереження, внутрішньоігрові покупки, відповідність вимогам платформ.

7. Передача проєкту: вихідні коди, таблиці балансу, документація за параметрами та доступи до збірки — із супроводом після релізу.

Що ви отримуєте на руки: код, схеми, документація та регламенти

Передаємо проєкт так, щоб його можна було розвивати без нас: силами вашої команди або другого підрядника. Комплект фіксується актом приймання, розгортається на вашій інфраструктурі й не містить прихованих залежностей від нашої сторони.

• Вихідний код — повний репозиторій з історією змін і осмисленими коментарями щодо бойової логіки: шляхи ворогів, поведінка веж, обробка зіткнень, збереження прогресу.
• Схеми рівнів — описи карт, маршрутів і точок появи хвиль, таблиці параметрів противників, вартість і час відновлення веж.
• Модель економіки — таблиці нагород за рівень, правила видачі ресурсів, прив’язка внутрішньоігрових покупок до прогресу. Баланс правиться в конфігураційних файлах без перезбирання.
• Документація проєкту — карта модулів, порядок збирання релізної версії, вимоги до середовища, перелік зовнішніх бібліотек з їхніми ліцензіями та обмеженнями.
• Регламент оновлень — як додається новий рівень, сезон або правка балансу: від гілки в репозиторії до публікації в магазинах застосунків.
• Правила доступу — ролі та права в репозиторії, порядок видачі ключів підпису, схема роботи з консолями публікації та тестовими групами.
• Права на проєкт — виключні права на код і ігровий контент закріплюються за вами в договорі, включно з графікою, звуком і текстами, створеними в межах робіт.

Окремо передаємо чек-ліст перевірки: як зібрати проєкт з нуля на чистій машині та переконатися, що збірка відтворюється. Такий набір знімає головний ризик — коли гра працює, а внести правку в баланс або випустити рівень може лише автор.

Кейс: утримання гравців зросло втричі після переробки хвиль

Проєкт Bastion Line — Tower Defense з ручною розстановкою веж, який прийшов до нас уже після релізу. На старті до фінальної хвилі доходило 8% гравців, утримання сьомого дня трималося на 9%: перші рівні проходилися без напруги, а до 14-ї крива складності ламалася.

Здоров’я противників зростало швидше за дохід, апгрейди веж не доганяли, і гравець закривав застосунок на одному й тому самому рівні.

Переробка балансу йшла від даних. Криву складності рознесли по кроках: здоров’я хвиль зростає лінійно й задається таблицею множників, яку правлять без перезбирання клієнта. Повний програш замінили на м’яку невдачу — втрачається життя бази, а не весь прогрес рівня.

Економіку перезібрали: нагорода за хвилю прив’язана до кількості виживших веж, тому акуратна гра окупає наступний апгрейд, а не накопичується в глухий кут.

Метрики після: частка тих, хто дійшов до фіналу — 31% проти 8%, утримання сьомого дня зросло втричі, середня сесія — з 5 до 11 хвилин. На ранніх хвилях додали підказки з розстановки: новачок довше залишається в грі, а середина при цьому не стає простішою.

Обмеження залишилися усвідомлено. Мережевий режим і внутрішньоігрові покупки не чіпали — висновки не переносяться на змагальні сценарії автоматично.

Складність для хардкорної аудиторії винесли в окремий режим, а сезонні події все ще налаштовуються вручну: їхнє вирівнювання залишилося на наступну ітерацію.

Що робити, якщо механіку вже зібрано на готовому шаблоні?

Готовий шаблон — нормальна відправна точка: ігровий цикл уже працює, прототип грабельний, сценарії перевірені. Проблема проявляється пізніше: логіка хвиль, шкоди й балансу виявляється зашита прямо в обробники, дані перемішані з поведінкою, а числа правляться лише в коді.

Нарощувати другу механіку на такій основі дорожче, ніж один раз розділити шари, — тому спочатку шукаємо вузькі місця, потім вирішуємо, що переносимо.

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

Доробка механіки йде блоками: вежі та шляхи ворогів, потім економіка й прогрес — збірка залишається грабельною на кожному кроці.

Сумісність рішень перевіряємо до старту перенесення: умови ліцензії шаблону та сторонніх модулів, порядок ініціалізації сцен, поведінка під час оновлення платформи.

Окремо фіксуємо точки відкату: якщо після перенесення механіка поводиться інакше, повертаємося до попереднього стану, а не шукаємо причину в загальній збірці. Для прототипів на Unity це стандартний набір перевірок, для іншого середовища принцип той самий.

Підсумок: шаблон економить старт, але платити за нього доводиться підтримкою, якщо дані й логіка залишаються злитими. Опишіть, що вже зібрано і які механіки потрібно доопрацювати, — повернемося з планом перенесення та оцінкою.

Технічні питання, які знімаємо до старту робіт

Технічні сумніви знімаємо до підписання плану робіт — якщо залишити їх на середину, змінювати архітектуру під нові вимоги доводиться вже на живій збірці. Нижче — те, що найчастіше обговорюємо на першій зустрічі щодо Tower Defense.

Що входить у підтримку після релізу?

Оновлення під актуальні версії мобільних систем і вимоги магазинів, розбір падінь за логами, правки балансу та навчання. Окремо плануємо супровід сезонних подій і нових наборів рівнів.

Наскільки складно додати нову вежу або ворога?

Вежі, противники й хвилі описуються даними, а не розмазані по коду. Новий юніт додається налаштуванням параметрів і перевіркою взаємодій — тому доробка гри не перетворюється на переписування бойової логіки.

Як тестуєте механіки, якщо спільноти гравців ще немає?

Проганяємо хвилі на власних наборах сценаріїв: перевіряємо шкоду, час перезарядки, поведінку при втраті бази та економіку в довгій партії. Це замінює зовнішній тест і ловить дисбаланс до релізу.

Обговоримо завдання і повернемося з планом та оцінкою етапів

Оцінка етапів виходить точною лише коли є на що опертися: механіка, обсяг контенту та кількість платформ змінюють трудовитрати в рази.

Щоб не рахувати наосліп під час розробки мобільної гри Tower Defense, достатньо надіслати матеріали для оцінки — далі ми повернемося з планом робіт і розбивкою за строками.

• Сценарій або його начерк: хвилі противників, типи веж і їхніх покращень, економіка, умови перемоги та поразки — за ним видно обсяг ігрової логіки й балансних таблиць.
• Приклади ігор зі схожою механікою: що в них подобається, а що ні — це задає вимоги до керування, темпу та кривої складності.
• Поточний прототип, якщо він уже є: навіть зібраний нашвидкуруч, він показує, які системи працюють, а які доведеться переписати.
• Цільові платформи та режим роботи: чи потрібна гра без мережі, на яких екранах запускається, як часто плануєте додавати рівні та контент.
• Строки та пріоритети: що важливіше — вийти до дати чи довести кількість рівнів і баланс до потрібного стану.
• Обмеження: покази реклами, покупки всередині гри, зовнішні сервіси, вимоги магазинів застосунків до збірок і описів.

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