Sollte die Engine für ein eventuelles webbasiertes Spiel als Webdienst starten?

Ich habe vor kurzem beschlossen, eine Engine für ein Kartenspiel zu schreiben. Ich bin kein großer "Kartenspieler", aber ein Freund hat mich in das Spiel eingeführt (es ist eine Neuerung des dänischen Spiels), und ich habe mich verliebt.

Ich möchte das Spiel in 3 Segmenten entwickeln:

1. Die Basis-Engine verwaltet Karten / Decks / Gamestate usw.
2. Eine Benutzeroberfläche (in Form einer mobilen / Desktop-Webanwendung)
3. Eine künstliche Intelligenz mit verschiedenen Strategien / Schwierigkeiten usw.

Ich denke, das sind sehr unterschiedliche Projekte ... und ich habe Probleme damit, zu sehen, wie sie auf lange Sicht alle zusammenpassen. Zuerst möchte ich nicht einmal in der Lage sein, das Spiel mit der Engine zu "spielen". Der Motor wird in erster Linie durch seine Unit-Tests getestet. Die Spieletests werden erst gestartet, wenn ein Client vorhanden ist. Hier besteht also eine Art Client-Server-Beziehung.

Der Motor ist ein sehr großer Teil des Puzzles. Was ich wissen möchte ist: Wie würden Sie die "öffentliche API" für diese Engine entwickeln?

Ich dachte, die Engine könnte ein sehr einfacher Webdienst sein, der seinen Status über Abfragen an eine RESTful-API zurückgibt, aber ich mache mir Sorgen, dass die Entwicklung der Engine selbst als Web-App zu schlechten Programmierentscheidungen führen könnte. (Wenn ich zum Beispiel ein MVC-Mikroframework wählen würde, hätte diese API keine wirklichen Ansichten ... sie gibt nur serialisierte Objekte über JSON zurück oder etwas in diesem Sinne. Ist es schlecht, MVC für einen Dienst wie zu verwenden? diese? )

Meine andere Idee war, dass die Engine nur eine Konsolen-App sein würde, und ich würde später eine Brücke schreiben, um Daten zwischen ihr und der Web-App zu leiten. (Die Brücke könnte wirklich alles sein. Ich meine, der Webserver und die Spiel-Engine könnten beide auf einem IRC-Server inaktiv sein und ihren Status in Kanälen teilen.)

Welchen Ansatz würden Sie wählen (als Webdienst entwickeln oder als eigenständige App entwickeln und später überbrücken) und warum?

Danke, Robbie.

EDIT: Also ich denke, das gehört in die Spieleentwicklung. Zur Verdeutlichung werde ich eine Kartenspiel-Engine schreiben. Ich versuche herauszufinden, wie die API der Engine am besten verfügbar gemacht werden kann, damit sie in Zukunft in einen Webclient und einen AI-Client integriert werden kann.

Ich hatte hier nicht einmal einen Account, also grüß dich :)

Die Webservice-Route ist wahrscheinlich die beste und skalierbarste.

Ich sehe auch absolut KEIN Problem bei der Verwendung eines MVC-Frameworks zur Rückgabe von JSON (asp.net mvc ist hier großartig). Wenn Ihre Controller zunächst nur JSON zurückgeben, was in Ordnung ist, können Sie Unit-Tests ohne Ansichten durchführen. Wenn Sie bereit sind, Ihre Spieloberfläche hinzuzufügen, können Sie Ansichten hinzufügen. Wenn es sich um einfaches HTML / CSS oder Flash / Silverlight handelt, spielt es keine Rolle, da Sie, wie Sie bereits angegeben haben, die zugrunde liegende Engine bereits erstellt haben.

Ich bin mir nicht sicher, wie Ihre Entwicklungs- oder Hosting-Umgebungen aussehen, aber ich würde es nicht überentwickeln. Ein einfacher Satz von PHP-Dateien, die JSON zurückgeben, ist möglicherweise alles, was Sie benötigen. Ich bin mit dem Spiel, das Sie erstellen, nicht vertraut, daher bin ich mir nicht sicher, wie komplex es sein wird.

Meiner Meinung nach empfehle ich Ihnen dringend, etwas zu kaufen, das so schnell wie möglich spielbar ist, wenn Sie neu in der Spieleentwicklung sind und es selbst machen, da es Ihnen hilft, das Spiel zu vervollständigen und zu verbessern auf ein gutes Niveau.

Eine Ansicht ist eine Entität, die sich bei einem Modell registriert, um benachrichtigt zu werden, wenn Änderungen auftreten.

Wenn sich Ihr Modell auf einem Webserver befindet, liegt ein Problem vor, da das HTTP keine explizite Methode implementiert, mit der der Server eine Kommunikation starten kann. Sie können Websocket verwenden, um dies zu handhaben, aber Sie werden einen Teil Ihrer "RESTfulness" opfern ... Ich denke, dass eine gute Lösung darin bestehen kann, Ihre Web-URL ein Modell identifizieren zu lassen und den HTTP-Server-Push zu verwenden, um Ihre Ansichten benachrichtigen zu lassen wenn gebraucht.

Nehmen wir an, Sie haben ein laufendes Spiel in

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

Sie können die URL verwenden

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

das Modell zu ändern und

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

auf Benachrichtigungen warten.

Notify wartet einige Zeit, um Nachrichten vom Modell zu erhalten: Wenn etwas passiert, wird eine Nachricht gesendet (welche Daten werden geändert oder welche Art von Ereignis passiert oder was auch immer).

Der Client kann eine lange Ajax-Anfrage an / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notify senden und einen Benachrichtigungsrückruf registrieren, der sowohl die Ansicht aktualisiert als auch die nächste Benachrichtigungsanforderung erneut veröffentlicht.

Wenn games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / Timeouts auf dem Client benachrichtigt, wird eine neue Anforderung ausgeführt. Wenn Timeouts auf dem Server auftreten, werden die zugewiesenen Ressourcen freigegeben.

Sie können ein recht allgemeines Benachrichtigungssystem auf Ihrem Server und eine Benachrichtigungsbibliothek auf Ihren Clients erstellen, um eine konsistente MVC über eine transparente Benachrichtigungsebene aufzubauen.

Wenn Sie nach einer Technologie suchen, können Sie Ihre Spiel-Engine auf dem Couchdb-Server aufbauen. Couchdb ist ein nicht relationales REST-DBMS, das HTTP als Protokoll und JSON als Dokumentformat verwendet. Es kann auch Binär- oder HTML-Dateien als Anhänge PUT und GET, so dass es möglich ist, eine vollständige WebApp nur mit dem DBMS (einer couchApp) zu schreiben.

Es gibt eine Javascript-Bibliothek, die es unter anderem ermöglicht, auf Datenbankaktualisierungen zu reagieren. Eine couchdbApp ist einfach eine Datenbank, mit der Sie eine Anwendung durch Synchronisierung auf einen anderen Server kopieren können: Ihre Clients können Ihre App auf ihren lokalen Server kopieren und dann über ein externes LAN abspielen.