Розробка сучасних ігор передбачає наявність персоналу з широким спектром навичок. Для роботи над одним проєктом потрібні команди, до складу яких зазвичай входять представники різних спеціалізацій. Розмір команди може варіюватися від 10 до понад 100 осіб, в залежності від масштабності продукту. Художники, програмісти, геймдизайнер, звукорежисери, перекладачі, тестувальники – це далеко не весь список причетних до створення ігор.
Щоб створити якісну сучасну комп'ютерну гру, потрібен не один рік наполегливої роботи. Звичайно ж, хочеться максимально швидко видати публіці якісний продукт з мінімальною кількістю помилок. Тому компанії використовують шаблони, які дозволяють економити масу дорогоцінного часу на комунікаціях між розробниками і QA фахівцями.
Дотримання правил написання баг-репортів дозволяє швидко зрозуміти суть бага і зорієнтуватися, в який відділ відправляти звіт для виправлення помилки. Слід зауважити, що для різних проєктів і в різних компаніях можуть бути трохи інші шаблони та стандарти звітів про помилки. Розглянемо особливості оформлення баг-репортів на ігрові дефекти в нашій компанії.
Правило 1.
Заповнення розділу «Platform»
Якщо тестування проходить на персональному комп'ютері – вказується «PC», якщо на мобільному пристрої – «Mobile». В полі «OS» пишеться назва операційної системи (наприклад, Windows), в поле «OS Version» – версія операційної системи (наприклад, 10x64).
Розробка ігор, як і будь-якого іншого програмного забезпечення, проводиться на персональних комп'ютерах – настільних або ноутбуках. Багато ігор призначені для ігрових приставок, смартфонів, планшетів та ін. Спочатку розробка здійснюється за допомогою симуляторів зазначених пристроїв. Але, як і будь-яка модель, вони дуже часто істотно відрізняються від оригіналу. Тому гра, яка успішно працює на симуляторі, може мати проблеми при запуску на девайсі.
Крім того, багато хто з виробників пристроїв вводить ліцензування для програмного забезпечення. Одна з необхідних умов успішного проходження ліцензії – відповідність списку технічних вимог. Навіть при наявності незначних відхилень від вимог в ліцензії може бути відмовлено. Тоді програму повертають на доопрацювання і, таким чином, втрачають час, що призводить до втрати грошей. До того ж, процес ліцензування в більшості випадків платний. Тому дуже важливо перевірити гру на відповідність заявленим параметрам апаратного забезпечення.
Правило 2.
Грамотне оформлення розділу «Summary»
Це одна з найважливіших частин звіту. Тому вкрай важливо описати дефект так, щоб девайс, на якому він з'явився, його дислокація і сама суть легко розумілася зі списку звітів про помилки.
Для цього необхідно вказувати:
- для ПК – платформу, на якій проводилася перевірка (Win), для мобільних пристроїв – назва пристрою та модель (iPad 10.2, iPhone 12, Samsung А20S тощо);
- абревіатуру мови локалізації (якщо помилка пов'язана з перекладом тексту);
- місце розташування: рівень, розділ, локація та ін. (детальний опис про локації в іграх див. тут);
- короткий опис бага (за принципом «Що? Де? Коли?»).
Слід знати, що в полі «Description» ця інформація не дублюється, пишеться тільки опис бага за принципом «Що? Де? Коли?».
Локалізація ігор – це прекрасна можливість завоювати нові ринки. Але щоб витрати на неї були виправданими, компанія повинна бути впевнена, що гравці в інших країнах приймуть гру на ура. Найбільш складним при перекладі є адаптація гри слів і сталих виразів, виявлення культурних особливостей та переклад з відповідною передачею інтонації при озвучуванні. Також важливим є підбір акторів для озвучування з голосами, схожими на голоси оригіналу, передача емоційного забарвлення, передача акценту даного регіону.
Часто локалізацією займається ціла команда, іноді наймають окремі компанії. Все залежить від масштабу гри, вона може перебувати навіть в інших країнах. Адже носіям мови найкраще відомий культурний аспект, особливості деяких слів, стійкі вирази. Також до локалізації відносяться формати валют, чисел, часу, телефонних номерів тощо. Якщо в грі використовується оригінальний шрифт, окремо створюється аналогічний шрифт для алфавіту. Залежно від візуальної складової гри і особливостей в програмному коді, програмісти можуть вносити зміни в програмне забезпечення або створювати окремі файли для зручності перекладу.
Компанія зацікавлена, щоб її продукт був добре адаптований для певної цільової аудиторії відповідно до її культурних особливостей. Але і темпи розвитку ігрової індустрії не дають часу на розслаблену або розмірену роботу. Кожен відділ повинен працювати швидко, чітко і злагоджено, як деталі одного величезного механізму. Тому, якщо знайдено баг, необхідно якомога швидше його усунути. Читаючи тему бага, оформлену як вказано вище, розробники не витрачають час на з'ясування, якого виду цей дефект (локалізації, механіки, дизайну тощо) і на його пошук за рівнями.
Правило 3.
Детальний опис помилки
Кожен баг-репорт по грі повинен містити таку інформацію:
- платформу та назву пристрою з моделлю, на якій проводилася перевірка з версією ОС (Win 10х64, Samsung А20S Android 11 тощо);
- тему та опис бага;
- номер білда, на якому проводилося тестування;
- детальні кроки;
- фактичний та очікуваний результати;
- обґрунтування (чекліст, локкіт тощо).
На проєктах також може вказуватися категорія бага.
Що таке чекліст і як з ним працювати детально описано в статті нашого блогу.
Що таке локкіт? Це документ (з англійської localization kit – калька), який являє собою пакет даних, що надається замовником, в якому наведені всі тексти гри на всіх підтримуваних мовах. Найчастіше під цим терміном мається на увазі просто файл з необхідними перекладами.
Що таке білд? Простими словами – це версія гри. У кожної гри є номери збірок, так званих білдів. В процесі розробки проєкт тестується, і буває, що потрібно знати, яка версія і з яким номером збірки встановлені у тестувальника/іншого учасника процесу. Поведінка в одному білді може відрізнятися від поведінки в іншому, для цього і потрібно уточнювати, в якому саме був знайдений баг. Перед перевіркою виправлення бага необхідно переконатися в тому, що тестується потрібна версія. Можливо, помилка вже була виявлена і виправлена в наступній версії/білді.
Часто поруч з номером білда пишуть і стадію розробки для опису ступеня готовності гри – Аlfa або Вeta. Стадії або можуть бути офіційно оголошені і регламентуються розробниками, або іноді цей термін використовується неофіційно для опису стану продукту.
Слід зазначити, що стадії Beta і Alpha не є показниками нестабільності, так як присвоюються грі один раз або один раз за серію, в залежності від системи розробки. Вони можуть присвоюватися декільком версіям, що випускаються поспіль.
Як правило, платформа, на якій проводилася перевірка з версією ОС та номер білда, на якому виконувалося тестування, вказується в блоці «Steps to Reproduce» безпосередньо перед кроками.
Правило 4.
Необхідно уточнювати назву гри
Її можна вказати в кроках відтворення або в полі додаткової інформації. У компанії багато проєктів, і часто одні і ті ж люди працюють на декількох проєктах одночасно. Тому важливо конкретизувати, в якій саме грі знайдений баг.
Правило 5.
Використання спеціальної термінології
Безсумнівно, термінологія допомагає нам повніше зрозуміти конкретні теми. Хороша термінологія зменшує двозначність і збільшує ефективність комунікації та роботи загалом. Для того, щоб розуміння суті бага було якомога точнішим, використовують спеціальну термінологію.
Правило 6.
Граматичне оформлення
Незважаючи на те, що в основному при описах бага використовується пасивний стан, в багах в іграх часто доречний активний (дійсний) стан. Потрібно звертати увагу на суть помилки і вибирати доречну для конкретного випадку граматику. Також важливо зберігати структуру речення та правильно поєднувати слова між собою.
На перший погляд, інформація по оформленню баг-репортів на баги в іграх здається складною і об'ємною, але на практиці все набагато легше. Рекомендуємо вивчити приклади баг-репортів по іграх, скріншоти локкітів та чеклістів, інші корисні матеріали в статті.
Підводячи підсумки статті, можна сказати, що використовуючи шаблони, компанія економить купу часу на комунікаціях між відділами. А чітке, правильно побудоване граматично формулювання суті помилки допомагає у швидкому пошуку та усуненню багів. Всі ці, на перший погляд, дрібниці скорочують терміни випуску продукту, надають сучасному споживачу постійні новинки високої якості.
