Wieviele menschliche Gegner würde ein MP Spiel verkraften, wenn die Bandbreite des Internets kein limitierender Faktor w
-
Gruum schrieb:
Also Rechenleistung sehe ich nicht als Problem an. Um die 1000 Spieler sollte ein halbwegs moderner PC berechnen können. Wenn man die Spielmechanik simpel hält und der Rechenbedarf nur linear wächst dann wären denke ich sogar bis zu 50000 Spieler möglich.
Es wurde hier als Beispiel Battlefield genannt, bzw. Egoshooter. Das halte ich für keine sehr einfache Spielmechanik. Klar dürfte es bei Schach nicht so ein grosser Rechenaufwand sein. Allerdings habe ich auch noch nie ein Schachspiel mit 1000 Spielern gesehen
Gruum schrieb:
Der Bedarf an Bandbreite, der nun mal unweigerlich quadratisch mit der Anzahl der Spieler wächst wird hier eher das Problem sein.
Er wächst aber nur beim Server quadratisch. Beim Client ist dieser weiterhin linear. Und heutige Server werden mit Glasfaser bedient. Ich glaube nicht, dass da die Bandbreite wirklich eine grosse Rolle spielt. Diese Menge an Daten zu verarbeiten aber schon eher.
Grüssli
-
Ok hab mal den Bedarf an Bandbreite überschlagen. 1000 Spieler müssten von der Seite aus auch möglich sein. Aber billig ist es nicht.
-
Gruum schrieb:
Ok hab mal den Bedarf an Bandbreite überschlagen. 1000 Spieler müssten von der Seite aus auch möglich sein. Aber billig ist es nicht.
Und auf welchen Bandbreitenbedarf bist du gekommen?
-
Bei 40 Bytes die pro Spieler anfallen und an alle geschickt werden müssen und das 4 mal in der Sekunde komme ich bei 1000 Spielern auf etwa 150 Megabytes/s.
-
Gruum schrieb:
Wenn man die Spielmechanik simpel hält und der Rechenbedarf nur linear wächst dann wären denke ich sogar bis zu 50000 Spieler möglich.
Beide diese Annahmen sind höchstwahrscheinlich falsch. Die Spielmechanik ist in der Regel nicht simpel und der Aufwand ist aus dem gleichen Grund nicht linear, wie die Bandbreite nicht linear ist: Die Spieler interagieren. Selbst wenn es nur auf niedrigstem Niveau die Berechnung ist, welcher Spieler welche Auswirkungen der Aktionen anderer Spieler sieht, so ist dies schon quadratisch. Der Code dahinter dürfte auch kaum oder gar nicht parallelisiert sein, weil:
1. Ein Egoshooter kein MMO ist. Alle Spieler wechselwirken gleichzeitig miteinander. Das macht Parallelisierung sehr kommunikationsintensiv und damit ineffizient.
2. Es besteht vermutlich auch kein großes Interesse, einen Shooter für Hunderte von Spielern zu optimieren.
-
Gruum schrieb:
Bei 40 Bytes die pro Spieler anfallen und an alle geschickt werden müssen und das 4 mal in der Sekunde komme ich bei 1000 Spielern auf etwa 150 Megabytes/s.
Ping 250 ms? Inakzeptabel.
-
Ach blödsinn, die Spieler interagieren kaum und die Spieler zu finden die miteinander agieren geht auch schneller als quadratisch.
Mal abgesehen davon war für Spiele wie Battlefield meine erste Schätzung von 1000 Spielern relevant, also schon deutlich weniger als bei einem simplen spiel mit linearem Rechenbedarf.
Beim parallelisieren sehe ich auch keine besonderen Probleme. Aber keine Ahnung ob es gemacht wird. Wenn man viele Spieler will dann wird man es wohl tun, für 64 Spieler ist es eher unnütz.
-
Gruum schrieb:
Beim parallelisieren sehe ich auch keine besonderen Probleme.
Ich schon. Wie willst du X gleichzeitig interagierende Objekte effizient parallelisieren? Übliche Strategien beruhen da drauf, dass solche Interaktionen eben nicht zwischen allen Objekten gleichzeitig stattfinden (zum Beispiel beim genannten MMORPG kann man die Welt in Zellen aufteilen und nur die (in der Regel wenigen) Spieler in einer Zelle werden von einer CPU berechnet), aber hier liegt dieser Fall ja gerade nicht vor.
Ach blödsinn, die Spieler interagieren kaum
Blödsinn ist höchstens die Annahme, dass wenig quadratisch nicht quadratisch wäre. Zudem ist egal, wie viel Interaktion tatsächlich stattfindet, wenn der Aufwand, dies heraus zu finden, quadratisch steigt.
und die Spieler zu finden die miteinander agieren geht auch schneller als quadratisch.
So? Wie? Ich kann mir ja mit Einschränkungen (begrenzte Wechselwirkungsreichweite, also begrenzte Sicht-, Schuss-, Hörweite) noch N*log(N) vorstellen, aber dann sind wir wieder beim MMORPG (siehe oben), bei einem typischen Egoshooter hat man diese Einschränkungen eben gerade wieder nicht.
-
Nehmen wir an es schießen grad mehrere Spieler. Das Problem ist nun zu berechnen was die einzelnen Schüsse treffen.
Parallelisieren lässt sich das ziemlich einfach, jeder Schuss kann unabhängig voneinander berechnet werden.
Selbst wenn man nur einen einzelnen Schuss parallelisieren will geht das. Für mehrere Objekte berechnet man unabhängig voneinander ob der Schuss das Objekt treffen würde. Das ist natürlich spekulativ wenn der Schuss nur das erste Objekt auf der Flugbahn trifft, kann man die Ergebnisse von den anderen Objekten verwerfen.Um nicht jedes einzelne Objekt auf Kollision mit dem Schuss überprüfen zu müssen kann man z.B. irgendwelche space partitioning trees benutzen. Dadurch ist die Komplexität eben nicht mehr n pro Schuss sondern nur noch log(n)² oder so.
-
Gruum schrieb:
Bei 40 Bytes die pro Spieler anfallen und an alle geschickt werden müssen und das 4 mal in der Sekunde komme ich bei 1000 Spielern auf etwa 150 Megabytes/s.
Nur 40 Bytes?
Ich brauche von jedem Spieler mindestens eine Position und eine Blickrichtung.
Also mindestens 3 Koordinatenpunkte für die x, y und z Achse zu je 16 oder schlimmer 32 Bit und wenn man es mit der Blickrichtung nicht so genau nimmt, nur einen Winkel, anstatt 3 weitere Koordinaten.
Bei heutigen Spielen wird man aber wohl eher einen Vektor übermitteln wollen, also doch 6 Koordinatenpunkte, wobei für die Blickrichtung wohl auch 8 Bit je Achse genügen könnten.
Das macht also 3*16 + 3*8 = 72 Bit
bei 1000 Spielern also
72 Bit * 999 = 71928 Bits bzw. 8991 Bytes.Und wenn die Spielwelt 32 Bit groß ist, vergrößert sich diese Zahl noch einmal für die Position.
Andere Informationen, wie, welche Waffe er trägt, in welche Richtung der Kopf schaut bzw. sich bewegt (je nach dem, was oben nun die Blickrichtung war), ob er geschossen hat usw. sind hierbei noch gar nicht berücksichtigt.
-
Gruum schrieb:
Nehmen wir an es schießen grad mehrere Spieler. Das Problem ist nun zu berechnen was die einzelnen Schüsse treffen.
Parallelisieren lässt sich das ziemlich einfach, jeder Schuss kann unabhängig voneinander berechnet werden.Wen mit einem Laser geschossen wird.
Wenn es Gewehrkugeln sind, dann muss der Schuss ballistisch berechnet werden und schafft das auch nicht in einem Augenblick, sondern das dauert bis er das Ziel trifft. In der Zeit kann das Ziel wieder ganz wo anders sein.
-
1000 Gegner? schrieb:
Wen mit einem Laser geschossen wird.
Wenn es Gewehrkugeln sind, dann muss der Schuss ballistisch berechnet werden und schafft das auch nicht in einem Augenblick, sondern das dauert bis er das Ziel trifft. In der Zeit kann das Ziel wieder ganz wo anders sein.Das macht für die parallelisierung aber keinen unterschied. Bzw. wenn man die Flugbahn Stückweise annähern muss, hat man nur noch einen weiteren ansatzpunkt an dem man parallelisieren kann.
-
1000 Gegner? schrieb:
Gruum schrieb:
Bei 40 Bytes die pro Spieler anfallen und an alle geschickt werden müssen und das 4 mal in der Sekunde komme ich bei 1000 Spielern auf etwa 150 Megabytes/s.
Nur 40 Bytes?
Ich brauche von jedem Spieler mindestens eine Position und eine Blickrichtung.
Also mindestens 3 Koordinatenpunkte für die x, y und z Achse zu je 16 oder schlimmer 32 Bit und wenn man es mit der Blickrichtung nicht so genau nimmt, nur einen Winkel, anstatt 3 weitere Koordinaten.Könnte komprimiert übertragen werden. Insbesondere könnte die Rechenleistung fürs Komprimieren von vorgeschalteten Verbindungsrechnern erledigt werden.
1000 Gegner? schrieb:
Andere Informationen, wie, welche Waffe er trägt, in welche Richtung der Kopf schaut bzw. sich bewegt (je nach dem, was oben nun die Blickrichtung war), ob er geschossen hat usw. sind hierbei noch gar nicht berücksichtigt.
Muss nur übertragen werden, wenn er die Waffe wechselt, den Kopf dreht, seine Bewegungsrichtung ändert usw.
Oder um's auf die Spitze zu treiben: Wieviele Eingaben macht ein Spieler pro Sekunde? 4 Tastendrücke und 10Bits für die Maus?
-
Du meinst es werden gar keine Positionen übertragen, sondern nur, ob er eine Taste gedrückt hat und das Mausrad geschubst hat?
-
1000 Gegner schrieb:
Du meinst es werden gar keine Positionen übertragen, sondern nur, ob er eine Taste gedrückt hat und das Mausrad geschubst hat?
Ja, als Brechnungsmodell möchte ich das nicht unerwähnt lassen, wenn es drum geht, Untergrenzen der zu übertragenden Daten auszurechnen. Es wäre theoretisch möglich. Je weiter die Zahlen, die man als Untergrenze ausrechnet drüberliuegen, desto mehr sollte man einen Drang empfinden, zu begründen.
Und nein, ich glaube nicht, daß jemand das so implementiert. Sicherlich werden Positionen übertragen (wobei auch nur Positionsänderungen oder gar Beschleunigungsänderungen reichen würden).
Nur bei einem Spiel hege ich den Verdacht, daß die da Benutzereingaben gespeichert hatten, statt einen berechneten Spielverlauf, das war Stunts http://www.youtube.com/watch?v=-CITIXlw_T4
-
volkard schrieb:
Könnte komprimiert übertragen werden. Insbesondere könnte die Rechenleistung fürs Komprimieren von vorgeschalteten Verbindungsrechnern erledigt werden.
Ich sehe in den Informationen keine Redundanz, außer einer zeitlichen.
-
SeppJ schrieb:
volkard schrieb:
Könnte komprimiert übertragen werden. Insbesondere könnte die Rechenleistung fürs Komprimieren von vorgeschalteten Verbindungsrechnern erledigt werden.
Ich sehe in den Informationen keine Redundanz, außer einer zeitlichen.
Hab noch nie zeitliche von anderer Redundanz getrennt.
Also zeitliche ist da, ganz klar. Am einfachsten, man schickt Bescleunigungen und hat verdammt viele Nullen. Dann ists richtige Redundanz.
Aber richtige Redundaz gibt's auch, bei MMORPG hängen die Leute meinstens vor der Bank rum und laufen un Dungeons typische Wege, die koordinaten könnte man kürzer machen und dafür andere länger. Hhhm, wenn man die Userpositionen der letzen Woche speichert, und mit dem Wissen Huffman auf den Stream macht, wars richtige Redundanz, wenn man LZH draufmacht, wars zeitliche.Ich meinte vor allem die zeitliche, auch die Immergleichheit der Zeilen mancher Spieler im Chat.
