• Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011
Sign in to follow this  
Followers 0
AniProGuy2

Synchronisation von "Nicht-Spieler-Objekten" durch wechselnde Ownerships?

3 posts in this topic

Hallo liebe Community,

ich arbeite ja bereits seit einiger Zeit an einem Spiel, welches ich durch PUN netzwerkfähig machen möchte. Dabei handelt es sich allerdings um meinen ersten Versuch, Networking in einem Spiel umzusetzen und dementsprechend bin ich auf diesem Gebiet auch noch ein Anfänger (wobei ich schon einiges gelernt habe, in den letzten Monaten). Nun stellt sich mir allerdings eine grundsätzliche Frage zum Thema "Synchronisation" für mein Spiel.

Und zwar ist die Synchronisation von Spieler-Objekten in meinen Augen noch verhältnismäßig simpel. Client A hat seinen Spieler und auf diesem Spieler lasse ich alle wichtigen Funktionen laufen, deren Auswirkungen (Animationen hauptsächlich) ich dann auf allen anderen Clienten für dieses Spieler-Objekt nachmachen lasse (dafür kann ein Spieler-Objekt immer im aktiven und im nicht-aktiven Modus sein, sprich selbst aufführen oder nachmachen). Damit gibt es soweit eigentlich auch keine Probleme.

Was mir allerdings Kopfschmerzen bereitet, sind Nicht-Spieler-Objekte. In meinem Spiel sind diese ein essentieller Bestandteil des Grundkonzeptes. So gibt es z.B. Baumaterial wie Holz oder Steine und auch Waffen wie Bomben, die als Objekte in der Landschaft herumliegen, und mit denen jeder Spieler interagieren kann (z.B. diese aufsammeln). Nun ist für mich die Sychronisation dieser Objekte ein großes Fragezeichen. Und zwar ist es meines Wissens nach ja so, dass die Position eines Objektes - nehmen wir einmal das Spieler-Objekt - immer von Besitzer des Objektes hin zu den anderen Clienten synchronisiert wird. Sprich, wenn Client A seinen Spieler bewegt, wird diese Bewegung zu allen anderen Clienten synchronisiert. Allerdings haben besagte Nicht-Spieler-Objekte ja eigentlich keinen Besitzer, da jeder Client das gleiche "Anrecht" auf sie hat, sprich mit ihnen interagieren und sie aufsammeln kann. Somit steht nicht statisch fest, von welchem Clienten aus z.B. ihre Position zu den anderen Clienten synchronisiert werden muss. Und genau das ist für mich das Problem.

Mein bisheriger Lösungsweg sieht folgendermaßen aus: Wird eines dieser Nicht-Spieler-Objekte von einem Spieler aufgesammelt, wird automatisch dieser Spieler zum neuen "Besitzer", was via "Ownership Transfer" in PUN umgesetz wird. Die Position dieses Objektes und auch die Berechnungen im Objekt werden nun von besagtem Spieler aus sychronisiert (das Aufsammeln dieser Objekte stellt in meinem Spiel glücklicherweise in den meisten Fällen die Grundlage einer Interaktion mit ihnen dar).
Sammelt ein Spieler also nun eine Bombe auf und wirft diese auf einen anderen Spieler, ist das Treffen der Bombe und somit der entsprechende Schaden für den anderen Spieler, davon abhängig, ob die Bombe in der Version des "Aufsammlers" auch wirklich trifft. Das liegt daran, dass das Treffen und all seine Konsequenzen (Explosion, Schade, Zerstörung der Bombe) nur bei dem "Aufsammler" be,-und errechnet werden und zu allen anderen Clienten nur sychnronisiert wird (der Aufsammler ist ja wie bereits gesagt der Besitzer).

Das Prinzip is also gleich dessen der Spieler-Objekte, nur dass der Besitzer nicht mehr statisch ist, sondern durch das Aufsammeln eines Objektes wechseln kann. Somit ist eine Sychronität dieser Objekte (sofern ich es richtig umsetze ;P) immer gewährleistet. Alleridings ist es auch möglich, dass in der Version des Aufsammlers die Bombe aus besagtem Beispiel trifft und Schaden macht, aber in der Version des Ziels dies gar nicht der Fall ist (durch einen Lagg oder aus anderen Gründen). In diesem Fall ist also der Besitzer im Vorteil.

Meine eigentliche Frage ist nun:
Haltet ihr dieses Konzept für sinnvoll? Oder gibt es da viel bessere Lösungswege? Oder habe ich da etwas komplett falsch verstanden und es ist eigentlich ganz einfach? ^^

Ich bin dankbar für jede Hilfe! :)

mfG,
AniProGuy2

Share this post


Link to post
Share on other sites

Ich bin kein Netzwerkprofi, aber deine Theorie klingt für mich schlüssig. Ich kenne PUN nicht im Detail, aber deine beschriebenen Probleme kommen zum Teil daher, daß du quasi keinen authorativen Server hast, der den "Ownership" eines gespawnten Netzobjektes übernimmt und du damit immer einen Spieler als Owner bestimmen musst. Dies wird aber impliziert durch die verwendete Methodik von PUN, d.h. keinen authoritativen Server, der alle Zustände gespawnter Netzwerkobjekte definiert und vorgibt (wenn ich das richtig verstanden habe). sondern der PUN-Server stellt "nur" eine eindeutige Verbindung (PUN-Views) zwischen den Spielern (Clients) her und ordnet diese immer einer eindeutigen Identität zu (Lobby / Room / Groups / ViewID). Da dir also der Server fehlt, wird quasi immer ein Spieler zu "deinem Server" (Masterclient) und damit bestimmt auch immer ein Spieler den Zustand eines gespawnten Objektes.

PS:
Den (großen) Nachteil von PUN sehe ich allerdings nicht in der Methodik selbst, sondern eher in der Cheatanfälligkeit. Manipuliert ein Spieler seinen Client, kann er damit die Zustände den Spieles beeinflussen (und auch die anderen Mitspieler), was bei der Verwendung eines authorativen Server sehr erschwert wird, da hier der Server die Zustände der Clients noch einmal zusätzlich kontrollieren kann oder sogar sämtliche Zustände und "(Physik-)Simulationen" (bspw. Geschosse) selbst durchführt und damit nicht der Spieler entscheidet, ob beispielsweise ein anderer Spieler getroffen wurde. Die Clients dienen dabei mehr oder wenig nur noch als bessere "Eingabegeräte" und "Ausgabegeräte" und der Server simuliert sämtliche Zustände innerhalb des Spiels (es gibt aber denke ich auch "Teillösungen") Allerdings kostet diese Umsetzung wesentlich mehr Entwicklungsaufwand. Ich denke aber gelesen zu haben, daß auch mit Photon ein authorativer Server möglich ist:
https://doc.photonengine.com/en-us/onpremise/current/reference/authoritative-server

1 person likes this

Share this post


Link to post
Share on other sites

Also das mit dem authorativen Server klingt natürlich logisch und auch mehr als wünschenswert. Allerdings bin ich mir nicht sicher, inwiefer nich das umsetzen kann, da wie gesagt meine Fähigkeiten in diesem Bereich noch nicht so ausgereift sind. Allerdings werde ich mir das definitiv einmal ansehen und eventuell auch einmal ausprobiere (je nachdem, wie schwierig das ist).

Aber ansonsten ist meine Variante nachvollziehbar, bzw. logisch, oder? Es ist natürlich sehr cheatanfällig, das ist richtig und leider wohl auch mit meiner Umsetzung nicht wirklich vermeidbar :(

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0