Guide du système Unreal Game Economy, Currency, Shop et Loot

Réponse directe

Séparer les définitions immuables des soldes et de l’inventaire mutables. Les Data Assets ou les Data Tables définissent les objets, les prix, la rareté et les poids de loot ; un service d’économie ou un composant d’économie faisant autorité gère la devise et les transactions ; l’inventaire stocke des identifiants d’objets stables et des quantités ; l’UI se contente d’afficher des prévisualisations d’offres et de soumettre des demandes. Chaque attribution, achat, remboursement et tirage de loot doit être une transaction validée avec un seul résultat de commit et une frontière de persistance récupérable.

Il s’agit d’un guide d’architecture d’économie en jeu. Il ne promet ni commerce en argent réel, ni conformité marketplace, ni sécurité backend, ni une interface d’inventaire UI spécifique. L’objectif concret est un fragment de construction de jeu qu’un autre développeur peut reproduire à partir d’un dépôt propre. Conservez séparés le comportement du moteur, la politique du projet et les preuves mesurées : la documentation d’Epic Games définit les concepts pris en charge, le projet définit la propriété et les budgets, et seul un test nommé prouve le résultat local.

Ce que ce guide apporte

• Un modèle de propriété concret pour système économique de jeu Unreal, monnaie, boutique et butin.
• Un flux de travail de mise en œuvre Blueprint/C++ en six étapes avec un exemple réel d’API ou de commande.
• Trois scénarios de production, incluant comportement normal, limites, et comportement de passation.
• Critères de récupération d’échec et de validation pour les builds éditeur et packagés.
• Un passage de relais SEELE borné qui mène au créateur Unreal sans modifier l’intention technique de cette page.

Architecture système et propriété

Catalogue de définitions

Attribuez des identifiants stables aux objets et aux monnaies, et stockez l’affichage, la pile, le prix, la rareté, la catégorie et les références d’assets dans des Primary Data Assets ou des tables validées. Les définitions sont du contenu ; les quantités possédées par le joueur représentent l’état.

Revue du catalogue de définitions : capturez l’ID de catalogue et l’intégrité du schéma et montrez comment l’autorité de registre reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Autorité de registre

Un service mono-joueur local ou un serveur de confiance gère les soldes et les identifiants de transaction. Toutes les mutations indiquent une raison, une source, un delta, des valeurs avant et après, ainsi que le résultat de persistance afin que les attributions en double puissent être détectées.

Revue de l’autorité du ledger : capturez l’ID de transaction et l’autorité et montrez comment la transaction d’inventaire reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Transaction d'inventaire

Validez l’existence de l’objet, la quantité, les limites de pile, les prérequis, l’instantané du prix, la capacité et la propriété avant de valider simultanément la monnaie et l’inventaire. Les commits partiels créent des duplications ou des pertes.

Revue des transactions d’inventaire : capturez l’atomicité du solde et de l’inventaire et montrez comment la sélection de loot reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Sélection de loot

Résolvez une table de loot nommée avec une entrée déterministe ou possédée par le serveur, des filtres d’éligibilité, des poids, des règles de pity et des résultats explicitement vides. La présentation révèle le résultat engagé.

Revue de sélection de loot : capturez l’éligibilité de loot, le poids et la seed, et montrez comment le catalogue de définitions reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Workflow de mise en œuvre

1. Étape 1 : Définissez des identifiants stables pour les objets, la monnaie, les offres et les tables de loot, ainsi qu’une validation de schéma qui rejette les doublons, les prix négatifs, les assets manquants et les poids impossibles.
2. Étape 2 : Créer une seule API économique pour GrantCurrency, SpendCurrency, PurchaseOffer, GrantItem, RemoveItem et RollLoot. Retourner un succès structuré ou un rejet plutôt que de muter des champs depuis l’UI.
3. Étape 3 : Modélisez un achat comme une seule transaction : prenez une capture de l’offre, validez les fonds et la capacité, réservez ou calculez le résultat, validez les deux côtés, persistez, puis notifiez la présentation.
4. Étape 4 : Ajouter de l’idempotence ou des identifiants de transaction pour les récompenses pouvant être relancées après une déconnexion, un échec de sauvegarde ou une duplication de callback. Enregistrer le point de commit durable.
5. Étape 5 : Enregistrer les soldes et l’inventaire versionnés par des ID stables, et écrire des migrations pour les objets retirés, les conversions de devise ou les règles de pile modifiées.
6. Étape 6 : Testez les soldes zéro et maximum, l’inventaire complet, le rappel de callback en double, les entrées négatives, la modification d’une offre pendant l’achat, l’interruption de sauvegarde, les données corrompues, la seed de loot répétée, et la réconciliation hors ligne/ligne.

Exemple concret d’API ou de commande

FEconomyResult UEconomyService::Purchase(const FOfferId OfferId, const FTransactionId TxId)
{
    if (Ledger.Contains(TxId)) return Ledger[TxId];
    const FOffer& Offer = Catalog->RequireOffer(OfferId);
    ValidateFundsAndCapacity(Offer);
    FEconomyResult Result = CommitAtomic(Offer.Price, Offer.Grants);
    PersistAndRecord(TxId, Result);
    return Result;
}

Trois scénarios de production

Exemple 1 : Boutique de montée de niveau en solo

Un Data Asset définit la mise à niveau et le prix ; le composant économique local valide la devise et les prérequis, écrit à la fois le nouveau solde et la propriété de la mise à niveau dans une transaction de sauvegarde versionnée, puis met à jour l’UI.

La preuve pour la boutique de montée de niveau en solo doit inclure l’ID de catalogue et l’intégrité du schéma, l’identité de build propriétaire, et la condition qui ramène ce scénario à son dernier état stable connu.

Exemple 2 : Récompense quotidienne serveur

Le backend ou le serveur de confiance génère un ID de transaction de récompense unique. La répétition de la demande renvoie le résultat précédent au lieu d’accorder la monnaie deux fois.

La preuve de la récompense quotidienne côté serveur doit inclure l’ID de transaction et l’autorité, l’identité de build propriétaire, et la condition qui ramène ce scénario à son dernier état connu correct.

Exemple 3 : Coffre pondéré

Le serveur choisit une table de loot admissible avec une graine enregistrée et un compteur de pity, valide les quantités d’objets et envoie les IDs d’objets résultants pour affichage.

La preuve pour le coffre pondéré doit inclure l’atomicité du solde et de l’inventaire, l’identité de build propriétaire, et la condition qui ramène ce scénario à son dernier état stable connu.

Modes de défaillance et reprise

L’UI soustrait la monnaie avant que l’achat ne réussisse

Maintenez la prévisualisation séparée de l’autorité et mettez à jour l’affichage confirmé à partir du résultat de la transaction. L’animation de rollback n’est pas un substitut à un état atomique.

Avant que l’UI ferme, vérifiez si la devise est soustraite avant la réussite de l’achat, relancez la boutique de montée de niveau en solo et prouvez que l’atomicité du solde et de l’inventaire revient à la frontière attendue sans étape de réparation non documentée.

Récompense dupliquée après reconnexion

Conserver et vérifier un ID de transaction ou de subvention stable. Les tentatives réseau répétées et les rappels réitérés doivent être sûrs par construction.

Avant la fermeture, la récompense dupliquée après reconnexion : réexécutez la récompense quotidienne serveur et prouvez que l’éligibilité de loot, le poids et la seed reviennent à la limite attendue sans étape de réparation non documentée.

Le renommage d’actif efface l’inventaire

Conserver des ID logiques stables, maintenir les redirections ou migrations, et valider chaque ID enregistré par rapport au catalogue avant de matérialiser les objets.

Avant la fermeture, l’actif renommé efface l’inventaire : réexécutez le coffre pondéré et prouvez que le commit de sauvegarde, la relance et l’état de migration reviennent à la limite attendue sans étape de réparation non documentée.

Les poids de loot créent un biais caché

Normaliser et inspecter les entrées éligibles après filtrage, enregistrer les seeds et les résultats en développement, et tester explicitement les tables vides ou à poids zéro.

Avant de clôturer, si les pondérations du loot produisent un biais caché, refaire la boutique de mise à niveau en solo et prouver que l’ID du catalogue et l’intégrité du schéma reviennent à la limite attendue sans étape de réparation non documentée.

Matrice de validation

• ID de catalogue et intégrité du schéma : inspectez-le à côté du catalogue de définitions ; validez seulement lorsque l’UI soustrait la devise avant la réussite de l’achat, sans répétition dans la boutique de montée de niveau en solo et en précisant le build exact dans les preuves.
• ID de transaction et autorité : comparez-le à l’autorité de registre ; n’validez que lorsque la récompense dupliquée après reconnexion ne se reproduit pas lors de la récompense quotidienne côté serveur et que les preuves mentionnent la build exacte.
• atomicité du solde et de l’inventaire : inspectez-la à côté de la transaction d’inventaire ; validez seulement lorsque le renommage d’actif qui efface l’inventaire ne se reproduit pas dans le coffre pondéré et que les preuves mentionnent le build exact.
• éligibilité au loot, poids et graine : consultez-le à côté de la sélection de loot ; ne validez que si les poids de loot produisent un biais caché qui ne se reproduit pas pendant la boutique de mise à niveau solo et que les preuves mentionnent la build exacte.
• commit de sauvegarde, reprise et résultat de migration : l’examiner à côté du catalogue de définition ; valider uniquement lorsque l’UI soustrait la devise avant la réussite de l’achat et que cela ne se reproduit pas pendant la récompense quotidienne du serveur, et que les preuves mentionnent la version de build exacte.

Inspectez-le à côté de la présentation et de l’autorité ; validez uniquement lorsque plusieurs interactions déclenchées par une pression ne se reproduisent pas lors d’une porte avec état de verrouillage et que les preuves mentionnent le build exact.

Ces étapes ciblent la surface de documentation Unreal Engine 5 actuelle au 2026-07-26. Les valeurs par défaut du moteur, le statut expérimental, le packaging des plugins, les signatures API et la prise en charge des plateformes peuvent changer. Sélectionnez la version de la documentation qui correspond au projet, testez le patch exact et la cible, et conservez une révision de rollback. La documentation publique ne remplace pas les exigences NDA de plateforme, la revue en store, la certification console ou les preuves de performance spécifiques au projet.

Sources officielles

• Data Assets — preuve source pour le catalogue de définitions dans ce flux de système de boutique de monnaie et de butin de l’économie de jeu Unreal; vérifiez la version de la documentation par rapport à la branche de distribution.
• Éléments de gameplay pilotés par les données — preuve source pour l’autorité du ledger dans ce flux de travail de système de butin magasin devise du gameplay Unreal; vérifiez la version de la documentation par rapport à la branche de production.
• Sauvegarde et chargement de votre jeu — preuve source pour la transaction d’inventaire dans ce flux de système de boutique de monnaie et de butin de l’économie de jeu Unreal; vérifiez la version de la documentation par rapport à la branche de distribution.

Unreal Engine est une marque déposée d'Epic Games. SEELE AI est indépendant et cet article n'implique pas l'approbation d'Epic Games ou de Valve.

Du plan technique au jeu Unreal de SEELE

Utilisez cette page pour définir le système, les tests d'acceptation et les limites de défaillance ; puis transmettez ce cahier des charges précis dans [le créateur de jeu Unreal de SEELE](/features/create/unreal-game). SEELE peut générer un jeu natif Unreal 5, fournir un aperçu dans le navigateur, prendre en charge l'optimisation et le packaging dans SEELE, et vous permettre de télécharger le projet ou la sortie packagée pour une publication externe ou de le publier en tant que jeu SEELE gratuit ou payant.

Ce transfert ne modifie pas la responsabilité de production native décrite ci-dessus. L'approbation du magasin, les ventes, les revenus, la certification, la compatibilité des plugins tiers et la conformité de la plateforme ne sont pas garanties. Gardez le jeu Unreal source, les journaux de compilation, les preuves de test et les décisions de publication externes sous le contrôle de votre équipe.

FAQ

Quelle est la bonne architecture pour le système d’économie de jeu Unreal monnaie boutique et loot ?

Séparez les définitions immuables des soldes et de l’inventaire mutables. Les Data Assets ou Data Tables définissent les objets, les prix, la rareté et les poids de loot ; un service économique ou composant d’autorité propriétaire gère la monnaie et les transactions ; l’inventaire stocke des IDs d’objet stables et des quantités ; l’UI ne fait que prévisualiser les offres et soumettre des demandes. Chaque attribution, achat, remboursement et tirage de loot doit être une transaction validée avec un seul résultat de commit et une frontière de persistance récupérable. Commencez par le catalogue de définitions et l’autorité de registre, puis conservez la présentation comme observatrice de l’état de gameplay engagé.

Le système de monnaie, de boutique et de loot Unreal doit-il être implémenté en Blueprint ou en C++ ?

Les deux sont possibles. Blueprint est efficace pour une logique de jeu rapide et l’itération des designers ; C++ est utile pour des contrats réutilisables, des durées de vie complexes, des boucles sensibles aux performances et des tests automatisés. Conservez les mêmes limites de propriété, de validation, d’échec et de récupération dans les deux cas.

Comment le système d’économie de jeu Unreal monnaie boutique loot doit-il être testé ?

Testez un cas normal, une entrée invalide, une interruption ou arrêt, un redémarrage propre, et la parité du build packagé. Capturez l’ID de catalogue et l’intégrité du schéma, l’ID de transaction et l’autorité, l’atomicité du solde et de l’inventaire avec un identifiant de build et des critères de validation explicites.

Quelle est la panne la plus dangereuse dans le système d’économie de jeu Unreal monnaie boutique loot ?

Le fait que l’UI soustraie la devise avant que l’achat ne réussisse est un signal précoce : maintenez la séparation entre l’aperçu et l’autorité, et mettez à jour l’affichage engagé à partir du résultat de la transaction. Une animation de rollback ne remplace pas un état atomique. Vérifiez aussi le nettoyage et la nouvelle tentative afin que la correction apparente ne laisse pas d’état obsolète.

Quelle version d’Unreal est ciblée par ce guide du système d’économie de jeu Unreal monnaie boutique et loot ?

Il utilise la surface de documentation Unreal Engine 5 disponible le 2026-07-26. Vérifiez le sélecteur de version, la signature API, l’état du plugin, la chaîne d’outils de plateforme et le comportement packagé dans le patch moteur exact qui sera livré.

Que peut faire SEELE après que ce plan de système de boutique de monnaie et de loot de l’économie de jeu Unreal soit prêt ?

SEELE peut générer un jeu natif Unreal 5, fournir une prévisualisation navigateur, prendre en charge l'optimisation et l'empaquetage, et fournir des téléchargements de projet ou d'application empaquetée pour une publication externe ou une sortie SEELE gratuite ou payante. Il ne garantit pas l'approbation par des magasins tiers, la compatibilité, les ventes ou les revenus.