Від ручної рутини до AI-інструментів. Як ми автоматизуємо QA у World of Tanks

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

І от команда QA сідає звіряти одне з іншим. Рядок за рядком. Дата релізу прив’язана до календаря: ігрову подію на Хелловін не посунеш на тиждень, бо команда не встигла. Обсяг такий, що одна людина фізично не впорається, тому за звірку беруться всі п’ятеро. Виходить двадцять п’ять людино-днів на перевірку, від якої залежить, чи побачать гравці івент таким, як його задумали.

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

Я QA-інженер у Wargaming Kyiv, шість років працюю в геймдеві. Останні два роки паралельно з основними задачами розвиваю AI-інструменти для автоматизації рутинних QA-процесів. Те, що починалось як експеримент однієї людини, зараз використовує вже кілька команд. Стаття буде корисна тим, хто дивиться на свою рутину й думає, з якого боку до неї підійти.

Що таке сезонний івент з боку QA

Якщо ви давно не грали у World of Tanks або граєте тільки 15 на 15 проти інших гравців, то зараз щороку у грі зʼявляється ігрова подія до Хелловіну. Це окремий PvE-режим зі своєю історією, картою, стилем, власними механіками й повноцінною прогресією.

Останній такий івент, Babylon: Forbidden Zone, був у лайві на продакшн-сервері близько двох тижнів, мав три рівні складності (від Normal до Nightmare), п’ять різних босів і набір івентової техніки, яка більше ніде не використовується.

Структура забігу така. Спочатку треба пройти три фази, під час яких гравці катаються по кемпах, вибивають ботів і збирають Міріум, окремий ресурс в лорі ігрової події, що потрібний для бойових абілок. Коли зібрано достатньо, танкісти мають «здати» Міріум у колектор й перейти на наступну фазу. Бос-файт іде вже четвертою фазою. Але й на звичайних фазах розслабитись не вийде, бо бос увесь цей час їздить по карті за тобою. В цей час його не можна знешкодити, адже до 4 фази танки гравців занадто слабкі.

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

Самі ігрові події не складніші за іншу роботу. Але проблема тут в трьох речах, які накладаються одна на одну.

Перша це обсяг. Складний бос-файт, великі фази, багато нового контенту одночасно: боти, абілки, баффи, карта.

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

І третє це дедлайн. Реліз прив’язаний до дати в календарі, і зсунути його неможливо. Гравці не святкують Хеллоуїн в листопаді.

Тепер про ціну помилки. Гучних історій, коли розбіжність між документацією і конфігом доїхала до гравців, у нас немає, саме тому, що на цю звірку витрачалось стільки колективного часу. Але сама перспектива неприємна: якщо таке станеться на живому івенті, який уже стартував, доведеться патчити на гарячу. А гарячий патч у режимі, де все взаємопов’язане (фази, ресурс, боси, складності), це задача, якою не хочеться займатись на другий день релізу. То як оптимізувати процес тестування такої важливої події і одночасно дотримуватись рівня якості?

Передісторія: гаражний стартап у відкритому офісі

Історія почалась приблизно у 2024 році, ще до того, як AI став обов’язковою темою кожного другого мітингу.

Колега-розробник, який сидів поруч в офісі, сам захопився локальними моделями без жодного робочого завдання. У нього був сервер, не якийсь потужний кластер, просто те залізо, яке було доступне. На ньому він піднімав моделі й писав собі невеликі оптимізації під задачі розробки.

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

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

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

Прогалина в моїй області була очевидна. Усе, що на той момент існувало, робилось для програмістів. Для QA не було нічого схожого.

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

Ідея була в тому, щоб перекласти на модель наявний процес, а не вигадувати новий.

Зав’язка: тест-кейс райтер

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

Моделей перепробували кілька: локальні через Ollama, потім Mistral, найкраще під задачу заходив Qwen. На вхід йшов тікет із Jira, а контекст, який модель не могла дістати самостійно, доводилось докидувати руками.

Ура, працює? Не зовсім. Далі почались проблеми, і не там, де я на них чекав.

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

Окремо варто визнати й помилку в самій архітектурі. Перша версія була побудована на одинадцяти агентах. Виглядало це логічно, бо кожен відповідає за свою частину роботи, а на практиці така схема жерла величезну кількість контексту, забирала багато часу й видавала посередній результат. Нормального харнеса під таку задачу тоді теж не існувало, тому в роботі були обв’язки типу Roo Code, створені зовсім для іншого. Для розуміння швидкості розвитку напрямку, «тоді» — це ще два роки тому.

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

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

Розв’язала це не техніка, а розмова. Ми зібрали колег на окремий колл і разом вивели «ідеальний» для нас шаблон тест-кейсу. Уже потім ця структура закладалась у промпти й доводилась до того, щоб модель відтворювала її стабільно.

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

Розвиток: підтримка й нормальні інструменти

Момент, який усе змінив, виявився організаційним, а не технічним.

Показ напрацювань пройшов у два етапи. Спочатку флоу демонстрували так, як він і працював, прямо в CLI. Виявилось, що з консолі складно зрозуміти масштаб: працює щось, а що саме — не видно. Тому навколо того ж флоу з’явилась GUI-обгортка, написана разом із Claude, і вже на ній інструмент показували ліду, а потім менеджеру.

Наш перший GUI-застосунок: один прогін тест-кейс-райтера від тікета в Jira до готових кейсів

Реакція керівників на такий експеримент була доброзичливою від початку, що теж важливо, але саме на GUI стало видно обсяг зробленого. І лід, і менеджер побачили в цьому конкретну користь для роботи команди і як це можна масштабувати.

Формально це виглядало так. Доти задачі під AI-напрямок уже існували, але в межах одного проєкту й під потреби однієї команди. Коли з’явилась ідея винести інструмент на всіх, задача перетворилась із локальної на глобальну, тобто в офіційний напрямок роботи.

Приблизно тоді ж вирішилось питання потужностей. Enterprise-підписку на Claude Code спочатку отримали розробники, зокрема той самий колега. Різниця з тим, з чим доводилось борюкатись раніше, була настільки очевидною, що підписку попросили й для QA-напрямку. Заодно це зняло питання NDA: умови enterprise-підписки дозволяють передавати робочі дані, тож не доводиться щоразу вирішувати, що можна подавати в контекст, а що ні. Якщо ви тільки починаєте, це та річ, яку треба узгодити на старті, а не після того, як інструмент прижився в команді.

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

Наступна мішень: конфіги

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

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

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

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

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

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

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

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

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

Головний прийом: пакувати знання у скіли

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

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

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

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

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

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

Скіли доводиться не тільки писати, а й вирізати

Інструмент, що побудований під сьогоднішні моделі, за півроку може виявитись переускладненим. Ми з цим уже мали справу.

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

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

Тобто робота над інструментом іде не тільки в бік «додати ще», а й у бік «прибрати те, що вже зайве». Це неочевидно, і на це треба закладати час.

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

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

Що пішло не так

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

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

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

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

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

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

І ще одне, про що скажу прямо. Повністю на самоплив цей процес відпускати не можна. Контроль якості тримається на двох речах: харнес-скриптах, які перевіряють результат автоматично, і на human in the loop. Такі прогалини, як «модель не знала, що туди треба дивитись», закриває людина, і поки що інакше не виходить, хоча ми поступово й рухаємось в бік більшої автономності.

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

Задач, де від AI відмовились свідомо, у нас поки немає, намагаємось перевести на ШІ все, що можливо. Очевидно, що UI/UX-задачі модель не протестує замість людини. Але навіть там вона корисна не напряму: може оптимізувати сам підхід до тестування або допомогти розвернути тестове поле.

Де ми зараз

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

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

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

Чого довелось навчитись (і чи треба бути програмістом)

Логічне питання в цьому місці: як людина, що не пише код щодня, дійшла до інструментів, якими користуються кілька команд?

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

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

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

«А тепер QA не потрібні?»

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

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

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

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

Плани

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

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

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

Поради тим, хто починає

Почніть з малого, і саме зі свого болю

Не з ревʼю коду чи власної вікі, а з чогось буквально механічного, що забирає ваш час щодня: шаблон баг-репорту, який пишеться з нуля або рутинні кроки перед тестуванням. Велике й універсальне на старті майже завжди закінчується втратою часу: AI видасть «результат», а ви потім довго шукатимете, де саме він помилився. У нашій історії і я, і колега починали з думок про щось грандіозне, а зрушилось усе тільки тоді, коли взялися за власну щоденну рутину.

Порахуйте не тільки економію, а й вкладення

Тест-кейс-райтер від першого прототипу до реального використання зайняв близько півроку при витраті 20–30% часу паралельно з основними задачами. Інструмент для звірки конфігів, коли база й досвід уже були, зайняв приблизно день. Перший інструмент завжди дорогий, бо разом з ним ви будуєте власні навички та обв’язки. Кожен наступний обходиться в рази дешевше.

Не переускладнюйте архітектуру на старті

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

Плануйте роботу над обв’язками, а не тільки над агентами

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

Тримайте набір еталонних прикладів і звіряйтесь із ним

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

Пакуйте напрацьоване у скіли, а не залишайте в чаті

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

У скіли пишіть тільки те, чого модель знати не може

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

Виберіть робочу модель і не перетворюйте цей вибір на окремий проєкт

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

Якщо йдете пітчити ідею керівництву, говоріть про час

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

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

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