4.4 KiB
Monétisation
Principe
La monétisation est une capacité optionnelle de plateforme et de distribution. Aucun jeu, aucune génération du moteur et aucun runner ne doit supposer qu'une publicité, un achat intégré ou un fournisseur particulier est disponible.
Le gameplay dépend uniquement de contrats abstraits et doit rester fonctionnel lorsque la monétisation est Disabled ou Unsupported.
Game
↓
Monetization contract
↓
capability state
├── Available -> backend plateforme
├── Disabled -> fonctionnalité volontairement coupée
└── Unsupported -> aucune implémentation pour cette cible
Android
Android est la cible prioritaire pour la monétisation publicitaire des premiers jeux. L'implémentation prévue passe par Java/JNI et un fournisseur ou médiateur Android tel qu'AdMob, AppLovin MAX ou LevelPlay.
La présence des SDK publicitaires n'est pas obligatoire dans toutes les variantes Android. Un build de test, une édition payante ou une distribution particulière peut désactiver la publicité tout en réutilisant exactement la même crate de jeu.
Web
La monétisation Web est distincte de la monétisation Android. Un frontend Web peut utiliser ultérieurement un fournisseur publicitaire destiné aux sites ou contenus Web, par exemple une solution de type AdSense, mais il ne doit pas être traité comme une simple réutilisation du SDK AdMob Android.
Le backend Web de monétisation reste optionnel et n'est introduit que lorsqu'une vraie cible Web est mise en œuvre et que ses contraintes de politique, consentement, sandbox navigateur et expérience utilisateur ont été validées.
Desktop natif
Aucun fournisseur publicitaire Desktop générique n'est imposé par le framework. La baseline Desktop native considère la publicité comme désactivée par défaut.
Une distribution Desktop peut préférer d'autres modèles : achat unique, donation, DLC, contenu premium, distribution via un store, cross-promotion externe ou absence totale de monétisation.
Si un fournisseur publicitaire Desktop pertinent est retenu ultérieurement, il devra être ajouté derrière le même contrat optionnel sans faire entrer son SDK dans les crates de gameplay.
Desktop Tauri
Un éventuel frontend Tauri peut techniquement afficher du contenu Web dans une WebView, mais cela ne transforme pas automatiquement une application Desktop en inventaire publicitaire Web autorisé. Toute solution publicitaire utilisée dans une WebView devra être vérifiée explicitement auprès du fournisseur concerné avant intégration.
Tauri n'est donc pas une stratégie de contournement pour utiliser une régie Web dans un binaire Desktop.
Publicités récompensées
Usages possibles : seconde chance, revive, bonus x2, coffre gratuit, accélération, skin temporaire, monnaie supplémentaire, nouveau tirage ou poursuite d'une série.
La logique de jeu doit prévoir un chemin normal lorsque la publicité récompensée est indisponible. Une récompense publicitaire n'est accordée qu'après réception de l'événement de succès défini par le backend actif.
Interstitiels
Les emplacements naturels sont entre deux parties, après plusieurs manches, à la fin d'un niveau ou après un écran de résultats. Ils ne doivent pas interrompre arbitrairement une action en cours.
Suppression des publicités
Une option remove ads peut supprimer les publicités non récompensées tout en laissant éventuellement disponibles les rewarded ads volontaires. Cette politique appartient à la distribution et au jeu, pas au moteur commun.
Billing et achats
Des achats ou déblocages peuvent concerner skins, personnages, cosmétiques ou packs. Le backend de billing est lui aussi optionnel et spécifique à la plateforme de distribution.
Médiation
Une plateforme de médiation peut agréger plusieurs demandes publicitaires. Cette architecture ne remonte pas dans le gameplay : le moteur manipule disponibilité, placement, affichage, fermeture, récompense et erreurs, pas le réseau publicitaire gagnant.
Configuration distante
Des paramètres comme la fréquence des interstitiels ou un multiplicateur de récompense peuvent à terme être configurables à distance, avec garde-fous et valeurs par défaut locales. Les règles critiques ne doivent pas dépendre exclusivement d'une configuration distante non vérifiée.