Architektur eines HTML5 Mehrspieler - Spiels

[Arthur]

Hallo,

Ich hätte eine prinzipielle Frage zur Struktur einer Web App. ...und zwar soll ein [relativ simples] HTML5 Kartenspiel entwickelt werden, welches entweder alleine gegen KI Gegner oder aber auch gegen "echte" Menschen gespielt werden kann.

OPTION 1: Die Architektur des Ganzen hätte ich mir so vorgestellt dass die KI-Logik im Single Player Modus auf dem jeweiligen Endgerät passiert, im Mehrspieler Modus aber auf dem Server, der dann die verbundenen Endgeräte anweist, welche Aktionen durchzuführen sind.

Ist das eine gute Architektur oder sollte

OPTION 2 die KI-Logik doch immer auf einem Endgerät stattfinden (vorzugsweise auf dem hostenden Gerät), welches die durchzuführenden Handlungen und Ergebnisse dann über den Server an die anderen broadcastet? (In diesem Fall müsste die KI Logik nicht wie in OPTION 1 auf den Endgeräten und auf dem Server laufen)

---

Serverseitig scheint mir ein Node Server in Verbindung mit Websockets für die bidirektionale Kommunikation die bevorzugte Wahl der Dinge zu sein, lasse mich da aber gerne eines besseren belehren.

Vielen Dank für eure Gedanken, Arthur

[Rolf B]

Hallo Arthur,

wir suchen sowas als Tutorial für's Wiki 😀. Bin auf dein Ergebnis gespannt.

Solange Du gegen one-on-one gegen einen Bot spielst, kann der im Browser laufen. Weiter als das wollte ich in der Wiki-Demo auch nicht gehen. Das setzt aber voraus, dass der Spieler "fair" ist, d.h. nicht per Entwicklertools im Bot oder der Game-Engine rumdebuggt und dadurch Dinge in Erfahrung bringt, die der Spielidee zuwiderlaufen (was liegt auf dem Nachziehstapel, was hat der Bot auf der Hand).

Spieler gegen Spieler braucht einen Server, richtig. Der kann auf Websockets basieren, die haben mich aber bisher immer in ihrer Komplexität abgeschreckt und man braucht dafür auch einen Socket-fähigen Server. Ein Web-Hoster bietet sowas nicht.

Ein Browser kann übrigens auch kein Server sein. Websockets mit PHP sind ebenfalls nicht ideal. Node.js ist da schon besser.

Node.js hat den Vorteil, dass die KI - wenn sie richtig geschrieben ist - unverändert im Browser und auf dem Server laufen kann. Die KI sollte dafür aus mind. 2 Schichten bestehen: Die eigentliche KI, und ein Abstraktionslayer, der die Umgebungsspezifika abbildet. Aber - ein Socket Server in Node ist auch nichts für schwache Gemüter. Wie fit bist Du in dem Thema?

Rolf

[Arthur]

Hallo,

Danke für deine Antwort.

Ich fürchte, fürs Wiki wird's nicht reichen. Da das das erste Mal ist, dass ich ein derartiges Projekt umzusetzen versuche, könnte es ziemlich hässlich (i.e. nicht "lege artis") werden. Habe natürlich schon mal mit einem einfachsten Express Server herumgealbert, - darüber hinaus bin ich aber wohl einer der letzten PHP Fanboys. Im direkten Vergleich merkt man einfach, dass diese Sprache für das Backend einfach gemacht wurde - so viele Dinge, für die ich in Node auf ein externes Package zurückgreifen muss, sind in PHP schon nativ verbaut (vielleicht spricht hier aber auch die blanke Unkenntnis aus mir). Für bidirektionale [Echtzeit-]Kommunikation scheint PHP aber einfach nicht [mehr?] das richtige Tool zu sein.

FÜR das Projekt spricht dass ich weder Abgabetermin noch irgendeinen tatsächlichen Kunden/in habe, vielmehr ist das Projekt für mein Portfolio gedacht, vielleicht hilft's ja bei der Jobsuche...

Grob übers Knie gebrochen wäre die Idee gewesen, Socket.io in den Prozess einzubinden und wie bereits erwähnt die verschiedenen "States" an alle Mitspieler zu broadcasten.

[Matthias Scharwies]

Guten Morgen,

wir suchen sowas als Tutorial für's Wiki 😀. Bin auf dein Ergebnis gespannt.

Allerdings! Sowohl unsere Spiele-Reihe - als auch serverseitiges JS - sind Baustellen, bei denen wir gerne mehr hätten!

Ich fürchte, fürs Wiki wird's nicht reichen. Da das das erste Mal ist, dass ich ein derartiges Projekt umzusetzen versuche, könnte es ziemlich hässlich (i.e. nicht "lege artis") werden.

...

FÜR das Projekt spricht dass ich weder Abgabetermin noch irgendeinen tatsächlichen Kunden/in habe, vielmehr ist das Projekt für mein Portfolio gedacht, vielleicht hilft's ja bei der Jobsuche...

Warum nicht zweigleisig fahren:

1. Ein quick & dirty Projekt zum Probieren und parallel ...
2. einen Ausschnitt als Wiki- oder Blog-Artikel vorstellen ^[1]

Ein Wiki-Tutorial sollte ja in 45-xy Minuten durchgearbeitet werden können. Da wäre es schon gut, wenn man auf etwas Bestehendem aufbaut, sich auf einen oder zwei Aspekte beschränkt und dann evtl. einen etwas größeren Ausblick macht!

Herzliche Grüße

Matthias Scharwies

---

1. Veröffentlichungen in einer früher mal renommierten Dokumentation (alle Älteren kennen uns noch von früher) sollten doch auch gut für's Bewerbungsgespräch sein, oder? ↩︎

[TS]

Hello,

die Stichworte, die mir dazu einfallen, sind:

• Websockets
• konkurrierende Zugriffe
• Datenbank
• AJAX oder meinetwegen auch SPÜLI (ist noch nicht so bekannt, weil deutsch)
• JavaScript (für AJAX unabdingbar)
• Connectivity (bei schwacher Netzwerkanbindung darf das auuch nicht crashen)

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

SPÜLI (ist noch nicht so bekannt, weil deutsch)

Wem außer Dir ist es überhaupt bekannt? Warum sag ich "außer Dir"? Weil ich beim Versuch, das von zwei Enten binge-googeln zu lassen, NUR einen Beitrag von Dir im Selfforum von 2015 finde.

Rolf

[Der Martin]

Moin,

SPÜLI (ist noch nicht so bekannt, weil deutsch)

Wem außer Dir ist es überhaupt bekannt?

als generischer Begriff für Geschirrspülmittel ist das IMO seit Jahrzehnten geläufig.
Eine davon abweichende Bedeutung kenne ich allerdings nicht.

Warum sag ich "außer Dir"? Weil ich beim Versuch, das von zwei Enten binge-googeln zu lassen, NUR einen Beitrag von Dir im Selfforum von 2015 finde.

Echt? Ich finde Tausende von Beiträgen aus Haushaltsforen oder Werbung.

Einen schönen Tag noch
 Martin

[Matthias Scharwies]

Servus!

Serverseitig scheint mir ein Node Server in Verbindung mit Websockets für die bidirektionale Kommunikation die bevorzugte Wahl der Dinge zu sein, lasse mich da aber gerne eines besseren belehren.

die Stichworte, die mir dazu einfallen, sind:

• AJAX oder meinetwegen auch SPÜLI (ist noch nicht so bekannt, weil deutsch)
• JavaScript (für AJAX unabdingbar)

Ich hatte auch überlegt, den Sinn dieses Postings zu hinterfragen, wollte es aber nicht durch eine Antwort aufwerten.

Was muss ein professioneller Web-Entwickler denken, wenn er Websockets und Node.js erwähnt und kennt und ihm ein Urgestein dann JavaScript und AjaX (das X steht für XML!) vorschlägt.

Wem außer Dir ist es überhaupt bekannt?

als generischer Begriff für Geschirrspülmittel ist das IMO seit Jahrzehnten geläufig.
Eine davon abweichende Bedeutung kenne ich allerdings nicht.

Warum sag ich "außer Dir"? Weil ich beim Versuch, das von zwei Enten binge-googeln zu lassen, NUR einen Beitrag von Dir im Selfforum von 2015 finde.

@Rolf B versucht hier Professionalität reinzubringen und ihr…?

Echt? Ich finde Tausende von Beiträgen aus Haushaltsforen oder Werbung.

Liebe Kinder, bitte geht in euren Micro-SD-Thread, in dem euch von angeblich RFID-„gechippten“ Speichermedien über die Gasversorgung bis zum Autofahren heute und früher in den 80er Jahren der große Rundumschlag gelungen ist.

Langsam geht ihr mir auf den Sack mit eurer Dauer-Blödelei.

Herzliche Grüße

Matthias Scharwies

1. Vorsitzender SELFHTML e.V.

[Der Martin]

Hallo Matthias,

Langsam geht ihr mir auf den Sack mit eurer Dauer-Blödelei.

das ist zwar OT, aber eine Blödelei kann ich hier nicht erkennen.
Ebensowenig kann ich aber erkennen, wo Spüli auf einmal herkommt.

Einen schönen Tag noch
 Martin

[Matthias Scharwies]

Servus!

Hallo Matthias,

Langsam geht ihr mir auf den Sack mit eurer Dauer-Blödelei.

das ist zwar OT, aber eine Blödelei kann ich hier nicht erkennen.

Websockets in der MDN: „The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server...."

AjaX in der MDN: „Asynchronous JavaScript and XML, or Ajax, is not a technology in itself, but rather an approach to using a number of existing technologies together, including HTML or XHTML, CSS, JavaScript, DOM, XML, XSLT, and most importantly the XMLHttpRequest object.“

Der Einwurf von Tom war nicht falsch, traf angesichts der Vorkenntnisse des Threaderstellers aber eben nicht den Kern der Sache.

Ich bau' keinen Server mit Node.js, um dann mit XMLHttpRequest zu hantieren, Dass man für Node.js JavaScript braucht, sollte jedem SELFER klar sein.

Ebensowenig kann ich aber erkennen, wo Spüli auf einmal herkommt.

AjaX = Spüli → klingelt's jetzt?

Wir Moderatoren müssten viel schneller löschen (oder uns einfach mal zurückhalten beim Blödeln).

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

ich wollte lediglich und durchaus ernstgemeint hinterfragen, ob "SPÜLI" ein neudeutsches Akronym für die AJAX Technik ist, von dem ich noch nichts gehört hatte. Dass beides im deutschen Sprachraum Reinigungsmittel sind, weiß ich durchaus.

AJAX als Kommunikationstechnik für ein Multiplayer-Spiel finde ich dagegen durchaus relevant - als Fallback für Websockets. Es hat nämlich längst nicht jeder einen Websocket-fähigen Server zur Hand und deswegen ist eine reine Request-Response Implementierung gerade im Einsteigerbereich nicht uninteressant. Systeme wie die Board Game Arena würden daran kaputtgehen, wegen zu vieler Requests.

Rolf

[Gunnar Bittersmann]

@@Matthias Scharwies

AjaX (das X steht für XML!) vorschlägt.

Tut es das?

Langsam geht ihr mir auf den Sack mit eurer Dauer-Blödelei.

Es sind die Blödeleien, die das Forum am Leben erhalten.

🖖 Живіть довго і процвітайте

[MudGuard]

Hi,

SPÜLI (ist noch nicht so bekannt, weil deutsch)

Wem außer Dir ist es überhaupt bekannt?

Du kennst "Ajax Amsterdam gegen Spüli Lissabon" nicht?

von Otto …

Weil ich beim Versuch, das von zwei Enten binge-googeln zu lassen, NUR einen Beitrag von Dir im Selfforum von 2015 finde.

Es gibt eine Welt außerhalb des Selfforums …

cu,
Andreas a/k/a MudGuard