Pokerprojekt realisierung

[.chicken]

Also, hier ist shcon wieder ein Thread ovn mir, ich hoffe das ist nicht schlimm, dass ich jetzt soviele Threads öffne, aber hab halt ne Menge Fragen, damit ihc hinterher nicht wieder mein komplettes Projekt verwerfen darf...

Also wie der Titel schon sagt, programmier ich gerade ein Pokerspiel, bzw. fange gerade richtig an!

Ich wollte es als Netzwerkspiel programmieren und dazu habe ich noch einige Fragen.
Habe noch nicht soviel Erfahrung auf dem Gebiet und bisher nur ein kleines Tutorial zu der Programmierung eines kleinen Chats durchgearbeitet.
Aufgrund dieser Kenntnisse habe ich nun folgendes überlegt.

Ich habe das Pokerspiel als Programm, dort kann ich entweder einem Netzwerkspiel beitreten oder eines erstellen.
Wenn ich dann zB eines erstelle, gebe ich zu Beginn einige Werte ein wie zB
Blinds zu Beginn, Startgeld, maxSpielerzahl etc...
Diese Werte würde ich dann an eine Form die als Server dient (mittels TServerSocket) weitergeben.

Von da aus könnte ich dann immer wieder den aktuellen Stand (welcher Spieler dran ist etc.) abfragen. Was haltet ihr von der Idee? Realisierbar? Verbesserungsvorschläge?
Werde mich da noch genauer informieren, aber ich wollte halt erstmal hier fragen ob das so realisierbar und sinnvoll ist!

MfG und nochmal sorry für die vielen Threads im Moment!

[Der_Unwissende]

Zitat von .chicken:

Also, hier ist shcon wieder ein Thread ovn mir, ich hoffe das ist nicht schlimm, dass ich jetzt soviele Threads öffne, aber hab halt ne Menge Fragen, damit ihc hinterher nicht wieder mein komplettes Projekt verwerfen darf...

Hi,
also ich bin jetzt kein Moderator o.Ä., aber ich denke viele Threads sind kein Problem (darüber hat sich afaik noch keiner beschwert). Wichtig ist halt nur, dass die Threads auch wirklich unterschiedliche Fragen beinhalten (da sollst Du sogar für jede Frage einen Thread eröffnen!). Wenn es aber 5x die Frage X von Dir gibt, dann weiß ja keiner wann die wo schon beantwortet wurde.
Worauf Du mehr achten solltest ist die Rechtschreibung, Dinge wie shcon, ovn und ihc sollten nicht sein. Einfach vorm Abschicken oder während des Tippens nochmal überfliegen und korrigieren (kann ja mal passieren, häuft sich aber bei Dir auffällig).

Zitat von .chicken:

Diese Werte würde ich dann an eine Form die als Server dient (mittels TServerSocket) weitergeben.

Von da aus könnte ich dann immer wieder den aktuellen Stand (welcher Spieler dran ist etc.) abfragen. Was haltet ihr von der Idee? Realisierbar? Verbesserungsvorschläge?
Werde mich da noch genauer informieren, aber ich wollte halt erstmal hier fragen ob das so realisierbar und sinnvoll ist!

Ist definitiv realisierbar und verbesserungswürdig Also erstmal zur Realisierbarkeit, ich sehe nicht welcher Teil davon nicht klappen sollte. Das könnte aber auch daran liegen, dass Du Dein Problem noch sehr einfach formuliert hast (was nicht falsch ist!!!). Natürlich ist es möglich so ein Netzwerkspiel zu erstellen.

Was allerdings den momentanen Plan angeht, so denke ich kannst Du doch ein wenig etwas verbessern. Was hier ein wenig störrt ist das Formular. Ein Server nimmt Daten entgegen, kennt den Zustand usw., alles gut, aber die Darstellung hat damit nichts zu tun. Du kannst einfach eine Klasse verwenden, die das ganze realisiert. Damit schaffst Du eine gewisse Unabhängigkeit. Verbesserst Du irgendwann das Aussehen der Formulare/die Steuerung, so sollte das keinen Einfluss auf den Server haben. Die Spiellogik kann einfach gleich bleiben.
Etwas allgemeiner lautet das Ziel, dass Du immer ein Problem in eine Einheit steckst. Eine solche Einheit kann dann z.B. eine Klasse sein (oder ein Modul, eine Komponente, etc.). Jedenfalls ist die Darstellung ein Problem, die Verwaltung ein anderes und als Drittes kannst Du noch den aktuellen Zustand abkapseln (was hat wer auf der Hand, wer ist am Zug, ...).
Genaueres findest Du, wenn Du nach MVC (Modell, View, Controller) suchst. Das Modell sind dabei wirklich nur die Daten (ohne große Logik). Z.B. würde ein Spieler zum Modell gehören. Im Modell speicherst Du dabei nur was er auf der Hand hat, wie viel Geld er hat, wie er heißt,... Aber eben nur solche Informationen! Alle Methoden dienen dann nur dazu, dass Du den Zustand änderst, über Änderungen benachrichtigst und die Konsistens prüfst (z.B. darf kein Pokerspieler je mehr Geld setzen als er hat, solche Änderungen kannst Du dann verbieten).
Das View erklärt sich von selbst. Dabei handelt es sich um ein Formular, dass einfach Datensätze aus dem Modell bekommt und anzeigt. Wo die Datensätze herkommen weiß es eigentlich gar nicht, es bekommt von irgendwo Daten und zeigt diese an. Zudem stellt das View die Schnittstelle zum Benuzer her, alle Aktionen die vom Benutzer ausgehen muss das View melden können (z.B. Stichwort Observer, geht aber auch ohne).
Der Controller enthält dann die eigenltiche Logik. Alles was der Benutzer tut wird dem Controller gemeldet. Dieser reagiert darauf, in dem er das Modell verändert. Dieses benachrichtigt dann entweder direkt das View oder wieder den Controller, der dann als Vermittler zwischen View und Modell steht. Im Letzteren Fall wird das View dann vom Controller benachrichtigt. Wer das View benachrichtigt ist eigentlich auch egal, dass View bekommt einen neuen Zustand übergeben und zeigt diesen an (egal wo der her kommt).

Der Vorteil dieser Trennung liegt (wie gesagt) in der Unabhängigkeit. Änderst Du z.B. beim View das Aussehen der Karten, so hat das keinen Einfluss auf die anderen Teile, da dies nur innerhalb des Views geschieht und nur die Darstellung betrifft. Zudem findest Du Dich in den einzelnen Klassen leichter zurecht, da sie nur genau eine Aufgabe beinhalten.

Gruß Der Unwissende

[.chicken]

So, sorry erstmal für die Rechtschreibung, diese Flüchtigkeitsfehler passiern mir recht häufig, sollte ich mir mal abgewöhnen
Ich versuche drauf zu achten!


Also so wie ich das verstanden habe, soll ich für alle "Oberbereiche" eine eigene Klasse schreiben?
Hab da noch nicht so viel Erfahrung, das mach ich dann am besten jeweils iner eigenen Unit oder?

Und den Server also ohne extra Form und auch ne eigene Klasse?


Also habe ja vor längerem schonmal angefangen ein Pokerspiel zu programmieren, allerdings hatte ich da noch keine Netzwerkfunktion und so eingeplant, sondern mich vorerst nur mit der Darstellung der Karten und dem Abfragen der Hände beschäftigt.
Deswegen bin ich nun etwas ratlos, wie ich das alles realisieren soll, is für mich schon ein etwas größeres Projekt


Danke für die großartige Hilfe hier!

[Der_Unwissende]

Zitat von .chicken:

Also so wie ich das verstanden habe, soll ich für alle "Oberbereiche" eine eigene Klasse schreiben?
Hab da noch nicht so viel Erfahrung, das mach ich dann am besten jeweils iner eigenen Unit oder?

Ich würde sagen ja, aber das ist (vielleicht) eher Geschmackssache. Eine Unit für eine Klasse hat den Vorteil, dass Du halt nicht schauen musst wo eine Klasse anfängt und eine andere endet, ist also einfach besser lesbar und damit leichter verständlich/wartbar/erweiterbar/...
Was die Oberbereiche angeht, so stimmt das, die kommen in eine Klasse, aber die können natürlich selbst wieder aus anderen (kleineren) Klassen zusammengesetzt werden. An sich ist die Idee der OOP (Objekt Orientierten Programmierung), dass eine Klasse ein bestimmte Problem löst. Man versucht dabei möglichst allgemeine Probleme zu lösen, nicht nur sehr spezielle Fälle. Das ganze realisiert man durch Abstraktion und kann dann eben die Lösung eines sehr abstrakten Problems für sehr viele unterschiedliche Fälle verwenden.

Zitat von .chicken:

Und den Server also ohne extra Form und auch ne eigene Klasse?

Genau!

Zitat von .chicken:

Also habe ja vor längerem schonmal angefangen ein Pokerspiel zu programmieren, allerdings hatte ich da noch keine Netzwerkfunktion und so eingeplant, sondern mich vorerst nur mit der Darstellung der Karten und dem Abfragen der Hände beschäftigt.
Deswegen bin ich nun etwas ratlos, wie ich das alles realisieren soll, is für mich schon ein etwas größeres Projekt

Und genau hier kann man leicht zeigen, warum diese Trennung sinnvoll ist. Vieles von dem was Du schon hast möchtest Du sicherlich wieder verwenden. Hast Du jetzt schon die Trennung zwischen Modell, View und Controller, so werden nur Anpassungen am Controller notwendig. Wie Karten, Geld, wer dran ist, ... dargestellt werden ändert sich nicht. Auch das speichern der Daten (was für Eigenschaften hat ein Spieler) ändert sich nicht. Sogar am Controller bleibt vieles gleich. Er muss weiterhin zwischen Daten und VIew vermitteln. Allerdings wird er einfach um bestimmte Ereignisse erweitert, die dann die Netwerkereignisse betreffen. Ok, dass View muss auch ein wenig erweitert werden, da hier zwischen aktivem Benutzer und inaktiven Benutzer unterschieden werden muss. So kann man dem View wie gehabt mitteilen, was gerade für eine Aktion statt findet (wer setzt wieviel, ausgeben der Karten, ...) aber natürlich darf der Spieler nicht die Karten anderer sehen oder für andere setzen, etc. Hier sollte es dann also ein Ereignis geben, dass mitteilt, dass das Formular gerade dem aktiven Spieler zugeordnet ist. Dann kann das Form entsprechende Möglichkeiten (call, pass, raise, ...) anzeigen. Die Aktion wird dann wiederum dem Controller gemeldet, der passt die Daten an und benachrichtigt über das Netzwerk alle bekannten Spieler.
Wie Du vielleicht bemerkt hast blieb das Modell wirklich völlig außen vor. Auch die Änderungen um etwas zu erweitern halten sich bei sauberer Modellierung immer in Grenzen.

Alles was Du tun must ist dazu Dein Problem (das gesamte Pokerspiel) in kleinere Teilprobleme zu zerlegen (z.B. Darstellung der Karten, Spieler, Steuerung, ...). Unterprobleme kannst Du dann noch weiter zerlegen, so besteht ein Spieler aus verschiedenen Eigenschaften, kann aktiv sein oder warten, kann callen, erhöhen, ... Hier findest Du vielleicht wiederum Probleme, die unabhängig voneinander sind (z.B. das Speichern der Daten vom Spieler und die Anzeige Selbiger). Dein eigentliches Projekt baust Du dann einfach aus den Lösungen dieser kleinen Probleme zusammen. Das hat den Vorteil, dass Du sehr leichte/kleine Probleme hast, die kann man viel besser überschauen, testen und entwickeln. Das gibt dann weniger Fehler und ist leichter wartbar.
Zudem kannst Du wenn Du das Programm erweiterst immer vieles wiederverwenden. So kann es reichen, dass Du einen solchen kleinen Teil austauscht oder erweiterst, manchmal sind es auch mehrere, aber selten oder nie alle. Hast Du hingegen eine große Unit, in der alles drin steht, dann musst Du natürlich direkt die Unit bearbeiten, die alles enthält. Gibt es hier Abhängigkeiten sind die schwerer zu berücksichtigen und Änderungen haben schnell viel größere Auswirkungen. Da ist es dann schwer den Überblick zu haben.

Gruß Der Unwissende

[.chicken]

Suuuuuuper Tips! Danke, hast mich um einiges weitergebracht, wenn weitere Fragen gibt, melde ich mich!

[.chicken]

Ok, jetzt nochmal meine genauere Planung.

Ich habe den Server, dem sind alle Klassen bekannt, das heisst zB die Spieler oder das Kartendeck.
Die Clients senden dann Befehle an den Server, welcher dann die Werte aendert (zB Geld der Spieler oder so).
Per Timer rufen die Clients dann jede Sekunde oder so, die Werte die sie zum Zeichnen brauchen ab.
(Das würd ich mit Textnachrichten oder so realisiern!?)

Hat zur Folge, dass die Clients die Klassen nicht direkt kennen, sondern nur die Infos über den Server abrufen können (Server hat die Klassen in uses und Clients den Server).

Ist das richtig gedacht so? Wird das funktioniern oder ist es sinnvoller das anders zu machen?

Will mich nochmal absichern, bevor ich die ganze Arbeit reinstecke und hinterher gehts net.

[Der_Unwissende]

Zitat von .chicken:

Per Timer rufen die Clients dann jede Sekunde oder so, die Werte die sie zum Zeichnen brauchen ab.
(Das würd ich mit Textnachrichten oder so realisiern!?)

Hat zur Folge, dass die Clients die Klassen nicht direkt kennen, sondern nur die Infos über den Server abrufen können (Server hat die Klassen in uses und Clients den Server).

Ist das richtig gedacht so? Wird das funktioniern oder ist es sinnvoller das anders zu machen?

Ich würde sagen, dass Du hier etwas anders machen kannst/solltest. So klingt es schon so, als ob auch Du mit dem Weg nicht 100%ig zufrieden bist (jeder Sekunde oder so).
Das häufige/ständige Abfragen von Werten wird als Polling bezeichnet, Du schaust ständig nach ob sich etwas geändert hat. Dabei gibt es zwei Probleme, ändert sich etwas, bekommst Du es vielleicht erst später mit (hier können 0.9999999 Sek. vergehen, bevor Du die Änderung bemerkst). Das andere Problem ist, dass Du häufig völlig umsonst nachfragst, weil sich noch überhaupt nichts geändert hat. Nicht zuletzt kann es natürlich auch zu einer gewissen Last führen, wenn alle gleichzeitig anfragen.

Der deutlich intuitivere Weg ist es, dass Du die Clienten über Änderungen Informierst. Der Server erfährt immer von jeder Änderung und das sofort. Hat sich etwas geändert, kannst Du nun alle Clienten über die Änderung informieren und dabei selbst steuern, wer wann benachrichtigt wird (ob alle nacheinander oder ein paar/alle parallel).
Somit erfahren alle Clienten schnellst möglich von Veränderungen und nur genau dann, wenn es wirklich Veränderungen gab.

Ich denke Dein vorgeschlagener Weg ist einfacher zu programmieren, aber da solltest Du selbst den jeweiligen Aufwand abschätzen. An sich denke ich, dass Du den Weg wie gesagt selbst nicht 100%ig richtig findest (kann mich da aber auch irren). An sich wird die ereignisbasierte Benachrichtigung aber häufiger begegnen, da man hier viele Ressourcen spart und sich über Dinge wie Update-Intervalle keine Gedanken machen muss (reicht eine Sekunde, erzeugt eine halbe Sekunde zu viel Last, ..).

Die Frage ist natürlich, wie benachrichtigt man alle Clienten? Dazu möchte ich einfach mal auf folgenden Thread verweisen http://www.delphipraxis.net/internal...=657757#657757
Darin wird kurz das Prinzip von Ereignissen in einer Liste (auch als Observer-Pattern bekannt) behandelt. Dieser Weg beschreibt dabei, wie man ein Ereigniss beobachtet (sich über den Eintritt benachrichtigen lässt). Das ganze kannst Du dabei auch auf das Netzwerk übertragen.
Schließt sich ein Client einem Netzwerk-Spiel an, verbindet er sich einfach mit dem Server. Dabei wird dem Server einfach mitgeteilt, dass ein neuer Spieler hinzu gekommen ist und über alle Änderungen benachrichtigt werden möchte. Beim Verbinden erhält der Server dabei automatisch alle Daten vom Clienten (IP-Adresse und Port). Der Rest (Kommunikation über Textnachrichten) kann dabei erhalten bleiben. Bekommt der Server eine Änderung mit, so schickt er einfach eine Nachricht an alle ihm bekannten Clienten.

Hoffe das hilft weiter (und klingt nicht zu kompliziert, ist es nämlich gar nicht). Schau einfach mal, wie Du selbst den Aufwand einschätzt und frag ggf. natürlich gerne wieder nach!

Gruß Der Unwissende

[.chicken]

Alsooo...das es sich so anhört als wär ich damit nicht zufrieden, lag denke ich eher an meiner Unwissenheit, aber ich sehe das Problem an meiner Lösung!

Daaaanke für deine wirklich sehr hilfreichen Lösungsansätze.

Also den Link les ich mir denke ich mal morgen genauer durch, fehlt mir jetzt die Konzentration für

Hab ja noch einen Thread eröffnet, um zu fragen ob ich ganze Klassen übers Netzwerk übertragen kann, da ist nun die Sache wie ich die Sachen übertrage auch schon wieder zum Hauptthema geworden ^^

Also du denkst immernoch das ist mit einfachen Textnachrichten möglich und am simpelsten?

[Der_Unwissende]

Zitat von .chicken:

Hab ja noch einen Thread eröffnet, um zu fragen ob ich ganze Klassen übers Netzwerk übertragen kann, da ist nun die Sache wie ich die Sachen übertrage auch schon wieder zum Hauptthema geworden ^^

Hm, ganze Klassen übertragen? Das geht nur für Klassen die serialisierbar sind, zudem müsstest Du Dir für die entsprechenden Klassen eine Serialisierung überlegen. Die einfachste währen dann einfache Strings. Natürlich spricht nichts gegen ein Byte-Format, dass direkt die Information enthält.
Die Frage wie Du hier die Informationen überträgst (quasi das gewählte Protokoll) sollten etwas mehr im Hintergrund stehen. Wichtiger ist, welche Informationen Du überträgst. Ganze Klassen zu übertragen ist häufig nicht nötig, da reicht häufig schon weniger Information aus.
Der Vorteil an einfachen Textnachrichten liegt einfach darin, dass Du sehr einfach beobachten kannst, was übertragen wurde. Für binäre Formate wird das ein wenig schwieriger, ist aber natürlich ebenso möglich! Der klare Nachteil an Textnachrichten bestünde darin, dass Du die Informationen beim Sender in einen String umwandelst, den String überträgst und beim Empfänger wieder dekodierst, nicht unbedingt der schönste/nötigste Weg!
An sich würde ich Dir jedenfalls vom Einsatz von komplett serialisierten Klassen abraten, die sind hier nicht nötig! Vielmehr läufst Du sonst Gefahr, dass Änderungen an den Klassen größere Konsequenzen haben könnten. Besser ist es, wenn Du nur die tatsächlichen Änderungen überträgst und der Empfänger dies geeignet weiter leitet (also das Update der Daten auf eigenen Klassen erfolgt).

PS.:
Sorry, bin zu faul nach dem anderen Thread zu suchen und dessen Fazit hier mit zu diskuttieren und/oder den Beitrag mit dort rein zu stellen. Falls sich also etwas wiederholt haben oder den dortigen Ansätzen wiedersprechen sollte, dann nicht wundern.

PPS.:
Eigentlich gehört ja auch jede Frage in einen eigenen Thread, also weitere Themen/Probleme lieber direkt in einem solchen eigenen Thread diskuttieren und auf den Thread verweisen (immerhin trifft das Thema Pokerprojekt realisierung ja nun auf alle Teilaspekte/Diskussionen zu).

Gruß Der Unwissende

[.chicken]

Jo, ok super danke dann werd ichs mir Textnachrichten versuchen, hab auch festgestellt, das 50% der Informationen sowieso nur für den Server von Belang sind.

Also falls ich da jetzt keinen Denkfehler gemacht hab dann muss ich garnet soviele Werte übertragen!

Nagut, danke!