Чим займаються R&D-команди в геймдев-компаніях. Бліц з розробниками

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

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

«R&D команда може працювати як незалежний підрозділ, що шукає новий продукт, або як скаут-юніт»

Олексій Захарчук — Game Designer, Stepico

Робота геймдизайнера в R&D — це постійна швидкість і гнучкість. Тут немає звичного предпродакшену чи відпрацьованих процесів — рішення приймаються на ходу. Часто доводиться працювати з аналітикою ринку, відстежувати нові релізи, грати у проєкти різних жанрів і платформ, щоб розуміти, куди рухається ринок і де є «вільні ніші». Тестувати не тільки нові ігри, а і платформи.

Існує поняття Red Ocean і Blue Ocean. Перший — це надконкурентний ринок, де всі копіюють успішні продукти. Другий — простір нових ідей, де мало конкурентів, але й немає готових рішень. R&D постійно балансує між цими двома океанами. Від цього залежить і підхід: або ми шукаємо нову нішу, або намагаємось переосмислити вже знайоме. Усе інше — знайоме для будь-якого геймдизайнера: документація, комунікація, тестування, дослідження. Але горизонт свободи тут набагато ширший.

R&D-команда може працювати як незалежний підрозділ, що шукає новий продукт, або як «скаут-юніт» для вже наявного — тестуючи гіпотези, шукаючи рішення, перевіряючи нові фічі. Масштаб команди буває різним — від одного геймдизайнера, який формулює концепт і передає його продуктовій команді, до невеликої групи з дизайнерів, девелоперів, художників, UX/UI-спеціалістів і наративного дизайнера. Знайшовши вдалу ідею, така команда або перетворюється на продуктову, або передає напрацювання далі й вирушає шукати наступну нішу.

Будь-яка ідея має розв’язувати конкретну задачу або покращувати певний показник. Якщо ідея не дає вимірюваної користі — її можна відкласти у беклог і повернутися під час ітерацій. Я керуюсь принципом data-driven і фреймворком AERM, який дозволяє дивитись на гру як на бізнес. Не просто «додати фічу», а чітко розуміти, навіщо і як це вплине на метрики.

Абсолютно захистити свої напрацювання неможливо. У великих студій є ресурси, щоб побачити будь-який успішний експеримент, тому найкращий захист — швидкість. Робити швидше, якісніше й глибше за інших. Новизна сьогодні — це не винахід колеса, а нові комбінації знайомих елементів. Змішуєш «жовту» механіку з «синьою» — отримуєш «зелену». Успішна гра — це не лише геймплей, а й правильний маркетинг, розуміння аудиторії, платформа доставки контенту. Наприклад, зараз є певний тренд на кросплатформеність. Гравці хочуть грати в гру вдома на ПК і продовжувати в дорозі на телефоні. Якщо даси їм це — навіть у Red Ocean можна отримати свою частку аудиторії.

«Якщо систематизація задач або ієрархія процесів заважає швидким творчим підходам і глобальним змінам — її потрібно послабити»

Дмитро Бессонов — Senior Concept Artist, Gameloft

Мій досвід з R&D у геймдеві відбувся в Gameloft. У нас, хоч і не спершу, та навіть була команда, що так і називалася — R&D Team. Це не була група підтримки якогось одного відділу, а повноцінна команда, яка створювала прототипи мобільних ігор (в основному казуальних) і перевіряла їх на реальних користувачах.

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

На цьому етапі сам візуал уже не був таким вирішальним, але все ще сильно впливав на результати тестів. Наприклад, були випадки, коли ми навмисне робили графіку примітивною і недорогою на вигляд, щоб продукт виглядав як гіпер-кежуал, не вимагав великого комітменту і з низьким порогом входу — більш зрозумілий широкій аудиторії. Тому художник у R&D повинен бути відкритий до різного, тут усі підходи корисні. Чим більша вартість виробництва візуала — теж фактор, тож якщо в експерименту невеликий бюджет — потрібно пропонувати дешеві, але виразні засоби.

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

У команду R&D, на мою думку, повинні входити люди-оркестри, дженералісти, яким комфортно працювати автономно і які вміють глибоко копати у будь-якій темі. Ті, хто бачать загальну картину та потреби проєкту і навіть студії. Конкретний біль для художників — дуже багато напрацювань викидаються через тиждень, місяць. Тому товста шкіра також не завадить. Якщо пощастило отримати зелене світло, то передаючи розробки далі варто зробити хороший гайд, залишити вихідники й інструменти.

З мого досвіду, маленькі команди — це ключ до гнучкості й відкритості до нових ідей, її легше розгорнути на 180° у будь-який момент. У невеликій команді комунікація більш ефективна, а її було дуже багато: з програмістами, геймдизайнерами, продюсерами, 3D/technical артистами. Певний час у нас була дуже крута практика щотижневого плейтесту прототипу, у який ми грали всією командою. Живий фідбек приходив з усіх відділів.

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

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

Може здатися, що «все вже створено», але насправді комбінацій безліч. Якщо ви туди ще додасте свій особистий унікальний досвід і ставлення, а не просто формально зробите умовний рескін, то в будь-якому разі вийде щось нове. Комбінуйте сетинги, стилі, жанри, міняйте хороших і поганих героїв місцями тощо. Крім того, можна використовувати нехитрий прийом, який називається «матриця ідей» Фріца Цвіккі, коли параметри розкладаються по осях таблиці, а на перетинах народжуються несподівані комбінації. І цей процес можна повторювати багато разів, правил немає. Можна комбінувати вже готові комбінації.

У концепт-арті це часто використовується. Якщо у тебе вже є 3–5 варіантів, але вони ще не вивели тебе з кола банальщини, спробуй комбінувати їх між собою. Навіть якщо не вийде цілісний хороший варіант, можна взяти лише вдалу частину і це можливо наштовхне на новий, якісно кращий раунд скетчів. Тож комбінації та експерименти — ще один ключ.

Мій особистий досвід R&D був не просто частиною звичного продакшена, а простором, де можна експериментувати і впливати на напрямок майбутніх ігор без рамок ліцензорів і франшиз.

«R&D має бути першими, хто тестує нові підходи»

Сергій Білявський — R&D Project management, Playtika

Моя роль — на стику технологій, креативу й командної динаміки. Я координував R&D-ініціативи від гіпотези до інтеграції в live-продукт, вибудовував процеси, де команда могла швидко тестувати ідеї без бюрократії. У House of Fun це означало створити середовище, де художники, деви й аналітики могли експериментувати, але в чітких межах delivery-ритму.

Робота з тасками — це пріоритизація експериментів, синхрони з технічними лідами, оцінка ризиків і ресурсів, відстеження метрик proof-of-conceptів. R&D-команда працює поруч із core-продакшном, але має автономію — ми тестуємо рішення, які потім передаємо в основний пайплайн після перевірки ефективності.

Ядро — це технічний ПО, дев фронт + бек і tech artist (аніматор/ інтегратор). Вони задають напрям експериментів, формують технічну базу й впливають на фічсет майбутніх проєктів. Щоб зберігати гнучкість я впроваджував короткі спринти з чітким критерієм «go/no-go» або ж must/nice to have і меритократичне обговорення будь-яких гіпотез.

Серед здобутків нашої R&D команди можна виділити пропозиції по оптимізації пайплайну. Річ у тім, що логіку гри у нас раніше прописували девелопери, а, як відомо, вони зазвичай хочуть зробити швидко і так щоб воно точно працювало, не завжди для цього використовуючи останні технології. І згодом, коли маєш зробити надбудову на певну гру, то це може значно ускладнитись ненайкращим кодингом та застарілими технологіями. Тож ми зробили так, що техартісти, які є творчими людьми, опанували більш технічні речі, як от: робота всередині рушія, загальна структура гри і те, як воно виглядає в бекофісі. Після цього — ми передали їм написання логіки гри, яку ми робили на Miro у форматі bpml.

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

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

Ми фіксували всі напрацювання у внутрішніх репозиторіях. Але ключ — не тільки захист, а швидкість і видимість: R&D має бути першими, хто тестує нові підходи (AI-генерація контенту, нові типи монетизації). Навіть у світі, де «все вже є», інновація часто — просто вдала комбінація всім добре відомих елементів.

«Надавши максимальний пріоритет R&D, я витратив незрівнянно менше ресурсів ніж інші розробники»

Владислав Фоменко — Technical/Game Designer, FPV Drone Simulators

Як технічний геймдизайнер, я займався дослідженням, веденням R&D документації та розробкою нових ігрових механік. До певного часу в компанії не було цього департаменту й ідея формування R&D команди була запропонована дизайн-директором Леонідом Воробйовим. Я радо долучився до команди першим, тому мав змогу впливати на його структуру і процеси. R&D — це в першу чергу про економію ресурсів та конкурентоспроможність. Якщо компанія здатна швидко дослідити та протестувати перспективні ідеї — це значна перевага. Для цієї позиції важливо дуже добре розуміти специфіку ринку, технічну частину рушія та проєкту й правильно використовувати наявні ресурси.

У R&D кожен день відчувається по новому, завдання включали як документацію та дослідження ринку, так і технічну роботу, реалізацію механік та систем (як приклад новий комбат), баланс. Окремо — це робота з фідбеком та організація внутрішніх плейтестів, також важливо зазначити, що завжди необхідно враховувати технічний фактор та вплив механіки на оптимізацію проєкту.

Колись Форд сказав, що на його заводах найкращі інженери працюють над інструментами, бо хоч іноді це може здаватись дрібничкою, але вона впливає на весь бізнес. R&D також допомагає компанії знайти правильні інструменти.

На мій погляд, R&D має супроводжувати та підтримувати розробку, тому це не просто «етап». Ринок стрімко розвивається і важливо швидко адаптуватись, щоб продукт не застарів ще до релізу. Тому головне завдання R&D — це оперативно реагувати на тренди та дії конкурентів, швидко реалізувати прототипи та пропонувати технічні рішення для розробки.

Через необхідність контролювати стан ринку та досліджувати усі «новинки», у команді обов’язково має бути спеціаліст з відділу геймдизайну, також важливо мати технічних спеціалістів, які можуть швидко реалізувати технічні завдання. У моєму випадку, я об’єднав обидві ролі: як дизайн, так і участь у технічній складовій розробки. Здебільшого інші спеціалісти долучаються до R&D за потреби.

Як інді-розробник, я поєдную технічну, дизайнерську та польову роботу. Ви маєте не лише розуміти технічні особливості вашої роботи, вам обов’язково необхідно знати для кого ви це робите і чого не вистачає вашим гравцям. У моєму випадку, через специфіку симулятора військового використання FPV дронів, попередній R&D зайняв більше часу за розробку першої демо версії.

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

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

Ще 4 роки тому ніхто не міг і подумати, що FPV дрон буде найстрашнішою зброєю на лінії фронту (не враховуючи засоби стратегічного рівня), людська фантазія безмежна.

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

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

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