- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Das stimmt nicht. Starcraft 2 ist auch Peer-to-Peer geregelt....
(also nach Spielstart)
Mit einigen zusätzliche serverseitigen Features des Battle.nets.
C&C Feedback-Montag | Teil 2 - Peer-to-Peer oder Serverbasiert?
- Thread starter freezy
- Start date
(also nach Spielstart)
Mit einigen zusätzliche serverseitigen Features des Battle.nets.
- Joined
- Jun 24, 2008
- Messages
- 6,753
- Points
- 0
Können wir uns darauf einigen das es nicht direkt P2P ist? 
Alle Daten gehen durch das Battlenet, auch während dem Spiel. Man Connectet niemals direkt zu seinem Mitspieler... Und wenn jemand lagged kommt auch "Waiting for Server" und man selbst merkt nichts davon (bis der DC Screen kommt).
Kannst du auf TL nachlesen wenn du willst...
http://www.teamliquid.net/forum/viewmessage.php?topic_id=145084
Zurück zu eigentlichen thema. Für den neuen C&C Teil würde ich auch eine Serverseitige oder Battlenet ähnliche lösung bevorzugen. Eben wegen der Fairness und den ganzen Laggern die denken Online mit ihren Holz PCs auf Max Grafik Spielen zu müssen.
Alle Daten gehen durch das Battlenet, auch während dem Spiel. Man Connectet niemals direkt zu seinem Mitspieler... Und wenn jemand lagged kommt auch "Waiting for Server" und man selbst merkt nichts davon (bis der DC Screen kommt).Kannst du auf TL nachlesen wenn du willst...
http://www.teamliquid.net/forum/viewmessage.php?topic_id=145084
Zurück zu eigentlichen thema. Für den neuen C&C Teil würde ich auch eine Serverseitige oder Battlenet ähnliche lösung bevorzugen. Eben wegen der Fairness und den ganzen Laggern die denken Online mit ihren Holz PCs auf Max Grafik Spielen zu müssen.
Last edited:
- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Die Leute da beschreiben es als routed Peer-to-Peer, also als nen Zwischending zwischen reinem P2P und serverbasiert 
Ich hatte ne ältere News auf TL gelesen (aus der Betazeit), in der ziemlich sicher verkündet wurde, dass es P2P ist. Scheinbar ist sich die Community da wohl nicht einig
Ich hatte ne ältere News auf TL gelesen (aus der Betazeit), in der ziemlich sicher verkündet wurde, dass es P2P ist. Scheinbar ist sich die Community da wohl nicht einig
- Joined
- Aug 19, 2007
- Messages
- 9,714
- Points
- 290
- Lieblings C&C
Wie ich es mir halt gedacht hab. Ist halt nen schwieriges Thema zum Diskutieren, da die wenigsten Ahnung von der Sache (technisch) haben.
Auch hab ich ehrlich gesagt kein Dunst, was man hier überhaupt diskutieren soll.
Auch hab ich ehrlich gesagt kein Dunst, was man hier überhaupt diskutieren soll.
Last edited:
- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Ich denke man kann auch ohne technisches Verständnis inhaltliches Feedback beitragen und zwar kann man seine Vorlieben über die resultierenden Eigenschaften darlegen.
Hier ein paar Punkte (diese Liste kann gerne erweitert werden):
Hier ein paar Punkte (diese Liste kann gerne erweitert werden):
- Sollte ein DC eines Mitspielers als Niederlage gewertet werden?
- Sollte ein asynchroner Spielzustand eines Mitspielers als Niederlage gewertet werden?
- Sollte die Spielgeschwindigkeit unabhängig von den Mitspielern sein?
- Wie schnell sollte die Spielgeschwindigkeit sein (im Vergleich zu bisherigen C&C Spielen)?
- Ist es annehmbar, wenn die Spielgeschwindigkeit bei einer großen Auslastung einer serverseitigen Verbindung geringer ist?
- Joined
- Aug 2, 2002
- Messages
- 25,427
- Points
- 0
Ich bin mir nicht sicher ob ein komplett serverseitiges System oder ein Hybridsystem besser ist.
In der Theorie natürlich erstmal serverseitig. Aber dort sind performance Faktoren enthalten wie die Serverfarm, der Standort der Serverfarm etc. Sprich da haben die Entwickler mehr Einblick und mehr Erfahrung als wir. Deswegen sollten sie die Entscheidung welches System verwendet wird nicht nur danach treffen, welches theoretisch, bei optimalen Einstellungen am besten fährt, sondern welches mit den von EA gegebenen tatsächlichen Vorraussetzungen die beste Performance gewährleistet.
Wenn die EA Oberen sagen "Wir geben euch zwei 486iger als Server" (überzogen dargestellt), dann macht es ja keinen Sinn alles serverseitig auszurichten.
Meine Liste:
DC=Loss: zwingend erforderlich
max. 30sec grace period: Man darf in den ersten 30sec das Spiel verlassen, wenn es laggt, ohne zu verlieren. Wenn Feindkontakt erfolgt ist gilt dies nicht mehr. Verhindert zwar nicht AM dodgen, dafür müsste die Zeit bei 0sec liegen, aber da muss man abwägen und das geringere Übel nehmen.
Async muss nicht zwingend als Loss gewertet werden - wenn serverseitig ja. In einem hybridsystem schwer. Aber auf jeden Fall den Spieler markieren, der zuviele Asyncs hat. Und mit einem Team die Daten checken. Hier wäre auch eine sync-Datei gut (wie in Ra2) die von beiden Rechner an den Server gesendet wird und dann kann dort von Personen drübergeguckt werden, bei welchem Rechner der Cheat an war. Serverseitig wäre das Automatisch möglich, da der Server selber den Spielzustand kennt. Ist halt performance lastiger als ein Hybridsystem, in dem der Server nur lauscht - und so d/c abfängt.
Spielgeschwindigkeit natürlich hoch, wie immer in den CnC Spielen.
Serververursachter Lag ist nicht hinnehmbar. Wenn das eine Gefahr ist bei der Serverfarm, die EA bereitstellt, dann bin ich stark für ein Hybridsystem.
In der Theorie natürlich erstmal serverseitig. Aber dort sind performance Faktoren enthalten wie die Serverfarm, der Standort der Serverfarm etc. Sprich da haben die Entwickler mehr Einblick und mehr Erfahrung als wir. Deswegen sollten sie die Entscheidung welches System verwendet wird nicht nur danach treffen, welches theoretisch, bei optimalen Einstellungen am besten fährt, sondern welches mit den von EA gegebenen tatsächlichen Vorraussetzungen die beste Performance gewährleistet.
Wenn die EA Oberen sagen "Wir geben euch zwei 486iger als Server" (überzogen dargestellt), dann macht es ja keinen Sinn alles serverseitig auszurichten.
Meine Liste:
DC=Loss: zwingend erforderlich
max. 30sec grace period: Man darf in den ersten 30sec das Spiel verlassen, wenn es laggt, ohne zu verlieren. Wenn Feindkontakt erfolgt ist gilt dies nicht mehr. Verhindert zwar nicht AM dodgen, dafür müsste die Zeit bei 0sec liegen, aber da muss man abwägen und das geringere Übel nehmen.
Async muss nicht zwingend als Loss gewertet werden - wenn serverseitig ja. In einem hybridsystem schwer. Aber auf jeden Fall den Spieler markieren, der zuviele Asyncs hat. Und mit einem Team die Daten checken. Hier wäre auch eine sync-Datei gut (wie in Ra2) die von beiden Rechner an den Server gesendet wird und dann kann dort von Personen drübergeguckt werden, bei welchem Rechner der Cheat an war. Serverseitig wäre das Automatisch möglich, da der Server selber den Spielzustand kennt. Ist halt performance lastiger als ein Hybridsystem, in dem der Server nur lauscht - und so d/c abfängt.
Spielgeschwindigkeit natürlich hoch, wie immer in den CnC Spielen.
Serververursachter Lag ist nicht hinnehmbar. Wenn das eine Gefahr ist bei der Serverfarm, die EA bereitstellt, dann bin ich stark für ein Hybridsystem.
- Joined
- Aug 19, 2007
- Messages
- 9,714
- Points
- 290
- Lieblings C&C
@ Osbes
Deinen 4ten Punkt versteh ich den Zusammenhang nicht. Was hat denn eine Gameplay Entscheidung mit der Entscheidung des Netzwerkstyps (Server oder P2P) zu tun ?
1. Punkt:
Ja, der einen DC hinlegt, muss ein Loss kassieren.
Gründe dafür findest hier, hier, hier, hier und hier.
2. Punkt:
Asynch ist schon schwieriger. Wenn man vorraussetzt, dass Asynchs net aufgrund von miserablen Netcode oder Bugs wie zB bei KW verursacht wird und es möglich ist, festzustellen wer diesen verursacht, dann gilt auch hier Asynch = Loss. In TW zB sind bzw waren Asynchs bei mir äußerst selten und diese in der Regel nur auf schlechten Customgames mit Unlimitd Blue Tiberium und somit Millionen Einheiten auf der Karte. Es ist also schlichtweg ein Rechner nicht mehr mit den ganzen Berechnungen hinterher gekommen (oder etwas falsch berechnet hat), was dann zum Asynch führte.
--> Ergo, sind hier eher die Programmierer gefragt, sodass der Code solcherlei Ansprüche standhält oder man fügt einen Unit-Cap ein.
Punkt 3+5:
Hab ich keine Meinung zu.
Deinen 4ten Punkt versteh ich den Zusammenhang nicht. Was hat denn eine Gameplay Entscheidung mit der Entscheidung des Netzwerkstyps (Server oder P2P) zu tun ?
1. Punkt:
Ja, der einen DC hinlegt, muss ein Loss kassieren.
Gründe dafür findest hier, hier, hier, hier und hier.
2. Punkt:
Asynch ist schon schwieriger. Wenn man vorraussetzt, dass Asynchs net aufgrund von miserablen Netcode oder Bugs wie zB bei KW verursacht wird und es möglich ist, festzustellen wer diesen verursacht, dann gilt auch hier Asynch = Loss. In TW zB sind bzw waren Asynchs bei mir äußerst selten und diese in der Regel nur auf schlechten Customgames mit Unlimitd Blue Tiberium und somit Millionen Einheiten auf der Karte. Es ist also schlichtweg ein Rechner nicht mehr mit den ganzen Berechnungen hinterher gekommen (oder etwas falsch berechnet hat), was dann zum Asynch führte.
--> Ergo, sind hier eher die Programmierer gefragt, sodass der Code solcherlei Ansprüche standhält oder man fügt einen Unit-Cap ein.
Punkt 3+5:
Hab ich keine Meinung zu.
- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Zum 4. Punkt.
Die max. Spielgeschwindigkeit hängt neben der reinen Berechnung des aktuellen Zustandes auch von der Übertragungsgeschwindigkeit der korrespondierenden Informationen zwischen den Nutzern ab.
Daher ist die maximale Spielgeschwindigkeit in der Regel (nicht immer, z.B. durch dynamischen Routing-Algorithmen kann es sich auch in Einzelfällen umkehren) bei einer Verbindung über einen Server - der recht weit entfernt ist - langsamer, als bei einer Peer-To-Peer-Verbindung zwischen zwei Freunden die nah beeinander wohnen.
Wie stark der Unterschied ist hängt dann von der Wahl der Infrastruktur ab.
Die max. Spielgeschwindigkeit hängt neben der reinen Berechnung des aktuellen Zustandes auch von der Übertragungsgeschwindigkeit der korrespondierenden Informationen zwischen den Nutzern ab.
Daher ist die maximale Spielgeschwindigkeit in der Regel (nicht immer, z.B. durch dynamischen Routing-Algorithmen kann es sich auch in Einzelfällen umkehren) bei einer Verbindung über einen Server - der recht weit entfernt ist - langsamer, als bei einer Peer-To-Peer-Verbindung zwischen zwei Freunden die nah beeinander wohnen.
Wie stark der Unterschied ist hängt dann von der Wahl der Infrastruktur ab.
- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Ich denke nicht, dass Asynch direkt nen Loss bedeuten sollte. Vielmehr sollte der Server erkennen, welcher Spieler den Asynch verursacht und ihn aus dem Spiel zwangsdisconnecten. Sollte der Spieler keine Spieldateien manipuliert haben sondern einfach nur sein Rechner mit den Berechnungen nicht mehr synchron gewesen sein, kann er nun innerhalb der Zeitlimits neu reconnecten und das Spiel kann fortgesetzt werden (Zeitlimit wie bisher 1 Minute würde ich sagen). Sollte er dies nicht schaffen, dann bekommt er den Loss über die DC = Loss Regel. So wird garantiert, dass Spiele nicht durch Asynchs versaut werden und man diese nach einem Asynch auch weiterspielen kann, wenn die Daten wieder synchronisiert sind (mithilfe des Servers).
In HoN ist es jedenfalls so, dass man mit irgendner Fehlermeldung vom Server fliegt wenn was nicht stimmt und man dann wieder reconnecten kann und die Spieldateien dabei neu zieht und so wieder synchronisiert wird.
In HoN ist es jedenfalls so, dass man mit irgendner Fehlermeldung vom Server fliegt wenn was nicht stimmt und man dann wieder reconnecten kann und die Spieldateien dabei neu zieht und so wieder synchronisiert wird.
- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Ich denke dieses Verfahren dürfte bei Command & Conquer recht schwer sein, so müsste der Server dem Spieler den gesamten Spielstand schicken, damit die Engine wieder korrekt weiterrechnen kann (immerhin sind die eigenen Daten ja korrupt, sonst hätte es keinen asynchronen Zustand gegeben). Und danach muss die Engine es schaffen auf den vom Server neu erhaltenen zustand zu wechseln.
Man könnte sicherlich mit Hilfe einer Heuristik auch nur den Datensatz ermitteln, der diesen asynchronen Zustand verursacht hat und somit die Aufwand für die Engine verringern, jedoch würde dies den Aufwand für den Programmierer - sofern solch eine Lösung nicht schon vorliegt - massiv erhöhen.
Man könnte sicherlich mit Hilfe einer Heuristik auch nur den Datensatz ermitteln, der diesen asynchronen Zustand verursacht hat und somit die Aufwand für die Engine verringern, jedoch würde dies den Aufwand für den Programmierer - sofern solch eine Lösung nicht schon vorliegt - massiv erhöhen.
- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Ist in HoN aber genauso (und das ist sehr RTS ähnlich), warum sollte es in C&C nicht gehen? Man kann doch auch Replays angucken, das wäre dann wie wenn man dem Spieler die Daten eines Zeitpunkts im Replay schickt (der Server hat ja die korrekten und synchronen Daten). Wenn man schon Server nutzt, dann sollte man auch die ganze featurepalette nutzen können, und das gehört dazu imo ^^. Sonst kann man im Grunde auch nen Hybridsystem nutzen wo der Server nur bissl überwacht.
- Joined
- Aug 2, 2002
- Messages
- 25,427
- Points
- 0
Das wäre dann zwangsläufig eine serverbasierte Lösung, mit einer Hybridlösung wäre das nicht möglich.
Ich frag mich auch wie das technisch dann gelöst wird bei HoN mit den Spieldaten neu senden und neu synchronisieren. Klingt für mich auf den ersten Blick jetzt nicht einfach. Und insbesondere bei 'oldschool' RTS Spielen wo der Focus auf 1on1 und 2on2 liegt ist es in Sachen Coding wohl sinnvoller es ordentlich so zu programmieren das die Spiele nur äußerst selten out of sync laufen (abgesehen von der Cheatprotection), sprich ich würde die Codingzeit in die Ursache stecken. Und nicht versuchen die Auswirkung durch einen resync Mechanimus zu fixen, der dann auch das große Async Problem, nämlich die Cheats nicht fixen kann. Bzw. die Cheats können sich dadurch auch sehr gut vortasten, was sie sich erlauben können, bevor der Server den resync durchführt. Schlupflöcher gibt es da immer. Siehe Ra2-Präsidenten oder die ganzen Map und Foghacks. Und wenn der Cheat nen resync verursacht, dann wird er einfach deaktiviert und versucht es ne Minute später mit ner anderen Subroutine neu.
edit: Ich führs mal etwas näher anhand eines Beispiels aus:
Stell dir für Spieler X benutzt einen Maphack - keinen Foghack, er kann also gegnerische Einheiten die sich unter dem Schatten befinden angreifen.
Spieler X macht nun genau das, er gibt einen Angriffsbefehl auf eine Einheit die er eigentlich gar nicht sehen kann.
Im Spiel seines Gegners wandelt die Engine diesen Angriffsbefehl in einen Bewegenbefehl um, da sie ja nicht "weiß" das dort im Schatten eine Einheit ist.
Hier kommt dann der Async. Klar. Spieler X hat gecheatet. Zum Schutz muss das Spiel hier stoppen.
In dem 'HoN' System hat Spieler X jetzt die Möglichkeit diesen Fehler rückgängig zu machen und eben nicht den Angriffsbefehl zu geben, bzw. dieser wird automatisch umgewandelt in einen Bewegenbefehl, wenn der Server die Daten neu sendet. Spieler X, der Cheater, wurde nun erfolgreich vom Spiel beschützt und darf dieses Spiel weitercheaten. Ob dann im Hintergrund der Async ausgewertet wird und der Spieler im Nachhinein bestraft wird ist eine andere Frage. Dann hat man aber zumindest die Zeit seines Gegners verschwendet.
Ich frag mich auch wie das technisch dann gelöst wird bei HoN mit den Spieldaten neu senden und neu synchronisieren. Klingt für mich auf den ersten Blick jetzt nicht einfach. Und insbesondere bei 'oldschool' RTS Spielen wo der Focus auf 1on1 und 2on2 liegt ist es in Sachen Coding wohl sinnvoller es ordentlich so zu programmieren das die Spiele nur äußerst selten out of sync laufen (abgesehen von der Cheatprotection), sprich ich würde die Codingzeit in die Ursache stecken. Und nicht versuchen die Auswirkung durch einen resync Mechanimus zu fixen, der dann auch das große Async Problem, nämlich die Cheats nicht fixen kann. Bzw. die Cheats können sich dadurch auch sehr gut vortasten, was sie sich erlauben können, bevor der Server den resync durchführt. Schlupflöcher gibt es da immer. Siehe Ra2-Präsidenten oder die ganzen Map und Foghacks. Und wenn der Cheat nen resync verursacht, dann wird er einfach deaktiviert und versucht es ne Minute später mit ner anderen Subroutine neu.
edit: Ich führs mal etwas näher anhand eines Beispiels aus:
Stell dir für Spieler X benutzt einen Maphack - keinen Foghack, er kann also gegnerische Einheiten die sich unter dem Schatten befinden angreifen.
Spieler X macht nun genau das, er gibt einen Angriffsbefehl auf eine Einheit die er eigentlich gar nicht sehen kann.
Im Spiel seines Gegners wandelt die Engine diesen Angriffsbefehl in einen Bewegenbefehl um, da sie ja nicht "weiß" das dort im Schatten eine Einheit ist.
Hier kommt dann der Async. Klar. Spieler X hat gecheatet. Zum Schutz muss das Spiel hier stoppen.
In dem 'HoN' System hat Spieler X jetzt die Möglichkeit diesen Fehler rückgängig zu machen und eben nicht den Angriffsbefehl zu geben, bzw. dieser wird automatisch umgewandelt in einen Bewegenbefehl, wenn der Server die Daten neu sendet. Spieler X, der Cheater, wurde nun erfolgreich vom Spiel beschützt und darf dieses Spiel weitercheaten. Ob dann im Hintergrund der Async ausgewertet wird und der Spieler im Nachhinein bestraft wird ist eine andere Frage. Dann hat man aber zumindest die Zeit seines Gegners verschwendet.
- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Zu freezy:
Es ist wie schon beschrieben möglich, in dem man die wesentliche Zustände des Spiel sendet und die Engine nun zu diesen Zuständen wechseln kann. Wenn die Engine nicht lokal läuft (im Sinn des Cloud Computing), so geht dies natürlich ohne weiteren Aufwand, aber dies nur am Rande, leztztlich ist dies für C&C nicht relevant.
Letztlich sehe ich es aber wie Mooff, dass der Aufwand für die Implementierung einer Resynchronisierung (bzw. des Beitretens eines laufenden Spiels) nur einen seher geringen Nutzen für Command & Conquer mit sich bringen wird.
Ein hybrides System ist sicherlich ein guter Kompromiss, jedoch wäre dann die Frage, was der Server leisten soll. Sofern es nur den Verbindungsabbruch einem Spieler zuordnen soll, jedoch nicht einen asynchronen zustand, so muss dieser das Spiel nicht direkt kontrollieren und somit auch nicht selbst das Spiel zumindest logisch durchlaufen.
Da oft der Vergleich zu StarCraft2 gezogen wird möchte ich darauf Hinweisen, dass dort der Server insbesondere für das Routing genutzt wird, so dass jeder Nutzer nur eine Verbindung zum Server aufbaut und dieser dann die Daten weiterleitet. Damit umgeht man einige Probleme aus dem direkten Verbindungsaufbau zwischen den Nutzern.
Es ist wie schon beschrieben möglich, in dem man die wesentliche Zustände des Spiel sendet und die Engine nun zu diesen Zuständen wechseln kann. Wenn die Engine nicht lokal läuft (im Sinn des Cloud Computing), so geht dies natürlich ohne weiteren Aufwand, aber dies nur am Rande, leztztlich ist dies für C&C nicht relevant.
Letztlich sehe ich es aber wie Mooff, dass der Aufwand für die Implementierung einer Resynchronisierung (bzw. des Beitretens eines laufenden Spiels) nur einen seher geringen Nutzen für Command & Conquer mit sich bringen wird.
Ein hybrides System ist sicherlich ein guter Kompromiss, jedoch wäre dann die Frage, was der Server leisten soll. Sofern es nur den Verbindungsabbruch einem Spieler zuordnen soll, jedoch nicht einen asynchronen zustand, so muss dieser das Spiel nicht direkt kontrollieren und somit auch nicht selbst das Spiel zumindest logisch durchlaufen.
Da oft der Vergleich zu StarCraft2 gezogen wird möchte ich darauf Hinweisen, dass dort der Server insbesondere für das Routing genutzt wird, so dass jeder Nutzer nur eine Verbindung zum Server aufbaut und dieser dann die Daten weiterleitet. Damit umgeht man einige Probleme aus dem direkten Verbindungsaufbau zwischen den Nutzern.
- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Vermutlich hast du Recht, dass für C&C ein Hybridsystem ausreichend ist und der Server wie in SC2 nur das Routing und Datenflow übernimmt, wodurch man die gängigsten MP Probleme beheben kann. In HoN dauern die Spiele ja schon um einiges länger als in C&C, sodass hier die Serverfeatures mehr Sinn machen.
Ich weiß grad nicht wie das in SC2 ist, da ich es ewig nicht mehr gespielt hab: Hier laggt das ganze doch auch nur für den Lagger und nicht für die anderen Spieler, oder? Liegt dies an der verwendeten Engine oder resultiert dies daraus, dass alles über den Server geroutet wird?
Ich weiß grad nicht wie das in SC2 ist, da ich es ewig nicht mehr gespielt hab: Hier laggt das ganze doch auch nur für den Lagger und nicht für die anderen Spieler, oder? Liegt dies an der verwendeten Engine oder resultiert dies daraus, dass alles über den Server geroutet wird?
- Joined
- Aug 2, 2002
- Messages
- 25,427
- Points
- 0
Man kann sowas wohl teilweise in die Engine reinschreiben.
Wenn die Prozessorpower nicht da ist und das Spiel auf dem Rechner nicht schneller laufen kann, dann laggt es für beide Spieler. Ziemlich schwer das zu ändern, sollte aber selten vorkommen - vielleicht wenn man nebenbei einen HD-Film laufen lässt. :P
Die Limitierung könnte oft von der Grafikkarte kommen und wenn die eigentliche Spielberechnung und die optische Darstellung getrennt ist, dann kann man der Engine sagen sie soll vom Prozessor aus immer 40fps liefern - und dann halt Frames skippen in der grafischen Darstellung.
(nur ein Gedanke, ob das technisch möglich ist bleibt fraglich)
Wie und ob Starcraft2 Lagger abstraft hab ich aber keine Ahnung. Zumindest kommt es auf Streams öfters vor das die Spieler sich über Lag beschweren und dann ein Observer rausgeht. Von daher ist anzunehme ndas Sc2 dies nicht bietet.
Wenn die Prozessorpower nicht da ist und das Spiel auf dem Rechner nicht schneller laufen kann, dann laggt es für beide Spieler. Ziemlich schwer das zu ändern, sollte aber selten vorkommen - vielleicht wenn man nebenbei einen HD-Film laufen lässt. :P
Die Limitierung könnte oft von der Grafikkarte kommen und wenn die eigentliche Spielberechnung und die optische Darstellung getrennt ist, dann kann man der Engine sagen sie soll vom Prozessor aus immer 40fps liefern - und dann halt Frames skippen in der grafischen Darstellung.
(nur ein Gedanke, ob das technisch möglich ist bleibt fraglich)
Wie und ob Starcraft2 Lagger abstraft hab ich aber keine Ahnung. Zumindest kommt es auf Streams öfters vor das die Spieler sich über Lag beschweren und dann ein Observer rausgeht. Von daher ist anzunehme ndas Sc2 dies nicht bietet.
- Joined
- Sep 26, 2002
- Messages
- 62,151
- Points
- 615
Das fände ich ziemlich fail, da meines Erachtens doch die Lagfreiheit so nen tolles feature von WC3 und SC2 sein sollte? Oder verwechsel ich das? ^^
Indem man es über den Server routet kann man ja eigentlich auch keinen Lag umgehen oder? Die Daten werden ja nur weitergeleitet und nicht irgendwie ausgewertet, sodass der Server dann sagt "skip frame XY". In dem Fall wäre es also wohl nur über eine sehr schlaue Engineprogrammierung (ich halte allerdings Blizzard für schlau und nichtmal die sollen das geschafft haben?) oder halt doch über eine volle serverseitge Lösung möglich?
Indem man es über den Server routet kann man ja eigentlich auch keinen Lag umgehen oder? Die Daten werden ja nur weitergeleitet und nicht irgendwie ausgewertet, sodass der Server dann sagt "skip frame XY". In dem Fall wäre es also wohl nur über eine sehr schlaue Engineprogrammierung (ich halte allerdings Blizzard für schlau und nichtmal die sollen das geschafft haben?) oder halt doch über eine volle serverseitge Lösung möglich?
- Joined
- Aug 2, 2002
- Messages
- 25,427
- Points
- 0
Lagfreiheit kriegste auch einfacher hin. ^^
Mindestanforderungen, die man auf die Packung schreibt hoch.
Grafikeffekte und Physikeffekte runter.
Ist halt ein Feature was bei RTS schwierig ist. Eben weil eine komplett serverseitige Lösung unglaublich viel Performance frisst. Shooter fressen da weniger, weswegen es dort Standard ist.
Mindestanforderungen, die man auf die Packung schreibt hoch.
Grafikeffekte und Physikeffekte runter.
Ist halt ein Feature was bei RTS schwierig ist. Eben weil eine komplett serverseitige Lösung unglaublich viel Performance frisst. Shooter fressen da weniger, weswegen es dort Standard ist.
- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Das Routing über den SC2-Server sollte zunächst keinen Einfluss darauf haben, ob der Lag bei allen oder nur bei einzelnen Spielern auftritt, da es zunächst keinen Unterschied zwischen anderen Knotenpunkten macht.
Es verringert jedeoch den Übertragungsaufwand für den jeweiligen Spieler, da der Server einen Multicast realisieren kann. Dies bedeutet, dass du deine Aktionen nicht an jeden einzelnen Peer senden musst, sondern dass du diese nur an den Server sendest und dieser diese Aktionen an alle anderen Mitspieler verteilt. Dadurch ist der benötigt Upload des jeweiligen Spielers zunächst unabhängig von der Anzahl an Spielern, da der jeweilige Server an den du die Daten sendest, diese erst an die anderen Mitspieler aufteilt.
Auch der Download könnte sich dadurch verringern, in dem der Server die Aktionen der anderen Mitspieler in gebündelten Paketen zusammenfasst. Je nachdem wie der Server die Daten weiterleitet (d.h. in welchem OSI-Layer man einsteigt), geht dies automatisch oder ist mit leichtem Aufwand verbunden.
Man könnte natürlich auch ohne einen Server in einem reinen Peer-to-Peer-Netz den Upload verringern, in dem der leistungsstärkste Peer einen Multicast realisiert, oder mehrere Peers kleinere Multicasts realisieren, jedoch ist dies sehr aufwendig und erhöht die Anzahl der Routingprobleme, gerade wenn es eine dynamische Bestimmung der leistungsstärksten Peers gibt, um z.B. einen - aufgrund der größeren Auslastung im Multicast - entstehenden Hotspot auszugleichen, welcher die Leistung wieder verringern würde.
Fazit zu den beiden oberen Absätzen:
Bei einem Routing über einen zentralen Server ist die benötigte Übertragungsleistung des Uploads unabhängig von der Anzahl der Spieler, was Geschwindigkeitseinbrüche durch langsame Verbindungen deutlich verringert.
Dieser Vorteil kommt natürlich erst bei Spielen mit mehr als zwei Spielern zum tragen.
Es ist jedoch zusätzlich denkbar, dass die Engine in einem Peer-to-Peer-Netzwerk (mit oder ohne Routing über einen zentralen Server) in der Lage ist die Spielgeschwindigkeit nicht vom langsamten Spieler abhängig zu machen, ohne dass dies zu asynchronen Zuständen führt, jedoch fällt mir zugegebenermaßen zunächt keine Lösung ein, welche sich nicht zusätzlich deutlich negativ auf die Spielgeschwindigkeit auswirkt, denn jede Lösung benötigt eben auch Rechenleistung.
Es verringert jedeoch den Übertragungsaufwand für den jeweiligen Spieler, da der Server einen Multicast realisieren kann. Dies bedeutet, dass du deine Aktionen nicht an jeden einzelnen Peer senden musst, sondern dass du diese nur an den Server sendest und dieser diese Aktionen an alle anderen Mitspieler verteilt. Dadurch ist der benötigt Upload des jeweiligen Spielers zunächst unabhängig von der Anzahl an Spielern, da der jeweilige Server an den du die Daten sendest, diese erst an die anderen Mitspieler aufteilt.
Auch der Download könnte sich dadurch verringern, in dem der Server die Aktionen der anderen Mitspieler in gebündelten Paketen zusammenfasst. Je nachdem wie der Server die Daten weiterleitet (d.h. in welchem OSI-Layer man einsteigt), geht dies automatisch oder ist mit leichtem Aufwand verbunden.
Man könnte natürlich auch ohne einen Server in einem reinen Peer-to-Peer-Netz den Upload verringern, in dem der leistungsstärkste Peer einen Multicast realisiert, oder mehrere Peers kleinere Multicasts realisieren, jedoch ist dies sehr aufwendig und erhöht die Anzahl der Routingprobleme, gerade wenn es eine dynamische Bestimmung der leistungsstärksten Peers gibt, um z.B. einen - aufgrund der größeren Auslastung im Multicast - entstehenden Hotspot auszugleichen, welcher die Leistung wieder verringern würde.
Fazit zu den beiden oberen Absätzen:
Bei einem Routing über einen zentralen Server ist die benötigte Übertragungsleistung des Uploads unabhängig von der Anzahl der Spieler, was Geschwindigkeitseinbrüche durch langsame Verbindungen deutlich verringert.
Dieser Vorteil kommt natürlich erst bei Spielen mit mehr als zwei Spielern zum tragen.
Es ist jedoch zusätzlich denkbar, dass die Engine in einem Peer-to-Peer-Netzwerk (mit oder ohne Routing über einen zentralen Server) in der Lage ist die Spielgeschwindigkeit nicht vom langsamten Spieler abhängig zu machen, ohne dass dies zu asynchronen Zuständen führt, jedoch fällt mir zugegebenermaßen zunächt keine Lösung ein, welche sich nicht zusätzlich deutlich negativ auf die Spielgeschwindigkeit auswirkt, denn jede Lösung benötigt eben auch Rechenleistung.
- Joined
- Oct 29, 2008
- Messages
- 983
- Points
- 0
Mal ein paar fragen, da es ein paar Sachen gibt, die mir nicht schlüssig werden.
Kann ich bei einem "Serverbasiertes Netzwerk" selber hosten oder machen es "Bots"? Sprich: Ich gehe in die Lobby und warte bis der Bot öffnen bzw. sehe ein Spiel von Bots zu jeder Karte?
Wenn Serverbasiertes Netzwerk so gut ist, wie es der Threadersteller oben gut redet, warum haben die es dann bisher noch nicht verwendet?
Wäre es nicht möglich, dass man beide Systeme, also PeertoPeer und Serverbasiertes Netzwerk, einbringt?
Also würde ich dann Peer to Peer für Automatches einfügen und Serv. bas. Netwerke für Fungamer!
Kann ich bei einem "Serverbasiertes Netzwerk" selber hosten oder machen es "Bots"? Sprich: Ich gehe in die Lobby und warte bis der Bot öffnen bzw. sehe ein Spiel von Bots zu jeder Karte?
Wenn Serverbasiertes Netzwerk so gut ist, wie es der Threadersteller oben gut redet, warum haben die es dann bisher noch nicht verwendet?
Wäre es nicht möglich, dass man beide Systeme, also PeertoPeer und Serverbasiertes Netzwerk, einbringt?
Also würde ich dann Peer to Peer für Automatches einfügen und Serv. bas. Netwerke für Fungamer!
- Joined
- Aug 19, 2007
- Messages
- 9,714
- Points
- 290
- Lieblings C&C
Das fände ich ziemlich fail, da meines Erachtens doch die Lagfreiheit so nen tolles feature von WC3 und SC2 sein sollte? Oder verwechsel ich das? ^^
Indem man es über den Server routet kann man ja eigentlich auch keinen Lag umgehen oder? Die Daten werden ja nur weitergeleitet und nicht irgendwie ausgewertet, sodass der Server dann sagt "skip frame XY". In dem Fall wäre es also wohl nur über eine sehr schlaue Engineprogrammierung (ich halte allerdings Blizzard für schlau und nichtmal die sollen das geschafft haben?) oder halt doch über eine volle serverseitge Lösung möglich?
Ich kann mich nicht daran errinnern, dass Wc3 oder sc2 oder irgendein anderes Blizzspiel wegen Lagreiheit gelobt wurde. Wofür sc2 allerdings mitunter kritisiert wird, ist der relativ hohe Ping. Aber fragt mich diesbezüglich bitte nicht nach Einzelheiten.
Sc2 differenziert zwischen Lags wegen schlechten Internet und lags wegen "rechner ist am verglühen wegen zu vieler Berechnungen".
Bei ersteren merkt man das Ruckeln, aber im Wesentlichen kommen solche Lags nur zustande, wenn die Verbindung, aus welchen Gründen auch immer, instabil sind, aber nicht wegen zu langsamer Leitung. (Man vergleiche zB Replaygrößen von sc2 und einem C&C)
Bei zweiteren, wird das Spiel langsamer und man bekommt eine Meldung wer das Spiel ausbremmst.
Similar threads
