Netzwerk-Game mit UDP

Massenhaft

Mitglied
Hi,
ich hab mich mal an einem Netzwerkspiel versucht. Eigentlich ging es mir um den
UDP-Stack. Ich hab das ganze mit Slick, Artemis und Netty gebaut. Das UDP-Protokoll
(Sequenzen) und der Bewegungsmechanismus (LERP) basiert auf einer Konzeptmischung aus Valve(HL2) und Quake.
Es "scheint" ganz gut zu funktionieren, allerdings hab ich es noch nicht wirklich testen können.
Quellcode und alles weitere liegt auf google-code:

slick-netty-network-game-example - An UDP 2d netwok game example - Google Project Hosting

Video:
YouTube - ‪fumag.avi‬‏

Einiges ist noch recht "ineffektiv" und ein paar refactorings sind auch noch nötig (Z.B. hab ich
eine recht sinnfreie FSM eingebaut, weils geht 🙂).

Gruß,
Andreas
 
Zuletzt bearbeitet:
Ohne jetzt einen qualitativen Kommentar abzugeben (Hab nur das UTube-Video gesehen...), möchte ich dennnoch kurz fragen/darauf hinweisen, dass es so vorkommt, als ob die ÜBertragung der Koordinaten möglicherweise was unschön gelöst ist ? Es sah so aus, als ob am Anfang der eine Android, der im Kreis ging, "Verzögerung hatte oder hinterherhing"... Da du den Test ja vermutlich mit "localhost" als Adresse gemacht hast, solllte das eigentlcih nicht vorkommen... Aber vlt wars auch eine vollkommene Fehlinterpretation meinerseits, ....^^

Ich mach zur Zeit in etwa genau das Selbe... Ich arbeite mit Slick und Netty3 an einem Isometrischen Coop-RPG. Ich bin aus meiner Sicht schon relativ weit... Allerdings ist bei das Netzwerk auch noch ein kleines Problem... Wobei ich nich auf UDP setze, sondern TCP verwende... Ich wollte mal etwas anti sein und gegen jeden Hinweiß TCP dazu verwenden.... Es klappte bei den ersten Tests auch recht gut, auch über Internet... Auf Wunsch können wir beide uns mal beraten^^

Eins noch: (Wie gesagt, ich habe mir nich den Sourcecode angesehen) Aber kann es sein, dass du viel zu oft die Koordinaten sendest ? Wie gesagt, ist reine Vermutung, aber diese Verzögerung kam mir so vor, als ob da zuviele Daten durch ein enges Nadelöhr müssten.... Wie machst du das genau ? Ich z.B. sende alle 33 ms ein Update und beim Rendern nehme ich Interpolation um die Bewegungen flüssig aussehen zu lassen.... Ich hab mich da auch recht dicht an den Wikiartikel zur Sourceengine gehalten 😀



Gruß,

Chris
 
Hi,
danke für das Feedback 🙂! Ich habe ein UDP-Proxy bei Sourceforge gefunden:
Delayed Proxy | Download Delayed Proxy software for free at SourceForge.net

Bei dem Test habe ich verschiedene Packet-Lost-Raten und Delays eingestellt. Das "Ruckeln" kommt allerdings
eher von meinem Aufnahmeprogramm...die Framerate ist nicht sehr hoch 🙂. Zu meinen Netzwerkeinstellungen:
Code:
	public static final int CLIENT_INTERPOLATION_TIME = 100; //ms
	public static final int CLIENT_NETWORK_INTERVAL = 33; // ms
	public static final int SERVER_NETWORK_INTERVAL = 50; // ms
	public static final int SERVER_WORLD_SIMULATION_INTERVAL = 33; //ms
	public static final int CLIENT_WORLD_SIMULATION_INTERVAL = 25; //ms
	public static final int CLIENT_INPUT_SAMPLE_INTERVAL = 33; //ms

	private static final int MAXIMUM_COLLECTED_PINGS = 32;
	private static final int MINIMUM_COLLECTED_PINGS = 16;

Alle Clients laufen 100ms in der Vergangenheit + Ping/2 - dadurch laufen sie wirklich etwas hinterher. Dies wird
aber durch das zurückspulen bei der Kollisionserkennung kompensiert. Ich habe auch versucht mich möglichst an
das Valve-Wiki zu halten 🙂.
Es werden immer nur die letzen Positionsdaten gesendet, sollte einige Pakete verloren gehen -> Pech...
Wichtige Daten, wie z.B. einen Schuss, werden so lange gesendet, bis sie von der Client-Seite bestätigt werden. Das
könnte zu Problemen führen...vielleicht muss ich das noch ändern.
 
Hab ich noch vergessen:

bis hierhin gute Arbeit!



Ich hoffe, dass ich mit meiner TCP Lösung nicht auf die Nase fliege 😀
 
Wenn du bei deinem RPG mit der Maus auf die "Ziel-Lauf-Koordinaten" klickst sollte es gehen 🙂.
Starcraft und ähnliche Spiele arbeiten auch mit TCP...
 
Ob OpenSource oder nicht, ist noch nicht entschieden... Ist ein Gemeinschaftsprojekt... Zu Sehen gibt es etwas in naher Zukunft (Hoff ich zumindest!) gibt noch viel zu klären...
 

Zurück
Oben