Gamefunctionaliteit testen: mechanics, quests en alles wat kapot kan gaan

Functionele gametests zijn het onzichtbare schild tussen uw meesterwerk en een vloedgolf aan één-sterrecensies. Uw game kan er prachtig uitzien, beschikken over adembenemende ray tracing en vloeiend draaien op 120 FPS, maar als een kernmechaniek faalt, een save-bestand corrupt raakt of een cruciale missiereeks niet wil afsluiten, is de game stilletjes kapot. Het opsporen van deze kritieke bugs voordat uw spelers dat doen, is precies de reden waarom gespecialiseerde game-testdiensten bestaan. Functioneel testen is niet zomaar een regel op de begroting; het is waar kwaliteitsborging echt begint.

De belangen in de huidige markt zijn nog nooit zo groot geweest. Met een wereldwijde gamemarkt die rond de enorme grens van 188,8 miljard dollar schommelt en de spelersgroei die stagneert, is de concurrentie om aandacht moordend. Wanneer het winnen van nieuwe spelers moeilijker wordt, wordt het behouden van uw bestaande community uw absolute topprioriteit. Hoewel een opvallende grafische glitch viraal kan gaan als een grappige meme op TikTok, zorgt een kapot save-bestand of een vastlopende voortgangscyclus ervoor dat spelers woedend afhaken en uw app direct verwijderen.

Stelt u zich een speler voor die eindelijk een legendarisch eindbaasgevecht bereikt, de voortgang opslaat en uitlogt voor de nacht. De volgende dag keren ze terug en spawnen ze in een lege kamer: geen baas, geen uitgang en geen enkele manier om verder te komen. De game is niet gecrasht en er waren geen visuele artefacten. Op het eerste gezicht ziet alles er goed uit, maar de game is simpelweg vergeten wat hij moest doen. Dat stille, spelbedervende falen is precies wat wij voorkomen. Het onderstaande artikel legt uit hoe onze QA-experts dit bereiken.

Wat is functioneel gametesten?

Functioneel gametesten is het proces waarbij gecontroleerd wordt of elke functie, mechaniek en elk systeem in een game doet wat het ontwerp voorschrijft, zowel wanneer spelers zich voorspelbaar gedragen als wanneer ze iets doen wat niemand had voorzien. De International Software Testing Qualifications Board, bekend als ISTQB, definieert functioneel testen als controles gebaseerd op een analyse van wat een component of systeem geacht wordt te doen. In een game is die lijst van ‘geacht te doen’ lang en loopt deze uiteen van het besturen van het personage en het openen van het menu tot het opslaan van voortgang, het voltooien van een quest en het uitkeren van beloningen.

Het helpt om duidelijk te maken wat functioneel testen niet is:

• Het meet niet hoe leuk de game aanvoelt; dat is de taak van bruikbaarheidstests en playtesting.
• Het meet niet de frame rate, laadtijd of het geheugengebruik; dat zijn onderdelen van performancetesten.
• Het controleert niet of de game op elk apparaat draait; dat is compatibiliteitstesten.

Functioneel testen stelt een nauwere en hardnekkigere vraag. Doet de game in elke situatie precies wat de bedoeling is? Onze pagina over functioneel testen legt uit hoe wij deze vraag per project benaderen.

Wat omvat functionele QA bij een game?

Functionele QA dekt de systemen die de daadwerkelijke gameplay ondersteunen. Voor een moderne titel doen vijf gebieden het meeste zware werk:

• Kernmechanieken en gamelogica bepalen hoe beweging, gevechten en botsingen zich gedragen.
• Opslaan, laden en persistentie zorgen dat de voortgang van een speler behouden blijft nadat hij de game afsluit.
• Voortgang en level-gating bepalen wat spelers ontgrendelen en in welke volgorde.
• De in-game economie beheert valuta, beloningen en aankopen.
• Quest- en missie-flow houdt bij waar elke speler zich bevindt in een vertakkend verhaal.

De rest van dit artikel loopt al deze vijf punten door, omdat daar de functionele bugs zich verschuilen en waar het succes wordt gewonnen of verloren.

De gamesystemen die kapotgaan, en hoe wij ze testen

De onderstaande systemen delen één kenmerk dat ze kwetsbaar maakt: elk bevat een stukje status, onthoudt iets en geeft die herinnering door aan het volgende systeem in de rij. Wanneer één schakel verkeerd interpreteert wat eraan voorafging, blijft de fout niet beperkt. Daarom testen we ze als een verbonden keten in plaats van in isolatie. We doorlopen ze ruwweg in de volgorde waarin een speler ze tegenkomt, van de kleinste herhalende acties tot de langste verhaallijnen.

Kernmechanieken en gamelogica testen

Mechanieken zijn de werkwoorden van een game, de bewegingen die een speler maakt om te rennen, vechten, klimmen, craften en handelen. Wanneer een ervan faalt, merken spelers dit direct, omdat dit de acties zijn die ze honderden keren per uur herhalen. Een sprong die soms niet wordt geregistreerd, een zwaard dat dwars door een vijand heen gaat, een deur die van de ene kant wel opent maar van de andere niet; elk punt verbreekt het basiscontract tussen de speler en de game.

Mechanieken goed testen betekent verder kijken dan de ideale route waar alles in de verwachte volgorde gebeurt. We controleren wat er gebeurt wanneer een speler twee knoppen tegelijk indrukt, interageert met een object vanuit een vreemde hoek of een actie activeert precies op het moment dat een cutscene begint. Gamelogica neigt ernaar aan te nemen dat spelers in volgorde handelen. In werkelijkheid gedragen spelers zich echter vaak onvoorspelbaar.

Opslaan, laden en persistentietests

Save-systemen lijken simpel, maar hun gedrag is het tegenovergestelde. Een save-bestand moet de volledige status van de wereld vastleggen, inclusief waar de speler staat, wat hij bij zich draagt, welke deuren hij opende, welke vijanden hij versloeg en hoe ver elke quest gevorderd is. Als er een stukje ontbreekt of in de verkeerde volgorde wordt opgeslagen, kan de speler in één moment uren aan voortgang verliezen, wat de snelste weg naar een verzoek om restitutie is.

We testen saves op de momenten waarop ze het meest waarschijnlijk fout gaan: tijdens gevechten, tijdens dialogen, tijdens een cutscene en precies op het moment dat een autosave wordt geactiveerd. We laden ook een save gemaakt in een oudere build na een patch, omdat updates routinematig de manier veranderen waarop gegevens worden opgeslagen. Een save die vorige week werkte, moet vandaag nog steeds werken.

Voortgang en level-gating testen

Voortgang is de onzichtbare steiger die bepaalt wat een speler kan bereiken en wanneer. Gates voorkomen dat spelers naar content dwalen voordat ze er klaar voor zijn, en ze zijn afhankelijk van voorwaarden die in een vaste volgorde worden behaald. De problemen beginnen op het moment dat een speler aan die voorwaarden voldoet in een volgorde die de ontwerper nooit heeft voorzien.

We zagen een duidelijk voorbeeld van haperende voortgang tijdens een van onze gratis Bug Crawl-tests. In Plug Head voor iOS, een razendsnelle puzzel-doolhofgame, kwamen onze testers een moeizame overgang tussen levels tegen die de flow onderbrak die spelers als vloeiend zouden moeten ervaren. Eén onhandige overgang zoals die is genoeg om iemand te laten stoppen met de game, en vermenigvuldigd met een paar duizend spelers, komt dat terug in uw recensies in de store.

In-game economietests

Elke game met valuta, loot of aankopen heeft een economie, en exploits verzamelen zich eromheen als mieren op een picknick. Als een beloning dubbel kan worden geclaimd, een saldo onder nul kan zakken of een valutaplafond kan worden omzeild, zal een kleine groep spelers de truc vinden en het hele systeem onderuithalen.

Om dit tegen te gaan, testen we bewust de uiterste randen. We claimen dezelfde quest-beloning keer op keer, duwen een saldo over het beoogde plafond, kopen en verkopen in één enkel ogenblik en veranderen de inventaris sneller dan de game verwacht. Het doel is om het achterpoortje te vinden voordat iemand anders dat doet, want zodra een exploit zich verspreidt, betekent het dichten ervan gefrustreerde spelers en ongemakkelijke patch notes.

Missie- en quest-flow testen

Quests zijn het punt waar functionele tests hun waarde bewijzen, omdat elke quest in feite een kleine toestandsautomaat (state machine) is. Het is een reeks stappen die in een geldige volgorde moeten plaatsvinden, waarbij de game nauwkeurig bijhoudt waar de speler zich op elk moment bevindt. Vertakkende quests, waarbij de ene keuze paden opent en andere afsluit, vermenigvuldigen het aantal mogelijke statussen razendsnel. Mis één combinatie en een speler kan vastlopen in een doodlopend spoor waar het verhaal niet uit kan ontsnappen.

Dit is het type fout dat zelfs grote studio’s vertraagt: een quest die wacht op een gesprek dat de speler niet langer kan voeren, een doelstelling die nooit als voltooid wordt gemarkeerd, of een voorwerp dat verdwijnt van de enige plek waar het nodig was. Geen van deze fouten laat de game crashen, maar ze zorgen er allemaal voor dat het spel volledig tot stilstand komt.

Functionele testcases schrijven voor een game

Dit is het onderdeel dat de meeste handleidingen overslaan, en daarom focussen wij ons hierop. Beschrijven wat er gecontroleerd moet worden is eenvoudig, maar het schrijven van een testcase die een vertakkende, statusafhankelijke bug opvangt, vereist meer structuur. Een functionele testcase is een kort, herhaalbaar script met een beginconditie, een reeks stappen en een duidelijk verwacht resultaat. Iedereen in het team moet dit kunnen volgen en tot hetzelfde resultaat kunnen komen.

Neem een vertakkende quest als voorbeeld. Stel je een quest voor genaamd ‘Red de koopman’, die spelers op meer dan één manier kunnen aanpakken.

De waarde zit in die laatste rij. Een zwakke testcase controleert alleen het pad dat de ontwerper voor ogen had. Een sterke testcase bewandelt bewust het pad dat de ontwerper was vergeten.

Voor systemen die een status bijhouden, brengen we de combinaties in kaart in een matrix, zodat er niets door de mazen van het net glipt. Een save- en load-matrix kruist bijvoorbeeld het moment van opslaan met de situatie waarin de speler opnieuw laadt.

Elke cel is een afzonderlijke test. Het raster verandert een vage zorg – ‘werkt het opslaan wel?’ – in een checklist die een tester kan voltooien en met vertrouwen kan aftekenen. We bouwen hetzelfde type matrix voor quests, waarbij we elke keuze afzetten tegen elke latere stap die ervan afhangt.

Als u wilt zien hoe functionele tests zich verhouden tot performance, compatibiliteit en andere methoden, biedt onze gids over de soorten gametesttechnieken een compleet overzicht.

Wat functionele gametests in de praktijk aan het licht brengen

Testgevallen zijn slechts zo goed als de bugs die ze aan het licht brengen, en bij live projecten is het patroon consistent. Bekijk enkele voorbeelden uit onze ervaring met gametesten:

• Voor Human Park, een avatar-gebaseerd Web3-platform, voerden we in een vroeg stadium handmatige functionele tests uit op macOS. We controleerden de installatie en verwijdering, wallet-verbindingen en avatar-aanpassingen, waarna we de gevonden functionele bugs en interfacefouten rapporteerden. Onze controles hielpen de studio de vroege builds te stabiliseren en de deuren te openen voor meer dan 30.000 early access-spelers.
• Voor Highrise City, een stedenbouwsimulatie met een sterke focus op economie en grondstoffenbeheer, werkten we aan de stabiliteit en het hardwaregedrag, zodat de game ook buiten de machine van de ontwikkelaar goed presteerde. De lancering werd op Steam ontvangen met een score van 80% positief.
• Voor Couple Up! Love Show Story, een snelgroeiende datingsimulatie, beoordeelden we de code en serverconfiguratie. Vervolgens boden we het team een plan aan om de prestaties te stabiliseren en fouten te verminderen voordat het aantal spelers verder steeg.

Bij elk project is de rode draad hetzelfde. De bugs die er echt toe doen, zijn niet de opvallende fouten, maar de stille, functionele defecten die de voortgang blokkeren, saves corrumperen of de economie verstoren; dat zijn de problemen die spelers zich herinneren.

Wanneer schakelt u een partner in voor game-functionaliteitstests?

U kunt veel intern opvangen, en dat moet u ook zeker doen. De signalen dat het tijd is om een toegewijde partner in te schakelen zijn praktisch, zoals:

• Quest-logica die sneller vertakt dan uw team handmatig kan bijhouden
• Save-systemen die verspreid zijn over meerdere platforms en patchversies
• Een releaseschema dat geen ruimte laat om elk pad opnieuw te spelen vóór de dag van uitgave

Op dat punt is gestructureerde functionele QA geen luxe extraatje meer, maar de factor die bepaalt of uw lancering slaagt of mislukt op basis van gebruikersrecensies.

Ons team heeft door de jaren heen meer dan 100 games getest voor mobile, PC en console. We voeren een gratis bug crawl-programma uit waarbij een live build door echte testers wordt gecontroleerd, waarna u een eerlijk bugrapport ontvangt. Als u liever direct over uw game wilt praten, neem dan contact op met ons team en wij stemmen het testproces af op uw project.