Hallo Besucher, der Thread wurde 23k mal aufgerufen und enthält 179 Antworten

letzter Beitrag von SkulleateR am

Brainstorm - näher Zusammenrücken bei sozialer Distanz: gemeinsam online C64 zocken/streamen

    Zitat von tilobyte

    Schade und ein wenig seltsam, das das da nur wenig Feedback gekommen ist, denn es ist ja wirklich eine schöne und sehr nützliche Sache.

    Ja sicher. Das dachten wir bis dahin auch. Anstatt die Ärmel hochzuziehen und mitzuarbeiten, gab es aber nur Gemecker. Warum wir denn nur für Windows (Visual Basic) programmiert hätten und nicht auf Java.

    Warum eine Server-Software. Wir hätten gerne was eigenständiges. Alles das ist auf Dauer sehr demotivierend.


    Zitat von Matthias

    Absolut :D Aber das hat mich gerade zu einer anderen Idee gebracht

    Die Du uns natürlich nicht verraten möchtest. Ist es nicht schöner, wenn mehrere Leute Brainstorming betreiben? ;-)

    Zitat

    Alles das ist auf Dauer sehr demotivierend.

    Demotivierend, ja, ich weiß auch nicht, evtl. ist es manchmal wirklich besser, bevor man Kritik äußern möchte, es dann eher nicht zu tun, und eher dort etwas beizutragen, bei dem man zustimmen kann (so wie bei Kennedy und Chruschtschow in der Kuba Krise). Das erzeugt den wenigsten Schaden ;-) Am Ende ist es immer eine Frage wie man mit all dem umgeht, und fertig wird (jeder Tag ist ja auch anders). In der Schule lernt man nur lesen, rechnen und schreiben, aber auf diese Fragen und Situationen bereitet Dich niemand vor... das sollst Du irgendwie alleine hinbekommen. Dem entsprechend richtet man Schaden an, oder ist dem selbst ausgesetzt :-) Alles nicht so einfach.


    Zitat

    Ist es nicht schöner, wenn mehrere Leute Brainstorming betreiben?

    Brainstorming ist vollkommen in Ordnung, und ich mag es wenn Leute mit ihren Ideen um die Ecke kommen (so wie beim ATX 64 Board), woran man selbst nicht gedacht hat. Ich liebe auch Projektarbeiten, doch es ist auch wichtig den richtigen Zeitpunkt für sich selbst abzupassen. Also erst einmal festigen, ausarbeiten, anfangen, ... . Und etwas nicht zu verraten, verhindert ja das Brainstorming nicht gänzlich, sondern wird nur nach hinten verschoben :D


    Die Idee hat nichts mit der Netzwerk/Server Entwicklung zu tun. Soviel kann ich sagen :-)


    Was das Multiplayer Netzwerk anbelangt wäre mir eine Lösung am liebsten, bei der der C64 überhaupt nichts machen muss. Dabei sollte selbst der Spieleprogrammierer mit dem Netzwerk auch nichts am Hut haben. Sondern im Prinzip ist sein Spiel der Host... und verwaltet nur die Eingaben von Joystick 1-4 (evtl. Keyboard 1-4).


    Als eine andere Variante (oder Modus), könnte man noch eine API fürs Netzwerk machen (eine möglichst sehr sehr Einfache), für die Spiele, bei dem nicht alle Spieler gleichzeitig auf dem Bildschirm zu sehen sind.


    So hat man unterschiedliche Schwierigkeitsgrade für die Programmierer. Der Einstieg geht schneller, die Motivation ist höher (ist mal schnell gecoded).

    Zitat von Matthias

    Christian hatte ja was von Pong geschrieben und das Problem der Latenz, was nicht funktionierte.

    Ich bin gerne bereit, ein bisschen was zu dem Thema zu erzaehlen. Das Pong war NICHT fuer den C64, sondern das war ganz normal auf dem PC, ist schon bestimmt 15 Jahre her, einfach so fuer mich um "Netzwerk" zu lernen. Und dabei wurde ich unweigerlich mit den prinzipiellen Probleme des ganzen Vorhabens konfrontiert. Seither habe ich mich auch immer wieder mal gedanklich mit dem Thema beschaeftigt und auch mit ein paar Experten (die sowas wirklich programmieren) geredet, und es bestaetigt sich halt alles immer wieder.


    Pong ist ein sehr gutes Beispiel, weil es vielleicht das simpelste 2-Spieler-Spiel ist, das man sich vorstellen kann. Zwei Schlaeger und ein Ball sollen sich bewegen.


    Ich habe es damals so programmiert, dass die Rechner direkt miteinander kommunizieren, also ohne Server dazwischen. Jeder Spieler sieht immer sofort seine eigene Aktion, also z.B. wenn er den Joystick bewegt, dann bewegt sich auch der Schlaeger. Loest der Gegenspieler eine Bewegung aus, dann kommt diese erst mit einer gewissen Verzoegerung an. Es kann also sein, der Schlaeger des Gegenspielers bewegt sich scheinbar vom Ball weg, aber der Gegenspieler hat bereits die Richtung geaendert und er bewegt sich nun zum Ball hin. Wenn es recht knapp war, dann kann es sein dass fuer Spieler 1 der Ball bereits scheinbar am Schlaeger von Spieler 2 vorbei ging. In der Zwischenzeit hat Spieler 2 aber bereits reagiert und den Ball doch noch getroffen, aber diese Information kommt bei Spieler 1 erst mit 60 ms Verspaetung an. Nun wuerde das Spiel bei ihm den Spielstand korrigieren und er wurde sehen wie der Schlaeger ploetzlich an die richtige Stelle "springt" und der Ball reflektiert wurde, obwohl es fuer ihn ja gerade noch aussah, als waere der Ball schon vorbei. Je hoeher die Latenz, desto schwerwiegender dieser Effekt. Beim C64 ist ein Frame 20 ms lang, und z.B. bei meinem Spiel SHOTGUN bewegen sich die Figuren 3 Pixel pro Frame. Das heisst, nach 60 ms ist die Figur schon 9 Pixel weit gelaufen. Wenn sie zuvor nach oben lief, aber jetzt der C64 die Nachricht erhaelt, dass die Figur vor 60 ms bereits umgekehrt und nach unten gelaufen ist, dann betraegt der Versatz bereits 18 Pixel. Die Kugel bewegt sich, wenn ich mich recht erinnere, ca. 10-12 Pixel pro Frame, d.h. die ist dann in 60 ms schon 30-36 Pixel weit geflogen. Ein Sprite auf dem C64 hat eine Groesse von 24x21 Pixel, d.h. die Kugel koennte also schon deutlich sichtbar an dem Spieler vorbeigeflogen sein.


    Jetzt gibt es verschiedene Moeglichkeiten, solche Dinge zu kompensieren. Vor allem in modernen 3D-Spielen ist das vielleicht etwas leichter, denn in einem 3D-FPS sieht man die Geschosse vielleicht gar nicht, und es ist auch etwas "schwammiger" zu beurteilen, ob man nun getroffen hat oder nicht. Bei einem 2D-Pixelspiel wie SHOTGUN oder Pong kaschiert sich das nicht so leicht. Auch wenden viele moderne Spiele Interpolationen an, d.h. wenn die ploetzlich bescheid gesagt bekommen, dass die Figur sich vor 60 ms in die andere Richtung bewegt hat und in Wirklichkeit nun eigentlich ganz woanders stehen muesste, dann wird die Figur evtl. nicht hart "umgesetzt", sondern mit einer "weichen Bewegung" angepasst - bei Autorennspielen faellt das z.B. nicht so sehr auf, weil die Autos sich ja eh permanent bewegen. Daher ist es auch je nach Spiel unterschiedlich geloest.


    Was natuerlich auch immer geht, ist ein zentraler Server. Die Clients schicken ihren "Input" (also die Joystick-Bewegungen) an den Server. Dort landen sie aber natuerlich auch erstmal mit Verzoegerung. Nun berechnet der Server das Spiel und bestimmt nun die "Wahrheit", also wer wo steht und wer wen abgeballert hat usw, und sendet diese "Wahrheitsdaten" an die Clients zurueck. Nun gibt es Spiele, die NUR die Wahrheit des Servers anzeigen - diese ist immer konsistent und gueltig, allerdings hat der Spieler dann selbst natuerlich ein Latenzgefuehl, denn er drueckt den Joystick, sieht aber erst z.B. 60 ms spaeter dass sich seine Figur bewegt. Allerdings passen die Bewegungen dann wenigstens zu den anderen Spielern. Bei manchen Spielen ist solch eine Latenz zu verkraften, aber bei einem schnellen Spiel wie SHOTGUN ist das schnell unspielbar - ich habe mal auf einem Beamer gespielt, der eine Latenz hatte, und ich konnte mein eigenes Spiel nicht mehr gescheit spielen, weil die Latenz einfach schon zu gross war. Dann gibt es auch Spiele, die zwar die Wahrheit des Servers akzeptieren, die eigene Figur aber trotzdem sofort bewegen. Somit fuehlt sich das Spiel fuer den Spieler wieder spielbarer an, allerdings besteht hier nun natuerlich wieder das Problem, dass die Bewegung der eigenen Figur u.U. nicht zu denen der Mitspieler und deren Geschosse usw. passt. Da muesste man dann also wieder irgendwie kaschieren, und je nach Latenz kann es fuer den Spieler zum Frust werden, wenn er denkt, er muesste doch eigentlich getroffen haben, aber der Server sagt ihm, nee, hast Du nicht, Dein Mitspieler war naemlich eigentlich schon ganz woanders.


    Es gibt uebrigens ein C64-Spiel mit Netzwerk, naemlich "NetRacer". Mit dem Entwickler habe ich mich auch schon unterhalten, bei ihm ist es wohl genau so, dass die eigene Position sofort gesetzt wird und die fremden Positionen verzoegert vom Server kommen. Selbst gespielt habe ich es noch nicht. In einem LAN sollte das natuerlich ein kleineres Problem sein, aber uebers Internet kommt es eben auf den Ping an, wie "schlimm" es dadurch wird.


    Natuerlich kann es auch andere Spiele geben, z.B. welche in denen die Spieler nicht so sehr miteinander agieren. Nehmen wir mal als Beispiel "Bubble Bobble", da spielen die Spieler ja weitgehend "parallel" zueinander, da ist es vielleicht nicht so tragisch wenn die Positionen mal nicht 100% stimmen oder wenn man ploetzlich erfaehrt, dass der Mitspieler den Gegner doch schon erwischt hat, den man gerade selbst noch erwischen wollte. Bei einem "Gegeneinander"-Spiel wie bei SHOTGUN ist das aber mit einem Ping mit mehreren Frames wie oben beschrieben schon sehr frustrierend.

    Dann gibt es ja noch Spiele, bei denen die beiden Spieler komplett getrennt nebeneinander spielen, wie z.B. bei "Puzzle Bobble" oder bei einem 2-Spieler-Tetris. Sowas waere sicherlich auch umsetzbar. Also je weniger sich die Spieler gegenseitig beeinflussen, desto besser geeignet waere solch ein Spielkonzept. Und rundenbasierte Spiele sind natuerlich ueberhaupt kein Problem.


    Also das mal so als grober Ueberblick worin die Probleme bei Netzwerk-Spielen bestehen. Nicht nur auf dem C64, sondern ueberall. Das heisst nicht, dass man diese nicht irgendwie umschiffen kann, aber es muessen i.d.r. Kompromisse eingegangen werden und manche Spiele sind dafuer einfach weniger gut geeignet.

    Ja, mal schauen. Vielleicht muss es eine Ping Begrenzung geben, und es können nur Spieler zusammen spielen die einen Ping von <20ms in der Region erreichen (bei mir und meinem Server wäre das der Fall: 16ms). 16 ms ist nicht viel, und ich hatte auch schon überlegt ob man die Framerate nicht halbiert, also nur alle 40ms Daten sendet. Dann sind die Bewegungen zwar weiter, aber wenn man Zwischenschritte berechnet und diese nach 20ms "zwischenschiebt" bleibt das Spiel für den Spieler flüssig. Evtl. könnte man auch die Joystickbewegungen puffern, so das die 16ms vom Netz kompensiert werden. Nur zur Erinnerung, der C64 Mini hat eine Verzögerung von ca. 80-110ms was den Videoframe/Joystick angeht. Das merkt man kaum. Da fallen 16ms bestimmt auch nicht auf :-)

    Ich sehe mich schon Pong programmieren :-) Morgen vielleicht :D


    Aber ich hatte heute ein anderes Erfolgserlebnis... meine neue Modul-Emulationskarte für den Modular64 mit Dual-Port SRAM funktioniert endlich, nachdem ich das 35ns SRAM gegen ein 55ns SRAM getauscht habe (heute aus den USA bekommen ;-) ). Dabei musste ich noch den GPL-Lizenz Ballast loswerden, indem ich anstatt einer USB Library einfach eine fertige USB->Serial Platine eingebaut habe :-) . Das gleiche habe ich mit der Ethernet-Platine gemacht (von ENC28J60 - denn für den ENC28J60 gibts nur GPL Libraries - auf WIZ5500 / Serial gewechselt)


    Mehrere Probleme weniger :thumbsup:


    Somit habe ich immer mehr zusammen, um das Netzwerk Projekt voran treiben zu können. Jetzt muss nur noch meine neue Programmiersprache fertig werden :-) (mein neuer Assembler und Compiler ist ja bereits fertig).

    Zitat von ZeHa

    aber uebers Internet kommt es eben auf den Ping an, wie "schlimm" es dadurch wird.

    Das "schlimme" was mir zu dem Thema nur einfällt: Bei den ganzen ESP Wlan Geschichten gehen nicht nur manchmal "Pakete" verloren, nein - Sie kommen sogar in falscher Reihenfolge auf dem Netzwerk-Stack an - Und dann wird's richtig beschissen wenn es um Live-Gaming und Realtime-Joystick-Geschichten gehen sollte.


    So etwas wie ein Schiffe-Versenken via Internet - also Rundenbasiert - würde man in Soft & Hardware von A-Z Ruck zuck hin bekommen. ESP32 an den Userport gehängt und kleines Protokoll dafür Entwickelt - das ist im Jahr 2020 kein Hexenwerk mehr.

    KiWi - wie ich schon in einem Text beschrieben hatte, braucht man als Basis eine simpel nachzubauen- oder zu produzierende, preiswerte, schnelle W-Lan Hardware mit einfach zu bedienender Schnittstellensoftware für den C64. Dann könnte man ein Netzwerk für Chat, Forum, Spiele darauf aufbauen. Ist, wie du schon erwähnt hast, mit den heutigen Mitteln und preiswerten Bausteinen kein Hexenwerk. Auch wenn die Spiele am Anfang rundenbasiert wären. Was würde Abends gemeinsam online gegen eine Partie Poker oder ein Spiel wie Kaiser am C64 sprechen. Wenn genügend Module auf dem "Markt" sind, dann werden sich auch Entwickler finden die Spiele und Anwendungen Programmieren. Wäre ja schon klasse so ein C64 Netzwerk :-)

    Interessant, aber habe jetzt kein W-Lan gesehen. Ich würde um was wirklich einfaches zu machen eine ESP8266 nehmen. Also keine große Logik in das Modul stecken. Nur Daten raus und rein. Als Anschlüsse würde ich den Userport oder den Tapeport nehmen. Die sind ja meinstens unbenutzt und schnell genug.

    Hm. Ich mag die Idee, Add-On Hardware Vieles übernehmen zu lassen, so dass zum einen dem C64 Rechenlast erspart wird und zum anderen die Einstiegshürde für Game-Developer möglichst niedrig ist. Aus eiegner Erfahrung weiß ich auch, dass die Anforderungen an ein funktionierendes Multiplayer-Spiel via Netzwerk sehr verschieden sein können:


    - Verläuft das Spiel rundenbasiert?

    - Findet die Handlung auf jedem Client zu jedem Zeitpunkt gleichzeitig statt?

    - Sieht jeder Player an seinem Client alles, oder nur jeweils einen Ausschnitt?

    - Gibt es abhängige Aktionen, die teils zufallsgesteuert sind?

    - ...


    Anfang der 2000'er habe ich bspw. u.a den Netzwerkcode für einen Bomberman Clone geschrieben (Bomberfun Tournament). Hier war die Herausforderung die, dass alle Spieler alles sehen konnten und zudem Computergegner unterwegs waren. Wenn da irgendwo eine Bombe von einer KI gezündet hochging und die Explosion nicht rechtzeitig überall ankam, konnte es passieren, dass die menschlichen Spieler auf ihren jeweiligen Clients schon ganz woanders waren, wenn die Explosionswelle anrollte. Und dann verpuffte ein Spieler auf einem Client und auf einem anderen sah es für einen Moment so aus, als wäre er entkommen. Denkste.


    Außerdem wurden viele Dinge vom "Zufall" gesteuert.


    Wir haben das damals so gelöst, dass zu Spielbeginn eine große Menge an Zufallszahlen an einer Stelle generiert und dann mit allen Clients synchronisiert wurde. AUs dem Pool haben sich nach und nach alle Clients bedient und bei bedarf wurde rechtzeitig nachgeschoben. So haben wir sichergestellt, dass zu jedem Zeitpunkt die gleichen Dinge jeweils lokal "berechnet" wurden und damit auf ein Client-Server-Konzept verzichtet. Außerdem haben wir immer ein paar Frames im Vorraus berechnet und synchronisiert. Je nach Netzwerkgeschwindigkeit war das manchmal kurzfristig als Lag spürbar.


    Ich kann mich gut daran erinnern, was das für ein Aufwand war und heutzutage bilden das eher Frameworks von spezialisierten Anbietern ab.


    Dem C64 traue ich in dieser Hinsicht wenig potentielle Szenarien zu. Hier sehe ich Chancen im Bereich eher langsamer Spiele. Text-/Grafikadventures, rundenbasierte Strategiespiele, Puzzler, sowas in der Art. Wenn die Hardware das nicht übernimmt, indem sie Daten in Echtzeit abgreift und in einem mordstempo verteilt, sehe ich allein schon bei Loderunner schwarz. ;-)

    Sehe ich genauso. Deshalb war mir von Anfang an irgendwie klar, dass alles muss Zusatz-Hardware vollkommen autonom liefern. Das ist auch möglich, wenn man ein paar Regeln befolgt und ein bisschen Tüftlergeist mitbringt :-) Wenn man den Transfer den C64 machen lässt, kann man einen Ping von 16ms ganz schnell auf 150ms verlangsamen (vor allem über WLAN), und das bringt niemanden etwas. Denn dann ist das ein einziges Geruckle... wie man bei Netracer 64 sehr gut sehen kann. Vor 2 Jahren, als ich zum ersten mal das Netracer C64 Spiel sah, hatte ich mich schon gewundert warum sich die Fahrzeuge garnicht, oder nur ruckelnd auf dem Screen bewegten :-)


    Das mit den Zufallszahlen hat übrigens auch so ähnlich Schuemi mit dem C64-Go gemacht. Er hat zu Spielbeginn den Zufallsgenerator geresettet, und dann auf den V-Blank syncronisiert. Deshalb laufen die C64 Spiele bei ihm syncron.


    Es gibt somit verschiedene Ansätze wie man das Problem wirklich gut lösen könnte.

    Pixel Pong Internet Delay Test :D


    Damit man mal Praxisdaten hat, habe ich einen UDP Server und einen UDP Clienten programmiert:syshack:


    Der UDP Server wartet auf Daten (Positionsdaten eines Spielers). Ist der Spieler unbekannt, wird er in die Userliste aufgenommen. Anschließend werden alle User-Positionsdaten an jeden Clienten/User/C64 versendet.


    Auf der Linken Seite des Spiels bewegt sich der Balken "Lokal", also ohne Verzögerung.

    Auf der Rechten Seite bewegt sich der Balken aufgrund der ankommenden Daten vom Server.

    Das Spielfeld wird alle 50/s Frames upgedatet (20ms) = PAL.


    Bei einem Ping von max. 20 ist flüssiges Spielen "ohne Tricks" möglich (auf einer LAN hat man einen Ping von 1-2, da muss man sich keine Gedanken machen, es läuft alles flüssig :thumbsup:). Bei 30ms und aufwärts geht leichtes Ruckeln los, bei >= 60ms ruckelt es schon erheblich.


    Von meinem DSL Anschluss zu meinem Internet-Server habe ich einen konstanten Ping von 16ms. Somit könnte ich und andere die einen Ping von <= 20ms haben, problemlos flüssig spielen (ohne Tricks :D ).


    :DJ


    Smoothing (Trick, bei Pings über 20ms): Wenn man den Durchschnittswert von den X und Y Bewegungen berechnet, und diese in der "Leerlaufzeit" benutzt und zwischenschiebt, dann sieht man kaum noch ruckeln (das Ruckeln was man sieht ist nicht vom Netzwerk, sondern von dem Java Thread Screen-Update. Das erkennt man daran das selbst der lokale linke Balken, der nie ruckeln sollte, öfter ruckelt oder sogar anhält).


    Es sieht jedenfalls so aus als wenn flüssiges Spielen zu 100% möglich ist, selbst wenn man einen Ping von 80ms hat. Dazu sollte jedoch der C64 möglichst nicht die Netzwerkaufgabe übernehmen (Daten senden und empfangen) und so weit es geht jegliche Verzögerungen reduziert werden.


    Deshalb sehe ich kein Problem in der Zukunft, was C64 Multiplayer Action-Games anbelangt :ChPeace


    Das Video dazu:


    [Externes Medium: https://www.youtube.com/watch?v=wJY2DmyHsTw]

    Aber wahrscheinlich wird selbst dieser Beweis den wenigsten "geht nicht" Anhängern gefallen :-)


    Macht aber nichts. Es hat ja auch was gutes. So kann ich in Ruhe an dem Gaming Board arbeiten, und damit alle überraschen... einschalten, und mittendrin sein (bereits verbunden mit allem drum und dran, kein Laden, kein Umrüsten, kein Verbinden, von Hause aus 4 oder 8 Joystick Ports, damit man auch die unmöglichste Übertreibung noch ausleben kann ;-) ). Ich werde mir dazu noch zahlreiche Gimmicks einfallen lassen, und vor allem eine runde Infrastruktur einrichten, damit es nicht nur geht, sondern ein Erlebnis wird :D Ob das dann zum Herbst fertig wird, schaun wir mal. Ist eigentlich ein ideales Event für kurz vor Weihnachten :weihnachten: Und wenn sich dann immer noch niemand dafür interessiert... ich habe meinen Spaß, das ist die Hauptsache :ChPeace


    Ich hoffe ja immer noch das ich dann nächstes Jahr endlich etwas mit KI machen kann. Wäre gerade auf dem C64 lustig. 8-Bit KI :thumbsup: Es gibt noch so schöne Sachen die man machen kann... :love:

    Zitat von Matthias

    Von meinem DSL Anschluss zu meinem Internet-Server habe ich einen konstanten Ping von 16ms. Somit könnte ich und andere die einen Ping von <= 20ms haben, problemlos flüssig spielen (ohne Tricks :D ).

    Wenn Du einen Ping von 16ms zu Deinem Server hast, dann hat Dein Server hoechstwahrscheinlich auch einen Ping von 16ms zu Dir zurueck - folglich benoetigt der Roundtrip mindestens 32ms. Wenn Dein Server dann noch kein einfacher "Echo-Server" ist wie jetzt, sondern einen Spielstand trackt, dann wird auch er eine Taktrate haben, und dann werden auch da nochmal ein paar ms anfallen, bis er die Daten wieder rausschickt.


    Zitat von Matthias

    Smoothing (Trick, bei Pings über 20ms): Wenn man den Durchschnittswert von den X und Y Bewegungen berechnet, und diese in der "Leerlaufzeit" benutzt und zwischenschiebt, dann sieht man kaum noch ruckeln (das Ruckeln was man sieht ist nicht vom Netzwerk, sondern von dem Java Thread Screen-Update. Das erkennt man daran das selbst der lokale linke Balken, der nie ruckeln sollte, öfter ruckelt oder sogar anhält).

    Warum bewegen sich beide Balken langsamer, wenn Smoothing an ist? Was passiert da genau?


    Zitat von Matthias

    Es sieht jedenfalls so aus als wenn flüssiges Spielen zu 100% möglich ist, selbst wenn man einen Ping von 80ms hat. Dazu sollte jedoch der C64 möglichst nicht die Netzwerkaufgabe übernehmen (Daten senden und empfangen) und so weit es geht jegliche Verzögerungen reduziert werden.

    Wie funktioniert ueberhaupt das Delay in Deinem Testprogramm? Rechnest Du die Verzoegerung auf die Server-Antwort drauf? Wenn ja, dann fehlt Dir auch hier ein Weg, bei einem Ping von 80ms dauert die Nachricht von Deinem Gegenspieler zu Dir letztendlich 160ms.


    Zitat von Matthias

    Aber wahrscheinlich wird selbst dieser Beweis den wenigsten "geht nicht" Anhängern gefallen :-)

    Genau, Du wirst uns allen zeigen dass fuer Dich die Gesetze der Physik nicht gelten :rolleyes:


    Bau mal einen Ball in Dein Spiel ein und spiele das wirklich mit zwei Spielern uebers Internet. Vorher ist das noch kein "Beweis". Dein Enthusiasmus in allen Ehren, aber das hier ist noch kein Spiel und Du wirst noch einige Aha-Effekte erleben.

    Zitat von ZeHa

    Wenn Du einen Ping von 16ms zu Deinem Server hast, dann hat Dein Server hoechstwahrscheinlich auch einen Ping von 16ms zu Dir zurueck - folglich benoetigt der Roundtrip mindestens 32ms.

    Mit verlaub: hast du da nicht einen 'Denkfehler'?

    Ein Ping von 16ms ist die Zeit gemessen zwischen Ping (Server-Anfrage) und dem dazu gehörenden Pong (Server-Antwort).

    Folglich ist das schon die Zeit des 'Roundtrippes'.

    Natürlich würde bei einem Spiel da noch die Zeit dazu kommen die der Server für den Spielablauf 'verbraucht'.

    Ja, Ping ist hin und zurück. Also 8ms zum Server, dann noch mal 8ms zurück. Das bedeutet es bleiben noch 4ms um die irgendwie zu verwenden und zur Verarbeitung nutzen.


    Das Positive ist dabei:


    - LAN kein Problem

    - Internet kein Problem

    - Und wenns mal eine längere Leitung ist, zur Not smoothing


    Das ist jedenfalls eine gute Basis :-)


    Ich werde wahrscheinlich 2 Modi verwenden, einmal für die die einen Ping von <=20 ms haben, und einmal die einen höheren Ping haben. So können die Spieler mit <= 20ms zusammen Spielen, oder sich entscheiden auch noch mit langsameren Spielern zu spielen, oder nur die langsamen Spieler zusammen. So vermeidet man unnötige zusätzliche Probleme.

    Gut das ist wirklich flott. Aber natuerlich hat nicht jeder Spieler den gleichen Ping. Wenn Du 16 hast und ein anderer 80, dann ist je nach Implementierung des Servers natuerlich auch dieser Versatz zu beruecksichtigen. Deine Message ist dann nach 8 ms beim Server und fruehestens nach weiteren 40 ms beim anderen Spieler. Waehrend seine Message erst nach 40 ms beim Server ist und dann nach weiteren 8 ms erst bei Dir. Dauert beides gleich lang am Ende, aber die Events passieren trotzdem nich synchron. Jetzt ist noch ein Ball im Spiel, und den muss ja auch jemand steuern, das wird dann wohl der Server tun. Wenn sich der Ball nun fuer den Server an einer bestimmten Stelle befindet, dann erfaehrst Du das nach 8 ms, der Gegenspieler aber erst nach 40 ms.


    Und versteh mich nicht falsch, ich wuerde es ja auch toll finden wenn das alles klappt am Ende. Es ist halt nur trotzdem nicht so straightforward wie man es sich vielleicht im ersten Moment vorstellt. Aber entwickel ruhig mal den Pong-Test weiter, sodass man den wirklich spielen kann, erst dann kann man genau sagen, wo es dann klemmt.

    Deshalb habe ich mein Post noch mal korrigiert (bevor ich Deine Antwort gelesen habe), weil mir das auch in den Sinn kam, also die Trennung zwischen schnellen und langsamen Spielern (und als Option zusammen, je nachdem welchen Anspruch man hat).


    Ich verstehe die Bedenken, aber ich versuche vieles anders zu machen, und den C64 möglichst nicht am Netzwerk zu beteiligen, sondern das dieser sich nur um die Sprites kümmert... den Rest macht ein spezielles Developer Board.

    Zitat von Freddy

    Natürlich würde bei einem Spiel da noch die Zeit dazu kommen die der Server für den Spielablauf 'verbraucht'.

    Wenn man denn so einen Server einsetzt. Da ich das Ganze aber anders plane, wird da auch keine extra Zeit verbraucht ;-)


    Für mich war erst einmal nur wichtig zu sehen das es funktioniert, und das auch noch besser als ich das selbst erwartet habe.