Netzwerkspiel

[flashray]

Hallo,

ich brauche eine Strategie um ein Netzwerkspiel zu programmieren.

Unzwar ist mir unklar, wie die Synchronisation von Server und den Clienten erfolgt. Also eine asynchrone Kommunikation in dem der Client eine Nachricht schickt, daraufhin der Server antwort und ähnliches ist kein Problem.

Aber?

Folgendes simples mini Beispiel Szenario:
Ein Server und ein Client haben beide das gleiche JFrame vor sich. Darin befinden sich zwei Komponenten beispielsweise JLabels mit dem Benutzernamen, stellvertretend für je einen der Mitspieler. Jeder soll einen dieser, das eigene per Maus beliebig verschieben können.

Wie geht man hier vor? Sollte es nur ein JFrame und zwei JLabels auf dem Server geben. Und bei jeder Änderung wird diese komplett auf den Clienten geschickt und angezeigt? Oder gibt es von der selben Applikation mehrere Instanzen, und nur die Positionen der Labels werden jeweils ausgetauscht?

Kann mir da jemand eine grobe Strategie geben wie ich das hier bei dem einfachen Beispiel machen sollte, und wie es bei komplexen Spielen besser wäre?


Vg Erdal

 

[tobias_petry]

generell verschickt man bei netzwerkprogrammierung so wenig daten wie möglich, damit es auch genauso gut für online-zwecke nutzen könnte
Bei deinem Beispiel ist schwer zu erkennen was passiert, wird die neue Position des JLabels schon dargestellt wenn man es beim verschieben noch nicht losgelassen hat oder erst beim Loslassen?
Generell würde ich aber sagen, dass Positionsdaten übergeben werden und jedes neue Datenpaket sollte eine Nummer bekommen, damit du beim Client alte Datenpakete rausfiltern kannst, die schon überholt sind.

 

[flashray]

Hallo,

wäre es dann besser die Positionsinformationen per Thread in gewissen Zeitabständen zu schicken, oder immer nur dann wenn der User per Mouse oder Tastatur die eigene "Spielfigur" bewegt?


Vg Erdal

 

[MeinerEiner_80]

Moin!
Auch das hängt meiner Meinung nach davon ab, was genau du tun willst.
Wenn die Bewegungen sofort sichtbar sein bzw. die Änderungen sofort angezeigt werden sollen, müsstest du auch bei jeder Änderung durch den Nutzer die Informationen senden.
Wenn die Änderungen nicht sofort angezeigt werden müssen, würde ich wahrscheinlich eine intervall artige Aktualisierung bevorzugen..

*grüssle*
MeinerEiner

 

[flashray]

Hallo,

in ca. 2 Monaten soll es ein 3D Multiplayer Bomberman werden, so jedenfalls die Aufgabenstellung.

Aus euren Antworten interpretiere ich dann, das bei jeder Interaktion der Mitspieler die Teilnehmer synchronisiert werden sollten. Bei einem Brettspiel, wie Schach würde es vielleicht auf die halbe Sekunde nicht ankommen, hier jedoch schon gedenke ich.

Eine weitere Frage in diesem Zusammenhang:
Unzwar soll ein Teilnehmer ein Netzwerkspiel beginnen, und andere können mit daran teilnehmen. D.h. der initierende startet/ist den/der Server, die anderen sind die Clienten.

Wäre es von der Software-Architektur her besser, wenn der Initierende, der zuerst ein Netzwerkspiel startet auch ein interner/der erste und zunächst einzige Client neben dem Server auf dem gleichen System ist, oder nicht?

Ist mir eben so eingefallen, weiss aber nicht ob das Sinn macht!

Vg Erdal

 

[flashray]

Hallo,

ich glaube ich habe gefunden, welche Client Server Architektur man hier als Basis nehmen könnte: Einen Chatserver und -Clienten.

Bei einem Chat können, alle Clienten zu jeder Zeit Eingaben machen, die dann sofort bei allen sichtbar sind.

Werde mal in der Richtung recherchieren, wie ein einfacher Java-Chat aufgebaut ist.


Vg Erdal

 

[MeinerEiner_80]

Moin again!
Bin mir nicht sicher, ob ich dich da richtig verstanden habe, aber ich versuchs mal.
Prinzipiell denke ich mal das es egal ist, fände es aber schöner, wenn bei der Spielinitinierung nur erstmal der Server gestartet wird. Jeder Nutzer hat dann auch die Möglichkeit, sich mit einem Client zum Server zu verbinden.
Warum? Vielleicht möchte man garnicht als Client dem Spiel beitreten, sondern nur den Serverdienst zur Verfügung stellen.
Allerdings hat das wenig mit der Software-Architektur zu tun, sondern nur das Startverhalten der Software, von daher bin ich mir wie gesagt nicht sicher, ob darauf deine Frage rauslief. Architekturtechnisch sollte es aber auf jeden Fall so sein, das Client- und Servermodul strikt getrennt sind.

*grüssle*
MeinerEiner

 

[flashray]

Hallo MeinerEiner,

der Initierer wird auch auf jedenfall mitspielen. Natürlich wird er zunächst einen Server starten, damit sich andere Teilnehmer nach Wunsch verbinden können.

Für den Initierer habe ich aber die Alternative dessen Spiel Logik mit in den Server zu packen, oder für ihn wird ebenfalls ein Client gestartet, so dass es nur Spieler gibt die Clienten sind, wobei auf dem Rechner der das Spiel gestartet hat sowohl der Server als auch der eigene Client läuft.

Meine Frage zielte darauf ab, ob das so vielleicht programmiertechnisch einfacher zu realisieren ist, und die Informationsverteilung leichter wäre, weil die Informationen einfach an alle Clienten geschickt wird, und die Rollenverteilung strikter ist.


Vg Erdal

 

[tobias_petry]

es sollte4 auf jedenfall so sein, denn wenn du von dem Prinzip abweichst, dass es einen broadcast-server und nur clienten gibt wird das entwickeln schwieriger und unnötig komplex wenn es vllt nacher auch einfach nur eine server-software geben soll

 

[MeinerEiner_80]

Für den Initierer habe ich aber die Alternative dessen Spiel Logik mit in den Server zu packen, oder für ihn wird ebenfalls ein Client gestartet, so dass es nur Spieler gibt die Clienten sind, wobei auf dem Rechner der das Spiel gestartet hat sowohl der Server als auch der eigene Client läuft.

Wie ich schon sagte, Client und Sermodul, bzw. Spieler und Server strikt trennen.
Der Initierer sollte sich ebenfalls als Spieler extra zum Server verbinden.
Aber, die Logik die für die Verwaltung und Initierung des Spiels nötig ist, solltest du auch in den Server packen...

*grüssle*
MeinerEiner