Cloud-Datensignale senden

(☁ Variable)

Dieser Artikel oder diese Sektion benutzt Cloud Daten. Benutzer, die noch den Neuer Scratcher Status haben oder den Offline-Editor, benutzen, können keine Projekte mit Cloud Daten erstellen oder sie in Projekten anderer Benutzer verwenden. Um Cloud-Daten zu verwenden, ist es erforderlich, den Online-Editor mit Status Scratcher zu benutzen.

Projekte, die Cloud Daten verwenden, müssen unter Umständen Signale von einem Spieler zum anderen senden. Das in diesem Artikel erläuterte Szenario ist, dass ein Projekt nur dann fortgesetzt werden kann, wenn alle Spieler bereit sind - sie müssen sich also gegenseitig Signale senden, was für jemanden, der mit Cloud-Daten nicht vertraut ist, komplizierter sein kann, als es klingt. Die Beispiele verwenden ein Spielprojekt, an dem drei Spieler beteiligt sind.

Eine Cloud-Variablen Methode

Information:

Diese Methode sollte nicht angewandt werden. Sie wird nur angegeben, um zu veranschaulichen, warum ein komplexerer Ansatz erforderlich ist.

Wie man es erstellt

In diesem Abschnitt wird davon ausgegangen, dass das Projekt eine Cloud-Variable mit dem Namen (☁ warte) hat und dass diese Variable anfangs auf 0 gesetzt ist. Wenn der Spieler ein bestimmtes Level im Projekt erreicht hat und daher bereit ist, weiterzumachen, ändert er die Variable um eins. Dann wird gewartet, bis die Variable der Anzahl der Spieler (in diesem Fall 3) entspricht, bevor das Skript fortgesetzt wird:

ändere [☁ warte v] um (1)
warte bis <(☁ warte)=(3)> // Wartet, bis alle Spieler dieses Level erreicht haben

Probleme mit dieser Methode

Diese Methode sollte auch dann funktionieren, wenn zwischen den Spielern eine 5-Sekunden-Verzögerung besteht und alle Spieler zur gleichen Zeit bereit sind. Stellen Sie sich vor, die Variable ist noch 0 - keiner der Spieler ist bereit, weiterzumachen. Dann werden zwei Spieler sehr kurz nacheinander bereit. Der erste Spieler, der bereit ist, sieht, dass die Cloud-Variable 0 ist, und setzt sie daher auf 1. Bevor dies auf den Scratch-Server hochgeladen wurde (es gibt immer eine kurze Verzögerung), ist der zweite Spieler bereit. Er sieht ebenfalls, dass die Cloud-Variable 0 ist und setzt sie daher auf 1. Der Server wird zweimal angewiesen, die Variable auf den Wert 1 zu setzen, so dass der Wert 1 bleibt, obwohl zwei Spieler bereit sind. Wenn der dritte Spieler bereit ist, setzt er die Variable auf 2, und dann warten alle Spieler unendlich lange weiter.

Mit drei Cloudvariablen und einer normalen Variable

Information:

Diese Methode sollte nicht angewandt werden. Sie wird nur angegeben, um zu veranschaulichen, warum ein komplexerer Ansatz erforderlich ist.

Wie man es erstellt

In diesem Abschnitt wird davon ausgegangen, dass das Projekt 4 Cloud-Variablen (3 Spieler plus eine zusätzliche) mit den Namen (☁ warte1), (☁ warte2), (☁ warte3) und (☁ globalwarte) hat und dass diese Variablen anfangs alle auf 0 gesetzt sind. Auch hier hat jeder Spieler eine lokale Variable namens (meine nummer), die einen Wert von 1 bis 3 hat, je nachdem, welcher Spieler er ist.

Wenn jeder Spieler diese Phase des Projekts erreicht, ändert er seine eigene Cloud-Variable (diejenige, die seiner Nummer entspricht) um 1 und wartet dann, bis alle anderen Spieler dasselbe getan haben. Auf diese Weise wird das Problem der obigen Methode 1 beseitigt, bei der zwei Spieler dieselbe Variable gleichzeitig änderten.

Sobald sie mit dem Warten fertig sind, d. h. alle Spieler tatsächlich bereit sind, setzen sie die Variable globalwait auf 1. Dann können sie ihre eigenen Cloud-Variablen nach Belieben ändern, da globalwarte als Signal an den letzten Spieler fungiert. Damit ist das in Methode 2 beschriebene Problem gelöst.

falls <(meine nummer) = (1)> , dann 
  ändere [☁ warte1 v] um (1)
sonst 
  falls <(meine nummer) = (2)> , dann 
    ändere [☁ warte2 v] um (1)
  sonst 
    falls <(meine nummer) = (3)> , dann 
      ändere [☁ warte3 v] um (1)
    end
  end
end
warte bis <<(☁ globalwarte) = (1)> oder <<(☁ warte1) = (1)> und <<(☁ warte2) = (1)> und <(☁ warte3) = (1)>>>>
setze [☁ globalwarte v] auf (1)

Probleme mit dieser Methode

Ein Problem kann auch hier auftreten, wenn es eine lange Verzögerung durch einen der Spieler gibt - das passiert normalerweise nicht, aber ein Skript muss immer funktionieren, nicht nur normalerweise. Aufgrund der begrenzten Anzahl von Cloud-Variablen, die in Scratch zur Verfügung stehen (10 pro Projekt), müssen die Variablen wahrscheinlich bald darauf in einem Cloud-Spiel wiederverwendet werden. Stellen Sie sich vor, zwei Spieler sind bereits bereit und haben ihre jeweiligen Cloud-Variablen auf 1 gesetzt. Dann kommt der dritte Spieler an und setzt seine Cloud-Variable auf 1. Die anderen Spieler machen weiter, da alle drei Variablen gleich 1 sind, und geben ihren eigenen Cloud-Variablen neue Werte. Wenn der dritte Spieler zum Warteblock kommt (was bei einer Verzögerung mehrere Sekunden später sein kann), sind die Variablen nicht mehr alle gleich 1, und der dritte Spieler wartet wieder unendlich lange.

Verwendung von vier Cloud-Variablen und einer normalen Variablen

Information:

Dies ist die Methode, die verwendet werden sollte und die garantiert funktioniert.

Wie man es erstellt

In diesem Abschnitt wird davon ausgegangen, dass das Projekt 4 Cloud-Variablen (3 Spieler plus eine zusätzliche) mit den Namen (☁ warte1), (☁ warte2), (☁ warte3) und (☁ globalwarte) hat und dass diese Variablen anfangs alle auf 0 gesetzt sind. Auch hier hat jeder Spieler eine lokale Variable namens (meine nummer), die einen Wert von 1 bis 3 hat, je nachdem, welcher Spieler er ist.

Wenn jeder Spieler diese Phase des Projekts erreicht, ändert er seine eigene Cloud-Variable (diejenige, die seiner Nummer entspricht) um 1 und wartet dann, bis alle anderen Spieler dasselbe getan haben. Auf diese Weise wird das Problem der obigen Methode 1 beseitigt, bei der zwei Spieler dieselbe Variable gleichzeitig änderten.

Sobald sie mit dem Warten fertig sind, d. h. alle Spieler tatsächlich bereit sind, setzen sie die Variable globalwait auf 1. Dann können sie ihre eigenen Cloud-Variablen nach Belieben ändern, da globalwait als Signal an den letzten Spieler dient. Damit ist das in Methode 2 beschriebene Problem gelöst.

falls <(meine nummer) = (1)> , dann 
  ändere [☁ warte1 v] um (1)
sonst 
  falls <(meine nummer) = (2)> , dann 
    ändere [☁ warte2 v] um (1)
  sonst 
    falls <(meine nummer) = (3)> , dann 
      ändere [☁ warte3 v] um (1)
    end
  end
end
warte bis <<(☁ globalwarte) = (1)> oder <<(☁ warte1) = (1)> und <<(☁ warte2) = (1)> und <(☁ warte3) = (1)>>>>
setze [☁ globalwarte v] auf (1)

Diese Methode sollte auch dann funktionieren, wenn zwischen den Spielern eine 5-Sekunden-Verzögerung besteht und alle Spieler zur gleichen Zeit bereit sind.

Siehe auch

• Cloud Daten

---

Code zum Einbinden ins Forum:
[wiki=de:Cloud-Datensignale senden]Cloud-Datensignale senden[/wiki]