Das deutsche QBasic- und FreeBASIC-Forum

[FredKowalzki]

Hallo liebe Leute,

ich möchte gerne ein Online Kartenspiel programmieren.
Damit meine ich, dass sich 4-7 Spieler (Freunde) wo auch immer einloggen können und dann miteinander das Kartenspiel spielen können.
Das Programm selbst soll nicht intelligent sein, d.h. es soll keinen Spieler ersetzen. Es soll lediglich allen Spielern mitteilen können, wer gerade welche Karte ausgespielt hat.
In einem Heimnetzwerk stelle ich mir das recht simpel vor, da alle auf eine Datei in einem freigegebenem Ordner zugreifen könnten. Aber bei online muss ich total passen.
Ich habe schon einige Netzwerkbeiträge hier gelesen, aber die habe ich leider überhaupt nicht begriffen.
Kann mir jemand mal einen Ansatz geben, wie und womit ich anfangen könnte?

Vielen Dank im Vorraus.

Fred

[dreael]

Meine berühmter Artikel zum Thema:

http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/InternetMitQuickBASIC.html

Wichtigster Unterschied in FreeBasic: direktes Ansprechen der WINSOCK.DLL möglich bzw. es gibt sogar plattformneutrale Bibliotheken.

Konzeptionell würde ich in Deinem Fall mit Sockets arbeiten, das Ganze als Client- und Serverapplikation. Dabei gibt es die Varianten Heimnetz (=der FreeBasic-Prozess des einen Spielers ist der Server) und die Variante Zentralserver (=dedizierter Server, der bei Microsoft als Dienst läuft bzw. bei Linux als Daemon). Diesen könntest Du im Prinzip auf einem gemieteten Rootserver (heute dank Virtualisierung als sog. vServer sehr preiswert!) hosten.

An Deiner Stelle würde ich das Ganze vielleicht wie folgt ansetzen:
Schritt 1: Heimnetzvariante. -> Dann brauchst Du Dich nur um gerade ein laufendes Spiel kümmern
Schritt 2 (spätere Phase): Server separat. -> Hier kämen dann Dinge wie Registrierung als Benutzer / Gast usw. ins Spiel. Natürlich auch hier die Zwischenetappe "interner Server" denkbar, d.h. bereits separater Prozess. evtl. sogar als Dienst, der aber noch nicht das ganze Benutzermanagement besitzt und sich deswegen nur primär im LAN hinter dem NAT-Router eignet.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[Sebastian]

Hallo und willkommen im Forum!

In dem Fall muss einerseits eine Lösung gefunden werden, Teilnehmer zu Spielrunden zuzulassen, andererseits muss dafür gesorgt werden, dass der Spielstand eines laufenden Spiels stets an alle Teilnehmer übermittelt werden kann. Es muss also für den einzelnen Teilnehmer die Möglichkeit geben, seine "Spielzüge" an die anderen zu vermelden.

Das passiert im Internet nicht über Windows-Netzwerkfreigaben (SMB/CIFS), sondern andere Protokolle der Anwendungsschicht (bspw. möglich wäre HTTP in der Ausprägung eines Webservices).

Idealerweise würde man bei einem Online-Multiplayer-Spiel einen zentralen Host im Internet einrichten, gegenüber dem sich die Teilnehmer zunächst authentifizieren und zu Spielrunden anmelden.
Anschließend würde immer der Host (Server) die aktuellen Spielinformationen an alle verbundenen Teilnehmer (Clients) übermitteln.
Die Clients melden dann ihrerseits dem Host ihre Spielaktionen/-züge zurück. Der Host passt den Spielstand, über den er "Buch führt", dann entsprechend an (Veränderung z. B.: "neue Karte liegt auf dem Tisch") und sendet die "Neuigkeit" an alle verbundenen Teilnehmer.
Hierbei handelt es sich um einen zentralistischen Ansatz, der viele Vorteile hat, aber die Einrichtung eines zentralen Servers voraussetzt.
Das kann einerseits ein "richtiger", angemieteter Server im Internet (Rootserver/vServer) sein oder aber ein Heimserver/Heim-PC, der über einen Dienst wie DynDNS zugänglich gemacht wird.

Neben dem zentralistischen Ansatz, dem ich den Vorzug einräumen würde, gäbe es die Möglichkeit, ein solches Spiel als Peer-to-Peer-System zu gestalten. Jeder Teilnehmer würde sich direkt mit allen anderen Teilnehmern verbinden und so Spielrunden abwickeln. Vor Beginn eines Spiels müsste jeder Spieler die IP-Adressen (oder DynDNS-Domainnamen) aller anderen Spieler kennen und im Spiel angeben.

Möglich wären aber auch "Hybrid-Ansätze". Es wäre denkbar, dass eine einfache php-basierte Seite auf einem Webserver den Login abwickelt und die IP-Adressen der eingeloggten Teilnehmer zentral speichert. Auf dieses zentrale Teilnehmer-Register könnten dann die Clients zugreifen, um ein Spiel anzubahnen, aber dennoch im Spielverlauf peer-to-peer kommunizieren.

Ehe man anfängt, etwas zu programmieren, muss man also erst einmal eine Herangehensweise auswählen und darauf aufbauend ein Detailkonzept (z. B. unter Einschluss eines eigenen Protokolls) entwickeln. Davon hängt nämlich ab, welche Software/Bibliotheken geeignet sind.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!

[FredKowalzki]

Vielen Dank für die Denkanstöße.

[nemored]

TPM hat mal eine Bibliothek zu TSNE speziell für Spiele zusammengestellt. Ein Kartenspiel ist da zwar nicht das perfekte Zielprojekt, aber ich bin damit trotz fehlenden Netzwerkkenntnissen sehr schnell zurechtgekommen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Sebastian]

[FredKowalzki]

Ich habe mir jetzt mal intensiv TSNE angeschaut. Hm. Um das verwenden zu können bräuchte ich einen Beispielcode wie der Client zum Server den String "Hallo ich bin ein Client" übergibt und einen Beispielcode wie der Server den Client antwortet "Und ich habe dich gehört" oder sowas. Denn ich verstehe den Code nicht einmal ansatzweise.
Genau das schreckt mich also eher ab TSNE zu verwenden, denn ich würde etwas benutzen, was ich nicht verstehe. Bei eventuellen Fehlern könnte ich nichts korrigieren.
Noch einmal zur FTP Idee:
Kenn- und Passwort kann im Programmcode enthalten sein. Somit muss der Mitspieler Kenn- und Passwort nicht kennen. Bei Bedarf kann ich jederzeit mein FTP Passwort ändern. Dann kommt niemand mehr auf meinen FTP Server.
Ich kann mir auch einen eigenen FTP Server einrichten. Dann landen die Leute auf einem meiner Rechner per Dyndns, wäre ja auch durchaus machbar.

Fred

[nemored]

[FredKowalzki]

Ja, da fängt es leider schon an.
Die Testplay.bas:
'Das Programm wird auf 2 arten gestartet

'<Programmname> server
'<Programmname> <hostname>

Welches Programm muss aufgerufenwerden mit dem Parameter "Server"?
If Command() = "server" Then...
Ich habe folgendes probiert:
command="Server"
Command("Server")
Geht beides nicht.

[nemored]

Du musst das Programm zweimal starten, z. B. beide Male über (zwei verschiedene) Konsolen - einmal mit dem Befehl

[dreael]

Schau Dir sonst als Beispiel mein Rasterbike an. Dort gibt es einen Client (QB-Programm damals; dürfte in FreeBasic logischerweise den eleganteren Code geben!) und einen Server (ist dort ein C-Programm für vorzugsweise Linux).

Dateien sind aus meiner Sicht der komplett falsche Ansatz! Die bessere Vorstufe: Nimm doch sonst einmal ein Nullmodemkabel und spiele mit einer Terminalemulation auf beiden Rechnern etwas! Anschliessend ersetzst Du die Terminalemulationen durch Beispiele wie hier (müssten in FreeBasic sogar 1:1 umsetzbar sein!). Bald merkst Du hoffenlich selber, das wie Telefonleitungen geschaltete Verbindungen (Nachrichten von A nach B schicken) der viel klügere Weg ist als da mit irgendwelchen temporären Dateien herumhantieren, wo noch auf Locking-Mechanismen geachtet werden muss.

Sobald Du die Beispiele mit der Nullmodemkabelkommunikation verstanden hast, ist es nur noch ein kleiner Schritt auf TCP/IP: Dort stellst Du Dir den Serverprozess als PC mit haufenweise COM-Ports eingebaut vor, bei welchem gleich haufenweise Socketverbindungen offen sind. Übrigens braucht es nicht einmal Threads, aber Du musst die vielen gleichzeitig geöffneten Sockets mit select() (So zumindest der Standard-C-Bibliothek-Aufruf jedes unixoiden Betriebssystems. An die TSNE & Co.-Profis: Vielleicht Hinweis geben, wie dort die entsprechende SUB-Prozedur heisst, um den Prozess schlafen zu legen, bis in einem der Sockets Daten hineinkommen) abwarten.

In Deinem Fall würde ich dann bald einmal als erstes auf dem Papier das Socketprotokoll entwerfen + überhaupt die Aufgabenverteilung, d.h. Schritte, die der Client machen muss und die Schritte vom Server. Dabei kann etwas auf ASCII-Textbasis den Vorteil haben, dass Du mit der Programmierung vom Server zuerst starten kannst und dabei den Client mit einem einfachen Telnet-Aufruf simulierst (=gewissermassen Deine Terminalemulation!). Übrigens hätte ich für Linux noch ein kleines Socket-Debugging-Tool (ist in C geschrieben), wobei aber "tcpdump" und "tcpflow" in diesem Zusammenhang ebenfalls sehr wertvolle Arbeit verrichten können.

Zu Beginn würde ich den Server nur für ein einziges Spiel auf einmal designen, erst später dann der Schritt für auf Dauerbetrieb als Dienst (Microsoft) bzw. Daemon (Linux).
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[FredKowalzki]

Vielen Dank für eure Tips.
Ich bin allerdings Hobbyprogrammierer in BASIC, kein Informatiker.
TSNE ist mir 10 Nummern zu groß, leider.
Meine einzige Chance TSNE zu benutzen wäre, wenn ich einen Beispielcode hätte wo Server und Client Strings ausgeben und miteinander kommunizieren. Dann könnte ich vielleicht den Code für meine Zwecke via VERSUCH verwenden. Begreifen tue ich mangels Hintergrundwissen das ganze nicht.
Im Prinzip braucht der Server ja nur soetwas wie ein Echo sein. Speler 1 spielt Herz Ass aus. Diese Info sendet er an den Server. Der Server empfängt diese Nachricht und sendet sie an die Clients. Alles andere wäre dann Aufgabe der Clients. Gibt es für sowas nicht einen Beispielcode? Bin ich wirklich der einzige, der sowas mal machen wollte?

Fred

[MOD]

Vor längerer Zeit habe ich ein Beispiel gemacht, indem ich die Funktionen der TSNE in ein UDT gepackt:

Server
Client

Die Programme machen nicht viel außer einen String zu senden.
Es gibt im Übrigen auch ein Tutorial zu TSNE im Portal.

[nemored]

Hier habe ich auch nochmal einen Server und einen Client; ob es aber trotz aller Bemühungen wirklich einfacher ist, weiß ich nicht.

Server starten, Client gern auch mehrmals gleichzeitig starten (maximale Zahl 10, wobei da vielleicht der Server mitgerechnet ist). Ein Tastendruck wird als Meldung an alle anderen Fenster übertragen.

Der Server "tut" im Prinzip gar nichts, außer als Server zu dienen. Der Client "tut" zweierlei: ganz unten ist das eigentliche Programm - Tastatur abfragen und evtl. Meldung losschicken. In der Funktion TSNEPlay_Message wird auf die Meldung anderer reagiert.

Überhaupt dienen alle Prozeduren nur dazu, auf Ereignisse zu reagieren. Die meisten machen in meinem Beispiel überhaupt nichts ...
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[dreael]

[FredKowalzki]

@nemored
Ich habe mir deinen Server und deinen Client heruntergeladen, habe bis jetzt den Server auf PC1 und den Client auf PC2 laufen lassen. Was soll ich sagen: Ich bin begeistert!
Das ist genau das, was ich wollte.
Jetzt geht es natürlich an das modifizieren und an die Fehlerbehandlung.
Wenn z.B. Client3 die Internetverbindung unterbricht und er sich wieder neu verbindet, muss er sich ja wieder als Client3 anmelden können. Oder wenn der Server die Internetverbindung abbricht, dann müssen sich natürlich alle Clients mit der selben Nr wieder anmelden.
Ich denke, ich habe, dank euch allen, nun eine Grundlage auf die ich aufbauen kann. Ihr seit echt klasse!
Vielen Dank für eure Denkanstöße - ich werde mich bestimmt noch einmal wieder melden, wenn ich nicht weiterkomme

@dreael
Vielen Dank für deine Tips.
Dazu möchte ich sagen, dass ich kein Programm für fremde Leute schreibe, sondern tatsächlich nur für Freunde. Da schummelt niemand. Davon einmal abgesehen, dass niemand meiner Freunde in der Lage wäre ein Programm zu modifizieren (die sind froh, wenn sie richtig klicken können), so sind wir aus dem Alter heraus, wo man mit Schummeln oder Cheats gewinnen möchte. Wir wollen gemeinsam Karten spielen, nur leider können wir uns, da wir in ganz Deutschland verteilt sind, nicht so oft treffen, wie wir es gerne hätten. Deshalb die Idee des Online-Kartenspiels.
Da wir miteinanander spielen wollen entfällt der Dummy-Ersatzspieler, falls jemand die Verbindung abbricht. dann muss der abwesende Spieler sich neu verbinden - wie auch immer.
Da der Server immer an alle sendet, also tatsächlich "nur" ein Echo ist, muss ich jetzt mal gucken, wie ich es mache, dass sich einzelne Clients b.B. angesprochen fühlen. Aber das ist halt die "Bastelei", die ich so liebe am Programmieren.
Eine Frage noch zu den Ports (Wer denkt sich solche Namen in der IT Szene eigentlich aus? Hafen...): Kann ich irgendwelche Ports benutzen (1234) oder gibt es, wenn es über das Internet läuft, bestimmte Ports, die man nehmen sollte?

Also vielen Dank nochmals an alle. Ihr habt mir sehr geholfen!

Fred

[Sebastian]

[nemored]

Port heißt zwar Hafen, aber genauso Eingang oder Öffnung ...

Die Identifikation mittels der ID ist, gerade bei Verbindungszusammenbruch und Neuverbindung, vermutlich eher fehleranfällig. So wie ich das sehe, wird diese ID einfach durchgezählt. Ich würde die eindeutige Identifizierung eher über den Anmeldenamen des Clients laufen lassen (der dritte Parameter von TSNEPlay_ConnectToServer, wo bisher "Client" & zufallsnummer steht). Eine Nachricht würde ich tatsächlich immer an den Server schicken, der dann überprüft, an wen sie gerichtet ist, und entsprechend weiter verschickt. Du kannst die Nachricht natürlich auch einfach an alle schicken, und jeder Client muss dann selbständig schauen, ob er mit dieser Nachricht etwas anfangen kann. Ich könnte mir z. B. vorstellen, dass die Nachricht ganz einfach immer mit dem Namen des Clients beginnt, für den sie gedacht ist; bekomme ich eine Nachricht ohne meinem Namen am Anfang, dann ignoriere ich diese einfach.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[dreael]

[FredKowalzki]

So, die erste Sache wo ich nicht wirklich weiterkomme.
Ich habe testweise den Server vom Netz genommen, damit er nicht mehr erreichbar ist und nach einer kleinen Weile wieder rangeklemmt.
Die Clients kommen allerdings dann nicht mehr auf den Server. Die Netzwerkmeldung lautet: TSNEPlay_NotReadyForNewConnection
Wenn ich den Client neu starte, dann geht es wieder, aber das ist ja nicht Sinn der Sache, mitten im Spiel das Spiel von vorne anzufangen.
Ich muss den Client also "ready für neue Connections" machen. Blos wie?

Fred.