Un jeu qui s'ouvre n'est pas nécessairement un jeu prêt. Le joueur peut ne pas être en mesure de comprendre l'objectif, le texte généré peut violer une politique de sécurité, un atout peut manquer de provenance, ou un itinéraire peut disparaître des métadonnées de découverte après une mise à jour de contenu.
Utilisez cette liste de contrôle après l'approbation de la boucle prototype et avant toute décision de déploiement. Pour un processus de premier passage plus petit, commencez par le plan de jeu de navigateur de 48 heures.
Lecture rapide
Points clés
- Tester les chemins de gameplay déterministes séparément de la sortie générée par variable.
- Enregistrez les instructions, les modèles, les actifs de source, les licences, les modifications humaines et le statut de divulgation.
- Utilisez des appareils cibles réels, des méthodes d'entrée, des conditions réseau et des sessions de nouveaux joueurs.
- Navire seulement avec surveillance, comportement de repli, un chemin de recul, et un ordonnateur humain responsable.
Jeu et état
- But, contrôles, rétroaction, victoire, perte, pause, reprise, redémarrage et travail d'état sauvegardé.
- La première minute est compréhensible sans coaching développeur.
- Les entrées répétées, les cas de bord et les redémarrages rapides ne corrompent pas l'état.
- La variation générée ne peut pas créer d'objectifs impossibles ou d'états inrécupérables.
Contenu et sécurité générés
- Les produits et les produits sont enregistrés au niveau requis pour le diagnostic et la politique.
- Les catégories de contenu bloqué et les invites adverses sont testés.
- La génération vivante a un temps mort, un refus, une réessayer, une modération et un comportement de repli sûr.
- Les actifs prégénérés ont des modèles, des dates, des sources, des licences, des enregistrements rapides et des enregistrements d'édition humaine.
Lisibilité, entrée et accessibilité
Vérifiez le clavier, le pointeur, le toucher, le contrôleur, la visibilité de la mise au point, le remapping où supporté, la taille du texte, le contraste, le mouvement, les alternatives audio et l'état indépendant de la couleur.
WCAG est écrit pour le contenu Web plutôt que la conception de jeu seul, mais son interaction, contraste, mouvement, et guide d'entrée fournit une base de référence utile pour interface utilisateur orientée navigateur.
Performance, compatibilité et réseau
- Mesurer le chargement, le frame-pating, la mémoire, les longues sessions, les transitions de scène et la génération répétée.
- Tester les navigateurs et les appareils de faible puissance, pas seulement la machine de développement.
- Simuler les états réseau lents, intermittents et hors ligne le cas échéant.
- Vérifier le cache des actifs, la version, le rapport d'erreur et la dégradation gracieuse.
Droits, divulgation, découverte et opérations
Examiner les licences, ressemblance et risque de marque, la divulgation de l'IA de la plate-forme, l'âge et le positionnement de la sécurité, la confidentialité, l'analyse, les canoniques, les métadonnées et l'inclusion de la carte du site.
Terminez par une construction de production, une validation automatique du référencement, un test de lecture manuel, une surveillance, des instructions de retour en arrière et une approbation humaine explicite.
Établir une matrice d'AQ fondée sur le risque
Énumérez la boucle de base déterministe, les actifs d'IA prégénérés, les systèmes générés en direct, les services externes, les itinéraires publics et les opérations de libération. Scorez chacun par impact, probabilité, détectabilité et réversibilité des joueurs.
Carter chaque élément à risque élevé auprès d'un propriétaire, vérifier automatiquement, faire des scénarios manuels, localiser les preuves, déterminer le seuil de libération, surveiller le signal et effectuer des opérations de renversement.
| Système | Risque primaire | Preuves requises |
|---|---|---|
| Jeu de base | État brisé ou impossible | Invariants automatisés et jeu humain |
| Actifs prégénérés | Écart entre les droits, les artefacts ou les divulgations | Provenance et revue visuelle |
| Génération vivante | Sortie non sûre, indisponible ou incohérente | Essais d'adversaires, garde-corps, chute |
| UI de navigateur | Défaut d'entrée ou d'accessibilité | Clavier, toucher, contraste, tests de mouvement |
| Décharge | Mauvaise construction ou découverte manquante | Construire l'ID, les métadonnées, la carte du site, le retour |
Séparer les portes de sortie des cas d'essai
Les cas d'essais décrivent les mesures prises et les résultats attendus. Les barrières de rejet définissent les preuves requises pour une décision humaine.
Créer des barrières pour l'intégrité du gameplay, la sécurité générée-contenu, l'accessibilité, la performance, les droits et la divulgation, la découverte, et les opérations. Chaque barrière a un ordonnateur responsable et un petit ensemble de bloqueurs qui ne peuvent être renoncé silencieusement.
- Gameplay gate: objectifs, intégrité de l'état, sauvegarde, redémarrage et récupération
- Portail de génération : schémas, garde-corps, modération, recul et abattage
- Portail d'expérience : lisibilité, entrée, accessibilité, performance et compatibilité
- Portail de diffusion : droits, divulgation, métadonnées, plan du site, confidentialité, analyse
- Portail d'exploitation : surveillance, propriétaire de l'incident, désactivation de la fonctionnalité et retour en arrière
Tester la sortie variable sans faire semblant d'être déterministe
Utiliser des invariants et des distributions. Une quête générée peut varier en termes, mais elle doit renvoyer des entités valides, produire des objectifs réalisables, rester dans la longueur et les contraintes de sécurité, et préserver la compatibilité de l'état d'économie.
Le sondage actuel de Steam demande sur les garde-corps générés en direct, tandis que WCAG fournit une base de référence pour l'accessibilité de l'interface du navigateur.
| Symptôme | Cause probable | Contrôle suivant |
|---|---|---|
| La production varie trop largement | Rapide, température, contexte ou schéma | Contraintes et validation des invariants |
| La modération bloque le jeu normal | Seuil de garde ou recul manquant | Tester les faux positifs et la récupération |
| L'état de la corruption dans le temps | Génération couplée à une transaction | Utiliser l'état en attente et la réessayer idémpotent |
| Bug ne peut pas être reproduit | Modèle manquant/le journal des entrées/versions | Capturer le contexte diagnostique de la vie privée |
| Règles modifiées après l'AQ | Service non effectué ou rapide | Dépendances de la version et ré-exécution de la porte |
Dossier de preuves de libération
Le dossier de preuve devrait permettre à un examinateur de connecter la revendication du produit, le résultat du test, la règle de source et la construction exacte.
Après le lancement, traiter la surveillance et l'examen des incidents comme une QA continue. Les systèmes générés peuvent changer par des mises à jour de modèle, des changements rapides, une politique de modération ou un comportement du fournisseur même lorsque le code d'application est inchangé.
- Le registre des risques et les propriétaires couvrent les systèmes déterministes, générés, externes et opérationnels.
- Les invariants à haut risque et les chemins de défaillance ont des preuves automatisées et manuelles.
- L'accessibilité, les appareils, le navigateur, le réseau et les tests de longue durée reflètent l'utilisation soutenue.
- La provenance de l'IA et les divulgations actuelles de la plateforme correspondent à la construction exacte.
- Le suivi détecte l'échec de la génération, les événements politiques, les performances et la corruption d'État.
- Les communications avec les personnes handicapées, les personnes en situation de repli, les personnes en situation de repli et les personnes en situation d'incident sont répétées.
Ce que les sources principales établissent au sujet de l'IA Jeu QA Liste de contrôle
Nous l'utilisons pour établir un comportement documenté, une terminologie ou des contraintes, sans prétendre que la source appuie le déroulement ou les conclusions d'Elseland. L'artefact pratique à l'étude est une matrice de libération fondée sur le risque, avec des tests reproductibles, des preuves d'accessibilité, des dossiers de provenance, des garde-corps, la propriété et le retour.
Cette distinction est essentielle pour E-E-A-T. Une page de première partie peut établir quels documents publics un format, outil, plate-forme, modèle ou équipe de jeu est disponible. Elle ne peut pas prouver qu'un atout particulier est rapide, accessible, légalement nettoyé, amusant ou prêt à la production.
Pour ce sujet, la décision est de déterminer si la construction examinée est sûre, compréhensible, opérationnelle et représentée avec précision à la diffusion. Les observations suivantes transforment la référence officielle en un dossier de production évaluable plutôt qu'une citation décorative :
| Couche des preuves | Ce qu'il peut soutenir | Ce qu'il ne peut soutenir seul |
|---|---|---|
| Source officielle | Caractéristiques, règles, formats ou contextes de conception documentés | Qualité spécifique au projet ou performance universelle |
| Mesure du projet | Comportement observé dans une construction, une scène, un périphérique ou un échantillon nommé | Plateformes non mesurées ou versions futures |
| Examen humain | Utilisation, jugement visuel, éditorial et de production | Sécurité juridique ou comportement des acteurs de la population |
| Dossier de sortie | Qui a approuvé quoi, quand, avec quelle preuve | Conformité permanente après changement d'entrées ou de règles |
- 1. tester invariants de gameplay déterministes séparément de la génération probabiliste. Entreposez le résultat avec l'actif ou l'identificateur de construction afin qu'un autre examinateur puisse reproduire la conclusion.
- 2. lier les vérifications d'accessibilité aux interactions réelles et aux états de défaillance. Entreposez le résultat avec l'actif ou l'identificateur de construction pour qu'un autre examinateur puisse reproduire la conclusion.
- 3. stockez chaque chemin de modèle d'actif et d'exécution généré. Conservez le résultat avec l'actif ou l'identificateur de construction afin qu'un autre examinateur puisse reproduire la conclusion.
- 4. exiger un retour en arrière et propriétaire sûr pour la défaillance de service externe. Entreposez le résultat avec l'actif ou l'identificateur de construction pour qu'un autre examinateur puisse reproduire la conclusion.
Un protocole d'examen sur le terrain pour AI Game QA Liste de contrôle
Utilisez ce protocole après la première sortie plausible et avant de mettre à l'échelle le flux de travail. Gardez une base de référence intacte, une révision candidate et un cas délibérément souligné. Le cas souligné devrait exposer le mode de défaillance probable du sujet – scènes surpeuplées, poses extrêmes, jeu à écran réduit, entrées inhabituelles, ou un changement de règle de libération – plutôt que de répéter le cas de succès le plus facile.
Exécutez l'examen dans le contexte de livraison réel chaque fois que possible. Capturez la version de l'outil ou du modèle, les fichiers sources, les paramètres, le périphérique cible ou le moteur, la date et l'examinateur. Si le travail dépend d'un service externe changeant, enregistrez la réponse ou l'artefact exporté au lieu de supposer que la même sortie peut être recréée plus tard.
Un examen utile se termine par une décision et une action suivante. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| État d'avancement de la révision | Signification | Mesure suivante requise |
|---|---|---|
| Passons | Toutes les portes visuelles, techniques et de libération définies sont étayées par des preuves | Geler l'artefact examiné et le relier à la construction |
| Passage sous condition | Une limitation connue est limitée et n'invalide pas l'utilisation prévue | Documenter l'exception, le propriétaire et le déclencheur pour la révision |
| Réviser | La direction est viable mais une ou plusieurs portes restent non soutenues | Changer une variable contrôlée et répéter les vérifications concernées |
| Rejet | Le candidat est en conflit avec l'utilisation prévue, les preuves, les droits, la sécurité ou le budget | Préserver le dossier et choisir une approche différente |
- Lecteur de cartes, contenu, technique, accessibilité, droits et risques opérationnels. Enregistrer le résultat attendu avant la vérification, puis joindre le résultat observé et toute exception après celui-ci.
- définir les tests reproductibles et les preuves attendues pour chaque risque. Enregistrer le résultat attendu avant la vérification, puis joindre le résultat observé et toute exception après celui-ci.
- les refus de la sonde, les délais, les tentatives répétées et les entrées indirectes. Consigner le résultat attendu avant la vérification, puis joindre le résultat observé et toute exception après celui-ci.
- testez le clavier, le focus, le contraste, le mouvement, l'audio et la rétroaction lisible. Enregistrez le résultat attendu avant la vérification, puis joignez le résultat observé et toute exception après.
- Consigner le résultat attendu avant la vérification, puis joindre le résultat observé et toute exception après celui-ci.
- vérifier la surveillance, la réponse à l'incident, la désactivation des fonctionnalités et le retour. Enregistrer le résultat attendu avant la vérification, puis joindre le résultat observé et toute exception après celui-ci.
Interprétation par des experts et limites du présent guide de création de jeux d'IA
La conclusion la plus forte que ce guide peut soutenir est une recommandation de production conditionnelle : utiliser le flux de travail lorsque ses hypothèses documentées correspondent au projet et conserver les preuves nécessaires pour revoir la décision. Nous ne sous-entendons pas la qualité universelle du modèle, la préférence du joueur, l'autorisation légale, ou la performance à partir d'une capture d'écran officielle, d'un exemple de fournisseur, ou d'un seul atout réussi.
L'expérience est importante ici parce que le jeu ai game qa checklist croise le jugement créatif et le détail de mise en œuvre. L'examen pratique devrait inclure les personnes qui modifieront la source, intégreront le résultat, le testeront en jeu, le maintiendront après la publication, et répondreont aux droits ou aux questions de politique.
Préserver des preuves datées, divulguer la méthode d'évaluation et distinguer les résultats mesurés de l'inférence éditoriale. Ce document est plus précieux qu'une conclusion confiante que les futurs examinateurs ne peuvent pas reproduire.
| Type de réclamation | Traitement rédactionnel |
|---|---|
| Fait documenté | Lien vers W3C WCAG 2.2 et inclure la date d'accès |
| Résultat observé du projet | Nommer la construction, l'environnement, l'échantillon et la méthode |
| Jugement d'expert | Indiquer les critères, le rôle de l'examinateur et le compromis |
| Inférence ou prévision | Étiquetez-le explicitement et décrivez les éléments de preuve qui pourraient le modifier. |
- Une liste de contrôle ne peut remplacer la sécurité, l'accessibilité ou l'examen juridique des spécialistes.
- La transmission des sorties générées échantillonnées ne garantit pas toutes les sorties futures.
- Les audits automatisés ne peuvent pas observer toutes les questions liées à la facilité d'utilisation ou à la technologie d'assistance.
- Les règles de la plate-forme et le comportement du modèle peuvent changer après l'approbation d'un candidat à la libération.
Questions fréquentes
Comment l'AQ pour un jeu généré par l'IA est-elle différente?
Il ajoute une sortie variable, modération, provenance, comportement du modèle, divulgation, recul et contrôles de surveillance à des tests de gameplay, de performance, de compatibilité et d'accessibilité normaux.
Les tests automatisés peuvent-ils valider le contenu généré?
Ils peuvent vérifier les schémas, les limites, les patrons bloqués, les invariants, les itinéraires et les régressions. L'examen humain reste important pour le contexte, l'équité, la qualité créative et les dommages inattendus.
Que devrait-il se passer lorsque la génération vivante échoue?
Utilisez un timeout testé et un retour en sécurité, préserver l'état du jeu, expliquer l'interruption dans le langage du joueur, enregistrer l'événement diagnostique, et éviter les boucles de réessayer sans fin.
Qui devrait approuver une version de jeu AI?
Un propriétaire humain nommé devrait examiner les preuves intégrées et approuver la libération. L'automatisation peut recueillir des preuves, mais ne devrait pas élargir silencieusement le produit ou l'autorité de sécurité.
Combien de produits générés devraient être échantillonnés par l'AQ?
Choisissez un échantillon basé sur le risque, la variabilité, les langues, les classes d'entrée et le coût de la défaillance. Combinez l'échantillonnage aléatoire avec les cas de conflit et de limite, puis surveillez la production parce qu'aucun ensemble fini de pré-libération ne couvre chaque sortie du modèle.
Que devrait être enregistré pour un bug de jeu AI?
Capturez la version de compilation, de fonctionnalité et de service rapide, la version de modèle ou de service lorsque disponible, les entrées désinfectées, les identifiants de contexte pertinents, la sortie, le résultat de modération, la latence, le chemin de repli et la transition d'état.
Un navire de jeu peut-il être livré lorsque le service AI n'est pas disponible?
Il doit avoir une décision de produit définie: un repli sûr, un comportement en file d'attente, une fonctionnalité désactivée, ou une session bloquée. Testez le chemin choisi délibérément et communiquez-le dans le langage du joueur sans corrompre le progrès.
Quand l'AQ doit-il être répété après le lancement?
Répéter les portes affectées après le modèle, l'invite, la modération, l'actif, la règle de la plate-forme, la dépendance ou les changements de gameplay.
Sources et lectures complémentaires
- Enquête sur le contenu des installations de vapeur
Exigences actuelles de la vapeur de première partie pour la divulgation du contenu de l'IA et les garde-corps de génération vivante.
- W3C WCAG 2.2
Norme d'accessibilité web autorisée pour les interfaces perceptibles et exploitables.
- Développement de jeux MDN
Référence Mozilla pour les technologies de jeu de navigateur, le développement et les considérations de plate-forme.
Étape suivante
