Ich habe dies für ein kommerzielles PSP-Rennspiel getan, das sowohl über ein Ad-hoc-Netzwerk als auch über einen drahtlosen Hotspot funktioniert. (Oder auf Wunsch zu einem statischen Server im Internet)
Aufgrund von Punkt 2 muss das System hinsichtlich der Optimierung nicht komplex sein
Nach meiner Erfahrung ist dies nicht wahr. Drahtlose Geräte (insbesondere kleine tragbare Geräte) sind nicht mit Computern mit kabelgebundenen Netzwerkverbindungen vergleichbar. Smartphones und drahtlose Spielekonsolen verfügen für Spielzwecke in der Regel über langsame Netzwerkschnittstellen.
Verstehen Sie mich nicht falsch - ihr Durchsatz ist normalerweise gut (dh die Datenmenge pro Sekunde; ideal für das Streamen von Filmen usw.), aber die Latenz bei der Zustellung eines bestimmten Pakets kann extrem schlecht sein und kann es auch sein Sehr variabel, dass es schwierig ist, abzuschätzen, wie lange die Zustellung eines einzelnen Pakets dauern wird. Diese Variation wird noch schlimmer, wenn mehr drahtlose Geräte in einem allgemeinen Bereich zusammengefasst werden, da ihre Signale beginnen, sich gegenseitig zu stören. Infolgedessen wurde ein großer Teil meiner Zeit damit verbracht, die Anzahl der zu sendenden Pakete zu reduzieren, sodass wir weniger Paketkollisionen haben würden. (Beachten Sie, dass dies in dem Fall, in dem es sich um einen Hotspot mit aktivem Netzwerk handelt, weniger problematisch ist, als dass die Geräte direkt über ein Ad-hoc-Netzwerk miteinander kommunizieren.)
Als Beispiel für diese Art der Optimierung fand unser Rennspiel in einer Welt mit Ampeln statt. Tausende von ihnen. Und wir mussten sicherstellen, dass ihre Signale zwischen allen Spielern in einer Netzwerksitzung synchron waren. Anstatt zu versuchen, Pakete zu versenden, um allen mitzuteilen, welche Ampeln sich in welchem Zustand befinden, haben wir einen statischen Zeitplan für alle Ampeln definiert und dann nur sichergestellt, dass sich alle Kunden auf die aktuelle "Spielzeit" geeinigt haben. Da sie alle die Spielzeit kannten und alle Ampelzustände aus der Spielzeit ermittelt werden konnten, haben wir alle diese Zustandsdaten synchronisiert, ohne tatsächlich spezielle Daten zu senden. Diese eine Änderung hat einen großen Unterschied für unsere Netzwerkleistung gemacht.
Die Einrichtung einer zuverlässigen Taktsynchronisation zwischen mehreren drahtlosen Geräten (mit sehr unterschiedlichen Ping-Zeiten, die hauptsächlich auf Paketverlust zurückzuführen sind) war eine große Herausforderung. Gerne sprechen wir mehr darüber, wenn Sie Interesse haben.
Jeder Kunde kann eine maßgebliche Datenquelle über sich und seine unmittelbare Umgebung sein (z. B. Aufzählungszeichen).
Dies ist, was wir getan haben, und es hat in unserer Situation (Autos) gut für uns funktioniert. Der problematische Teil ist natürlich, wenn ein Objekt nicht mehr näher an Spieler 'a' als an Spieler 'b' ist und sein Eigentum daher von einem Spieler auf einen anderen übertragen wird.
Dies ist tatsächlich eine überraschend komplexe Verhandlung zwischen Spielern, bei der Spiel 'a' Spiel 'b' vorschlägt: "Ich denke, dieses Objekt ist näher bei Ihnen. Sie sollten die Kontrolle darüber übernehmen." Und dann kann Spiel 'b' entweder akzeptieren oder ablehnen, basierend auf seiner eigenen Sicht der Situation. Unterschiede im wahrgenommenen Spielzustand zwischen 'a' und 'b' und die Änderung der Zeit zwischen dem Senden und Empfangen der Anfrage und der Antwort machen dies zu einer besonders unangenehmen kleinen Verhandlung, um zuverlässig zu werden, und es kann leicht zu einem Spiel von degenerieren "heiße Kartoffel", bei der das Eigentum ständig zwischen mehreren Spielern hin und her springt. Und selbst wenn es richtig funktioniert, aus der Sicht von Spiel 'c', dort '
Meine Intuition ist, dass diese Art von "Objektbesitz" -Ansatz für kleine, kurzlebige Objekte wie Kugeln wahrscheinlich zu umständlich ist. Wir haben es für Verkehrsautos und KI-Rennfahrer verwendet, die dazu neigten, relativ lange in der Simulation zu leben. Es scheint ein performanterer Ansatz zu sein, wenn Sie bereit sind, den Kunden zu vertrauen, dass das Spiel jedes Spielers seine Position und seine Projektile besitzt und erklärt, wann dieser Spieler vom Projektil eines anderen getroffen wurde. (Als "Spiel A" bin ich dafür verantwortlich zu sagen, wo sich die Projektile von Spieler A und Spieler A befinden, aber Spieler B ist dafür verantwortlich zu sagen, ob ich Spieler B getroffen habe). Mit einigem Dead-Reckoning sollten Sie in der Lage sein, aus einem solchen System ein ziemlich vernünftiges Verhalten herauszuholen.