Dois-je attribuer un identifiant unique à des unités individuelles de monnaie de jeu?

Je fais actuellement un MMORPG.

En ce moment, je travaille sur la partie monétaire du jeu, mais je ne sais pas si je dois attribuer un numéro de série unique pour chaque unité de la monnaie générée.

J'espère utiliser ce système pour détecter toute utilisation abusive de la monnaie virtuelle, mais est-ce une pratique courante et sinon, serait-ce une bonne idée du point de vue opérationnel et / ou de performance?

Il est peu probable que cela ait du sens.

Lorsque j'obtiens 100 Zorkmids du joueur A et 100 Zorkmids du joueur B, j'ai 200 Zorkmids.

Quand je paierai ensuite 50 Zorkmids au joueur C, C les obtiendra-t-il des Zorkmids que j'ai reçus du formulaire A ou de ceux que j'ai reçus de B? Dois-je contrôler cela? Est-ce même important? Un Zorkmid est un Zorkmid.

Cela n'a certainement pas d'importance pour les banques et les comptables du monde réel, qui retracent tous l'historique des transactions des comptes, pas l'historique des transactions des unités de monnaie individuelles. Il est toujours possible d'identifier les abus de cette manière.

Cela étant dit, je pourrais imaginer un jeu qui traite les pièces individuelles comme des éléments d'inventaire, donc lorsque vous échangez avec quelqu'un, vous devez vous assurer que vous avez des pièces de rechange. Cela permettrait certaines fonctionnalités intéressantes, comme le marquage, l'enchantement ou la contrefaçon de pièces. Dans ce cas, il serait logique de tracer chaque pièce individuellement. Mais je ne peux penser à aucun jeu qui fasse ça.

Non, tu ne devrais pas.

Alors que vous devez créer des systèmes qui peuvent vous permettre de suivre les transactions en devises (surtout si cette monnaie est un obscurcisseur en argent réel), vous n'avez pas besoin de suivre chaque unité individuelle de cette monnaie. La chose que vous souhaitez suivre est le mouvement global des fonds, en particulier dans les grands volumes (car cela pourrait être un indicateur de transactions potentielles en argent réel externes / non autorisées). Le suivi des unités de monnaie individuelles n'aide pas à cela (en fait, cela peut nuire) et complique uniquement la maintenance des données pertinentes en vous obligeant à générer de nombreux ID et à stocker des volumes d'informations relativement massifs dans votre base de données.

Cette idée a une certaine valeur pour les monnaies d'obscurcisseur en argent réel (c'est-à-dire, chose que vous achetez avec de l'argent réel qui est utilisé pour acheter du contenu dans le jeu, comme les gemmes dans Guild Wars 2). En particulier, ce désir pourrait surgir afin de lever toute ambiguïté entre les unités de monnaie introduites dans l'économie "gratuitement" et celles qui ont été introduites via une transaction réelle. Généralement, vous ne pouvez finalement reconnaître les revenus que sur ces derniers, il est donc important de les garder distincts.

Cependant, vous pouvez suivre les informations dont vous avez besoin simplement en stockant les nombres dans leur ensemble (unités totales entrantes, unités totales sortantes, pour les instances "gratuites" et "payantes" de la devise). Cela va de pair avec l'idée générale que vous souhaitez suivre ces choses dans leur ensemble, généralement au niveau de la transaction et non au niveau actuel, car il suit les données dont vous avez vraiment besoin et facilite le suivi de gros morceaux de fonds lors de leur dispersion dans tout votre système.

Note de l'auteur: cette réponse part de l'hypothèse que vous ne faites pas de trading en dehors du réseau, puis que vous effectuez une synchronisation avec les serveurs.

Vous n'avez pas besoin de suivre les numéros de série individuels des devises, car toute transaction entre des joueurs individuels doit se faire via vos serveurs. En d'autres termes, vos serveurs sont la source faisant autorité sur les soldes des comptes. Vos serveurs ne demanderont pas à l'utilisateur combien d'argent il a. Les clients attachés aux serveurs demandent au serveur "combien d'argent mon joueur possède" via un appel API. Cela suppose que les joueurs ne font pas de trading en dehors du réseau, puis se synchronisent avec le (s) serveur (s) [Bien que ce soit nouveau, je ne le recommande pas, sauf si vous souhaitez passer beaucoup de temps en théorie ].

Dans l'exemple de la monnaie du gouvernement, la seule source faisant autorité est la monnaie lorsqu'elle n'est pas attachée au compte [Un homme enlève 200 $, chaque facture est "signée" avec un numéro de série qui la marque afin que d'autres puissent déterminer si elle est réelle (si ils sont passés par les tracas de le faire) pour le prendre]. Lorsque la facture est déposée dans une banque, il existe des moyens de déterminer si les numéros de série ont été marqués comme hors circulation, etc.]. Mais, vos transactions sont plus similaires à celles de plusieurs utilisateurs dans une même succursale qui transfèrent des fonds entre des comptes sans jamais voir de devise.

L'histoire principale à illustrer est de savoir qui est votre source faisant autorité: je vais essayer d'illustrer: un utilisateur veut retirer de l'argent du guichet automatique. L'utilisateur ne va pas à la succursale et déclare «J'ai 500 $, croyez-moi, ce sont les publications en série». Au lieu de cela, il remet la clé [numéro de compte / clé] et la succursale / le serveur peut informer l'utilisateur de ses fonds et lui permettre de retirer de la monnaie tout en diminuant son solde. Peu importe ce qu'un utilisateur fait pour essayer de convaincre la banque "Vraiment, j'ai 500 $" à moins que la source faisant autorité (le serveur) ne vérifie le solde, rien ne se passera.

À votre santé.

Si vous essayez de programmer une simulation de jeu basée sur le fonctionnement du monde réel, vous allez rencontrer de gros problèmes en ce qui concerne la quantité d'informations qu'un ordinateur peut traiter.
Prenons par exemple la page suivante qui est une tentative de calculer combien d'atomes il y a dans un grain de sable.

http://www.thenakedscientists.com/forum/index.php?topic=6447.0

J'ai vu beaucoup de problèmes comme celui-ci en étudiant la chimie et la physique et le nombre ridiculement élevé auquel la personne sur cette page est arrivée se trouve dans le parc de ce que j'ai vu avec divers enseignants et manuels. -> 78 000 000 000 000 000 000 000

Même si c'est loin et que vous supprimez 6 de ces zéros, vous aurez toujours un nombre beaucoup trop grand pour que l'ordinateur moyen puisse le gérer à des tarifs interactifs. Surtout quand des milliers de ces transactions ont lieu à un moment donné.

Comment pourrions-nous éventuellement calculer et suivre la quantité de mouvement, les positions, la vitesse, les accélérations instantanées, les charges de champ, etc., de chaque atome dans chaque grain de sable sur une plage si un seul grain a 78000000000000000000 composants individuels. (Ou encore plus si vous considérez les composants sub-atomiques.)

J'ai lu une fois un document de programmation graphique nVidia qui disait quelque chose comme ce qui suit.
Faites ce qui donne la meilleure approximation de l'apparence, car personne ne pourra vraiment dire si la simulation n'est pas précise à 100%. L'efficacité doit être prise en considération.

La même chose s'applique à chaque type de simulation de jeu même si cela n'a pas à voir avec les graphismes. Vous ne devriez probablement faire que le strict minimum pour faire fonctionner les choses. Si vous allez tout faire ici, vous allez enterrer l'ordinateur dans une complexité qu'il ne peut pas gérer.
Vous devrez également écrire et essayer de maintenir le code de cette complexité.

Vous pouvez attribuer des numéros de série uniques à chaque unité monétaire, mais vous utiliserez toutes les ressources de l'ordinateur sur ce seul détail.

Peut-être qu'une meilleure façon de gérer cela est de ne donner qu'un seul identifiant unique pour chaque transaction.

Ainsi, le joueur n ° 1 paie le joueur n ° 2 1000000 $.
Si vous donnez à chaque dollar un identifiant unique, les ordinateurs de nombreuses personnes commenceront à avoir de gros problèmes, sans parler de tout le trafic réseau et du retard que cela causera.

Ou vous pouvez simplement créer une valeur qui représente la transaction entière.

uint transferFunds_Player1ToPlayer2 = 1000000;

Même une calculatrice de poche de 20 ans peut gérer quelque chose comme ça.