weiss hier jemand eigentlich, warum genau man fürs onlinespielen unbedingt breitband brauchen soll?
geschickt programmiert reicht imho eine analogverbindung nämlich locker.
nehmen wir mal als beispiel ein einfaches (leider imaginäres) onlinespiel - zwei konsolen spielen online perfect dark:
zu beginn muss ein startwert übertragen werden, damit der zufallsgenerator auf beiden konsolen synchronisiert wird. also folge davon kann jede konsole die ki und andere ereignisse für sich selbst berechnen, da das resultat dann auf beiden gleich sein wird (ki ist bekanntlich auch nur eine anwendung des zufallsgenerators). es muss also nur noch übertragen werden, was die spieler gerade drücken.
pro kontroller reichen da 3 byte aus (1 byte zeigt die position des analogsticks - 8 abstufungen in alle richtungen sollte reichen; 2 bytes zeigen zusammen den status aller knöpfe (bis auf L, das bei pd bekanntlich mit R gleichzusetzen ist)
das ganze mal 3, da drei kontrollerports abgefragt werden müssen (maximal, da pd nur bis zu vier spieler unterstützt - wären es also vier ports so hätte die andere konsole gar nix mehr hier zu suchen).
also 9 byte pro abrage. nehmen wir die utopische framerate von 50 fps. öfters als einmal pro frame diese abfrage zu machen lohnt sich nicht. also 50 mal pro sekunde 9 byte senden und und 9 byte empfangen.
benötigt wird also ein konstanter upstream von 450 bytes (minimal 150 bytes - wenn nur ein kontroller abgefragt werden muss) sowie denselben downstream. verdoppeln wir das vorsichtshalber noch, um einen konstanten datenfluss zu gewährleisten: 900 B/s downstream und 900 B/s upstream im maximalfall also (wobei nie downstream und upstream gleichzeitig den maximalwert einnehmen natürlich).
sollte doch eigentlich locker reichen, sogar mit gprs übers handy

hab ich da was falsch berechnet oder sind die entwickler einfach zu blöd für sowas?

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>k7avenger schrieb am 01.01.2004 19:09
zu jedem Zeitpunkt die Position, die Blickrichtung, und sogar _alle_ Ausbreitungsrichtungen der Geschosse übermittelt werden (ein Vektor im R³ eben),
und auch noch die ausgewählte Waffe, ob man sich duckt etc.<hr></blockquote></p>

nun, diese informationen sind allerdings alle berechenbar, wenn man den kontrollerstatus kennt. wie gesagt rechnen alle konsolen alles für sich selbst aus - der zufallsgenerator ist ja synchronisiert.
oder wozu soll konsole a der konsole b sagen, wo jetzt wer steht, wenn konsole b das ja selbst schon weiss?

(das ist bei cs und konsorten afaik ja nicht der fall)

benutzt man ein relativ verlustsicheres protokoll zur datenübertragung, steigert sich das ganze vielleicht auf 1-2kb/s.

ob bei den verwendeten protokollen die positionen oder die bewegungen übertragen werden, weiss ich nicht.

aber nehmen wir an, der zufallsgenerator ist auf beiden seiten synchron (neuartiges protokoll also), dann müssten doch sämtliche vom computer gesteuerten oder berechneten ereignisse ebenfalls synchron ablaufen. also warum etwas übermitteln, was der andere schon weiss/bzw. selbst herausfinden kann?
die einzigen variablen bleiben in dem fall nur noch die spielereingaben. und die sind in so wenig bytes zu fassen, dass auch bei einem weitgehen verlustfreien protokoll (wo sichergestellt wird, dass jedes packet auch korrekt ankommt) das ganze sehr gering sein sollte.
das ganze wäre dann ziemlich direkt vergleichbar mit dem splitscreensystem und langen kontrollerverlängerungskabeln. nur dass im "online-fall" sämtliche berechnungen halt an zwei orten zugleich ausgeführt werden.

ich verstehe allerdings, dass der preis für eine geringe bandbreite eine absolut stabile verbindung oder zumindest ein ausgeklügeltes übertragungsprotokoll (vielleicht eine weiterentwicklung des schon recht verlustsicheren tcp?) ist. meinst du das?

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>Burning Death schrieb am 01.01.2004 21:35

Es werden die einzelnen Positionen von der Spielfigur, Hitbox, anderen Objekten, usw. übertragen. So kommt es bei z.B. Ego-Shootern bei schlechten Verbindungen öfters mal dazu das die "Headshot"-Hitbox nicht direkt da ist wo sie sein sollte. Man sollte bedenken das Games wie CS,UT und co. sozusagen reine Online-Games sind und rein dafür optimiert wurden (und trotzdem noch nicht "perfekt" ohne Lags).
<hr></blockquote></p>
ja, das ist die bisher angewandte methode. meine idee ist jedoch völlig anders.

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
www.warppipe.com hat ja schon ähnliches mit MKDD versucht, immerhin läuft es konstant...mit 20fps :rolleyes:.<hr></blockquote></p>
auch nicht zu vergleichen. afaik wird hier auch mehr als nur den kontrollerinput übertragen.

@k7
jup, das protokoll würde das ganze verlangsamen. hm. bleiben wir mal bei pd. wenn wir die rate von 50 fps auf 25fps herunterschrauben, würde das niemand merken (pd und fps :D)
also könnte man jedes packet zweimal durchschicken und nach dem zweiten mal entscheidet die empfängerkonsolen, was damit zu tun ist.
vielleicht zusätzlich alle 3 minuten ein kontrollpacket, bestehend aus einer checksumme, berechnet aus den aktuellen positionen. sollten die nicht synchron sein, schalten beide konsolen auf pause und synchronisieren sich. dann ein "press start to continue" oder sowas.

ein zufallsgenerator ist nichts anderes als ein algorithmus, der eien ziemlich zufällig wirkende zahlenfolge ausspuckt. zufällig ist sie aber nicht wirklich. das einzige, was hier etwas an zufall beitragen kann, ist der "zufällig" gewählte startwert der folge (in der regel nimmt man hier einen timerwert, z.b. anzahl sekunden seit 1970 oder sowas).
startet man zwei zufallsgeneratoren (nach demselben algorithmus natürlich) mit demselben startwert, so erhält man genau dieselbe zahlenfolge.
und die ki ist auch nur eine anwendung des zufallsgenerators: situation analysieren, liste der möglichkeiten berechnen, eine der möglichkeiten per zufall auswählen (wobei die wahrscheinlichkeit auf bestimmte möglichkeiten je nach ki-stärke verlagert wird).
ein gleicher startwert führt also, von den spielereingaben mal abgesehen, zu einem absolut identischen match.
(das ist ja auch meine hauptidee, so bleiben für die übertragung nur noch die spielerdaten übrig und die bots/wasauchimmer wird lokal auf jeder konsole direkt berechnet - es kommt eh dasselbe raus auf beiden seiten)

schafft es jemand, schneller als 25 mal pro sekunde auf einen knopf einzuhämmern? wenn nein sollte diese rate locker reichen.

das mit dem ping muss ich mir allerdings noch überlegen. hm..

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>k7avenger schrieb am 02.01.2004 11:00

worauf ich im speziellen hinaus wollte, und weshalb deine Idee nicht praktikabel ist:
Nehmen wir an, wir haben einen dedicated server. Es müssten - damit dein und mein Spiel absolut gleich ablaufen - für jeden von uns die Informationen über die Aktionen des anderen zum gleichen Zeitpunkt vom Server ankommen => Unmöglich. Daher mein utopischer Vorschlag mit der Uhrzeit.
<hr></blockquote></p>
wozu ein server?
wir sprechen immer noch von einem simplen onlinespiel zwischen zwei konsolen. direktverbindung?

nein. wenn man es schon so ausdrückt, dann sind beide sowohl server wie auch client.
hm. das protokoll müsste die verzögerung einkalkulieren. so dass lokale eingaben gleich stark verzögert werden wohl.
die frage ist jetzt, ob eine verzögerung von weniger als einem frame überhaupt was ausmacht. müsste man halt durchrechnen

hm. hab mich mal etwas informiert. bei lan-spielen macht der gamecube genau das: er sendet und empfängt kontrollerdaten - und nur kontrollerdaten