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