Nommez la méthode de distribution ou de randomisation, les choix du joueur, la table de paiement et les options prises en charge. Des jeux visuellement proches peuvent nécessiter des mathématiques et tests différents lorsque les règles ou paris annexes changent.
Transformez les règles en matrice de décision
| Domaine de règle | Question à résoudre |
|---|---|
| État initial | Quelles cartes, valeurs ou positions commencent une manche valide ? |
| Choix du joueur | Quelles actions sont disponibles dans chaque état et à quel coût ? |
| Délai expiré | Quelle action ou quel résultat s’applique sans réponse ? |
| Égalité ou résultat exceptionnel | Quelle règle de paiement et de priorité s’applique ? |
| Pari annexe ou main supplémentaire | Comment est-il évalué et relié à la manche principale ? |
| Interruption | Quel état est conservé et comment le jeu reprend-il ou se règle-t-il ? |
Utilisez la matrice pour identifier les cas de test avant la mise en œuvre. Le nom d’un jeu familier ne remplace pas l’ensemble réel des règles de la variante.
Séparez l’état de référence de la présentation
L’enregistrement serveur doit établir les choix acceptés et le résultat. Les animations et messages doivent présenter cet état fidèlement, y compris les actions retardées ou reprises. Une requête client répétée ne doit pas créer tacitement une nouvelle mise ou décision.
Conservez un historique de main ou de manche qui relie la version des règles, les actions et le résultat. Le support a besoin de preuves suffisantes pour expliquer l’issue sans dépendre du dernier écran visible par le joueur.
Réalisez la recette des branches de règles et des données financières
- Testez chaque branche convenue de la matrice, y compris les délais expirés, les égalités et les paiements exceptionnels.
- Interrompez et reprenez des manches représentatives.
- Comparez l’historique aux débits, crédits et éventuelles contrepassations du portefeuille.
Définissez les exigences d’évaluation et de distribution de la version prévue. Un changement de variante, de paris annexes ou de règles de paiement peut modifier le périmètre des tests même si l’interface reste similaire.
Préparez les livrables de développement
Convenez de la livraison des règles, du travail mathématique, des ressources, du client, du serveur, de l’adaptateur et des preuves de test. Précisez les droits sur chaque composant et l’équipe responsable des mises à jour. Si plusieurs jeux partagent une infrastructure, coordonnez la conception RGS avec leurs exigences d’état et de transaction.
Transmettez la variante exacte et les règles de paiement, les appareils pris en charge et le circuit de distribution. Énumérez les fonctions optionnelles séparément pour l’examen du périmètre.