Тисячі вікон та «місток» до C++: технічні виклики розробки Football Manager 26 на Unity

Привіт, я Євген Мартиненко, Head of Unity в Pingle Studio. Останні роки геймдев помітно змінюється. Ми бачимо хвилі скорочень у великих студіях, заморожені або скасовані проєкти, обережніші рішення з боку паблішерів. Інвестиції стали більш вибірковими, а планування довгострокових ініціатив — значно складнішим.

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

Паралельно в індустрії розвивається й інший тренд: студії шукають партнерів, яким можна довірити складні частини розробки. Саме такою стала наша співпраця із Sports Interactive — разом з ними ми з 2024 року працювали над Football Manager 26.

На прикладі FM26 я хочу поділитися думками про те, як сьогодні виглядає співпраця з аутсорс-компаніями. А мої колеги, Unity-розробники Надія Гавриленко, Владислав Панченко і Ярослав Вологін, розкажуть, як це виглядало з технічного боку.

FM26 — гра, в якій більшість геймплею відбувається через UI

FM26 — це не типовий кейс із точки зору UI чи портингу. З одного боку, у гри є зрілий C++ core, який відповідає за симуляцію, дані і основні системи.

З іншого, новий UI-шар на Unity, який став основним інтерфейсом взаємодії з гравцем. Перехід на Unity означав необхідність працювати над «містком» між C++ core і C#-шаром Unity, зв’язати ігрову логіку з інтерфейсом, який приходить із Figma і відображається в UI. Це стало чи не найбільшим викликом проєкту.

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

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

Технічне ядро

Владислав Панченко — Unity Developer

Проєкт цікавий саме через свою архітектуру. Є C++ core, де вся логіка гри, і є Unity, який використовується як UI. Між ними — binding layer, який передає дані. Це окремий шар, який фактично виступає «клеєм» між двома системами.

З точки зору Unity-розробки це означає, що ти працюєш не тільки з UI, а й постійно думаєш про те, як ці дані приходять із C++, як вони оновлюються і як UI має на це реагувати.

Я більшу частину часу займався базовими UI-системами. Одна з ключових речей, яку я робив, це карусель.

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

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

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

Наприклад, у UI Toolkit не було нормальної підтримки деяких речей, які нам були потрібні. Частину таких задач ми, як команда SEGA і Sports Interactive, вирішували самі, і потім ці підходи, наскільки я бачив, вплинули на те, як сам Unity розвиває UI Toolkit.

Ще один приклад — система великих зображень. У базовій реалізації там фактично були тільки «іконки», і довелося робити окреме рішення для нормальних зображень у високій роздільній здатності.

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

Ярослав Вологін — Unity Developer

Гра спочатку розроблялася під ПК, і це одразу відчувається. На консолях UI ще більш-менш схожий, але на айфоні все сильно відрізняється. Дуже часто верстку доводилося робити майже з нуля.

Ще один момент — це перша версія гри на Unity. Через це багато речей не було готових, і нам довелося витратити багато часу на базові елементи: як будувати UI, як розбивати його на компоненти, як це все зв’язувати з даними. Бо дані приходять із C++, обробляються в C#, а UI — окремо. І цей зв’язок між ними потрібно було налагодити.

Гра дуже data-driven. Дуже багато гравців, клубів, параметрів. Через це легко щось переплутати: типи даних, форматування, значення. Більшість багів досить прості — наприклад, неправильне округлення або шрифт. Але через масштаб гри їх було дуже багато. Є і складніші випадки, коли неочевидно, де виникла проблема, у C++, у C# чи вже в UI.

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

Ще одна типова для проєкту задача — це інпут. Гра працює на ПК, консолях, iPhone, iPad, Mac, і під кожну платформу потрібно було враховувати свою логіку взаємодії. Особливо це стосується геймпадів: навігація між елементами, фокус, shortcut-и. Тут теж виникало багато дрібних багів, які потрібно було відловлювати.

Якщо говорити про внесок Pingle, ми багато де прискорили процес, підсвічували проблемні місця ще до того, як вони ставали критичними, допомагали з функціоналом у Unity, покращували процес верстки, давали фідбек дизайнерам. Також працювали над тим, щоб елементи і підходи були більш універсальними. Це в результаті спростило подальшу розробку.

Надія Гавриленко — Unity Developer

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

У попередніх частинах серії можна було перевикористовувати частину рішень, але в FM26 цього не було. Через перехід на Unity весь UI довелося реалізовувати з нуля.

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

Ця робота дуже зав’язана на командну взаємодію. Потрібно постійно синхронізуватися з дизайнерами, щоб зрозуміти, як саме має поводитися UI, з QA — щоб перевірити це в грі, і з C++/data-розробниками — щоб правильно відобразити дані.

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

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

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

Після релізу FM26 співпраця не завершилася

У квітні 2024 року ми почали співпрацю над FM26 невеликою командою з чотирьох розробників. Уже до вересня команда виросла до 29 людей з боку Pingle.

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

Після релізу FM26 співпраця не завершилася. Ми залишилися в проєкті і продовжуємо працювати над покращенням продукту.

І це добре показує, як зараз змінюється ринок. Великі компанії, як SEGA і Sports Interactive та інші, не просто оптимізують витрати, вони переглядають сам підхід до розробки. Для нас в Pingle це означає новий рівень задач і відповідальності. Ми працюємо з проєктами і франшизами, до яких кілька років тому було складно навіть уявити доступ. І це вже не разові історії, а довготривала співпраця, яка переходить із релізу в реліз.

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини