Export-Schnittstelle für ausgewählte Daten zur Nutzung in externen Tools?

Hi,

ich wollte mal nachfragen, ob jemand von euch sowas in der Art ggf. schon anbietet und etwas zur Technik/Umsetzung/Aufwand sagen kann?

Hintergrund meiner Frage ist, dass einige User in unserer Com gerne die Möglichkeit hätten, bestimmte Daten aus unserem Spiel in externen Tools, die sie selbst programmieren wollen, weiterzuverarbeiten (die Daten möchten sie vorzugsweise als CSV). Bei einem Managerspiel ist das natürlich nachvollziehbar, dass sie gerne manche Daten langfristig mitloggen/auswerten wollen. Ich habe eben mal etwas zu dem Thema im Internet gesucht und bin nicht so recht fündig geworden. Ich muss wohl zugeben, dass ich mir über sowas bislang keine großen Gedanken gemacht habe und mir erhoffe, hier ein paar Infos zu ergattern, falls jemand damit schon etwas Erfahrung hat.

Es müsste ja so laufen, dass die von den Usern programmierten Tools eine Möglichkeit hätten, sich mit unserem Server zu verbinden, Usernamen und Passwort an uns zu übermitteln und falls diese Infos passen als Rückgabe von uns alle nötigen Daten bekommen würden (vorzugsweise als CSV Paket). Vermutlich ist hier auch relevant, wie unser Serversystem aufgebaut ist. Deshalb hier kurz die wichtigsten Infos: Apache, PHP, MySQL :-)

Da würde eine (REST-)API doch wunderbar passen?

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Also ich kenne sowas aus anderen Projekte, die Setzen es mit SOAP und WSDL um, damit sind die sogar in der Lage funktionen zu übermitteln so dass ich nur noch rückgabewerte verarbeiten kann. vllt wäre das was für dich. Beispiel für deine Anwender dann:

$soap = new SoapClient('http://deinepage.com/soap.xml',array(

'username'=>'bla',

'password' =>'geheim'

));

print_r($soap->getUserInformations());

Weewar hat eine API mit der externe Entwickler auf das Spiel zugreifen können. http://weewar.com/api

Mit dieser API wurden diverse Tools umgesetzt. http://weewar.com/tools

Der Zugriff ist allerdings nur lesend erlaubt. Ich würde mir das so oder so drei mal überlegen, ob ich schreibenden Zugriff erlaube oder nicht. In WeeWar ist dieses allein den Bots erlaubt.

So long...

Maxx

Hey, schon mal vielen Dank für die raschen Antworten. Wenn wir sowas bereitstellen sollten, dann definitiv nur so, dass die User Daten auslesen, aber sicherlich nichts schreiben können.

Original von mar1us

Hey, schon mal vielen Dank für die raschen Antworten. Wenn wir sowas bereitstellen sollten, dann definitiv nur so, dass die User Daten auslesen, aber sicherlich nichts schreiben können.

wäre doch verrück wenn es gehen würde

$user->setPremiumAccount();

:D

Original von BlackScorp

wäre doch verrück wenn es gehen würde

$user->setPremiumAccount();

:D

Verrückter wäre es aber doch wenn man es sinnvoll einsetzen würde. ;)

War of Galaxy bot/bietet die Möglichkeit über deren IRC Bot Ingame Nachrichten und Ressourcenstände abzufragen und auch schreibender Zugriff in Form von Käufen von anderen Spielern Angebote. Das fand ich sehr gut gemacht.

Man könnte alle möglichen Aktionen die ein Spieler über die Webseite macht auch über andere Schnittstellen anbieten (ob REST, SOAP oder sonst etwas sei mal dahingestellt und jedem selbst überlassen). Und natürlich kann auch dein Beispiel gehen mit "$user->setPremiumAccount();", der Server zieht dem User dann einfach X Premiumwährung ab die er für die Aktivierung des Premium Accounts benötigt oder aktiviert den Account nicht wenn nicht genügend Premiumwährung vorhanden ist. Nur weil es über eine andere Schnittstelle geht heisst es ja nicht dass es ungeprüft gehen sollte.

Im Prinzip hat jedes Browsergame bereits eine Schnittstelle für externe Tools. Das externe Tool nennt sich Browser und ist per REST Ansatz mit dem Server verbunden.

Der Sprung würde dann "nur" bedeuten diese Schnittstellen logisch aufzubauen sodass auch ein aussenstehender einzelne Funktionalitäten nutzen kann und zu Dokumentieren.

Es kommt drauf an, wie Eure bisherige interne Struktur aussieht.

Erste Lösung: Ihr baut einen zweiten Satz von Controllern/URLs, die ausgewählte Daten mit ausgewählten Parametern bzw. ausgewählten URLs zur Verfügung stellen. Wahlweise sind das in Echtzeit generierte Daten, oder statisch abgelegte* oder eine Mischung (Caching*).
Das ist vor allem wohl dann sinnvoll, wenn bisher keine echte Trennung der Schichten Services und Controller/Views gemacht wurde.

Zweite Lösung: Ihr habt bereits eine entsprechende Trennung, dann braucht ihr u.U. nur einen weiteren Ausgabefilter und ggf. ein paar Einschränkungen definieren. Beispielsweise ist es bei richtiger Vorgehensweise kein Problem, zu einer HTML-Version *immer* ein XML- und ein JSON-Pendant bereitzustellen. 

Die zweite Lösung kann man natürlich auch mit der ersten Lösung kombinieren, wenn man dies a) eh neu bauen muss und b) bspw. XML und CSV bauen muss.

Es kann übrigens sinnvoll sein, wenn man sich intern auf ein Ausgabeformat einigt und dies bei Bedarf umwandelt. Man spart sich enorm viel Boilercode. Weniger Wartung, dafür etwas mehr Overhead. In meinen Augen aber bei den meisten Daten durchaus vernachlässigbar (Niveau normaler Requests). Geeignete interne Ausgabeformate können Hashstrukturen (Arrays, Maps, sowie einfache Datentypen) oder auch XML sein. Vor allem mit letzterem hat man ohne Anpassung der Applikation alle Möglichkeiten offen: CSV, XLS, XML, HTML, PDF, RSS, ...

* Je nach Daten kann man die auch von einem Job (als XML?) ablegen und entweder 1:1 ausliefern oder nochmals gefiltert ausgeben. Spart evtl. wertvolle Zeit an den Datenbankserver (je nach Konzept der Datenausgabe/-alterung).

Ich finde die Idee sehr gut. Bitte achtet darauf, die Daten dann auch unter eine entsprechend freie Lizenz zu stellen.

Vor ein paar Jahren hatte ich mal ein Tool geschrieben, daß die (kaputten...) XML-Daten von DAoC heruntergeladen & ausgewertet hat. Leider ist das rechtlich oft eine Grauzone, wenn man die Daten / Auswertungen dann wieder auf den eigenen Seiten veröffentlichen möchte (selbst bei nicht-kommerzieller Nutzung).

Randnotiz: wenn es eine Rubrik "Todesmeldungen" gibt, und ein Spieler "Paracetamol" heißt, dann gibt es unter Umständen ein paar Leute, die bei Google etwas anderes gesucht hatten, als sie auf den Link klickten.

Stellt jeder seine Webseite auch unter "Lizenz"? Unabhängig, ob man es jetzt ausdrücklich erlaubt oder nicht erlaubt?

Original von knalli

Stellt jeder seine Webseite auch unter "Lizenz"? Unabhängig, ob man es jetzt ausdrücklich erlaubt oder nicht erlaubt?

Webseiten allgemein unterliegen in Deutschland dem Urheberrecht (wenn sie die nötige Schöpfungshöhe erreichen ). Durch die Veröffentlichung stellst du deine Seiten dem einzelnen Nutzer zur unentgeltlichen Verfügung. Das heißt aber nicht, daß der Nutzer dann damit machen kann, was er will. Es gibt Seiten (flickr, wikipedia), bei denen genau geregelt ist, was man mit Bildern / Texten machen darf. Ohne Lizenz darf man ziemlich genau nur eines: im privaten Rahmen gemäß UhrG verwenden.

In Europa ist es so, daß schon Datenbanken mit sehr geringer Schöpfungshöhe urheberrechtlich geschützt sind. (http://dejure.org/gesetze/UrhG/87a.html ). Daher kann man z.B. nicht einfach die Spielerdaten von WoW von deren Webseite automatisiert herunterladen und dann eigene Statistiken über die Aktivität von Gilden / Spielern usw. veröffentlichen. Wer das dennoch macht, muß damit rechnen, bei Missfallen des Eigentümers eine Abmahnung zu kassieren.

Beispiel:

Ich erstelle auch einen Fußballmanager, der weitgehend 90-minutes kopiert, und biete dann zum medienwirksamen (haha) Start desselben an, daß jeder Spieler von 90-minutes seinen Account übertragen kann. Dies geschieht auf Basis der dort frei verfügbaren Spielerinformationen, die ich insgesamt herunterlade und konvertiere. Wenn es keine Lizenzbestimmungen für die Verwendung der Spielerinfos gibt, wird mich 90-minutes vermutlich am nächsten Tag abmahnen ;)

Das soll jetzt kein Gruselszenario sein, sondern nur verdeutlichen, daß man mit einer vernünftigen Lizenz ("Die Daten dürfen nicht-kommerziell verwendet werden" oder "Die Daten dürfen beliebig weiter verwendet werden, solange ein deutlicher Link zum Originalspiel enthalten ist.") auch als Nutzer der Daten besser fährt.

Ach ja, ich hatte das irgendwie anders oben verstanden ;) Wobei natürlich Grauzonen bleiben..

Weitere technische Buzzwords in dem Umfeld: API-Tokens, Limits.