Es ist extrem schwer, in einem Spiel mit solchen Bandbreiten auszukommen. Ich Arbeite in diesem Bereich (Spieleprogrammierung) und kenne die Probleme. ansich ist der beitrag kein schlechter inwand, nur scheint mir das doch eher änlich wie bei directx im vergleich zu opengl und glide, programmierern auf kosten der spieler die arbeit zu erleichtern. OT: mir kommt das schaudern wenn ich an die genutzten udp und tcp ports bei directplay denke des weiteren scheinen mir die hier genutzten zahlenwerte leicht übertriben: Nur mal ein kleines Beispiel: 1 Objekt mit Koordinaten (x,y,z = 12 Byte) und Bewegungsrichtung (nochmal 12 Byte) + ID Nummer des Objektes (vieleicht 2 Byte), somit 26 Byte pro Update und Objekt. In der Praxis braucht man oft mehr, z.B. Beschleunigungswerte, damit die Clients mit hoher Framerate die Bewegung “smoth” extrapolieren koennen. x,y,z= 12 byte= 96 bit= 2^96 möglichkeiten rund 7,9 * 10 ^ 28= (2^96)^(1/3) pro raumrichtung rund 4,3 * 10 ^ 9 bei einem angenommenem würfel mit der kantenlänge gleich dem durchmesser der erde (ca 15000km) währe jeder punkt im inneren dieses würfels mit einer genauigkeit von 3mm bestimmbar (4,3 * 10 ^ 9) / (15000 * 1000 * 00) == 2,86 koordinaten pro cm weiter: nein für eine bewegungsrichtung braucht man sicher nicht nochmal 12 byte, also einen weiteren genauen koordinaten punkt in meimem weltenwürfe, viel mehr reicht eine 360° einteilung in jeder radialen richtung also 2 aus (translation lass ich zumindest bei einem shooter mal außen vor). der einfachheit halber nehm ich 2 mal ein byte also je 256 richtungen. wem diese 2byte unangemessen wenig erscheinen, der nehme halt 4 und hat dann fantastische 65536 bewegungsrichtungsmöglichkeiten (unwort pro rotationsebene. gehe ich jetzt davon aus das ich 2,8 * 10 ^ 14 positionierungspunke also 65536 pro ebene (das wird nen hoher raum für nen shooter und 65536 richtungen pro eben (1. währ ich froh eine solche maus zu haben 2. ach ja consolen haben ja meist nichtmal eine maus 3. also 32768 möglichkeiten für die drücktiefe des joysticks pro richtung und dazu dann noch 65535 objekte (recht viel oder?) selbst wenn ich übertrieben rechne komm ich also auf x,y,z = 6 byte richtung = 4 byte objectid = 2 byte ach ja beschleunigung wurde gewünscht da reicht eine aproximation also 2 bit = 4 möglichkeiten ganz zu schweigen vom rückrechnen der zuletzt gesendenten koordinaten… im übrigen knaps ich das von der objectid ab, bleiben noch 16384 objekte. sollte reichen oder? schluss endlich 12 byte komprimierung aussen vor, könnte ja sein das sich nicht 10 mal pro sekunde alle parameter jedes objektes ändern… Nehmen wir an, es werden 10 Objekte “gesendet”, was eher wenig ist. Damit sind wir bei 260 Byte / Update. 12 * 10 = 120 Gehen wir von 10 Updates pro Sekunde aus (und 100ms Delay bei einem Autorennen ist verdammt viel…), so sind wir bei 2600 Byte/s. Dazu Steuerungsinformationen, UDP geadder, besondere Ereignisse (Crash, Tod usw), Chat und anderes. Damit sind 3KB/s schnell am Ende. 1200byte/s = 1,17kB/s Kein echtes Spiel (vieleicht von ganz einfachen Sachen abgesehen) wird einfach alle Objekte zyklisch ueber das Netz updaten. Da gibt es Prioritaeten, so dass schnelle Objekte oefter gesendet werden als langsame. Objekte, die z.B. gerade kollidiert sind, werden bevorzugt- Weit entferne bekommen vieleicht eine niedrigere Genauigkeit (und damit weniger Bytes) als nahe und natuerlich kann man die Daten komprimieren. Man kann auch nur die Differenz zum vorherigen senden, bekommt aber probleme, wenn zwischendurch Pakete verloren gehen, womit man bei UDP rechnen muss. Es gibt eine Menge Tricks, mit denen versucht wird, langsame Bandbreite und schlechte Pings zu “kompensieren”. … also noch weniger CS usw. kommen damit aus, weil sie so entwickelt wurden , dass sie das unbedingt muessen. Wenn man mehrere Rechner z.B. ueber ein Nullmodemkabel verbindet (langsames Netz!!!) per PPP und direkt nebeneinander stellt, so sieht man, dass sich die Objekte NICHT perfekt syncron bewegen. Es ist alles andere als einfach, einen Netzwerkcode zu schreiben, der ueber so niedrige Bandbreite, mit schlechten Pings, nicht garantierten Latenzzeiten und verlorenen Paketen klarkommt und immernoch ein vernuenftiges Ergebnis liefert. ja ich erinnere mich an doom2 über nullmodem oder duke3d über echo durchsetztes bnc, selbst bei dem angegrauten netzwerkkode war die asyncronität maginal. ja da gabs noch richtige “teleportation”.sicherlich ist mein statement angreifbar, so wie voriges auch, viel spaß dabei. solange wir nicht beim protokoll overheat von tcp vs udp landen sicher ist nur, die programmierer habens leichter, der code darf weniger qualität haben und die user dürfen mehr geld für zelte ausgeben.