Neocron hatte oder hat auch eine Kollisionsabfrage und die funktioniert auch recht gut, auch wenn man dadurch den Gegner schon mal in andere Zonen schubsen konnte, was nicht immer nett war, wenn man mal grad AFK war, aber das ist ja nicht das Thema.
Viele machen sich hier Gedanken um den Serverload und um den Traffic.... da das Spiel eh nicht über ISDN, ob single oder dual, spielbar sein wird, fällt das schon mal flach, da der Traffic an der Userseite locker selbst bei einer kleinen DSL-Leitung im Downstream ausreicht.
Kommen wir zum Upstream.
Ich hoffe ich kann mich verständlich ausdrücken weil ich es sehr aus der technischen Seite sehe und vielleicht zu sehr mit nicht allgemein verständlichen Sachen um mich werfe.
Gehen wir mal bei der Kollisionsabfrage von folgender Situation aus:
Spieler A steht auf der Stelle und Spieler B rennt gegen ihn an.
Nicht immer werden Daten übertragen sondern nur wenn sich eine Situation ändert und in bestimmten Zeitintervallen, Event bezogen. Es ist also so, ihr rennt, haltet die Taste gedrückt und erst wenn ihr eine neue Taste drückt oder die Taste los lasst wird ein neues Datenpaket an den Server gesendet, dass ihr nicht mehr rennt. Server prüft es gegen und gibt es an alle davon betroffenen Clients weiter.
Ein Event was die Sendung eines Datenpakets angeht kann aber auch zum Beispiel eine Kollision sein.
Es beginnt mit einem vereinfachten Modell auf der Clientseite.
Grob 2 Klötze, die die Spieler komplett umgeben. Die beiden Klötze kollidieren miteinander.
Nun gibt es mehrere Verfahren wie man es machen kann....
Der Client splittet schon mal die sogenannte Bounding-Box auf und prüft die Kollision genauer gegen anhand eines sogenannten Octrees, das kann runter gehen bis auf Pixelebene. Das Ergebnis der Kollisionskontrolle auf Clientseite wird dann an den Server übergeben, der es prüft und dann an die Clients weiter gibt.
Problem bei diesem Verfahren ist es, dass man den Client ja theoretisch manipulieren könnte und es ein ehernes Gesetz gibt, dass man keinem Datenstrom vom Client glaubt und es immer gegenprüft.
Vorteil der Sache ist, dass der Client schonmal vorarbeit leistet, man den Spieler schon gewähren lassen kann und der Server einfach sein OK dazu gibt und nichts zurücksetzt. Gibt der Server sein OK nicht, dann gibt es sowas wie einen winzigen Reset oder er gibt die korrekten Infos an den Client zurück.
Geringer Datentransfer, fordert allerdings mehr vom Client und vom Clientrechner.
Nun die andere Variante. Die BBs kollidieren, Client gibt SOFORT Info an Server, Server splittet die BBs im Octree auf, schaut nach Kollision und gibt dann die Kollisionsdaten an den Client zurück, der solange warten muss um wirklich zu erfahren was passiert was zu Lags und hohem Trafficaufkommen führt, weil man den Spieler ja nicht nur das Endergebnis sondern auch die Zwischenstufen präsentieren will, damit die Schlacht flüssig weiter läuft. Ist also die denkbar schlechtere Lösung.
Da ich den Client, geschweige den die Datenpakete von WAR kenne kann ich nichts genaues sagen, aber ich denke sie werden die erste beschriebene Version oder eine Abwandlung davon benutzen.
Datenaufkommen ist wirklich recht gering, wenn man bedenkt, dass man nur ein paar Vektoren oder Quaternionen dafür senden braucht, die nicht wirklich viel Platz beanspruchen.
Bei vernünftiger Programmierung werden sie wohl für die Kollisionsabfrage höchstens 3-4 Vektoren oder Quats versenden müssen. Das sind dann mit Overhead vielleicht 64 Byte