В 4A Games контроль над помилками не просто про код — це інструмент для оптимізації роботи всього контент-продакшену. В інтервʼю Денис Мехед, Lead Programmer студії, розповідає, як інтерфейси, телеметрія та AI інтегруються в робочі процеси команди та підвищують її ефективність. А також пояснює, чому іншим компаніям варто триматись за пропрієтарні рушії.
«У всіх були ідеї як робити ігри й що вони б зробили у своїй, та знання, звичайно ж, були на нулі». Про знайомство з іграми та фокус на кар’єрному виборі в геймдеві
Моє знайомство з комп’ютером в принципі почалося з ігор. Перший комп’ютер я побачив у дошкільному віці у батька на роботі, і, звісно ж, перше що нам з братом там показали — перші простенькі ігри. Тому розуміння, що комп’ютер це щось, на чому, в першу чергу, грають в ігри — було зі мною змалечку.
Коли ми навчались в школі, ігри були новим медіа для нас, всі ними захоплювалися, всі постійно у щось грали, шукали місця, де можна купити (і не тільки) нові ігри — це була наша маленька субкультура. У всіх були ідеї як робити ігри й що б вони зробили у своїй, оскільки реальні знання як саме робляться ігри, що для цього потрібно і з якої сторони до цього підходити, звичайно ж, були на нулі. В цьому плані все закінчувалося на рівні дитячих мрій, тому не можна сказати, що це захоплення якось вплинуло на вибір мого освітнього профілю.
Після школи вступив у Києво-Могилянську академію на спеціальність «Програмна інженерія» чисто з прагматичних міркувань — як крок до потрібної й престижної професії, адже на той момент думки про створення ігор, хоч і тимчасово, та покинули мою голову.
На нашому факультеті багато людей повноцінно працевлаштовувалися вже з другого чи третього курсу, тож багато розмов було про проєкти, задачі, технології. Я ж особисто з цим не дуже поспішав, прислуховувався до того, що кажуть однокурсники й все більше складалося враження, що те що вони роблять хоч і цікаво, але не дуже весело. Тож виникло бажання знайти для себе щось, що можна було б назвати веселим. Десь тут і пригадалося захоплення іграми і я почав шукати вакансії в геймдеві.
Озираючись, можу сказати, що буває весело, місцями буває складно, місцями стресово, але все ще дуже цікаво. Тому, думаю, з вибором я не помилився.
«Розробка інтерфейсу редактора ігрового рушія — це дещо інакше, аніж просто написання якісного та оптимізованого коду». Про початок роботи у 4A й динаміку змін у рушії
У 2013 році я прийшов на роботу у 4A Games. Тоді якраз розпочиналася робота над Metro Redux, перевиданням перших двох ігор серії Metro. Далі були Arktika.1, Metro Exodus, робота над SDK, нові проєкти… Але для себе я не можу чітко відокремити один проєкт від іншого — для мене це все була робота над 4A Engine, рушієм на якому ми й робимо наші проєкти.
Це як корабель Тесея: він розгалужується, мерджиться, змінюється по одній дощечці кожного дня, а якщо озирнутись на нього через 2 роки — то це вже зовсім інший рушій. Важко зрозуміти коли він перестає бути рушієм для Metro Redux і стає рушієм для Metro Exodus, коли ти дивишся на нього кожного дня, та водночас, за ці роки, вже можна записати реліз декількох ААА-тайтлів у свій послужний список.
З першого ж дня я був залучений до розробки інтерфейсів едітора, тобто тієї частини рушія, за допомогою якої наші контент-кріейтори створюють вже свій контент. Розробка інтерфейсу редактора ігрового рушія — це дещо інакше, аніж просто написання якісного та оптимізованого коду. У цьому процесі технічна сторона є лише одним із аспектів і далеко не завжди визначальним. Це перш за все інструмент для людей: левел-дизайнерів, художників, аніматорів. Тому ефективність редактора вимірюється не тільки тим, наскільки швидко працює код, а тим, наскільки швидко й комфортно контент-команда може створювати свій контент, зрозуміти, що вона перед собою бачить і як цим користуватися.
Код, який швидко працює, сам по собі не гарантує прискорення виробничого процесу. Якщо інтерфейс побудовано так, що користувачу доводиться виконувати зайві кроки, шукати потрібні функції або боротися з непродуманою логікою взаємодії, якщо людина буде по 5 хвилин дивитися на кожне повідомлення про помилку, то ваші оптимізації на мікросекунди не будуть нічого варті.
У складних пайплайнах контент-продакшену, найважливішим ресурсом завжди залишається людський час. Доводиться мислити не лише категоріями класів, структур і патернів програмування, а й категоріями UX, зрозумілості, передбачуваності й узгодженості поведінки інструментів і людей, вгадування місць, де людина може помилитися і не допускати цього.
Постійна частина роботи — комунікація з тими, хто буде користуватися редактором. Розмови, спостереження за тим, як люди взаємодіють із програмою, спільний аналіз вузьких місць — усе це настільки ж важливо, як і написання. Метрики корисності едітора знаходяться там, де він органічно вписується в робочі процеси команди та розв’язує їх реальні проблеми, а не там, де швидко виконується код.
З часом, такий підхід виходить за межі програмування і перетікає в питання загального пайплайну життєздатності рушія, команди й проєкту в цілому. Над усім цим і продовжую роботу кожного дня, роблю роботу команди швидшою і зручнішою: рядок за рядком коду, мітинг за мітингом.
«Хотілося б, щоб ті команди, які вже мають власні рушії, від них не відмовлялися». Про монополізацію комерційними рушіями ринку й переваги in-house рушіїв
Попри те, що Unity та Unreal Engine сьогодні стали галузевими стандартами, не хотілося б, щоб ця тенденція продовжувалася — все ж хотілося б збереження різноманітності. Ви знаєте, у мене тут упереджена думка і спортивний інтерес, тому за справжню пораду мої слова брати не можна 🙂 Я б хотів порадити абсолютно всім командам писати власний рушій.
Проблема комерційних рушіїв не в тому, що на них складно зробити унікальну й особливу гру, а в тому, що на них дуже просто зробити гру, схожу на інші. Просто найняти людину, яка прийшла з іншого проєкту і перевикористала свої напрацювання, просто зайти на маркетплейс і купити асети, зроблені для когось іншого. Так, це фантастично скорочує час входження та ризики, але й автоматично звужує діапазон творчих можливостей подеколи.
У підсумку — в усі ігри починають просочуватися знайомі тенденції: за звуком, освітленням, камерою чи характерними багами можна одразу впізнати на чому її зроблено. А як розробнику надзвичайно цікаво грати в проєкти, побудовані на кастомних рушіях! Інколи ти бачиш характерні баги, які допускав сам, інколи намагаєшся вгадати, як саме вони реалізували конкретну фічу, вчишся в інших людей, просто дивлячись і спостерігаючи за їх продуктом, вгадуєш як вони реалізували механіки, навіть без доступу за їх лаштунки — це дуже цікавий процес.
Але, на жаль, різноманіття рушіїв в індустрії стрімко зменшується. За останні роки від власних технологій відмовилися або скоротили їх роль і великі компанії: CD Projekt Red, BioWare та навіть частково Ubisoft. Це спрощує виробництво, але збіднює творчий ландшафт — зникає різноманітність підходів, культур, експериментальних рішень.
Звичайно, робити власні проєкти на власних рушіях для багатьох команд на ринку може виявитися недосяжною задачею. Від рішення про створення власного рушія до першого playable прототипу можуть пройти роки, а індустрія в наші дні такої затримки не пробачає. З іншої сторони, ліцензії на комерційні рушії далеко не безкоштовні і, не маючи хорошого контракту на руках, можна і не вийти в плюс з фінансової точки зору. Це все складні бізнес-рішення, на які немає однозначної відповіді.
Звичайно, радити усім розробляти власні рушії хочеться, але я розумію, що це мрія, а не реальність. Тому хотілося б, щоб ті команди, які вже мають власні рушії, від них не відмовлялися.
«Коли запитують, чи є в нашому продукті AI, найчесніша відповідь часто буде: це залежить від того, що саме ви вкладаєте в це слово». Про багрепортинг й контекст AI та ML інструментарію
Оскільки у нас пропрієтарний рушій, то, мабуть, 90% (а можливо і 99%) коду й інструментів, з якими ми працюємо — наші, самописні. Тому важко описати наші інструменти, не описуючи всю роботу команди й весь стек технологій з якими ми працюємо.
Багрепортинг має допомагати людям спілкуватися між собою, знаходити спільну мову — це і є головним принципом та ідеєю. Не кажучи навіть про комунікацію між різними відділами, адже часто навіть два художники не можуть чітко пояснити, що саме вони одне від одного хочуть. Одну і ту саму річ перший може називати мешем, а другий — 3D моделлю, і кожен з них в цьому випадку правий.
Інструмент має описувати ситуацію стандартизовано, має уніфікувати терміни, формати, структури. Не можна очікувати, що творчі люди, всі як один, уміють формалізовано описувати технічні проблеми і не варто витрачати сили аби змінити світ. Буде набагато краще, якщо проблему за них буде описувати машина.
Відповісти на питання, чи використовуємо ми в аналізі репортів AI непросто, адже немає єдиного, чіткого й універсально прийнятого визначення, що саме вважати штучним інтелектом. Майже кожен автор, який пише книгу про штучний інтелект, відштовхується від якогось визначення та розглядає його в контексті своєї галузі. Для когось це складні нейронні мережі з мільярдами параметрів, для іншого — будь-який алгоритм, який приймає рішення без прямої участі людини.
Будь-яка машина, яка здатна зробити щось, що можна назвати «рішенням», формально вже потрапляє під ознаки штучного інтелекту. Тому, коли запитують, чи є в нашому продукті AI, найчесніша відповідь часто буде: це залежить від того, що саме ви вкладаєте в це слово.
Тому, якщо машина вирішила, що два тікети в багтрекері схожі і залінкувала їх — це вже штучний інтелект. Якщо вона вирішила що вони повністю однакові й закрила один з них — це вже штучний інтелект. Якщо система побачила, що тікет постійно оновлюється додатковою інформацією від різних юзерів, значить він для них важливий, йому варто підняти пріоритет — це також штучний інтелект.
Але, звісно, ми тут говоримо про специфічний набір наперед заготовлених правил і підказок, які продумала людина і в межах яких оперує машина. На сьогодні ж називаючи ці дві букви — AI, майже завжди мають на увазі machine learning і в такому випадку можна однозначно сказати — відповідь ні.
У контексті створення контенту й ігрового досвіду, ми залишаємося прибічниками handcrafter підходу: не використовуємо у нашому фінальному продукті generative AI, і це має відображення також і в наших інструментах, тому логіка цього інструменту не є наслідком навченої моделі, а результатом інженерної майстерності та усвідомленого дизайну.
«Ці підходи формують середовище, у якому багрепортинг стає інфраструктурою довіри, комунікації, якості та спільної відповідальності». Про автоматизацію багрепортів й формування ціннісного лупу
Головний принцип у питанні автоматизації багрепортингу — розробник більше зацікавлений у тому, щоб отримати репорт про помилку, ніж користувач. Якщо сталась помилка, то треба зробити усе, щоб репорт ми все ж отримали. У цей момент фрустрації, будь-яка перепона призведе до того, що юзер просто натисне червоний хрестик в інтерфейсі, в якому мав би відправити повідомлення про помилку, і піде далі виконувати свою роботу.
Згадування паролів в системі багтрекінгу в браузері — перепона, заповнення обов’язкових полів у форматі анкети — перепона, вимагання від нього знайти певні логи чи скріншоти — перепона. У цей момент, не можна очікувати від юзера ніяких когнітивних зусиль, навпаки — інтерфейс багрепортингу має бути мінімалістичним і тривіальним, а бажано ще і приємним.
Людині, яка спромоглася відправити репорт, потрібно подякувати, донести, що вона це зробила не дарма, а зробила свій внесок у розвиток проєкту. Ну і, звичайно, не варто очікувати від юзера, що він у цей момент почне формалізовано описувати проблему. У самого рушія набагато більше розуміння того що сталося, коли сталося і що пішло не так.
Система багрепортингу має бути побудована так, що все наповнення звіту було орієнтовано, а бажано і прописано, тією особою, яка буде цей репорт читати і в майбутньому фіксити. Ми, як розробники, маємо описати помилку до того, як вона відбудеться, щоб зі сторони юзера інструмент багрепортингу був не засобом «розказати, що юзер зробив не так», а способом «повідомити, що рушій помилився».
Система багрепортингу має пронизувати всі аспекти розробки, створюючи безперервний цикл навчання команди. Кожна помилка, кожен інцидент, кожен несподіваний сценарій не просто фіксується, а стає елементом спільного досвіду. Замість того щоб повторювати ті самі помилки, команда накопичує дані, патерни, причини збоїв, типові пропуски та вразливі місця.
Кожен новий репорт підсилює цей цикл:
аналіз → систематизація → оновлення практик → покращення інструментів → вища якість наступних релізів.
Це і є «луп»: самопідтримувана пам’ять, яка робить продукт стабільнішим, а команду — більш зрілою.
Культура відповідальності передбачає, що багрепортинг — це спільна справа, що лежить на обох сторонах. З одного боку, кожен розробник має проєктувати свій код так, щоб у разі помилки система автоматично зняла максимум корисного контексту. Розробник не лише пише фічу, а він також відповідає за те, щоб майбутній репорт був інформативним, відтворюваним і корисним для діагностики.
З іншого боку, кожен користувач (внутрішній чи зовнішній) має розуміти, що звернення до системи багрепортингу є природною частиною взаємодії з продуктом. Це не тягар, не формальність, а спосіб допомогти команді швидко та точно виправити проблему. Разом ці підходи формують середовище, у якому багрепортинг стає інфраструктурою довіри, комунікації, якості та спільної відповідальності.
«Розкладати на екрані діагностичну інформацію так, щоб вона була завжди доступна оку розробника, але не заважала користувачеві — окреме мистецтво». Про приватність і необхідний контекст
Стосовно питання приватності в контексті багрепортингу, то в активній фазі розробки воно стоїть не так різко. Адже всі наші юзери на цьому етапі — співробітники компанії (в тому, чи іншому форматі) і їх робочі станції з нашими програмами. Тож хотілося б думати, що нічого зайвого вони за цими машинами не роблять і ніяких сторонніх ресурсів не відвідують.
В плані інформації, яку можна назвати чутливою, але яка є дуже важливою в контексті багрепортингу, особливо при розробці інтерфейсів, то на першому плані, звісно ж, виступають знімки екрана. Це дуже хороший спосіб передати інформацію про те, що бачив юзер, коли все пішло не так і не тільки.
Розробляючи лейаут інтерфейсу робочої програми можна залишати собі, як розробнику, маленькі підказки: на випадок, коли доведеться «дебажити» помилку візуально. Інтерфейс також може бути наповнений непомітною діагностичною інформацією, яка завжди присутня на екрані, та хоч і нічого не дає кінцевому користувачеві, але дуже багато каже розробнику.
Користувач може роками користуватися едітором і не знати для чого в кутку горить маленька зелена лампочка. А розробник, відкривши репорт про помилку і побачивши на скриншоті її відсутність, одразу зрозуміє, що у юзера не було з’єднання з VCS, і в яку частину логу з понад ста тисяч рядків потрібно одразу дивитися.
Розкладати на екрані діагностичну інформацію так, щоб вона була завжди доступна оку розробника, але не заважала користувачеві — це окреме мистецтво. Але, звісно, просто відкидати питання приватності тільки з тої причини, що людина знаходиться на робочому місці не можна. Це нетривіальне з технічної точки зору завдання: залити на скриншоті тільки ті зони, які відносяться безпосередньо до робочої програми й уникнути кепчуру всього іншого. І навіть в такому випадку користувачеві варто дати зрозуміти, що саме і в якому вигляді буде прикріплено до репорту, дати йому можливість виключити це з його репорту за бажанням.
Система багрепортингу має формувати довіру і культуру роботи в команді. Якщо людина буде думати, що ми через знімки екрана зможемо побачити, яку музику вона сьогодні слухає в Spotify, або ж що пише колегам в Slack і почне сумніватися в доцільності репорту, то це ще одна перепона на шляху отримання нами важливої діагностичної інформації.
Звичайно ж, після релізу ситуація докорінно змінюється. Взаємодія з користувачами фінального продукту перебуває в зовсім іншій площині, тож ні про які скриншоти, чи відеозапис на машинах користувачів, мова іти не може, адже ми оперуємо у межах GDPR.
«Яким би зручним і корисним не був новий інтерфейс, який ви додали в едітор, цінність його все ще буде залишатися нульовою, якщо люди не будуть знати про його існування». Про принципи автоматизованої аналітики
В контексті принципів автоматизованої аналітики спадають на думку пару речей. По-перше, це таймінги роботи ваших інструментів. Якщо говорити про таймінги в ігровому процесі, то регресію помітити набагато простіше. Гравець звик до швидкої реакції на свої дії, якщо після натисканні кнопки він візуально бачить реакцію навіть із затримкою на пів секунди, або помічає що fps counter впав навіть на 5 пунктів, то це вже привід бити на сполох.
В цьому плані розробка інструментів створення контенту трошки складніша. Користувач часто не розуміє, що саме зараз робить едітор після його інпуту, йому важко оцінити який адекватний час спрощення мешу з шести тисяч полігонів (5 секунд, 20 секунд, а може і хвилина?). Тому, навіть якщо подібний процес сповільниться в декілька разів через бажання якогось окремого старанного розробника обкласти все додатковими логами і тонами діагностичної інформації, користувач сприйме таке «покращення» за потрібне і навряд зарепортить це як проблему.
З таких маленьких уповільнень на кожній юзерській машині складаються дні, тижні або і місяці людиногодин, які проєкт не може собі дозволити. Але через неможливість все це адекватно оцінити, вони залишаться непоміченими. Тут на допомогу прийде телеметрія, де можна буде оцінити в часі зростання таймінгів окремо взятих операцій. Також телеметрія може допомогти оцінити чи взагалі ваші інструменти використовуються.
Яким би зручним і корисним не був новий інтерфейс, який ви додали в едітор, цінність його все ще буде залишатися нульовою, якщо люди не будуть знати про його існування і не будуть ним користуватися. Зібрана через телеметрію статистика з використання інструментів, чи просто навіть про натискання кнопок в інтерфейсі, допоможе зрозуміти, які частини інтерфейсу мають більший попит, які потребують більшої уваги, а про які взагалі варто ще раз нагадати вашим користувачам.
Усім студіям хотілось би порадити не відокремлювати багрепортинг від інших аспектів рушія. Його ідеї мають бути закладені в архітектуру з самого початку і протягуватися червоною ниткою від основ рушія до комунікаційних каналів, пов’язуючи всі аспекти роботи команди. Які б не були бюджети, їх варто вкладати в талановитих розробників, кожен з яких: програміст, dev-ops чи контент-креейтор, зможе посприяти покращенню системи багрепортингу і в процесі в команді загалом.
