DE102021005159A1

DE102021005159A1 - Steuerung und Übertragung von Fernwettbewerb

Info

Publication number: DE102021005159A1
Application number: DE102021005159.9A
Authority: DE
Inventors: Ewgeniy Oganian
Original assignee: Escs Inc
Current assignee: Escs Inc
Priority date: 2021-10-17
Filing date: 2021-10-17
Publication date: 2023-06-29
Also published as: WO2023062248A1

Abstract

Die vorliegende Offenbarung bezieht sich auf ein Verfahren zur Steuerung eines Fernwettbewerbs. Das Verfahren umfasst das Bereitstellen eines anzuzeigenden Frontends, das Instruieren an das Spiel, eine Partie zu initiieren, das Ermitteln eines Ergebnisses der Partie und das Steuern des Fernwettbewerbs. Die vorliegende Offenbarung bezieht sich ferner auf ein Verfahren zur Übertragung eines Fernwettbewerbs. Das Verfahren umfasst das Anzeigen eines Frontends, das Einleiten einer Partie gemäß einem Partieparametersatz, die Rückgabe eines Spielergebnisses und das Steuern des Fernwettbewerbs.

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Steuerung eines Fernwettbewerbs eines Spiels, ein Verfahren zur Übertragung eines Fernwettbewerbs eines Spiels, ein Programmprodukt, eine Vorrichtung und ein System zur Steuerung eines Fernwettbewerbs eines Spiels.
Fernpartien werden bei Computerspielen immer beliebter. Zum Beispiel kann ein Spiel einem Spieler erlauben, eine Fernpartie gegen einen anderen Spieler zu spielen, zum Beispiel über eine Internetverbindung. Ein Spieler kann an einem Fernwettbewerb eines Spiels teilnehmen wollen. Ein Spieler kann zum Beispiel eine Reihe von aufeinander folgenden Spielen spielen, bis er ein Spiel verliert und aus dem Wettbewerb ausscheidet.
Um einen Fernwettbewerb zu ermöglichen, kann ein Entwickler eine Fernwettbewerbsfunktion in ein Spiel implementieren. Es kann jedoch viel Zeit und Entwicklungsressourcen für den Entwickler erfordern, eine Fernwettbewerbsfunktion in ein Spiel zu implementieren. Außerdem erreicht die Fernwettbewerbsfunktionalität möglicherweise nicht die gewünschte Qualität.
Um einen Fernwettbewerb zu ermöglichen, kann alternativ ein externer Fernwettbewerbsbetreiber einen externen Fernwettbewerb durchführen. Beispielsweise können die Spieler verpflichtet sein, die Ergebnisse einer Partie nach der Partie an den externen Betreiber des Fernwettbewerbs zu übermitteln oder weitere Wettbewerbsregeln einzuhalten. Dementsprechend kann der Betreiber des externen Fernwettbewerbs den Spielern Informationen über den Fortschritt und den Verlauf des externen Fernwettbewerbs zur Verfügung stellen. Ein solcher externer Fernwettbewerb kann jedoch einen hohen manuellen Aufwand für den Betreiber des externen Fernwettbewerbs erfordern. Außerdem kann ein solches externes Fernwettspiel für die Spieler langsam und umständlich zu bedienen sein.
Diese Probleme werden durch die vorliegende Offenbarung überwunden. Die Erfindung umfasst ein Verfahren, das die Aufgabe löst, ein verbessertes Verfahren zur Steuerung eines Fernwettbewerbs bereitzustellen.
Die Erfindung ist in den unabhängigen Ansprüchen definiert. Die abhängigen Ansprüche beschreiben bevorzugte Ausführungsformen.
insbesondere bezieht sich die vorliegende Offenbarung auf ein Verfahren zur Steuerung eines Fernwettbewerbs. Das Verfahren umfasst das Bereitstellen eines anzuzeigenden Frontends, das Instruieren an das Spiel, eine Partie zu initiieren, das Ermitteln eines Ergebnisses der Partie und das Steuern des Fernwettbewerbs.
Das Verfahren umfasst die Bereitstellung eines Frontends, das innerhalb des Spiels angezeigt wird. Auf diese Weise muss der Spieleentwickler keine Bedienelemente in die Spieloberfläche integrieren und die Steuerung mit einem entfernten Wettbewerbssystem verbinden. Stattdessen kann der Spieleentwickler einen Aufruf an das universelle Frontend einfügen. Dadurch spart das Verfahren Zeit und ist weniger fehleranfällig.
Ein Spiel ist ein Programm, eine Anwendung, ein Gerät, ein System oder eine Kombination davon, die eine Form des Wettbewerbs zwischen Benutzern ermöglichen. Ein Spiel kann beispielsweise ein Programm sein, das einem Benutzer eine Anzahl von Punkten zuweist, die mit der einem anderen Benutzer zugewiesenen Anzahl von Punkten verglichen werden kann. Ein weiteres Beispiel ist ein Spiel, bei dem zwei oder mehr Benutzer virtuell miteinander interagieren können. In einem Fall kann jeder Benutzer versuchen, eine Aufgabe vor dem anderen Benutzer zu erledigen, z. B. ein virtuelles Autorennen zu beenden, ein Rätsel zu lösen oder eine Lösung für ein mathematisches oder technisches Problem zu finden. In einem anderen Fall können die Benutzer in einer virtuellen Umgebung miteinander interagieren, z. B. bei einem virtuellen Ping-Pong-Spiel oder einem virtuellen Fußballspiel.
Das Frontend kann als Overlay über dem Spiel angezeigt werden. In bestimmten Szenarien, z. B. während eines Spiels, kann das Frontend ausgeblendet oder reduziert werden.
Wenn das Frontend mit Hilfe von Webtechnologien bereitgestellt wird, kann das Frontend leicht unabhängig vom Spiel aktualisiert werden. Das Frontend kann zum Beispiel von einem Backend bereitgestellt werden. Wenn das Backend von einem entfernten Wettbewerbsbetreiber betrieben wird, kann das Frontend vom entfernten Wettbewerbsbetreiber aktualisiert werden, unabhängig vom Entwickler des Spiels. Daher kann das Frontend aktualisiert oder geändert werden, ohne dass der Spieler eine Aktualisierung des Spiels auf einem Client-Gerät herunterladen oder installieren muss.
Das Verfahren umfasst ferner die Anweisung an das Spiel, ein Spiel entsprechend einem Spielparametersatz zu initiieren. Zum Beispiel kann der Spieleentwickler einen Haken in das Spiel einbauen, so dass das Backend eine Spielanweisung an das Spiel weitergeben kann.
Wenn die Spielanweisung einen Spielparametersatz enthält, leitet das Spiel ein Spiel entsprechend dem Spielparametersatz ein. Ein Spielparametersatz kann zum Beispiel ein Zeitlimit, einen Schwierigkeitsgrad, einen Geschwindigkeitsgrad, eine Größe, eine Rückruffunktion und/oder einen Verbindungsparameter enthalten. Auf diese Weise kann ein Spiel die für einen Wettbewerb gewünschte Konfiguration aufweisen.
In einem Beispiel für ein Tetris-Spiel kann das Spiel eine Einzelspieler-Partie sein. In einem anderen Beispiel eines Go-Spiels kann die Partie eine Doppelspielerpartie oder eine Einzelspielerpartie gegen einen Computergegner sein. Im Beispiel eines Rennspiels kann die Partie eine Mehrspieler-Partie, eine Zwei-Spieler-Partie oder eine Einzelspieler-Partie gegen die Zeit oder gegen einen oder mehrere Computergegner sein. Wenn es sich um eine Doppel- oder Mehrspieler-Partie handelt, kann der Verbindungsparameter eine Ressource für das Spiel identifizieren, um sich mit den Gegnern oder Mitspielern zu synchronisieren. Der Verbindungsparameter kann zum Beispiel einen einheitlichen Ressourcenbezeichner eines Servers, eine Server-URI, enthalten.
Das Verfahren umfasst ferner das Ermitteln eines Ergebnisses der Partie. Zum Beispiel kann der Spieleentwickler eine Rückgabefunktion aufrufen, wenn ein Spiel beendet ist. Die Rückgabefunktion kann ein Teil eines Plugins sein, das der Spieleentwickler in das Spiel integriert. Alternativ oder zusätzlich kann das Spiel, wenn der Partieparametersatz eine Callback-Funktion enthält, die Callback-Funktion aufrufen, wenn das Spiel beendet ist. Daher kann die Ermittlung das Abrufen des Ergebnisses aus dem Spiel oder die Weitergabe des Ergebnisses durch das Spiel umfassen.
Das ermittelte Ergebnis einer Partie kann ein boolesches Ergebnis sein, z. B. eine Variable, die den Status „gewonnen“ oder „verloren“ annehmen kann. Das ermittelte Ergebnis einer Partie kann ein Satz von Ergebniswerten sein. Die Ergebniswerte können beispielsweise eines oder mehrere der folgenden Elemente umfassen: Spielergebnisse, gegnerische Ergebnisse, Spielzeit, Anzahl der Runden oder Läufe, Rundenzeiten, eine beste Rundenzeit, eine Punkthöchstzahl, verbleibende Spielfiguren, Spielgeld, Anzahl der Spielmarken, Foulspiel, Anzahl der Strafen, festgestellter Betrug und Ähnliches.
Das Verfahren umfasst auch das Steuern des Fernwettbewerbs. Mit anderen Worten: Der Betrieb und der Verlauf des Wettbewerbs werden gesteuert. Dazu können die hier beschriebenen Schritte für eine Anzahl von Spielern und Partien gleichzeitig und nacheinander ausgeführt werden. Beispielsweise kann eine Reihe von Partien so gesteuert werden, dass sie gleichzeitig stattfinden. Dadurch kann vermieden werden, dass eine Partie eine andere Partie beeinflusst.
Das Steuern kann beinhalten, dass nach den Partien eine Pause eingelegt wird und nach der Pause eine oder mehrere weitere Runden mit gleichzeitigen Partien eingeleitet werden. Alternativ oder zusätzlich kann das Steuern auch beinhalten, dass das Ende der letzten Partie abgewartet wird, bevor eine weitere Runde von Partien eingeleitet wird. Das Steuern kann zum Beispiel das Steuern eines Spiel-Servers beinhalten, um den Beginn von Partien zu verhindern oder den Beginn von Partien zu erzwingen.
Das Steuern kann die Auslosung von Spielern beinhalten, die zusammen oder gegeneinander in einer Partie spielen. Außerdem kann das Steuern beinhalten, dass ein Spieler auf der Grundlage der ermittelten Ergebnisse, auf der Grundlage des Zufalls oder sowohl auf der Grundlage der ermittelten Ergebnisse als auch des Zufalls eliminiert wird.
Verschiedene Ausführungsformen können vorzugsweise eine Kombination der folgenden Merkmale beinhalten.
In einer Ausführungsform umfasst das Verfahren ferner das Empfangen eines Wettbewerbsparametersatzes, und das Steuern umfasst das Erzeugen eines Partieparametersatzes für jedes einer Vielzahl von Partien gemäß dem Wettbewerbsparametersatz, und das Durchführen des Instruierens gemäß dem Partieparametersatz und dem Ermitteln für jede der Partien.
Gemäß dieser Ausführungsform umfasst das Verfahren den Empfang eines Wettbewerbsparametersatzes von einem Benutzer.
Der Wettbewerbsparametersatz kann eines oder mehrere der folgenden Elemente enthalten: einen Wettbewerbsmodus, Spieleridentitäten, Spieleranforderungen, Spielzeiten, Spielnummern, Wettbewerbsgröße, Wettbewerbsname und Wettbewerbsregeln. Der Wettbewerbsparametersatz kann außerdem Wettbewerbsstufen enthalten. Zum Beispiel kann jede von mehreren Wettbewerbsstufen einen oder mehrere separate Wettbewerbsmodi enthalten.
Ein Wettbewerbsmodus kann zum Beispiel eine Gruppenphase sein, in der Gruppen von Spielern so gebildet werden, dass jeder Spieler in einer Gruppe mindestens einmal gegen jeden anderen Spieler in der Gruppe spielt.
Ein weiteres Beispiel für einen Wettbewerbsmodus kann ein Einzelausscheidungsmodus sein, bei dem Spielerpaare so gebildet werden, dass jedes Paar eine Partie spielt und ein unterlegener Spieler des Paares aus dem Wettbewerb ausscheidet. Die verbleibenden Spieler werden für eine weitere Runde erneut gepaart.
Ein weiteres Beispiel für einen Wettbewerbsmodus kann ein Doppelausscheidungsmodus sein, bei dem Spielerpaare in einer Hauptrunde gebildet werden, so dass jedes Paar in der Hauptrunde ein Spiel spielt und ein unterlegener Spieler des Paares in eine Nebenrunde versetzt wird. Die verbleibenden Spieler in der Hauptrunde werden für eine weitere Runde wie zuvor erneut gepaart. Die Spieler in der Nebenrunde werden für eine weitere Runde gepaart, in der ein unterlegener Spieler aus dem Wettbewerb ausscheidet. Nach einer Reihe von Runden spielt ein einziger verbleibender Spieler aus der Hauptrunde ein Endspiel gegen einen einzigen verbleibenden Spieler aus der Nebenrunde. In einer Variante des Doppelausscheidungsmodus wird für den Fall, dass der einzige verbleibende Spieler aus der Hauptrunde im Endspiel gegen den einzigen verbleibenden Spieler aus der Nebenrunde unterliegt, ein weiteres Spiel zwischen den beiden Spielern ausgetragen.
Andere Beispiele für einen Wettbewerbsmodus können ein Schweizer-System-Modus, ein Round-Robin-Modus oder ein beliebiger Modus sein, der auf systematische Weise abgebildet werden kann.
Der Wettbewerbsparametersatz vom Benutzer wird empfangen. Dabei kann der Benutzer selbst ein Spieler sein. Alternativ kann der Benutzer ein unabhängiger Betreiber eines Wettbewerbs sein, zum Beispiel ein Sponsor eines Spiels oder ein Veranstalter. Der Wettbewerbsparametersatz kann in Form eines ausgefüllten Formulars empfangen werden, z.B. eine Anzahl von Auswahlen aus einem Dropdown-Menü. Alternativ oder zusätzlich kann der Wettbewerbsparametersatz in Form eines Pseudocodes empfangen werden, z. B. in einer Form ähnlich einer XML-Datei. Ein solcher Wettbewerbsparametersatz kann vom Benutzer auf der Grundlage einer Pseudocode-Syntax zusammengestellt werden. Alternativ kann ein solcher Wettbewerbsparametersatz vom Benutzer mit Hilfe eines Werkzeugs, z. B. einer grafischen Software, die es ermöglicht, visuelle Elemente zu kombinieren, die einen gewünschten Wettbewerbsparametersatz darstellen, erzeugt werden.
Gemäß dieser Ausführungsform umfasst das Steuern das Erzeugen eines Partieparametersatzes für jede einer Vielzahl von Partien gemäß dem Wettbewerbsparametersatz.
Gemäß dieser Ausführungsform umfasst das Steuern das Durchführen der Anweisung gemäß dem Partieparametersatz und dem Ermitteln für jede der Partien.
In einer Ausführungsform umfasst das Verfahren außerdem das Empfangen von Spielereingaben über das Frontend.
In einer Ausführungsform umfasst das Verfahren außerdem das Empfangen eines Überwachungssignals vom Spiel.
In einer Ausführungsform umfasst das Verfahren außerdem das Bereitstellen von Wettbewerbsbedienelementen über das Frontend.
Die vorliegende Offenbarung bezieht sich ferner auf ein Verfahren zur Steuerung eines Fernwettbewerbs eines Spiels, wobei das Verfahren das Anzeigen eines Frontends, das Einleiten einer Partie gemäß einem Partieparametersatz, das Zurückgeben eines Ergebnisses des Spiels und das Steuern des Fernwettbewerbs umfasst. Das Verfahren kann von einem Client-Gerät durchgeführt werden, zum Beispiel von einem Gerät, das von einem Spieler bedient wird.
Das Verfahren umfasst das Anzeigen eines Frontends innerhalb des Spiels.
Vorzugsweise wird das Frontend von einem Backend in Übereinstimmung mit der vorliegenden Offenbarung abgerufen.
Vorzugsweise wird das Frontend mit Hilfe von Webtechnologien abgerufen und angezeigt. Beispielsweise kann das Frontend über das Hypertext-Transfer-Protokoll (http) abgerufen und über eine Web-View-Komponente angezeigt werden, z. B. eine UlWebView-Komponente in einem Betriebssystem oder eine WebView-Komponente in einem anderen Betriebssystem. Dabei kann das Frontend in Hypertext Markup Language, html, und/oder einer ähnlichen Technologie, einschließlich JavaScript, beschrieben werden.
Wenn das Frontend mit Hilfe von Web-Technologien abgerufen wird, kann das Frontend leicht aktualisiert werden, ohne dass das Spiel aktualisiert werden muss. Daher kann der Spieler ein verbessertes Frontend genießen, ohne dass er ein Update, insbesondere ein Spiel-Update, herunterladen oder installieren muss. Außerdem kann der Spieler ein aktualisiertes Frontend genießen, ohne auf den Entwickler eines Spiels warten zu müssen und von ihm abhängig zu sein.
Das Verfahren umfasst ferner das Einleiten einer Partie gemäß einem Partieparametersatz. Das Verfahren kann das Spiel steuern, um das Spiel zu initiieren.
Vorzugsweise wird der Partieparametersatz aus einem Backend empfangen. Wenn der Partieparametersatz von einem Backend empfangen wird, kann eine Vielzahl von Partien innerhalb eines Wettbewerbs gesteuert werden, ohne sich auf das regelkonforme Verhalten eines Spielers zu verlassen. Die Partie kann zusätzlich zum Partieparametersatz nach weiteren Parametern, z. B. Grafikqualitätsparametern oder Schnittstellenparametern, eingeleitet werden. Mit anderen Worten, ein Partieparametersatz kann vom Backend empfangen werden, während weitere Parameter vom Spieler selbst definiert werden können.
Das Verfahren umfasst ferner das Zurückgeben eines Ergebnisses der Partie an das Backend. Das Ergebnis kann mit Hilfe von Webtechnologien an das Backend zurückgegeben werden, zum Beispiel mit einer POST-Anfrage in http.
Das Verfahren umfasst auch das Steuern des Fernwettbewerbs.
In einer Ausführungsform umfasst das Verfahren außerdem das Übertragen von Spielereingaben.
Vorzugsweise wird die Spielereingabe vom Frontend an ein Backend übertragen. Mit anderen Worten: die Spielereingabe wird am Frontend empfangen und an das Backend weitergeleitet.
Die Spielereingabe kann vor der Weitergabe an das Backend interpretiert, komprimiert und/oder kodiert werden.
In einer Ausführungsform umfasst das Verfahren außerdem das Signalisieren eines Überwachungssignals vom Spiel.
In einer Ausführungsform umfasst das Verfahren außerdem das Anzeigen von Wettbewerbsbedienelementen auf dem Frontend.
In einer Ausführungsform kann es sich bei dem Spiel um eine Anwendung zur Bereitstellung von Zufallsinformationen handeln, wie z.B. eine Streaming-Anwendung, eine Nachrichtenanwendung, eine Sportanwendung oder eine Glücksspielanwendung. In diesem Fall kann das Spiel als eine Seite-eins-Anwendung bezeichnet werden.
In diesem Fall wird das Frontend durch eine Seite-zwei-Anwendung, z. B. ein Plugin oder ein Modul, bereitgestellt. Die Seite-zwei-Anwendung ist so konfiguriert, dass sie Daten mit der Seite-eins-Anwendung und Daten mit einem Netzwerk, z.B. mit mindestens einem Teil des Internets, austauschen kann.
In dieser Ausführungsform kann das Verfahren das Bereitstellen von Partiebedienelementen im Frontend durch die zweite Anwendung umfassen. Die Partiebedienelemente können es einem Spieler ermöglichen, ein Spiel in der zweiten Anwendung zu initiieren, zum Beispiel ein Wettspiel. Mit anderen Worten, die Seite-zwei-Anwendung kann Bedienelemente für die Platzierung einer oder mehrerer Wetten durch den Spieler bereitstellen.
In dieser Ausführungsform kann zumindest ein Teil der Spiele, die von der ersten Anwendung ausgeführt werden, mit Spielen gemäß der Seite-zwei-Anwendung korrespondieren. Zum Beispiel kann die Seite-eins-Anwendung eine Roulette-Simulation durchführen. In diesem Beispiel kann die Seite-zwei-Anwendung das Platzieren von Wetten auf die Ergebnisse der Roulettesimulation ermöglichen. In einem anderen Beispiel kann die Seite-eins-Anwendung ein Video eines Tennisturniers übertragen. In diesem Beispiel kann die Seite-zwei-Anwendung das Platzieren von Wetten auf die Ergebnisse des Tennisturniers ermöglichen. In einem anderen Beispiel kann die Seite-eins-Anwendung ein Pseudo-Zufallsereignis wie ein Sportereignis, eine Auktion, ein Kunstevent, eine Produktpräsentation oder die Enthüllung einer geheimen Information anzeigen. In diesem Beispiel kann die Seite-zwei-Anwendung das Platzieren von Wetten auf den Ausgang des Pseudo-Zufallsereignisses ermöglichen.
In dieser Ausführungsform kann das Einleiten einer Partie das Einleiten einer Partie in der Seite-zwei-Anwendung und nicht in der Seite-eins-Anwendung umfassen. Insbesondere kann die Seite-eins-Anwendung überhaupt nicht durch das Verfahren gesteuert werden, z.B. wenn die Seite-eins-Anwendung eine Streaming-Anwendung zum Streamen eines Sportwettbewerbs ist. In diesem Fall bezieht sich das Steuern auf die Seite-zwei-Anwendung, d.h. für die Seite-zwei-Anwendung können Partien eingeleitet, Ergebnisse ermittelt und ein Wettbewerb gesteuert werden. Das Steuern der Seite-zwei-Anwendung kann in einer Weise erfolgen, die der Seite-eins-Anwendung entspricht. Zum Beispiel kann das Platzieren von Wetten den Partien gemäß der Seite-eins-Anwendung entsprechen. Beispielsweise kann die Ermittlung von Spielergebnissen in der Seite-zwei-Anwendung, z. B. Ergebnisse von Wetten in der Seite-zwei-Anwendung, den Ergebnissen von Spielen gemäß der Seite-eins-Anwendung entsprechen. So kann beispielsweise das Steuern von Partien in der Seite-zwei-Anwendung, z.B. das Steuern von Wetten in der Seite-zwei-Anwendung, gemäß Wettbewerbsparametern zu einer Abfolge von Partien gemäß der Seite-eins-Anwendung korrespondieren.
Die Seite-zwei-Anwendung kann die Kommunikation mit anderen Spielern entsprechend der Seite-eins-Anwendung ermöglichen. Beispielsweise kann die Seite-zwei-Anwendung so konfiguriert sein, dass ein Spieler, der ein Tennisspiel in der Seite-eins-Anwendung anschaut, mit einem anderen Spieler kommunizieren kann, der das gleiche Tennisspiel in der Seite-eins-Anwendung anschaut. Die Seite-zwei-Anwendung kann es einem Spieler ermöglichen, einzelne Partien zu initiieren, z.B. kann die Seite-zwei-Anwendung es einem Platzierer ermöglichen, eine einzelne Wette gegen einen virtuellen Buchmacher zu platzieren. Alternativ kann die Seite-zwei-Anwendung soziale Spiele ermöglichen, z.B. kann die Seite-zwei-Anwendung einem Spieler erlauben, eine Wette gegen oder mit einem anderen Spieler zu platzieren, der an demselben Spiel in der Seite-eins-Anwendung beteiligt ist.
Die vorliegende Offenbarung bezieht sich ferner auf ein Verfahren zur Übertragung eines Fernwettbewerbs eines Spiels, wobei das Verfahren das Erfassen einer Videoeinspeisung des Fernwettbewerbs in dem Spiel, das Speichern von Bildern oder Videoschnipseln auf der Grundlage der Videoeinspeisung, das Bereitstellen der Bilder oder Schnipsel an ein Frontend, das Abspielen einer aus den Bildern oder Videoschnipseln rekonstruierten Videoeinspeisung in dem Frontend, das Erzeugen eines Videostreams auf der Grundlage der rekonstruierten Videoeinspeisung in dem Frontend und das Übertragen des Videostreams umfasst.
Das Verfahren umfasst außerdem das Aufzeichnen eines Videos von dem Fernwettbewerb des Spiels.
Das Verfahren umfasst außerdem die Speicherung von Bildern oder Videoschnipseln auf der Grundlage der Videoübertragung.
Das Verfahren umfasst ferner das Bereitstellen der Bilder oder Schnipsel für ein Frontend. Vorzugsweise besteht das Frontend aus einer WebView-Instanz, wie z. B. einer UlWebView-Instanz in einem Betriebssystem oder einer WebView-Instanz in einem anderen Betriebssystem. Auf diese Weise können die Bilder oder Videoschnipsel weitergegeben werden, ohne dass ein Zugriff auf das Dateisystem auf der Ebene des Betriebssystems erforderlich ist.
Das Verfahren umfasst ferner das Wiedergeben eines aus den Bildern oder Videoschnipseln rekonstruierten Videofeeds im Frontend.
Das Verfahren umfasst ferner das Erzeugen eines Videostreams auf der Grundlage des rekonstruierten Videofeeds im Frontend.
Das Verfahren umfasst ferner die Übertragung des Videostreams.
In einer bevorzugten Ausführungsform wird das hier beschriebene Verfahren zur Übertragung eines Fernwettbewerbs mit dem hier beschriebenen Verfahren zur Steuerung eines Fernwettbewerbs kombiniert. Ein kombiniertes Verfahren zur Steuerung und Übertragung eines Fernwettbewerbs kann beispielsweise das Steuern eines Fernwettbewerbs einer Vielzahl von Client-Geräten durch ein Backend und das Übertragen eines Videostreams von jedem einer Teilmenge der Vielzahl von Client-Geräten an das Backend umfassen.
Die vorliegende Offenbarung bezieht sich ferner auf ein Programmprodukt für die Steuerung eines Fernwettbewerbs eines Spiels, das ein computerlesbares Medium und Programmanweisungen enthält, die auf dem Medium gespeichert sind und bei ihrer Ausführung die Steuerung des Computers bewirken, wobei die Programmanweisungen den Computer veranlassen, das Verfahren gemäß einer der hier beschriebenen Ausführungsformen oder einer Kombination davon durchzuführen.
Die vorliegende Offenbarung bezieht sich ferner auf eine Vorrichtung zur Steuerung eines Fernwettbewerbs eines Spiels, die in der Vorrichtung Computerdatenspeicherelemente, die ein Programm speichern, und eine CPU enthält, die mit den Speicherelementen in Verbindung steht. Die Speicherelemente und die CPU arbeiten bei der Ausführung des Programms so zusammen, dass die CPU unter der Steuerung des Programms das Verfahren gemäß einer der hier beschriebenen Ausführungsformen oder einer Kombination davon durchführt.
Die vorliegende Offenbarung bezieht sich ferner auf ein System zum Steuern eines Fernwettbewerbs eines Spiels, das mindestens ein hierin beschriebenes Gerät und ein Backend umfasst, das so konfiguriert ist, dass es das Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer der hierin beschriebenen Ausführungsformen oder einer Kombination davon durchführt. Das Backend kann eines oder mehrere der folgenden Elemente umfassen: Computer, insbesondere Server-Computer, Cloud-Computing-Instanzen, Computernetzwerke und verteilte Computersysteme.
In einer Ausführungsform des Systems ist das Backend ferner so konfiguriert, dass es einen Videostream von dem Gerät empfängt und den Videostream verteilt. Der Videostream kann von dem mindestens einen Gerät an das Backend übertragen werden. Der Videostream kann zum Beispiel ein Videostream sein, der eine Partie in einem Wettbewerb zeigt, der mit dem Backend betrieben wird. Das Backend kann den Videostream modifizieren. Beispielsweise kann das Backend ein Wasserzeichen in den Videostream einfügen, so dass der Videostream im Falle einer nicht autorisierten Weiterverbreitung identifiziert werden kann. Das Backend kann den Videostream über einen Rundfunkkanal, z. B. einen Fernsehkanal, verbreiten. Das Backend kann den Videostream individuell verteilen, z. B. über einen abonnementbasierten Streaming-Zugang.
Die vorliegende Offenbarung bietet einem Entwickler die Möglichkeit, eine Fernwettbewerbsfunktionalität einfach, schnell und mit geringen Ressourcen zu implementieren, um Wettkämpfe automatisch ohne manuelle Mitwirkung durchzuführen. Des Weiteren bietet die vorliegende Offenbarung einem Spieler die Möglichkeit, schnell und einfach an einem Fernwettbewerb teilzunehmen. Darüber hinaus bietet die vorliegende Offenbarung einem Benutzer die Möglichkeit, einen Wettbewerb auf einfache Weise zu organisieren, ohne dass der Spieleentwickler das Spiel ändern muss und ohne dass der Spieler Ergebnisse liefern oder weiteren Wettbewerbsregeln nachkommen muss.
Die Erfindung wird unter Bezugnahme auf die folgenden Figuren näher beschrieben:

ist ein Flussdiagramm eines Verfahrens zur Steuerung eines ferngesteuerten Wettbewerbs gemäß einer Ausführungsform,
ist ein Flussdiagramm eines Verfahrens zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform,
ist ein Blockdiagramm eines Programmprodukts für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform,
ist ein Blockdiagramm eines Programmprodukts für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform,
5 ist ein Blockdiagramm eines Programmprodukts für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform,
6 ist ein Flussdiagramm eines Verfahrens zur Übertragung eines Fernwettbewerbs gemäß einer Ausführungsform, und
ist ein Blockdiagramm einer beispielhaften Vorrichtung gemäß einer Ausführungsform.

1 ist ein Flussdiagramm eines Verfahrens 100 zur Steuerung eines Fernwettbewerbs gemäß einer Ausführungsform. Das Verfahren kann von einem Backend ausgeführt werden. Zum Beispiel kann das Verfahren 100 von einem Computerserver, einem Cloud-Dienst, einer verteilten Rechenressource oder einem Backend-Modul ausgeführt werden. Der Fernwettbewerb kann Teil eines Spiels sein, z. B. eines Computerspiels.
Das Verfahren umfasst einen ersten Schritt S110, in dem ein Wettbewerbsparametersatz 101 von einem Benutzer empfangen wird. Mit anderen Worten, der Wettbewerbsparametersatz 101 kann eine Eingabe für das Verfahren sein. Der Wettbewerbsparametersatz 101 kann zum Beispiel von einem Client, z. B. einem Client-Computer, einem Software-Client oder einem Client-Modul, bereitgestellt werden. In einigen Fällen kann der Schritt S110 entfallen. Zum Beispiel kann in einem Fall, in dem kein Wettbewerbsparametersatz 101 verfügbar ist oder der Wettbewerbsparametersatz 101 nicht bereitgestellt wird, Schritt S110 ausgelassen werden und das Verfahren kann mit einem Schritt S120 beginnen, in dem ein anzuzeigendes Frontend bereitgestellt wird.
Schritt S120 umfasst die Bereitstellung eines Frontends, das im Spiel angezeigt wird.
Vorzugsweise verwendet die Bereitstellung Webtechnologien. Zum Beispiel zeigt das Verfahren ein Frontend unter Verwendung einer Web-View-Komponente an, wie einer UIWebView-Komponente in einem Betriebssystem oder einer WebView-Komponente in einem anderen Betriebssystem. Die Details des anzuzeigenden Frontends, wie Design, Inhalt und Funktionalität, können unter Verwendung von Hypertext Markup Language, HTML, Cascading Style Sheets, CSS, JavaScript, JPEG und ähnlichen Webtechnologien kodiert werden. Das Frontend kann mit einem Webserver kommunizieren, z. B. mit Push- oder Pull-AJAX-Technologie. Darin können kodierte Details, die auf dem Frontend angezeigt werden sollen, mit Hilfe des Hypertext-Transfer-Protokolls (HTTP) von einem anderen Gerät oder einem Netzwerk gespeichert und/oder abgerufen werden. So kann beispielsweise ein Teil der Angaben auf einem Gerät, das das Verfahren ausführt, gespeichert oder zwischengespeichert werden, und ein anderer Teil der Angaben kann beispielsweise von einem Server abgerufen werden.
Durch die Verwendung einer Web-View-Komponente für die Anzeige eines Frontends kann das Verfahren auf sehr universelle Weise implementiert werden, z. B. durch ein universelles und leichtgewichtiges Plugin, das einfach und schnell in viele verschiedene Spiele integriert werden kann.
Das Verfahren fährt mit einem weiteren Schritt S121 fort, in dem eine Spielereingabe über das Frontend empfangen wird. Dieser Schritt kann optional oder obligatorisch sein. Die Spielereingabe kann zum Beispiel Spielpräferenzen, Mannschaftspräferenzen, ein „Spieler bereit“-Signal, ein
Das Verfahren fährt mit einem weiteren Schritt S130 fort, in dem das Spiel instruiert wird, eine Partie einzuleiten. Vorzugsweise leitet das Verfahren die Partie gemäß einem Partieparametersatz 102 ein, d. h. das Verfahren übergibt den Partieparametersatz 102 an das Spiel. Der Partieparametersatz 102 kann beispielsweise als eine Reihe von Parametern an das Spiel weitergegeben werden. Alternativ kann der Partieparametersatz als einzelne Zeichenkette an das Spiel weitergegeben werden, wobei mehrere Parameter in der Zeichenkette kodiert sind, z. B. unter Verwendung der JavaScript Object Notation (JSON). Der Partieparametersatz kann auch über eine Datenbank an das Spiel übergeben werden, z.B. durch Hinterlegung des Parametersatzes in einer Datenbank, auf die das Spiel zugreift.
Das Einleiten S130 kann mit weiteren Instanzen des Verfahrens synchronisiert werden. Beispielsweise kann das Verfahren auf ein Signal warten, bevor es ein Spiel S130 einleitet, so dass eine Reihe von Partien in einem Wettbewerb gleichzeitig oder nach einem vorgegebenen Zeitschema ausgelöst wird.
Das Verfahren fährt mit einem weiteren Schritt S135 fort, in dem ein Überwachungssignal vom Spiel empfangen wird. Das Überwachungssignal kann ein Signal enthalten, das anzeigt, dass die Partie noch läuft. Das Überwachungssignal kann ein Signal enthalten, das anzeigt, dass die Partieparameter nicht geändert wurden. Das Überwachungssignal kann ein Signal enthalten, das einen aktuellen Status der Partie anzeigt, wie z. B. einen aktuellen Punktwert, einen aktuellen Rennfortschritt, eine verstrichene Zeit, einen Gesundheitszustand, einen Standort oder eine Position und/oder eine aktuelle Geschwindigkeit. Der Punktwert kann sich beispielsweise auf Gesundheitspunkte, Trefferpunkte, die Anzahl der Tore, ein virtuelles Kontoguthaben oder Ähnliches beziehen. Das Überwachungssignal kann verwendet werden, um Manipulation oder Betrug zu erkennen und/oder zu verhindern. Beispielsweise kann das Überwachungssignal dazu verwendet werden, einen Punktwert zu verfolgen, um unmögliche oder unwahrscheinliche Werte, Änderungen, Änderungsraten oder Trajektorien zu identifizieren.
Das Überwachungssignal kann vom Spiel an das Frontend übermittelt werden, welches das Überwachungssignal an das Backend weitergibt. Auf diese Weise kann das Überwachungssignal in einem Plugin oder Modul implementiert werden, das schnell und einfach in jedes Spiel integriert werden kann. Alternativ kann das Überwachungssignal auch direkt vom Spiel an das Backend weitergegeben werden.
Das Verfahren fährt mit einem weiteren Schritt S140 zum Ermitteln eines Ergebnisses der Partie fort. Schritt S140 kann das Vergleichen oder Verarbeiten von Partiewerten beinhalten, um ein Ergebnis des Spiels zu ermitteln. Das Ermitteln S140 umfasst das Abrufen eines Ergebnisses oder von Partiewerten vom Client oder dem Spiel.
Vorzugsweise werden die Ergebnis- oder Partiewerte vom Client, d. h. von einem Plugin oder Modul, abgerufen. in diesem Fall kann das Verfahren in einem Plugin oder Modul implementiert werden, das einfach und schnell in ein Spiel implementiert werden kann.
Das Verfahren fährt mit einem weiteren Schritt S145 fort, in dem Wettbewerbsbedienelemente über das Frontend bereitgestellt werden. Die Wettbewerbsbedienelemente werden vom Backend bereitgestellt, um über das Frontend angezeigt zu werden. Zum Beispiel kann das Verfahren Wettbewerbsbedienelemente bereitstellen, um einem Team beizutreten oder es zu verlassen, eine Einstellung wie einen Schwierigkeitsgrad zu ändern oder ähnliches.
Das Verfahren wird mit einem weiteren Schritt S150 zum Steuern des Fernwettbewerbs fortgesetzt. Das Steuern S150 kann mit Hilfe der im vorherigen Schritt S145 bereitgestellten Wettbewerbsbedienelemente beeinflusst oder verändert werden.
Wenn das Verfahren den Empfang S110 eines Wettbewerbsparametersatzes 101 umfasst, kann das Steuern S150 auf dem Wettbewerbsparametersatz 101 basieren. Zum Beispiel kann der Wettbewerbsparametersatz 101 definieren, dass der Wettbewerb aus einer vorbestimmten Anzahl von Partien besteht. In diesem Fall kann das Steuern 5150 eine iterative Rückkehr zum Schritt S130 beinhalten, in dem das Spiel angewiesen wird, eine Partie einzuleiten, bis die vorbestimmte Anzahl von Partien beendet ist. In anderen Beispielen kann der Wettbewerb flexibler sein und das Steuern S150 kann auf den Ergebnissen eines oder mehrerer Partien basieren, auf der Interaktion der Spieler basieren und/oder ein Zufallselement enthalten.
Das Steuern S150 kann beinhalten, dass nach den Partien eine Pause eingelegt wird und nach der Pause eine oder mehrere weitere Runden mit gleichzeitigen Partien eingeleitet werden. Alternativ oder zusätzlich kann das Steuern beinhalten, dass ein Spieler das Ende der letzten Partie aller oder einer Teilmenge der Partien in einem Wettbewerb abwarten muss, bevor er eine weitere Spielrunde einleiten kann. Das Steuern S150 kann das Senden von Instruktionen, z. B. Pauseninstruktionen, an den einen oder die mehreren Clients umfassen. Die Instruktionen sollten vom Client empfangen und umgesetzt werden, z. B. von einem Plugin oder Modul, das ein Verfahren 200 gemäß 2 ausführt. Das Steuern S150 kann auch das Senden von Instruktionen an einen Spielserver umfassen, z. B. Pauseninstruktionen, die den Spielserver sperren und somit verhindern können, dass Clients irgendwelche Partien spielen.
Das Steuern S150 kann die Auslosung von Spielern beinhalten, die zusammen oder gegeneinander in einer Partie spielen. Darüber hinaus kann das Steuern das Ausscheiden eines Spielers auf der Grundlage der ermittelten Ergebnisse, auf der Grundlage des Zufalls oder sowohl auf der Grundlage der ermittelten Ergebnisse als auch des Zufalls umfassen.
In der vorliegenden Ausführungsform umfasst das Steuern S150 einen Teilschritt S155, in dem ein Partieparametersatz für jede einer Vielzahl von Partien gemäß dem Wettbewerbsparametersatz 101 erzeugt wird. In diesem Fall kehrt das Verfahren zu dem Schritt S130 zurück, in dem das Spiel instruiert wird, eine Partie entsprechend dem jeweiligen Partieparametersatz für jede die mehreren Partien einzuleiten. In diesem Fall basiert das Steuern S150 zumindest auf den Ergebnissen der Vielzahl von Partien.
ist ein Flussdiagramm eines Verfahrens zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform. Das Verfahren kann von einem Client ausgeführt werden. Beispielsweise kann das Verfahren 200 von einem Client-Gerät wie einem Mobiltelefon, einem Tablet, einem Notebook, einer Spielkonsole, einem Personal Computer oder einem Cloud-Gaming-Gerät ausgeführt werden. Insbesondere kann das Verfahren durch ein Plugin oder ein Modul implementiert werden, das in ein Spiel integriert werden kann. Alternativ kann das Verfahren mit Hilfe eines Frameworks, einer Sandbox, einer Virtualisierungsumgebung oder eines Moduls implementiert werden, das zumindest teilweise die Kontrolle über ein Spiel haben kann. Der Fernwettbewerb kann Teil eines Spiels sein, z. B. eines Computerspiels.
Das Verfahren umfasst einen ersten Schritt S220, in dem ein Frontend innerhalb des Spiels angezeigt wird. Das Frontend kann mit Hilfe von Web-Technologien angezeigt werden, zum Beispiel wie zuvor bei Schritt S120 in 1 beschrieben. Vorzugsweise wird das Frontend zumindest teilweise aus einem Backend abgerufen, beispielsweise wie zuvor bei Schritt S120 in 1 beschrieben. Dies ist besonders einfach und effektiv, wenn das Frontend über Webtechnologien dargestellt wird.
Das Verfahren fährt mit einem weiteren Schritt S221 des Übermittelns von Spielereingaben fort. Insbesondere kann das Verfahren das Übertragen der Spielereingabe S221 vom Frontend zum Backend beinhalten.
Das Verfahren fährt mit einem weiteren Schritt S230 fort, in dem ein Abgleich gemäß einem Partieparametersatz 102 eingeleitet wird. Der Partieparametersatz 102 kann vom Backend empfangen werden, zum Beispiel wie zuvor bei Schritt S150 in beschrieben.
Das Verfahren fährt mit einem weiteren Schritt S235 fort, in dem ein Überwachungssignal vom Spiel signalisiert wird.
Das Verfahren fährt mit einem weiteren Schritt S240 fort, in dem ein Ergebnis der Partie an das Backend zurückgegeben wird. Das Ergebnis kann auf der Grundlage von Partiewerten berechnet werden, z. B. Trefferpunkte, Gesundheitspunkte, Anzahl der Ziele, Rundenzeiten oder Ähnliches. Alternativ kann das Ergebnis selbst Trefferpunkte, Gesundheitspunkte, Anzahl der Ziele, Rundenzeiten oder Ähnliches enthalten. Das Ergebnis oder die Partiewerte können vom Spiel bereitgestellt werden. In diesem Fall umfasst das Verfahren das Abrufen des Ergebnisses oder der Partiewerte aus dem Spiel. Alternativ kann das Verfahren das Ergebnis oder die Partiewerte auch unabhängig von dem Spiel ermitteln, z. B. durch Messen der Zeit bis zum Ende der Partie.
Die Ergebnis- oder Partiewerte können dem Client vom Spiel über eine Callback-Funktion zur Verfügung gestellt werden. In diesem Fall hat das Spiel die volle Kontrolle darüber, welche Parameter es für die Ergebnis- oder Partiewerte bereitstellt. Auf diese Weise kann das Verfahren in einem Plugin oder einem Modul implementiert werden, das sehr einfach und schnell in viele Spiele integriert werden kann. Alternativ oder zusätzlich kann das Verfahren die Beobachtung der Ergebnis- oder Übereinstimmungswerte indirekt beinhalten, z.B. durch Abgreifen eines Anzeigeinhalts des Spiels. In diesem Fall kann eine optische Zeichenerkennung (OCR) an einem abgerufenen Screenshot oder Screencast durchgeführt werden, um ein Ergebnis oder Übereinstimmungswerte zu identifizieren. Auf diese Weise kann die Übergabe der Ergebnisse schwieriger zu manipulieren sein, oder das Verfahren kann die Ergebnisse anhand von mindestens zwei Quellen doppelt überprüfen.
Ein Teil der Partiewerte kann während der Partie gesammelt werden, so dass eine Trajektorie der Partiewerte erstellt werden kann. Auf diese Weise kann eine Plausibilitätsprüfung der Partiewerte erfolgen. Auf diese Weise kann Betrug erkannt und/oder verhindert werden.
Das Verfahren fährt mit einem weiteren Schritt S245 fort, in dem Wettbewerbsbedienelemente auf dem Frontend angezeigt werden. Die Wettbewerbsbedienelemente rufen Eingaben des Spielers ab, die an das Backend weitergeleitet werden. Darüber hinaus können die Eingaben des Spielers von dem Client, der das Frontend ausführt, verarbeitet und/oder zur Änderung des Spiels verwendet werden. Zum Beispiel kann das Verfahren Wettbewerbsbedienelemente bereitstellen, um einem Team beizutreten oder es zu verlassen, eine Präferenz wie einen Schwierigkeitsgrad zu ändern oder ähnliches.
Das Verfahren fährt mit einem weiteren Schritt S250 zum Steuern des Fernwettbewerbs fort. Schritt S250 kann das Empfangen von Anweisungen aus dem Backend beinhalten. Alternativ oder zusätzlich kann das Steuern S250 gemäß den Wettbewerbsparametern 101 durchgeführt werden, zum Beispiel gemäß einem durch die Wettbewerbsparameter 101 angegebenen Wettbewerbsmodus.
Das Steuern S250 kann beinhalten, dass nach einer Partie eine Pause eingelegt wird und nach der Pause eine oder mehrere weitere Runden mit gleichzeitigen Spielen eingeleitet werden, zum Beispiel entsprechend den Wettbewerbsparametern 101 oder zum Beispiel entsprechend den Instruktionen aus dem Backend. Alternativ oder zusätzlich kann die Steuerung auch beinhalten, dass das Ende der letzten Partie abgewartet wird, bevor eine weitere Runde von Partien eingeleitet wird.
Das Steuern S250 kann das Verbinden von Spielern beinhalten, um miteinander oder gegeneinander in einer Partie zu spielen, zum Beispiel gemäß den Instruktionen, die das Backend bei dem Steuern S150 des Fernwettbewerbs senden kann. Darüber hinaus kann das Steuern S250 das Eliminieren eines Spielers auf der Grundlage der ermittelten Ergebnisse, des Zufalls, der Wettbewerbsparameter, der Spielereingaben und/oder der Anweisungen des Backends umfassen.
3 ist ein Blockdiagramm eines Programmprodukts für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform.
Das Blockdiagramm zeigt die Struktur eines Programmprodukts 10, das als Plugin 10 bezeichnet werden kann, für eine Spiel-Engine 11. Das Programmprodukt 10 kann so konfiguriert sein, dass es das Verfahren 200 gemäß 2 ausführt. Die Spiel-Engine 11 kann zum Beispiel eine Unity-Spiel-Engine sein. Mit Hilfe des Plugins 10 kann die Funktionalität des Verfahrens 200 einfach und schnell in jedes Spiel integriert werden, das auf der Spiel-Engine 11 basiert.
Die Abbildung zeigt die Spiel-Engine 11, die über eine gemeinsame Schnittstelle 12 mit dem Plugin 10 verbunden ist. Auf diese Weise kann eine einzige Schnittstelle zwischen dem Plugin 10 und der Spiel-Engine 11 ausreichen, selbst wenn das Plugin 10 alternative Komponenten enthalten muss, zum Beispiel für verschiedene Betriebssysteme, die von der Spiel-Engine 11 unterstützt werden. Ein erstes Betriebssystem kann beispielsweise ein Android-Betriebssystem und ein zweites Betriebssystem ein iOS-Betriebssystem sein.
Die gemeinsame Schnittstelle 12 der Spielmaschine kommuniziert mit einer ersten Komponente 13 für ein erstes Betriebssystem. Eine erste Komponente 13 kann spezifische Wrapper, Typen und Klassen enthalten, die zur Implementierung der Funktionalität gemäß Verfahren 200 in Kombination mit einem ersten Betriebssystem verwendet werden. Die erste Komponente 13 kommuniziert mit der gemeinsamen Spiel-Engine-Schnittstelle 12, um die Kommunikation zwischen dem Spiel, das auf der Spiel-Engine 11 basiert, und dem Plugin 10 zu erleichtern.
Die erste Komponente 13 umfasst einen ersten Editor 14, der Software-Abhängigkeiten verwaltet und die Hardware-Beschleunigung für eine Web-View-Komponente verwaltet. Der erste Editor 14 kann eine .xml-Datei (Extensible Markup Language) zur Verwaltung von Abhängigkeiten und/oder eine C#-Datei zur Verwaltung der Hardwarebeschleunigung für die Web-View-Komponente enthalten.
Darüber hinaus enthält die erste Komponente 13 ein App-Lifecycle-Element 15, das Aufrufe an ein erstes natives Plugin 20 verwaltet. Das App-Lifecycle-Element 15 kann eine Android-Archivbibliothek, eine .aar-Datei, sein. Das erste native Plugin 20 enthält eine ausführbare Binärdatei, die mit dem ersten Betriebssystem kompatibel ist und so konfiguriert ist, dass sie die Funktionalität gemäß dem Verfahren 200 bereitstellt. Eine Struktur des ersten nativen Plugins 20 gemäß einer Ausführungsform ist in 4 dargestellt.
Die gemeinsame Schnittstelle 12 der Spielmaschine kommuniziert mit einer zweiten Komponente 16 für ein zweites Betriebssystem. Eine zweite Komponente 16 kann spezifische Wrapper, Typen und Klassen enthalten, die zur Implementierung der Funktionalität gemäß Verfahren 200 in Kombination mit einem zweiten Betriebssystem verwendet werden. Die zweite Komponente 16 kommuniziert mit der gemeinsamen Spiel-Engine-Schnittstelle 12, um die Kommunikation zwischen dem Spiel, das auf der Spiel-Engine 11 basiert, und dem Plugin 10 zu erleichtern.
Die zweite Komponente 16 umfasst einen zweiten Editor 17, der eine Nachbearbeitung des Softwareprojekts gemäß der zweiten Komponente 16 verwaltet, z. B. die Nachbearbeitung eines Xcode-Projekts zur korrekten Kompilierung von Swift-Code. Der zweite Editor 17 kann eine C#-Datei zur Verwaltung des Postprocessings enthalten.
Weiterhin enthält die zweite Komponente 16 ein Dummy-Element 18, das die Entwicklungsumgebung, zum Beispiel den Xcode-Compiler, dazu zwingt, Objective-C / Swift Cross-Header zu generieren. Auf diese Weise wird eine Funktionalität der hybriden Struktur des Plugins 10 beibehalten, wobei Code für verschiedene Betriebssysteme kombiniert wird.
Außerdem enthält die zweite Komponente 16 ein Lebenszykluselement 19, das Aufrufe an ein zweites natives Plugin 30 verwaltet. Das App-Lebenszykluselement 19 kann eine Objective-C++-Quelldatei, eine . mm-Datei sein. Das zweite native Plugin 30 umfasst eine ausführbare Binärdatei, die mit dem zweiten Betriebssystem kompatibel ist und so konfiguriert ist, dass sie die Funktionalität gemäß dem Verfahren 200 bereitstellt. Eine Struktur des zweiten nativen Plugins 30 gemäß einer Ausführungsform ist in 5 dargestellt.
Durch die Verwendung einer solchen Struktur ist das Plugin 10 sehr flexibel und kann einfach und schnell in ein Multiplattform-Spiel integriert werden, das auf einer beliebten Spiel-Engine basiert. Daher ist es für einen Spieleentwickler sehr einfach und effizient, ein Spiel mit Fernwettbewerbsfunktionalität zu erstellen. Außerdem ist ein Plugin mit einer solchen Struktur sehr wartungsfreundlich und flexibel, so dass das Plugin kostengünstig und schnell auf dem neuesten Stand gehalten werden kann.
kann auch eine Struktur einer Seite-zwei-Anwendung 10 wie zuvor beschrieben zeigen.
4 ist ein Blockdiagramm eines Programmprodukts 20 für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform. Insbesondere zeigt 4 ein Beispiel für ein erstes natives Plugin 20 wie in 3 gezeigt.
Das erste native Plugin 20 umfasst ein erstes Schaltflächenelement 21, mit dem ein Spieler ein Frontend innerhalb des Spiels aktivieren kann. Das Frontend wird durch ein Web-View-Element 22 bereitgestellt, das eine vom Betriebssystem bereitgestellte Web-View-Funktionalität nutzt. Sowohl das erste Schaltflächenelement 21 als auch das Webansichtselement 22 können implizit für eine Ansicht innerhalb einer beliebigen bevorzugten Aktivität im Spiel registriert werden. Das erste native Plugin 20 umfasst ferner ein Publish-Subscribe-Element 23, das als Nachrichtenvermittler für ein System von Ereignisproduzenten und -konsumenten, den sogenannten Publishern und Subscribern, fungieren kann.
Das erste Schaltflächenelement 21 kann das Publish-Subscribe-Element 23 in einer Nachricht 24 informieren, wenn die Position der Schaltfläche geändert wurde, z. B. aufgrund einer Spielerinteraktion. Das Publish-Subscribe-Element 23 kann das erste Schaltflächenelement 21 in einer Nachricht 25 informieren, wenn die Schaltfläche an den oberen Rand einer Ansicht verschoben werden soll.
Das Web-View-Element 22 kann das Publish-Subscribe-Element 23 in einer Nachricht 26 informieren, wenn die Web-View geschlossen wurde. Das Publish-Subscribe-Element 23 kann dem Web-View-Element 22 in einer Nachricht 27 mitteilen, wann es das Frontend aufrufen soll.
Das Publish-Subscribe-Element 23 integriert die Oberflächenelemente 21 und 22 mit einem Dienstelement 28. Das Dienstelement 28 kann in einer anderen Aktivität registriert sein als die Aktivität, in der das erste Schaltflächenelement 21 und das Webansichtselement 22 registriert sind.
Das Dienstelement 28 stellt außerdem die Kommunikation mit einer ersten Netzwerkschicht 29 sicher, welche verschiedene Methoden zum Austausch von Daten mit einem Netzwerk, insbesondere mit mindestens einem Teil des Internets, implementiert. Die erste Netzwerkschicht 29 kann z. B. Retrofit-Elemente, OkHttp-Elemente und Kotlin-Coroutinen enthalten.
Durch diese Struktur bietet das erste native Plugin 20 ein sehr flexibles Frontend, das genau dort präsent ist, wo und wann ein Spieler es nutzen kann, und sich nahtlos in das Spiel integriert. Gleichzeitig wird eine prompte und flüssige Nachrichtenübermittlung und Kommunikation erreicht.
5 ist ein Blockdiagramm eines Programmprodukts 30 für ein Verfahren zur Steuerung eines Fernwettbewerbs gemäß einer weiteren Ausführungsform. Insbesondere zeigt 5 ein Beispiel für ein zweites natives Plugin 30 wie in 3 gezeigt.
Das zweite native Plugin 30 umfasst einen Ansichtskontroller 31, der ein zweites Schaltflächenelement 32 und ein WebView-Element 33 enthält. Das WebView-Element 33 stellt eine Verbindung zu einer Web-View-Funktionalität eines Betriebssystems her, ähnlich wie das in 4 gezeigte Web-View-Element 22. Der Ansichtskontroller 31 verwaltet das zweite Schaltflächenelement 32, über das ein Spieler bei der Interaktion mit dem Spiel jederzeit auf das Frontend zugreifen kann, und das WebView-Element 33, das zum Anzeigen des Frontends konfiguriert ist.
Darüber hinaus kann das zweite native Plugin 30 die im WebView-Element 33 abgerufenen Spielerinteraktionsmeldungen 34 an ein Ansichtsmodellelement 35 senden. Das Ansichtsmodellelement 35 kann Datenauswirkungsmeldungen 36 an einen Speicher für beobachtbare Werte 37 senden. Der Speicher für beobachtbare Werte 37 kann seinerseits Ul-Benachrichtigungen 38 an den Ansichtskontroller 31 senden.
Das Ansichtsmodellelement 35 kann auf der Grundlage eines Datenaustauschs mit einer zweiten Netzwerkschicht 40, die Daten aus einem Netzwerk, insbesondere aus mindestens einem Teil des Internets, an das zweite native Plugin 30 weiterleitet, Datenimpulsnachrichten 36 senden.
Das Ansichtsmodellelement 35 und der Ansichtskontroller 31 tauschen Daten mit einem Service-Wrapper-Element 39 aus. Das Service-Wrapper-Element 39 stellt Methoden für den Client zur Verfügung und gibt ein ViewController-Element zurück, das in der Abbildung nicht dargestellt ist. Das ViewController-Element kann vom Client dem Ansichtskontroller 31 als untergeordneter View-Controller hinzugefügt werden.
ist ein Flussdiagramm eines Verfahrens 300 zur Übertragung eines Fernwettbewerbs gemäß einer Ausführungsform. Das Verfahren kann in einem Plugin implementiert werden, z.B. einem Fernwettbewerbs-Plugin 10 in einem Spiel. Das Verfahren kann auf einem Client-Gerät ausgeführt werden, z.B. einem Mobiltelefon, Tablet, Notebook, einer Spielkonsole, einem PC oder einem Cloud-Gaming-Gerät.
Das Verfahren umfasst einen ersten Schritt S310, bei dem ein Video-Feed des Fernwettbewerbs im Spiel erfasst wird. Die meisten Betriebssysteme bieten zumindest eine Methode zur Erfassung eines Videofeeds des Bildschirminhalts. Es ist jedoch keine Möglichkeit bekannt, diesen Video-Feed aus der Anwendung zu extrahieren.
Das Verfahren fährt mit einem weiteren Schritt S320 fort, in dem eines der Bilder oder Videoschnipsel auf der Grundlage des Videofeeds gespeichert wird. Der Video-Feed wird in Einzelbilder oder kurze Videoschnipsel mit einer Länge zwischen 0,5 s und 4 s, vorzugsweise zwischen 1 s und 3 s, noch bevorzugter zwischen 1,5 s und 2,5 s zerlegt.
Das Verfahren fährt mit einem weiteren Schritt S330 fort, in dem die Bilder oder Schnipsel an ein Frontend geliefert werden. Vorzugsweise ist das Frontend ein Web-View-Element 22, 33. In diesem Fall können die Privilegien des Web-View-Elements 22, 33 bei der Interaktion mit dem Spiel ausgenutzt werden. Daher können die Bilder oder Schnipsel auch auf gesperrten Betriebssystemen, die den anwendungsübergreifenden Datenaustausch stark einschränken, aus der Spielanwendung extrahiert werden.
Das Verfahren fährt mit einem weiteren Schritt S340 fort, in dem ein aus den Bildern oder Videoschnipseln rekonstruierter Video-Feed im Frontend abgespielt wird. In einer bevorzugten Ausführungsform wird der Video-Feed in einer Web-View-Instanz abgespielt, die für den Player unsichtbar ist.
Wenn dem Frontend Bilder zur Verfügung gestellt werden, kann der Video-Feed rekonstruiert werden, indem ein Bild in der Webansicht regelmäßig durch ein aktuelleres Bild ersetzt wird, z. B. fünfundzwanzig Mal pro Sekunde.
Wenn dem Frontend Videoschnipsel zur Verfügung gestellt wurden, kann der Video-Feed rekonstruiert werden, indem ein Videoschnipsel in der Web-View-Instanz regelmäßig durch einen neueren Videoschnipsel ersetzt wird, sobald der Videoschnipsel abgespielt wurde.
Die Videoübertragung wird gegenüber der Spielanzeige leicht verzögert, damit Bilder oder Videoschnipsel zwischengespeichert werden können. Auf diese Weise werden Ruckeln und Videounterbrechungen vermieden.
Das Verfahren fährt mit einem weiteren Schritt S350 fort, in dem ein Videostream auf der Grundlage des rekonstruierten Videofeeds im Frontend erzeugt wird. Die Web-View-Elemente 22, 33 bieten Methoden zur Erzeugung eines Videostreams auf der Grundlage des im Web-View-Element 22, 33 angezeigten Inhalts. Dadurch kann die auf die Web-View-Elemente 22, 33 angewendete Ausnahme genutzt werden, um einen Video-Feed aus einer Spieleanwendung zu extrahieren, was sonst nicht möglich wäre.
Das Verfahren fährt mit einem weiteren Schritt S360 fort, in dem der Videostream übertragen wird. Der in der Webansicht 22, 33 erzeugte Videostream kann an eine beliebige Internetressource übertragen werden. Vorzugsweise wird der Videostream über eine verschlüsselte Verbindung an einen Broadcasting-Server übertragen. Auf diese Weise kann der Videostream exklusiv gehalten und kontrolliert ausgestrahlt werden. Auf diese Weise kann der Videostream aus dem Spiel eine Ressource für z. B. einen entfernten Wettbewerbsanbieter sein.
ist ein Blockdiagramm einer beispielhaften Vorrichtung 70 gemäß einer Ausführungsform. Bei der Vorrichtung 70 kann es sich um ein Client-Gerät handeln, wie z. B. ein Mobiltelefon, ein Tablet, ein Notebook, eine Spielkonsole, einen Personal Computer oder ein Cloud-Gaming-Gerät. Die Vorrichtung 70 kann auch ein Backend-Gerät sein, z. B. ein Server-Computer, ein Cloud-Service-Gerät, ein Backend-Netzwerkgerät oder ein Backend-Modul. Die Vorrichtung 70 umfasst einen Speicher 71, eine Kommunikationsschnittstelle 72 und einen Prozessor 73.
Die Vorrichtung 70 kann so konfiguriert sein, dass sie ein Programmprodukt für ein Backend ausführt, wie oben in Bezug auf 1 beschrieben. Alternativ oder zusätzlich kann die Vorrichtung 70 so konfiguriert sein, dass sie ein Programmprodukt für einen Client ausführt, wie oben in Bezug auf die 2-5 beschrieben. Alternativ oder zusätzlich kann die Vorrichtung 70 so konfiguriert sein, dass sie ein Programmprodukt für eine Videostreaming-Funktion ausführt, wie oben in Bezug auf 6 beschrieben. Das Programmprodukt kann jeweils auf dem Speicher 71 gespeichert sein. Das Programmprodukt kann von dem Prozessor 73 ausgeführt werden.
Bei der Kommunikationsschnittstelle 72 kann es sich um eine Schnittstelle handeln, die mit einem Netzwerk verbunden ist und Befehle, Wettbewerbsparametersätze 101, Partieparametersätze 102 und Videoströme sendet und empfängt.
Wenn die Vorrichtung 70 als Backend-Gerät konfiguriert ist, kann die Kommunikationsschnittstelle 72 Partiewerte empfangen, die von dem einen oder den mehreren Clients erhalten wurden. Wie in 7 gezeigt, ist der Speicher 71 mit der Kommunikationsschnittstelle 72 gekoppelt und speichert z.B. die Partiewerte, die Wettbewerbsparametersätze 101, die Partieparametersätze 102, die Ergebnisse und die von der Kommunikationsschnittstelle 72 empfangenen Anweisungen. Der Speicher 71 kann einen oder mehrere verschiedene Speichertypen umfassen, wie z. B. Festplattenspeicher, nichtflüchtigen Speicher und flüchtigen Speicher, wie z. B. dynamischen Direktzugriffsspeicher, DRAM. In einigen Ausführungsformen speichert der Speicher 71 Statistiken über den Wettbewerb. Der Speicher 71 kann auch einen Videostream von einem oder mehreren Spielen speichern.
Wie in 7 gezeigt, kann der Prozessor 73 mit der Kommunikationsschnittstelle 72 und dem Speicher 71 verbunden sein. Der Prozessor 73 kann ein Mikroprozessor, ein Mikrocontroller, ein digitaler Signalprozessor oder eine zentrale Verarbeitungseinheit sein. Der Begriff Prozessor kann sich auf ein Gerät mit zwei oder mehr Verarbeitungseinheiten oder -elementen beziehen, z. B. eine CPU mit mehreren Rechenkernen. Der Prozessor 73 kann verwendet werden, um den Betrieb der Vorrichtung 70 durch die Ausführung von Softwareanweisungen oder Code zu steuern, die im Speicher 71 gespeichert sind. In einigen Ausführungsformen kann der Prozessor 73 die Schritte der in den 1, 2 und 6 beschriebenen Verfahren ausführen. Wenn der Prozessor 73 angewiesen wird, Informationen von einem anderen Gerät abzurufen oder Informationen an ein anderes Gerät zu übertragen, kann der Prozessor 73 der Kommunikationsschnittstelle 72 signalisieren, die Informationen abzurufen oder zu übertragen.
Gemäß der vorliegenden Offenbarung wird ein Verfahren bereitgestellt, das es einem Entwickler ermöglicht, eine Fernwettbewerbsfunktionalität einfach, schnell und mit geringen Ressourcen zu implementieren, um Wettbewerbe automatisch ohne manuelle Mitwirkung durchzuführen. Ferner wird ein Verfahren bereitgestellt, das es einem Spieler ermöglicht, schnell und einfach an einem Fernwettbewerb teilzunehmen. Ferner wird ein Verfahren bereitgestellt, die es einem Benutzer ermöglicht, einen Wettbewerb einfach zu organisieren, ohne dass der Spieleentwickler das Spiel modifizieren muss und ohne dass der Spieler Ergebnisse liefern oder weiteren Wettbewerbsregeln nachkommen muss.
Weitere Aspekte, Merkmale und Vorteile ergeben sich aus der obigen Zusammenfassung sowie aus der nachfolgenden Beschreibung, einschließlich der Figuren und der Ansprüche.
Obwohl die Erfindung in den Zeichnungen und der vorstehenden Beschreibung detailliert dargestellt und beschrieben ist, sind diese Darstellungen und Beschreibungen als illustrativ oder beispielhaft und nicht als einschränkend anzusehen. Es versteht sich, dass Änderungen und Modifikationen von Fachleuten im Rahmen der folgenden Ansprüche vorgenommen werden können. Insbesondere umfasst die vorliegende Erfindung weitere Ausführungsformen mit einer beliebigen Kombination von Merkmalen aus verschiedenen Ausführungsformen, die oben und unten beschrieben sind.
Außerdem schließt das Wort „umfassend“ in den Ansprüchen andere Elemente oder Schritte nicht aus, und der unbestimmte Artikel „ein“ oder „eine“ schließt eine Mehrzahl nicht aus. Eine einzige Einheit kann die Funktionen mehrerer in den Ansprüchen aufgeführter Merkmale erfüllen. Die Begriffe „im Wesentlichen“, „etwa“, „ungefähr“ und dergleichen in Verbindung mit einem Merkmal oder einem Wert definieren insbesondere auch genau das Merkmal bzw. genau den Wert. Etwaige Bezugszeichen in den Ansprüchen sind nicht als Einschränkung des Anwendungsbereichs zu verstehen.
Bezugszeichenliste

10: Programm Produkt, Plugin, Seite-zwei-Anwendung
11: Spiel-Engine, Seite-eins-Anwendung
12: gemeinsame Schnittstelle für die Spiel-Engine
13: erste Komponente
14: erster Herausgeber
15: Element des Anwendungslebenszyklus
16: zweite Komponente
17: zweiter Redakteur
18: Dummy-Element
19: Element des Anwendungslebenszyklus
20: erstes natives Plugin
21: erstes Schaltflächenelement
22: Web-View-Element
23: Publish-Subscribe-Element
24: Nachricht
25: Nachricht
26: Nachricht
27: Nachricht
28: Dienstleistungselement
29: erste Netzwerkschicht
30: zweites natives Plugin
31: Ansichtssteuerung
32: zweites Tastenelement
33: WebView-Element
34: Meldungen zur Spielerinteraktion
35: Ansicht Modellelement
36: Daten Auswirkungen Nachrichten
37: Merkmalswertspeicher
38: Ul-Benachrichtigungen
39: Dienst-Verschalungselement
40: zweite Netzwerkschicht
70: Gerät
71: Lagerung
72: Kommunikationsschnittstelle
73: Prozessor
100: Verfahren
101: Wettbewerbsparametersatz
102: Partieparametersatz
S110: Empfangsschritt
S120: Bereitstellung einer Stufe
5121: Empfangsschritt
S130: Instruktionsschritt
S135: Empfangsschritt
S140: entscheidender Schritt
S145: Bereitstellungsschritt
S150: Kontrollstufe
S155: Erzeugungsschritt
200: Verfahren
5220: Anzeigeschritt
S221: Übermittlungsschritt
S230: Einleitungsschritt
S235: Signalisierungsschritt
S240: zurückkehrende Stufe
S245: Anzeigeschritt
S250: Kontrollstufe
300: Verfahren
S310: Aufnahmeschritt
5320: Speicherstufe
S330: Bereitstellung einer Stufe
S340: Spielstufe
S350: Erzeugungsstufe
S360: Sendestufe

Claims

Verfahren zur Steuerung eines Fernwettbewerbs eines Spiels, wobei das Verfahren umfasst: Bereitstellen (S012) eines anzuzeigenden Frontends; Instruieren (S013) des Spiels, eine Partie einzuleiten; Ermitteln (S014) eines Ergebnisses der Partie; und Steuern (S150) des Fernwettbewerbs.
Verfahren nach Anspruch 1, das ferner umfasst: Empfangen (S101) eines Wettbewerbsparametersatzes (101); wobei das Steuern (S501) das Erzeugen (S551) eines Partieparametersatzes (102) für jede einer Vielzahl von Partien gemäß dem Wettbewerbsparametersatz (101) und das Durchführen des Instruierens (S301) gemäß dem Partieparametersatz (102) und das Ermitteln (S401) für jede der Partien umfasst.
Verfahren nach einem der Ansprüche 1 oder 2, das außerdem umfasst: Empfangen (S211) von Spielereingaben über das Frontend.
Verfahren nach einem der Ansprüche 1 bis 3, das außerdem umfasst: Empfangen (S351) eines Überwachungssignals von dem Spiel.
Verfahren nach einem der Ansprüche 1 bis 4, einschließlich: Bereitstellen (S451) von Wettbewerbsbedienelementen über das Frontend.
Verfahren zur Steuerung eines Fernwettbewerbs eines Spiels, wobei das Verfahren umfasst: Anzeigen (S202) eines Frontends; Initiieren (S302) einer Partie gemäß einem Partieparametersatz (102); Zurückgeben (S402) eines Ergebnisses der Partie; und Steuern (S502) des Fernwettbewerbs.
Verfahren nach Anspruch 6, ferner umfassend ein Übermitteln (S212) von Spielereingaben.
Verfahren nach einem der Ansprüche 6 oder 7, das außerdem ein Signalisieren (S352) eines Überwachungssignals vom Spiel umfasst.
Verfahren nach einem der Ansprüche 6 bis 8, das ferner ein Anzeigen (5452) von Wettbewerbskontrollen auf dem Frontend umfasst.
Verfahren zur Übertragung eines Fernwettbewerbs eines Spiels, wobei das Verfahren umfasst: Aufzeichnen (S310) einer Videoübertragung des Fernwettbewerbs im Spiel; Speichern (5320) von Bildern oder Videoschnipseln auf der Grundlage des Videofeeds; Bereitstellen (S330) der Bilder oder Schnipsel für ein Frontend; Abspielen (S340) eines aus den Bildern oder Videoschnipseln im Frontend rekonstruierten Videofeeds; Erzeugen (S350) eines Videostreams auf der Grundlage der rekonstruierten Videoeinspeisung im Frontend; und Übertragen (S360) des Videostreams.