Entwurfsmuster für die Spieleentwicklung

Ich entwickle ein Spiel, das derzeit einen GameFactory-Vertrag verwendet, um Instanzen eines Spielvertrags zu erstellen. Das Factory-Muster würde es einer beliebigen Anzahl von Spielern ermöglichen, ihr eigenes Einzelspieler-Spiel zu spielen und die Spieldaten in separaten Spielinstanzen zu speichern.

Idealerweise benötige ich jedoch die Spielverträge, um mit den GameFactory-Verträgen zu interagieren, um globale Highscores und Statistiken über alle derzeit gespielten Spiele zu aktualisieren.

Was wäre ein guter Weg, um dies zu erreichen? Gibt es bereits Beispiele für Muster für solche dezentralen Spiele?

Haben Sie darüber nachgedacht, alle Ihre Daten in einem Smart Contract zu speichern? Objektorientierte Muster lassen sich oft nicht gut in Solidity-Verträge übersetzen. Normalerweise sollten Sie sich Verträge nicht so vorstellen, wie Sie es zB mit den Klassen von Java machen würden.
Ich habe ungefähr 20 Variablen, einschließlich Arrays und Mappings, die ich für jede Spielinstanz im Auge behalten muss. Stattdessen sollte ich eine große Struktur all dieser Variablen erstellen und eine Zuordnung zur Spieleradresse und Spieldatenstruktur erstellen? Greifen Sie dann jedes Mal auf diese Zuordnung zu, wenn ich eine Funktion zum Aktualisieren aufrufen muss?
Um @JesseBusman zu widersprechen, tendiere ich vom Standpunkt eines Sicherheitsprüfers dazu, Fabriken und Einzelvertragsinstanzen zu bevorzugen. Meiner Erfahrung nach ist dieses Modell einfacher zu verstehen als eines, bei dem jeder Funktionsaufruf eine ID benötigt und eine komplexere Berechtigungsprüfung durchführen muss.
Was die ursprüngliche Frage betrifft, verstehe ich das Problem nicht. Einfach das Spiel in der GameFactory aufrufen. Die GameFactory sollte eine Zuordnung der Spiele führen, damit sie weiß, dass die Daten, die sie erhält, gültig sind (aus einem von ihr bereitgestellten Vertrag stammen).

Antworten (1)

Eine Hub-and-Spoke-Anordnung hat Vorteile, ebenso wie ein monolithischer Vertrag.

Nabe und Speiche

  • Einfachere interne Struktur, möglicherweise besser lesbar
  • Kann einen "rollierenden Upgrade"-Pfad aufnehmen, wenn dies wünschenswert ist.

Monolithisch

  • Es kostet erheblich weniger, ein paar Variablen zu initialisieren, als für jedes Spiel einen neuen Vertrag bereitzustellen.

Das Arbeiten auf Hub-and-Spoke-Basis führt natürlich zu einigen allgemeinen Bedenken. Wie Sie bereits erwähnt haben, müssen die Spokes wahrscheinlich Globals im Hub aktualisieren, der Hub muss den Zugriff auf bestimmte Funktionen einschränken, sodass nur ein Spoke dazu berechtigt ist usw.

Meine Erkundungen führten mich dazu, allgemeine Verträge zu erstellen, ungefähr:

contract Hub is Deployer { ...

contract Spoke is Deployed { ...

Bedenken Sie, dass der Deployer die bereitgestellten Spokes verfolgt und Dinge tut wie:

modifier onlyDeployed { // only trust contracts made by this Hub

... und Deployed macht Dinge wie das Erinnern an den Hub, der es hervorgebracht hat.

Wenn Sie die Spiellogik aktualisieren möchten, können Sie eine weitere Trennung von Hub-Daten und Factory-Logik in Betracht ziehen. Das heißt, Sie möchten in der Lage sein, die globalen Daten in einem Vertrag zu speichern, der voraussichtlich nicht geändert wird, während Sie den Vertrag, der neue Spiele bereitstellt, regelmäßig ersetzen.

Die niedrigsten Gaskosten und der einfachste Ansatz ist ein monolithischer Vertrag mit Spieldaten, die in Strukturen zusammengefasst sind, und ohne die Möglichkeit eines Upgrades.

Ich hoffe es hilft.

Entwurfsmuster für die Spieleentwicklung
AntwortenHierDatenschutz-Bestimmungen1y, 0v