Тестування ігор (Game testing)

PreviousТестування платіжного шлюзу (Payment Gateway)NextТестування VR програмного забезпечення

Last updated 2 years ago

Тестування ігор (Game testing)

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

Playtesting - це один із видів тестування ігор, який призначений для розуміння який ігровий досвід та емоції отримують гравці від ігрового процесу. Для проведення плейтестів гравцям дають доступ до раннього білду (даний вид тестування проводиться до релізу гри та/або фічі). Найчастіше в плейтестах беруть участь не QA фахівці, а рядові геймери, родичі, загалом хто завгодно, хто може поглянути на ваш продукт свіжим поглядом, дати вам зворотний зв'язок на основі свого ігрового досвіду та вражень, а також поважатиме те, що написано у підписаним ним NDA перед стартом плейтесту.

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

Говорячи про специфічні для відеоігор види тестування, я б виділив таку групу як Game Design Testing , куди включу Balance testing, Level Design testing, "Fun Factor" testing).

Balance Testing передбачає перевірку того, що баланс є:

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

Можливо, місцями навіть варто подумати про мету гри, але це вже як бонус, цим повинен займатися вже явно не Quality Assurance фахівець. Однак QA може зробити нотатки та поділитися з командою!

Level Design Testing передбачає перевірку рівнів (левелів). Навіть найкрасивіший візуально рівень може містити непрохідні місця через, наприклад, невидимі стіни (є модель (міш), але немає текстур), дірок у підлозі (наприклад через погану стиковку площин або моделей), попадання в так звані Stuck points, де встряв і вже нікуди далі зрушити персонаж не може.

Такий досить абстрактний вид тестування, як Fun Factor Testing , хтось виділяє окремо, а хтось вважає, що це частина Playtesting. Тут наголос робиться на "фановість" процесу гри. Ідеально збалансована гра може банально не весело грати і це відлякає аудиторію. Також тут варто перевірити такі ігрові механіки, як навігація, прицілювання, взаємодія з предметами, NPC тощо. Невдалі механіки, непривабливий арт, також на цій стадії. Якщо вас у процесі нічого не фруструє, ви на правильному шляху =) Більше про плейтести, включаючи Fun Factor, можна подивитися , хоч я і не в усьому згоден з автором.

Трохи вище хтось десь згадав персонажів/рівні/предмети тощо? Тобто. ми починаємо говорити про Visual Components Testing групі, куди можна внести тестування 3D моделей/сцен, 2D (спрайти) та 2.5D.

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

2D та 2.5D Testing- Тестування вже 2D та 2.5D графіки. Сюди включають роботу зі спрайтами (2D), перевірка спрайтів та/або 3D моделей для 2.5D ігор, часто в такому вигляді роблять файтинг, сайд скроллер або рогалики. Як приклади тестування, можна навести проблеми з порядком малювання світу та героїв в ізометричних проектах, з "віконцем", яке показує ГГ, якщо він за стіною (як приклад тут можна навести такі ігри як Fallout 1 і 2), та й часто нюанси, що зустрічаються в цілому, з прозорими об'єктами. Хоча ваш проект і в 2D/2.5D, проте такі елементи в ньому можуть взаємодіяти з 3D об'єктами та складними ефектами, пов'язаними з прозорістю. Один з поганих сценаріїв в даному випадку, коли об'єкт з декількох спрайт розчиняється або з'являється через alpha і alpha кожного спрайт вважається окремо. Як підсумок ви отримаєте на вигляд 3 незв'язані об'єкти замість 1 очікуваного. Для запобігання таким випадкам можна рендерувати об'єкт у текстуру і вже використовувати її для ефекту, щоб не втрачати цілісність.

Говорячи про персонажів, ми не обмежуємося лише ігровими персами та їх моделями. Сюди також варто віднести NPC, а також ворогів із їхньої AI, а тут уже ціле поле для групи AI testing, куди я включу перевірку таких фічі як Pathfinding, AI Spawning, AI Reaction, Detection Range/NPCs (конус зору) тощо). Адже завжди приємно, коли масовка поводиться правдоподібно, не втикаються у сцени, вороги з'являються не за спиною чи перед гравцем тощо. Тут же перевіряємо, що Імпостери правильно спауняться (імпостер - це 2D спрайт у 3D масовці або дуже лоу полі моделі, потрібні для розвантаження потужностей вашої машини). Явний приклад використання імпостерів можна побачити у фінальній битві Serious Sam 4. Тут варто згадати, що такий прийом використовується не тільки для AI, але також і для малювання частини ігрового світу: яка знаходиться досить далеко від гравця, але все ж таки видно на тлі. Це може бути будь-що: окремі елементи, місто, ліс, гори, і т.д. Все це може бути замінено на імпостера, поки гравець не підійде досить близько (такий підхід також відомий як billboard sprite). Також важливо перевірити Navigation Mesh (Nav Mesh), щоб переконатися, що вороги та NPC будуть рухатися не в предмети та стіни. Більше про натовп NPC можна подивитися .

Такі хитрощі як заміни хай полі на лоу полі моделі або навіть на Імпостерів, баланс та швидкість відображення полігонів на завантажених сценах, обробка ефектів тощо. дуже сильно можуть знизити продуктивність та кількість кадрів за секунду (FPS). Дані аспекти перевіряються в рамках всім відомого Performance Testing . Я відніс би плюс/мінус у цю категорію і Soak Testing, завдяки якому шукають memory leaks в іграх. Також в рамках групи з тестування продуктивності варто віднести Stability testing, в рамках якого ви знаходите такі улюблені речі як фризи, краші, чорні екрани, неможливість завантажити рівень, псування збережених даних та інше.

Вже все вищезгадане звучить досить громіздка і складна система. Але це ще нічого, адже ми більше говорили про front-end частини (клієнт), адже Back-End частину та Back-End testing ніхто не скасовував. Тут ми пробігаємося по вашому беку, який часто включає бази даних, API (наприклад REST API), телеметрію та багато іншого.

Вище я говорив про продуктивність на залізі, але не уточнив про яке саме, але ж ігри потрібно оптимізувати і переносити на різне залізо різних платформ - Playstation 4/5, XBox Series X/S, Nintendo Switch, Steam Deck і різні і неповторні конфігурації. персонального красеня (ПК). За це відповідає, як ви вже здогадалися, Compatibility testing. Багато платформ мають різні режими роботи, наприклад 4K 30FPS + Raytracing, 1080p 120fps і т.д. Та ж Nintendo Switch працює в 2х режимах: портативному (720р) та стаціонарному (1080р). Не варто забувати і про тенденцію "геймпади скрізь" і обов'язково варто перевірити, що найрізноманітніші контролери можуть працювати з вашою грою на ПК або консолі - різноманітні контролери, кермо і педалі для авто симуляторів, джойстики, контролери у вигляді музичних інструментів і т.д. .п. Всі вони мають у вашій грі коректні іконки під час перемикання контролерів, а також всі конфігурації для них працюють справно.

Також відносно недавно почав активно розвиватися ринок VR та AR додатків та ігор. VR і AR Testing хочу виділити окремо, т.к. дані пристрої мають занадто багато особливостей, щоб запхати їх під один гребінець з рештою девайсів. Як цікавий факт з практики: VR має "фізичне" обмеження, через яке не всі зможуть розробляти/тестувати під VR, а саме - моушн сікнес (закачування), який виникає при використанні шоломів.

Важливо брати до уваги, що, крім ваших власних стандартів якості до гри, свої стандарти є у платформоутримувачів. Часто такі перевірки називаються Technical Requirements Checklist або TRC, а перевіряються вони в рамках Compliance testing і часто не вашою командою, а командою QA на стороні платформоутримувача. В рамках даного тестування ви можете також перевірити внутрішньоігрові покупки, досягнення (Achievements), підписки (subscriptions), якщо вони у вас є, а також підтримку фіч стрімінгових сервісів. Часто для таких потреб "відгалужується" окремий білд, який доводять до розуму і не афектують його змінами основний білд.

Схожа ситуація відбувається під час Альфа та Бета тестування. Pre-Alpha, Alpha та Beta Testing це більше не про підхід до тестування, це про зріз гри у певний момент часу та перевірки готовності певного скоупу на тій чи іншій стадії. Раніше часто малося на увазі, що Альфа – це ще внутрішнє тестування, а Бета – вже зовнішнє (наприклад, закрите бета тестування, коли ключі від білда дають певній кількості гравців). Зараз багато ігор виходить в ранньому доступі і альфа білди стають доступними широкому загалу гравців. Живий фідбек дає зрозуміти розробникам, що вони роблять (не) вірно, що допомагає оперативно реагувати та задовольняти потреби гравців.

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

Більш ніж впевнений, що багато читачів цієї статті – аудіали. Звук в іграх, як і в кіно - один із найважливіших та потужних інструментів для впливу на гравця. За тестування таких нюансів як тригер та програш музики, звукових ефектів (SFX), діалогів та реплік, міксування музики під те, що відбувається на екрані та інше відповідає Audio testing. Для роботи зі звуком є спеціалізований софт та тригери багатьох ефектів та реплік можна знайти в автоматичному режимі. Якщо ви не спеціалізуєтеся на тестуванні аудіо, то, швидше за все, ваші завдання будуть лімітовані пунктами вище. У ваші завдання далеко не завжди буде пошук і використання потрібних звуків, головне - заімплементувати можливість програшу їх за певних умов, а далі аудіо команда вже зроблять магію, що залишилася за вас - вставить потрібне аудіо або створить абсолютно нове! Завжди приємно, коли саунд-дизайн у грі на висоті!

А ще приємніше користуватися грою рідною для вас мовою + вихід на глобальний ринок має на увазі більший охоплення потенційної аудиторії. Озброївшись знаннями з тестування I18N та L10Nви зможете зробити так, щоб від вашої гри отримували задоволення навіть у протилежній від вас частині земної кулі! Як особливості перевірки локалізації ігор (Localization testing), варто згадати різницю в часових поясах ваших гравців та сервера, а також можливість маніпуляції часу та дати на вашому пристрої через зміну дати та/або часу через календар. Часто це призводить до різноманітних помилок чи небажаного результату. Наприклад, якщо ви засітали якийсь контент для відображення з певної дати, то хитренький користувач може змінити дату на майбутню і заздалегідь побачити всю ту красу, яку ви йому підготували і спойлернути це всім. Навіть дата майнінгом займатися не обов'язково :) Для перевірки коректності мов є спеціальні команди локалізації, але не забувайте,

Ми вже поговорили про ПК, консолі, навіть про VR та AR ігри, але не обговорили ті девайси, які використовують більшість геймерів – мобільні телефони. Як мінімум основи Mobile Testing важливо знати і розуміти, адже дуже багато ігор виходить на мобілки і цей ринок вже давно обігнав по виручці консолі і ПК. Так, ігри ці, здебільшого, казуальні та гіперказуальні, але й далеко не всі гравці "хардкорні" і мають достатньо часу, щоб грати в ААА та інді гри на ПК та консолях. Всі види тестування, згадані вище, дійсні і для мобільних ігор, але також тут важливо знати специфіку мобільних девайсів та додатків!

Не варто забувати і про Security Testing , використання якого глобально не відрізняється від інших сфер. В іграх використовуються облікові записи, облікові записи від різних систем, включаючи онлайн сервіси та облікові записи від ваших обліку на консолях (наприклад вам потрібно грати грати в Rocket League через Epic Games обліковий запис, але в системі Playstation), В наш час дуже важливо приділяти цьому аспекту достатньо уваги, адже ніхто не хоче втратити навіть одну гру, яку ця людина купила або донатив у ній, не кажучи вже про втрату цілого акаунту з усім "напрацьованим" добром!

Також варто згадати роботу з DRM системами (Denuvo тощо) та Anti-Cheat програмами (Easy Anti-Cheat тощо).

Різновиди «ігрових» багів

Зображення прикладів див. у джерелі.

У категорію Visual багів увійдуть:

Visual Artefacts – будь-які візуальні баги, які не підпадають під інші види.
Missing Textures - пропущені/зниклі текстури. Зазвичай на їхньому місці намагаються ставити "заглушку" у вигляді яскравої текстури за умовчанням у вигляді шахівниці. Це не обов'язково, але завдяки такому підходу пропущені текстури видно не збройним поглядом.
Z-fighting - даний баг з'являється, коли кілька примітивів розташовані приблизно на однаковій відстані до камери і вони мають фактично однакові значення в Z-buffer, які відстежують глибину. Через це примітиви можуть частково відображатися один над одним.
Screen Tearing або "розрив екрану" - це візуальний артефакт, при якому відображається інформація з кількох кадрів на одному зображенні.
Culling та Clipping - баги, що належать до роботи рендеру та графічного пайплайну. Часто - перетин двох об'єктів, при якому один закриває геометрію іншого, приховуючи її від погляду. Якщо трохи заглибитись, то Culling – це відсікання того, що свідомо невидимо. У такому разі гра навіть не намагатиметься відмалювати цей сегмент. Culling буває різним і ось його приклади: rustrum culling - відсікання по піраміді видимості, backface culling - відсікання "задніх" граней, occlusion culling - відсікання граней факту їх перекриття іншою геометрією, depth culling - перекриття однієї геометрії іншою, яка вже була намальована, але на основі depth buffer. А ось коли малюється досить великий полігон і від нього відрізається все те, що свідомо знаходиться поза екраном - це вже Clipping.
Також окремо варто виділити схожий, але в суті інший баг – проблеми колізій . У відеоіграх відсікання може бути пов'язане з набором алгоритмів, які реагують на взаємодію двох суміжних або перекриваються геометрій (collision detection). А виявлення таких багів існують спеціальні режими перегляду (view modes).

У рамках Audio bugs групи виокремлю досить базові, але не менш набридливі речі:

неможливість програти SFX/музики/діалогу,
перепустка (тригера) програшу,
погане мікшування (звук занадто тихий або гучний),
спотворення (distortions),
дропи.

Баги левелів дизайну :

Invisible Walls (невидимі стіни) можуть бути як багом, так і фічею. Раніше так обмежували пересування персонажа гравця і не давали піти далі за потрібне. Зараз намагаються не створювати "невидимих перешкод", а обмежувати "прохідність" за допомогою левелів дизайну, наприклад виставити непрохідну перешкоду, барикаду, гори, ворота міста і т.п. Показувати гравцеві, що попереду є щось, але при цьому використовувати невидимі стіни для недопуску персонажа в цю зону - ознаки поганого левелів дизайну. Зараз так майже не роблять і невидимі стіни часто можуть бути наслідком реконструкції рівня: наприклад, якусь модель могли забути прибрати або додали невидимий елемент як тимчасову заглушку.
Map Holes найчастіше викликані не щільним приляганням площин об'єктів (підлога, стіни тощо). Це місця, де користувач може незаплановано для розробників потрапити за межі ігрової зони. Такі баги часто називають Out of Bounds.
Баги Navigation Mesh часто пов'язані з перебудовою рівня або автоматичною генерацією сітки. Наприклад, ви пересунули предмети, проте навігаційна сітка залишилася старою. Як наслідок, ваші NPC можуть "йти в стіну" або будь-який інший предмет, який вони не зможуть обійти і встрянуть там (один із випадків Stuck Points ).

Помилки штучного інтелекту (AI):

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

Раз у нас є і частина движка, що відповідає за фізику, то було б дивно, якби і багів з фізикою не було. Тут може бути майже що завгодно:

левітуючі об'єкти,
нереалістична фізика,
прискорення понад норму,
змивання предметів у космос через складання векторів при обробці контактів.

Баги стабільності та перформансу включають:

фризи,
фарбуй,
чорні екрани,
неможливість завантажити рівень,
видиме для користувача підвантаження хай полі моделей або взагалі будь-яких об'єктів,
просідання FPS,
дооооооооолга завантаження,
мікрофризи (підвантаження).
Сюди додам занадто довгу інсталяцію гри, а також неможливість запустити гру на ПК з мінімально допустимими вимогами.

Нерідко зустрічаються і баги сумісності . Особливо часті приклади виглядають так:

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

Про проблеми онлайн ігор чули всі. Погане з'єднання, лаги, "невидимі гравці" або "я зайшов за кут, а мене вбили", помилки підрахунку очок , неможливість реконнекту (якщо така фіча є), втрата пакетів під час гри, розбіжність у підрахунках інформації між клієнтом, дедікейтед сервером та бек ендом. Також при поганому з'єднанні деякі елементи інтерфейсу можна використовувати по кілька разів, щось може не провантажитися і "зникнути" і т.д., але, як правило, це UI баги і сильно не впливають на user experience гравця.

Під баги локалізації та compliance , з нетривіального, можна віднести:

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

Підходи та інструменти

Чит коди / Чит меню (Cheat Codes / Cheat Menu)

Чит коди спочатку були не пасхалками чи корисними нішцяками для гравців, щоб ті могли завантажувати певний рівень або встановити собі нескінченне здоров'я/гроші і навіть були придумані не для збережень, хоч і можуть бути так застосовані. Чит коди використовувалися розробниками для налагодження ігор. Їх, з різних обмежень, потрібно було вводити на певному екрані гри чи меню. Згодом коди потрапили в народ і стали вкрай затребувані зі зрозумілих "божественних" причин.

Зараз замість кодів, які потрібно запам'ятовувати і довго вводити, використовуються Чит Меню, в яких вже є списки чит кодів, згрупованих в зручний для використання вигляд. Даний список можна викликати практично на будь-якому екрані, проте якщо код не підходить під поточні умови, то він не виконається (наприклад, якщо ви намагаєтеся спалити об'єкт у головному меню). Чит меню – це не типова функціональність, у кожної гри воно має і унікальний вигляд, і унікальний код, відповідальний за його реалізацію.

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

Ігрова консоль

Консоль у грі може і часто використовується як корисний у тестуванні інструменту. Зазвичай вона викликається при натисканні кнопки "~" (тильда), випадає або внизу невеликим рядком, або зверху екрана, займаючи пристойну його частину. Думаю багато хто використовував консоль в Counter Strike 1.6, перетворюючи вашого персонажа з правши на лівшу або змінюючи характеристики вашого прицілу. Однак консоль не була включена за замовчуванням: її потрібно було попередньо активувати Options.

За допомогою консолі на дев білдах (наприклад відразу з Unreal Editor) можна підключати back-end з потрібними вам тестовим акаунтам, прискорювати або сповільнювати гру (не FPS, а саме внутрішньоігрові дії), використовувати чит коди, включати-вимикати потрібні вам HUD і багато іншого.

Внутрішньоігрові HUD (Heads-Up Display)

Вкрай корисні інструменти, які, втім, без допомоги розробників не отримати. HUD віджети часто викликаються консольною командою. Залежно від того, як розробники налаштують HUD, виводитиметься та чи інша інформація під певні потреби. За допомогою таких елементів вкрай зручно стежити за нанесеною шкодою, прогресами з випробувань (challenges), використанням предметів (consumables) тощо.

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

Weapon room / Training room

Такі кімнати, як правило, містять зброю, персонажів, ворогів (включаючи босів), поверхні, предмети (consumables), транспорт. Загалом, все необхідне і теоретично необхідне, що може стати в нагоді для тестування під час геймплею. Крім усього вищепереліченого, у таких просторах можуть бути створені кімнати під певні потреби: наприклад, в одній можуть бути розставлені предмети таким чином, щоб перевірити, чи захищає перешкода певного розміру вас у присіді, стоячи тощо; в іншій кімнаті - чи проходить персонаж між об'єктами тощо.

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

Файли конфігурації

Файли конфігурації зустрічаються повсюдно і ви можете ними користуватися для різних потреб. У дев білдах таких файлів більше, ніж у релізній версії, і через них ви можете включати/вимикати фічі, змінювати дозволи, керувати рівнем логування, вказувати до якого back-end'у конектитися, керувати налаштуваннями графіки та багато іншого. Часто любителі "ігор у віці" колупаються у файлах конфігурації (наприклад формату ".ini") для налаштування працездатності старих ігор на новому залізі, якщо для неї не виходив відповідний патч або перевидання. Кількість та обсяг доступних налаштувань та їх формат можу кардинально відрізнятись від гри до гри, навіть якщо ігри написані на одному движку.

Управління вашим інтернет-з'єднанням

Дуже важливий пункт для перевірки нашого часу, т.к. навіть у синглплеєрних іграх можуть (і найчастіше зустрічаються) елементи, зав'язані на онлайн. На жаль тут немає якогось унікального та всеосяжного інструменту. Особисто мені приємно і зручно використовувати інструмент Clumsy як помічник у цій справі. Програма маніпулює не грою, а вашим з'єднанням загалом, що робить Clumsy зручним інструментом для керування вашим з'єднанням для будь-яких потреб: web, standalone software тощо. В рамках даного інструменту ви можете керувати такими можливостями зіпсувати ваше інтернет з'єднання як Lag, Drop, Throttle, Out of order, Duplicate та Tamper. Причому робити це можна як для Inbound, так і для Outbound, вказавши шанси на зустріч даної проблеми.

Режими перегляду (View modes)

Ігрові движки мають таку функціональність як "режими перегляду" (view modes), яка допомагає вам побачити тип даних, що обробляються у вашій сцені, а також діагностувати будь-які помилки або несподівані результати. У найпоширеніших режимах перегляду є свої гарячі клавіші і вони можуть відрізнятися від движка до движка, але ви завжди можете переглянути їх усі з перегляду або викликати за допомогою відповідної команди в консолі. Нижче я наведу кілька прикладів на основі View Modes з Unreal Engine, а більше і детальніше ви можете почитати в документації движка. Погляньмо на кілька з них.

Інструментарій ігрових майданчиків

Всі ігрові майданчики надають розробникам свій інструментарій для завантаження та тестування гри через їхню систему. Наприклад Steam дозволяє через меню Properties вашої гри перемикати мови (локалізація), запускати гру з вашими власними параметрами (наприклад запуск гри з потрібними вам параметрами або перепису значень параметрів, що використовуються), дозволяє перевіряти цілісність файлів гри, вручну перевіряти оновлення з вашої CI/CD системи і багато іншого! Ну і майданчики дозволяють вам завантажити і додати в бібліотеку вашу гру за спеціальним кодом. Якщо гра вже доступна для скачування гравцям або ви хочете використовувати різні оточення (environments) для різних команд, то для таких потреб ігрові майданчики надають можливість використання різних гілок (Branches).

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

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

Загальні інструменти

Говорячи про інструменти, які безпосередньо не пов'язані з тестуванням, але можуть полегшити вам життя, я виділив би такі: VCS (Perforce, Git), редактори ігрових движків, Grafana і Playfab.

Тестування в азартних іграх/казино (Gambling)

Гемблінг (від англ. Gambling – азартна гра) – гра, результат в якій повністю або значною мірою залежить від волі випадку (удачі).

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

Зі специфічного:

тестування різної математики (алгоритми, ймовірності тощо);
взаємодія із законодавством;
фінансові операції (депозити, гаманці, бонуси, реферальні програми).

Джерела:

Дод. матеріал:

PreviousТестування платіжного шлюзу (Payment Gateway)NextТестування VR програмного забезпечення

Last updated 2 years ago