spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich verstehe deine Frage nicht ganz.
Der Server muss eine Verbindung zu jedem Client haben. Die Clients untereinander haben normalerweise keine Verbindung.
Gedanken machen solltest du dir darüber, wie du mit verlorenen, beschädigten oder in falscher Reihenfolge ankommenden Datenpaketen umgehst, denn dies kommt bei UDP vor.
Außerdem musst du mit der Latenz umgehen können, d.h. Pakete können z.B. 100 ms benötigen um zwischen Server und Client ausgetauscht zu werden. Idealerweise berechnet der Client schon vorher die Auswirkungen der Aktionen des Spielers (Client-side prediction), da ein hohes Delay den Spieler sonst stark benachteiligen und zu einer sehr schwammigen Steuerung führen würde. Natürlich muss der Client sich vom Server "korrigieren" lassen, wenn die Client-side prediction auf Grund einer anderen/veralteten Sicht auf die Spielsituation falsch lag.
Das ist sowieso ein generelles Problem: jeder Spieler hat eine andere Sicht auf das Spiel, da die Informationen immer bereits veraltet sind, wenn sie ankommen. Das führt dann zu Situationen, die man nicht lösen kann, ohne einen Spieler zu benachteiligen. Bekannt ist sowas z.B. von Counter Strike, wo jemand noch getroffen wird, obwohl er aus seiner Sicht bereits um eine Ecke in Sicherheit gelaufen ist. Aus der Sicht des anderen war er jedoch noch sichtbar und zu treffen ...

So wie ich das verstehe möchtest du nur einen Server, der zwischen den Clienten ein Peer-to-peer netzwerk erstellt ? weil sonst lohnt sich UDP eigentlich nicht so richtig. mit einem Server in der Mitte solltetest du TCP benutzten. Bei einem Peer-to-peer netzwerk soll es auch mit tcp gehen (hab ich mal irgendwo gelesen). Ich glaube raknet kann sowas, also mit mehreren clienten.

Bist du dir denn darüber im klaren, ob du eher ein Lobbyserver haben willst, der von Spieler gehostete Server auflistet oder willst du die Spielinstanzen zusammen mit dem Lobbyserver laufen lassen? In beiden Fällen kann es eigentlich nicht schaden, wenn pro Spielinstanz auch ein zufälliger Port geöffnet wird (gibt ja genug): man erspart sich das Zuordnen der Pakete zu den Spielinstanzen, hat eine klarere Trennung und man kann so eine Spielinstanz dann auch einfach auf einem anderen Rechner laufen lassen, aber man hat natürlich den "Nachteil", dass man den Netzwerkteil dann mehrfach laufen lässt, was aber je nach Implementierung kaum ins Gewicht fällt.

P.S: Der P2P Gedanke ist prinzipiell Protokoll unabhängig, aber mit UDP ist ein punchthrough durch NATs möglich, weshalb es für P2P klare Vorteile zeigt. UDP ist wunderbar geeignet, wenn einem Paketverluste egal sind, was z.B. bei A-Man in sehr guter Näherung gegeben ist, wenn man einfach den gesamten Zustand immer rüberschickt (komprimiert nat.) oder wie in UT mit "delta-states/state-changes" rangeht.