@Lossy : UDP funktiniert genauso in beide richtungen wie TCP und wenn er sein zu einem server konnekten würde wenn er tcp auf einem der gängigen port benutzen würde, würdest du es garnicht merken, da jene standard tcp-port von routern standardmässig durchgeleitet werden.
Bei udp ist dem nicht so, AFIK gibts da gar keinen port der von haus aus durchgeleitet wird. Dementsprechend würde sein game bei dir nicht konnekten können, jedenfalls nicht bei einem internet-game.

_________________
www.extrawurst.org

Also AFAIK ist es bei UDP so:

Es existiert keine stabile Verbindung wie bei TCP/IP, da bei UDP nur die Pakete an die Ziel-IP gesendet werden, aber nicht automatisch sichergestellt wird, ob die dort auch wirklich ankommen. TCP/IP baut dagegen eine Verbindung auf, die dann bidirektional ist. UDP dagegen hat mit richtigen Verbindungen wenig zu tun und sendet einfach die Pakete raus und überlässt sie sich dann selbst. Dafür ist UDP jedoch recht flott und das sind Aspekte, die bei Netzwerkspielen gern gesehen werden Bei TCP/IP kann man davon ausgehen, dass auch wirklich jedes Paket genauso ankommt, wie man es losgeschickt hat. UDP hat auch eine Fehlerkorrektur, aber es wird eben kein Paket zurückgesendet, um zu zeigen, dass es angekommen ist.

Und bei Spielen ist es ja im Allgemeinen weniger kritisch, ob die Spielerposition mal ein paar Frames lang nicht aktualisiert wird.

Um mit UDP eine "Verbindung" zu machen nach dem Client-Server-Prinzip muss man keine 2 verschiedenen Port benutzen:

Beispiel:
Client schickt an den Server mit UDP ein Päkchen z.B. an den Port 1234. Server bekommt es am Port 1234 und kennt von nun an auch die Absende-IP.
Dann sendet auch der Server ein UDP-Päkchen. Diesmal an den Client. Ebenfalls wieder am Port 1234. Und nun erhält der Client ein Päkchen... Den Rest kennt ihr ja

Bei UDP ist die strikte Trennung zwischen Server und Client nicht zwingend nötig, da es von vornherein keinen Unterschied in der Verbindung selbst gibt.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Da UDP keine Antwort auf das Paket fordert, ist das dem Server nach dem Senden egal. Das ist der Unterschied zu TCP. Der Zielrouter wird also von aussen Pakete bekommen, die er für keine Client bestellt hat. Er wird sie also droppen oder rejecten ('Ein richtig toller Fetzrouter wird sie total lethal stealthen, weils leet ist ). Daher muss der Portforward rein. Ne Lösung wäre vielleicht uPnP, aber damit kenne ich mich nich gut aus. uPnP bewirkt, dass der Router selbstständig Ports öffnet, wenn ein Programm das will. DAS widerum mach mir mehr Zahnschmerzen, als das Weiterleiten von irgendeinem 4000er Port, der normalerweise tot ist (also vom Rechner rejected wird), es sei denn das Spiel läuft und weiß was mit den Paketen anzufangen.
Deine Sicherheitsbedenken kann ich nicht verstehen, da das o.g. Szenario kein Sicherheitsloch aufreisst. Ein "Angriff" von aussen kann nur auf Ports erfolgen, auf denen Du einen Dienst anbietest. Das ist im Falle von 4711 mein Spiel. Läuft mein Spiel nicht, dann ist der Port tot. Das kannst Du gut mit "netstat -nao" anschauen.

Das Problem der Konfiguration vestehe ich. Aber z.B. Total Annihilation, Colin McRae 2, Q3 (oder was auch imme rich damals excessiv übers Netz zockte) haben immer ein Protforwarding benötigt. Ist das bei aktuellen Spielen anders? Bin kaum noch am Zocken, daher mangelt es an aktuellen Szenarien.

Das Problem, dass nur einer hinter einem Router spielen kann ist mir auch aufgefallen, aber da kann man evtl. was mit unterschiedlichen Ports machen. Das wird schon noch ein Thema werden.

Verwenden aktuelle Spiele TCP? Ich nahm an und las überall, das UDP _DAS_ Protokoll für Spiele sei. Daher meine Wahl. Habe ich die falschen Hinweise gelesen? Fehlt noch ein Kniff um alle Probleme des UDP zu lösen?

Grüße,
DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

TCP ist für Spiele weniger geeignet. TCP stellt wie Frase bereits gesagt hat sicher, dass die Pakete in exakt der selben Reihenfolge ankommen, wie sie abgeschickt werden. Im Internet ist der Paketverlust bekanntlich recht hoch was hierbei das Problem ausmacht. Geht ein Paket verloren wird es bei der Nutzung von TCP immer wieder verschickt, selbst wenn es bereits total veraltet ist. Wichtige neuere Informationen können dabei erst verarbeitet werden, wenn die inzwischen nutzlos gewordenen, veralteten Packete verarbeitet wurden. Obendrein wird der Datenverkehr erhöht, weil das veraltete Paket immer wieder gesendet wird, was wiederum den Paketverlust fördert. Das Resultat muss ich wohl nicht extra erklären.
UDP ist daher die bessere Wahl birgt aber eine Menge Probleme. Zum einen ist nicht sichergestellt, dass die Informationen überhaupt ankommen. Weiterhin ist unbekannt, in welcher Reihenfolge sie ankommen und soweit ich weiß ist auch nicht sichergestellt, dass die Daten in einem Stück ankommen.
Wenn du UDP nutzt solltest du möglichst so viele Daten wie möglich in ein Packet packen. Das verschicken vieler kleiner Packete führt eher zu Lags als zum Erfolg. Hier musst du am besten selbst etwas herumprobieren, welche Packetgröße für deinen Anwendungfall am besten ist. Mitunter macht es auch Sinn diese vom User einstellen zu lassen. Soweit ich weiß bieten auch einige Spiele die Möglichkeit die Verbindungsgeschwindigkeit zu wählen, was vielleicht intern auch einen Einfluß auf die Paketgröße hat (Achtung Spekulation).
Wenn du also ein Spiel fürs LAN entwickeln willst rate ich dir zu TCP. Fürs Internet ist UDP besser geeignet führt aber zu wesentlich mehr Problemen.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Ich könnte mich teuschen aber wenn man sich mal den proffessionellen source von richtig guten netz-fetz-games anschaut wird man feststellen das es eigentlich garnicht aufs protokoll ankommt, vielmehr ist die geschickte und intelligente nutzung (also programmierung) der entscheidene faktor.
im prinzip besteht jetzt hier die gefahr das so ein Flamewar-thread zum thema UDP oder TCP im stil "directX gegen OGL".
AFAIK ist das benutzte protokoll bei richtig gut designtem netzwerk-code egal, da man in einem solchen code sehr viel wert darauf legt ausbalancierte und vorher auf besondere performance geprüfte packet-größen zu senden, das heist man findet heraus welche paketgröße am vorteilhaftesten gesendet werden kann (preis/leistungs-verhältnis) und chached dann so lange anfallende pakete bis eine solche größe erreicht wurde.
2.Punkt: Man findet den günstigsten interval in dem die pakete gesendet werden, auch hier gilt bestes Verhältnis zwischen Preis und Leistung zu finden.
und da ist der punkt wo die meisten wie beklopt auf tcp einhämmern:"Hey tcp is doch so lahm, nimm udp da kannse n kleineren interval nehmen und öfter versenden".
dabei ist ein weiterer punkt viel wichtiger:
3.Punkt: Kernstück eines guten Netzwerkcodes ist es den Zeitraum zwischen dem letzten eingetroffenen Paket und dem erwarteten nächsten Paket möglichst so zu überbrücken das der spieler garnicht merkt das entweder der interval sehr groß gewählt ist oder das netzwerk laggt oder einige pakete nicht ankommen. ein programmierer sollte also besonders darauf wert legen jenen code zur bewegungsvorhersage zu optimieren !

_________________
www.extrawurst.org

Magellan: Danke für die gute Zusammenfassung.

Extrawurst: Ich glaube auch, dass der richtige Netzwerkcode ein wichtiger Punkt ist.

Leider haben beide Protokolle entscheidende Nachteile.
TCP: Kann bei häufigen Datenverlust und daraus folgenden "Nachsendungen" der Pakete mehr Probleme bringen (veraltete Daten) als Vorteile (garanierte Ankunft des Paketes)
UDP: Hauptproblem sehe ich hier eigentlich bei den von "Lossy eX" angesprochenen Routerproblemen (Konfiguration, und Multiplayer durch den Router). Alle anderen Probleme (eventuell nich ankommende Pakete, durcheinander ankommende Pakete) kann man durch gescheite Programmierung beheben.

Ich denke, dass ich mit meinem Netzwerkcode schon in die richtige Richtung gegangen bin. Denn jeder Client berechnet die Positionen der anderen Objekte selbstständig nebenher und benutzt dazu den letzten bekannten Bewegungsvektor und die Drehungsgeschwindigkeiten. Kommt nun ein Netzwerkpaket an, werden diese Berechnungsgrundlagen lediglich aktualisiert. Im LAN habe ich mit Aktualisierungsintervallen von 200 ms gute Ergebnisse (verwendet auch das aktuelle Kompilat), mit 100ms sieht man definitiv keine Ruckler mehr. Vielleicht bekommen wir ja erste Aussagen wie es übers Inet läuft, wenn ich am Wochenende den dedicated Server zünde.
Bisher nicht angegangen habe ich das UDP-Problem der "vertauscht ankommenden" Pakete, die Magellan erwähnte. Sollte aber einfach zu lösen sein. Jedes "Positionsupdate-Paket" bekommt einfach eine fortlaufende Nummer. Beim Auswerten werden veraltete Positionsdaten einfach weggeworfen.
Und die optimale Paketgröße benötigt auch noch ein paar Tests die noch vor uns liegen. Da wissen wir bald mehr.

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Ich bin ja mal gespannt wie denn die ersten live-Testberichte aussehen. Dein Spiel hat auf alle Fälle meine Aufmerksamkeit erregt (Wow..du darfst dich jetzt wahsinnig geadelt fühlen )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hehe, danke. Ich habe gestern noch die Maussteuerrung eingebaut (ja, ich weiß, es stand nicht auf dem Plan ) und noch einen grafischen Gimmick vorbereitet (Triebwerkspuren) und heute setze ich mich an die Vollendung des dedicated Servers. Ich hoffe das ich recht schnell neue Features bringen kann, aber es sieht ganz gut aus, da viele grundlegende Sachen schon laufen auf die ich jetzt aufbauen kann.

Deine Idee mit dem Modellierwettbewerb finde ich gut. Den könnte man im Januar ansetzen denke ich.

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Ich hab mir die Trail von Freelancer angespielt und und X-BTF (aktuellerer Titel war nicht im Haus) ausgegraben.
Also die Steuerung bei X macht nen guten und bekannten Eindruck. Wobei dort nicht zwischen Schub und Bewegung unterschieden wird (wie das wohl bei vielen Weltraumknallern so ist).
Die Steuerung in Freelancer ist sehr interessant. Ich find sie gar nich so komplex. Wenn man nur die Maus bewegt, steuert man die Waffen und das Schiff fliegt einfach gradeaus weiter (oder wird per Tastatur gesteuert). Bei gedrückter Maus kommt der "Mousemove", womit man das Schiff komplett mit Maus steuern kann, aber die Waffen nur noch gradeaus feuern. So ähnlich könnte man das machen. Freelancer selbst konnte mich vom Spielinhalt nich begeistern. Zu viel festgelegte Story, zu viele Waypoints, alles nur Arcade. Aber die Grafik ist nett. Die Modelle scheinen mir auch recht wenig Polygone zu haben. Reicht aber voll aus wie ich finde, wenn man die passenden Texturen nimmt. Dann noch schon mit Bumpmapping (evtl. per Shader) arbeiten und es sollte reichen.

Ich habe meine Steuerung also umgebaut. Ich habe außerdem die Mausunterstützung wieder aktiviert. Ein paar weitere Details findest Du im ProjektThread.
Am besten nochmal probieren, ob Ihr jetzt besser zurecht kommt.

Grüße,
DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Mit Shadern solltest du Vorsichtig sein.
1. Kann da nicht jeder dein Spiel spielen (es gibt verdammt viele alte Karten da drausen. Hab selber noch keine Shaderfähige)
2. Musst du verdammt viel testen, damit es auch auf ATI läuft. (Die sind da bisl pingeliger)
3. Kanns Performance kosten. (Eine art LevelOfDetail-Bumpmap wäre da angebracht.)

Noch eine kleine Idee:

Als Special solltest du "Gravitonbremsen" einbauen, die es dem Spieler ermöglichen nahezu schlagartig zu verlangsamen ohne dass das Schiff zerreist. (Um das zu sichern brauch man wieder andere Upgrades, die vielleicht die Max-Geschwindigkeit negativ beeinflussen, oder die Ladekapazität.) Das Bremsen ermöglicht es vielleicht dem Spieler in Verfolgungsjagden seinen Verfolgern durch die "Hintertür" zu entwischen.

Nur so ne Idee.... (Hab ich andauernd...is wie ne Krankheit )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ok, ich hatte nur letztens gelesen, dass Bumpmapping relativ bequem mit Shadern machbar sein soll. Wenn jedoch die Probleme überwiegen, dann lassen wir das. Oder es wird eine Option. Aber ich finde Bumpmapping relativ wichtig, wenn man schöne Modelle machen will bei moderater Polygonzahl.


Immer raus mit den Ideen.
Im Prinzip sind die Bremsen schon eingebaut. Taste "S". Die war aber mehr für die Testphase gedacht. Aber im endgültigen Spiel könnte man sowas auch vorsehen, stimmt. Ich freu mich schon richtig auf die Konfigurationsphase. Da können hier alle SciFi-Fans ihre Ideen ansagen und dann schauen wir, was umsetzbar ist.

P.S. Bei Elite gabs sowas in der Art auch, nur noch verschärfter. Retro-Rockets. Da haben die Verfolger immer Augen gemacht ....

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Hm, klingt auf alle Fälle interessant...
aber ma ne Frage: Hast du dir schon gedanken zum Grad des "Realisumus" bzw. wie simulationslastig das ganze werden soll?
Denn ich persönlich fand das Freelancer sich grad ma überhaupt nit angefühlt hat wie ein Weltraumspiel...
in Battlecruiser Millenium find ich das ganze dann schon wieder übertrieben...


cya
Deathball

Ich findes eigentlich schon gut wenns scalierbar ist. Am Anfang kann der User ja ein Schiff haben, was auch wirklich jeder vernünftig steuern kann. Die großen "Schlachtkreuzer" die er vielleicht später mal fliegen kann brauchen aber etwas mehr feingefühl und Erfahrung. Das könnte vorallem bei Onlinegames interessant werden, wenn man einem "alten Fuchs" zugucken kann wie er wildeste Manöver fliegt obwohl jeder Anfänger schon beim einfachen Kurvenfliegen in schwitzen gekommen wäre. Das hat dann was von Langzeitmotivation. Und jemand der halt ein richtig kompliziertes Schiff beherrscht bekommt dann auch mehr Ansehen (und als Nebeneffekt vielleicht auch Aufträge die andere nicht bekommen würden. Einfach WEIL er so ein besonderes Schiff hat, was Eigenschaften hat die man für den Auftrag brauch.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wenn möglich, würde ich das server-seitig einstellbar machen. Sowas wie Sim<>Arcade....

Und dann für Sim auf jeden Fall das ganze Programm.... Trägheit, Fliehkraft, Gravitation....

Ansonsten natürlich für den Storymode auch so Sachen, die einem im Sim-Mode helfen. Retro-Rockets, Trägeheitsdämpfer, Hilfsdüsen....

_________________


"User Error. Replace User and hit Continue."

Gute Frage das. Ich versuche den Simulationsgrad so hoch anzusetzen, dass er nicht den Spielspass verdirbt.
Ich würde es ungefähr bei X-BTF einsortieren.

Deine Meinung zu Freelancer teile ich. Ich habe die Demo angespielt und es war mir zu arcademäßig, aber die Steuerung war ok und die Grafik auch gut (Nur bissel sehr bunt). BCM kenne ich nicht, ich versuche aber mal ne Demo zu kriegen.

Ich glaube man muss einen guten Mittelweg finden. Und der Mittelweg geht bei mir so, dass überall wo ein Spiel durch Realismus eklig wird, die Science-Fiction aushelfen muss. Ich bringe mal ein paar Gedanken dazu.

- Triebwerke: wenn man es realistisch macht, braucht man ewig zum beschleunigen/bremsen. Das nervt den Spieler. Genauso dass entsprechend stärkere Triebwerke die Insassen sofort töten würden. Also SciFi -> geht halt.
Aber das Prinzip, dass ein Triebwerk nur die Richtung des Objektes ändert behalte ich bei. Auch, dass man Gegenschub erzeugen muss um anzuhalten (Auch wenn die Art diesen zu erzeugen vereinfacht wird).

- Laser: Laser ist prinzipbedingt schnell. Den sieht man nicht "fliegen", den sieht man als Strahl. Sofort und bis zum Ziel. Aber so sind Dogfights öde und die Laser sehen nich so schön aus. Also sinds halt keine Laser sondern was anderes. Partikelbeschleunigerkanonen oder sowas.

- Gravitation soll rein. Finde ich, dass die wichtig ist. Irgendeiner muss ja den rumtreibenden Weltraummüll aufsammeln. Kann sein, dass ich die Gravitation etwas stärker wirken lassen muss. Mal sehen.

- Bewegung der Planeten und Monde. Da fehlt mir der physikalische Background, aber die Frage interessiert mich schon. Genaugenommen bewegen sich ja die Planeten und das nicht mal langsam. Wenn man jetzt anfängt diese Bewegungen mit echten Geschwindigkeiten im Spiel umzusetzen, werden hunderte Schiffe von herumfliegenden Planeten getroffen. Also werden die Planeten bei mir stehen. Eine Vereinfachung die ich für unumgehbar halte, da ich auch nicht weiß, wie ich das ganze im Spiel umsetzen sollte. Zum Beispiel wenn ein Schiff stationär über einem Mond steht. Beide sind relativ in Bewegung, aber stehen quasi zueinander. Allein der Stress denn man sich aufbürdet einen Planeten zu erreichen (also praktisch sich von ihm in seinen Orbit einfangen lassen).

- Entfernungen. sind ja nun riesig. Die werden im Spiel etwas angepasst und den Rest regeln wir mit entsprechenden Triebwerken oder dem guten alten TorusDrive. Es wäre schlimm, wenn der Spieler ewig bis zum nächsten Planeten braucht.

- Licht und Schatten. Auf der Sonne abgewendete Seite eines Planeten kann man Sachen prima verstecken ('ne Flotte oder so). Mal schauen ob ich das umgesetzt kriege.


Welche Punkte fallen Dir denn noch ein? Vielleicht kann man ja ein neckisches physikalisches Feature einbauen, welches das Spielprinzip unterstützt und nicht behindert? Es kommt in jedem Fall darauf an, wie knallhart man das umsetzt.

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de