Glenn gibt in seinem Artikel und seinen Kommentaren ein sehr starkes Argument für die Verwendung von UDP über TCP an, aber SC2 verwendet offensichtlich TCP.
Glenn spricht hauptsächlich über physikgetriebene Spiele, dh. Ego-Shooter und Fahrspiele. Diese haben andere Anforderungen als Echtzeit-Strategiespiele, bei denen genaue Einheitenpositionen bei jedem logischen Schritt wichtig sind. Die Kommunikationsstrategien sind also notwendigerweise unterschiedlich.
"Echtzeit" bedeutet verschiedene Dinge in verschiedenen Kontexten. Spiele sind in Echtzeit nicht "schwer". Wenn eine Nachricht zu spät kommt, bricht das Ganze zusammen. (Zumindest gibt es keinen guten Grund dafür, dass ein Spiel so anspruchsvoll ist, da ein reines Softwaresystem im Gegensatz zu einem Kernkraftwerk oder einem medizinischen Gerät in der Lage sein sollte, sich von Verarbeitungsverzögerungen zu erholen.) Spiele sind wirklich "weich" oder "fest" in Echtzeit. ( Definitionen bei Wikipedia wie gewohnt .) Die Art des Spiels macht einen Unterschied, wie schnell Sie die Informationen benötigen, ob Sie Informationen verlieren und damit durchkommen können usw. Es genügt zu sagen, dass TCP für viele Spiele gut genug ist, aber Für andere Spiele ist UDP vorzuziehen.
Ich vermute, dass sein Ansatz darin besteht, den vollständigen Spielstatus jeder Einheit auf jedem Frame zu senden.
Er würde genügend Informationen senden, um den relevanten Spielstatus jeder Einheit zu rekonstruieren, die sich geändert hat.
- Sie müssen keine Informationen zu etwas senden, das sich nicht geändert hat.
- Sie müssen nicht den vollständigen Status senden, wenn Sie genügend Informationen senden können, damit der Empfänger den neuen Status aus dem alten Status erstellen kann. (z. B. Senden Sie einfach einen Delta-Wert relativ zu einem alten Status. Oder senden Sie einfach die Teile des Status, die sich geändert haben, und nicht den Rest.)
- Wenn zwei Spiele genau denselben Algorithmus ausführen und genau dieselben Daten haben, können Sie einfach Eingaben senden, und der Empfänger simuliert die Effekte lokal neu, um den neuen Status abzuleiten.
Die meisten Spiele erfüllen nicht die Kriterien für 3, daher verwenden sie stattdessen 1 und 2. Viele RTS-Spiele können und können jedoch 3 verwenden.
Außerdem muss es nicht unbedingt "jeder Frame" sein. Das Konzept eines Rahmens ist ebenfalls nebulös. Ist es ein Rahmen für das Rendern? Ist es eine Menge Logik? Ist es ein Rahmen von Netzwerkdaten, die gesendet werden? Stimmen die drei immer eins zu eins überein oder erhalten Sie eine variable Grafikrate mit festen Logikraten? Einige Spiele, insbesondere Echtzeit-Strategiespiele wie Starcraft 2 oder Spiele mit Wiederholungsfähigkeit (wie Sie sie berühren), möchten alles durch regelmäßige Netzwerkaktualisierungen (die in anderer Hinsicht mit "Frames" übereinstimmen oder nicht) in perfektem Gleichschritt halten Dies ist nicht für alle Spiele erforderlich. Viele Spiele senden nur regelmäßig Updates, je nachdem, wie weit sie bereit sind, die Clients laufen zu lassen.
Die Eingabe durch den Spieler ist wichtig, und die Eingabesequenz ist noch wichtiger. Ich denke nicht, dass es für SC2 machbar ist, einen Spielstatus von 200 Einheiten und mehr mit 30 - 60 FPS zu senden.
Viele Spiele behandeln einen Rendering-Frame nicht unbedingt als logischen Frame. Sie haben möglicherweise 60 FPS in Grafiken, aber nur 10 Logikaktualisierungen pro Sekunde und senden jeweils 1 Netzwerkaktualisierung. Aber selbst 30 Netzwerkaktualisierungen pro Sekunde sind sinnvoll, wenn Sie die Methode "Eingabe senden" verwenden.
Ich habe versucht, zwei mögliche Datentypen zu identifizieren. Was sind andere Techniken? Es wird gut sein, das Spiel zu beenden, wenn Sie so wollen.
Es gibt nicht so sehr unterschiedliche Techniken, sondern verschiedene Einschränkungen für die Systeme, und die Bedeutung jeder Einschränkung variiert von Spiel zu Spiel. Sie müssen also nur ein System auswählen, das für Sie funktioniert.
- Nur wenige Einheiten, die sich schnell und unregelmäßig über Benutzereingaben bewegen, haben eine empfindliche Latenz, eine genaue Synchronisation zwischen Systemen ist nicht wichtig - Broadcast-Positionen über ein unzuverlässiges Protokoll (z. B. UDP), um maximale Geschwindigkeit zu erzielen, und verpasste Nachrichten spielen keine Rolle wie neue komm bald rein. Simulieren Sie die Physik lokal, um die Renderqualität zu verbessern, korrigieren Sie jedoch die Positionen, wenn neue Informationen eintreffen. Gut für Schützen und Fahrspiele.
- Viele Einheiten, aber die meisten sind irrelevant und bewegen sich langsam - senden Sie nur Aktualisierungen für Einheiten in der Nähe des Empfängers, senden Sie sie als Änderungen und nicht als vollständige Zustände, senden Sie sie relativ selten und senden Sie sie über ein zuverlässiges Protokoll (z. B. TCP), um dies zu vermeiden sich Gedanken darüber zu machen, wie mit verpassten Updates umgegangen werden soll. Gut für MMOs.
- Viele Einheiten, die von der KI aufgrund vorheriger Benutzereingaben bewegt wurden, haben eine genaue Synchronisation zwischen den Systemen sehr wichtig. Senden Sie Benutzereingaben mit Zeitstempel über ein zuverlässiges Protokoll und simulieren Sie sie lokal neu, damit die Spielalgorithmen den Status synchronisieren. Gut für RTS und rundenbasierte Spiele.