Standard FPS Multiplayerfähig machen

[Faddy]

Hallo,

 

ich mach mich grad zum ersten Mal an den Networktools von Unity 5.

Jetzt dachte ich mir nimm ich einfach den FPS aus den Standard Assets (RigidbodyFirstPersonController) um mir das zu sparen.

 

Jetzt hab ich das Problem, wenn der Client joint, sind die beiden Spieler zusammen. Einer lässt sich aber nur steuern aber der andere bewegt sich mit.

 

Nun hab icg das Script einmal auf NetworkBehavior umgesellt, eine NetworkIdentity Variable erstellt und zugewiesen und vor jedem input

 

if (Playeridentity.isLocalPlayer) abgefragt.

 

Nun bewegen sich beide Synchron und ich kann von beiden steuern...

 

Oo

 

Gibt es eine Möglichkeit den Standart FPS so umzumodeln das es läuft oder muss ich da doch selber ran und mir was eigenes bauen... ?

 

Oder hab ich gar einen ganz anderen Denkfehler...?

 

Danke

[Faddy]

Mir ist aufgefallen, dass ich da einen Denkfehler hatte.

Ich denke ich muss nicht den Charakter Controller anpassen, sondern diesen abschalten. Genauso wie die Kamera.

Ich werd das mal versuchen und wenn es zum Erfolg führt hier noch einmal posten.

 

:/

 

EDIT:

So dann hab ich das auch mal getestet...

Und für alle die ähnlich faslch an die Sache ran gehen, hab ihc das so gelöst.

 

using UnityEngine;
using System.Collections;
using UnityEngine.Networking;
public class NetIDCheck : NetworkBehaviour {
public NetworkIdentity _identity;
public Camera _cam;
public CharacterController _charcont;
public BasicLauncher _Launcher;

// Use this for initialization
void Start () {
	//Debug.Log("Start");
	_Launcher = GetComponentInChildren<BasicLauncher>();
	if (!_identity.isLocalPlayer)
	{
	   // Debug.Log("isnotlocal");
		_cam.enabled = false;
		_charcont.enabled = false;
		_Launcher.enabled = false;
	}
	else
	{
	   // Debug.Log("islocal");
		_cam.enabled = true;
		_charcont.enabled = true;
		_Launcher.enabled = true;
	}
}

// Update is called once per frame

}

 

Also ein Script am Prefab, wo ich die islocalPlayer-Abfrage t#tige und dann alle Komponenten die nicht vom anderen Spieler beeinflusst werden sollen ein- bzw. ausschalte.

[MaZy]

Stell dir einfach beim Multiplayer das vor.

 

Die digitale Welt ist nicht anders.

Wenn ein Auto von einen Menschen gefahren wird, schalten wir das "fahren" nicht aus, weil wir selber nicht fahren. Wir wissen, dass andere Autofahrer/in Pedale und Lenkrad benutzen usw. Quasi wir "Empfangen" die Daten. Da wir aber logisch denken können wissen wir, warum ein Auto gerade beschleunigt oder bremst. Weil der Fahrer/in das tut.

 

Genau so ist es in Multiplayer auch (naja bissel so). Wir schalten keine Scripte (fahren) nicht aus, sondern passen es an. Fahre ich das Auto, dann drücke ich auf die Pedale und man sendet, dass man gedrückt hat. Fährt ein anderer.. dann drücke ich nicht drauf, sondern Empfange die Daten, ob der Mitspieler auf die Pedale drückt.

Je nach dem Bewegt sich das Auto dann.

 

Klar kann man auch einfach nur die Position updaten, aber dann sieht das nicht toll aus. Auch nicht bei Charaktere. Für so Kleinigkeiten kann man das aber machen.

 

Alles was clientsided nicht gebraucht wird kann weg bzw. auch ausgeschaltet werden wie die Kamera.

 

Nur so mal als tip

[malzbie]

Da möchte MaZy's Erklärung aber ein kleines Bißchen wiedersprechen.

Denn leider nutzt man aus performancegründen ein Netzwerkprotokoll (UDP) welches nicht überprüft ob ein Datenpaket auch angekommen ist. Würde jetzt solch ein Datenpaket nicht ankommen, und dort wäre gerade die Info drin, dass eine Taste vom Gegenspieler gedrückt wurde, dann würde das Objekt, was der Gegenspieler steuert, etwas falsches auf deinem Rechner machen.

Das fürht in der Regel zu falschen Positionen des Gegenspielers. Denn auch wenn nur eine zehntel Sekunde zwischen 2 Paketen liegt, summiert sich das mit der Zeit.

Also muss man immer wieder die wichtigen Dinge wie Position und Ausrichtung im Raum an die anderen Spieler senden um das zu synchronisieren. Da die Gegner dann aber zurück gesetzt werden, falls sie unsynchron waren, kommt es zu unschönen Spielerlebnissen.

Wenn man also sowieso oft die wichtigen Dinge wie Position und Ausrichtung senden muss, kann man das auch gleich jedesmal tun und kann sich auf der anderen Seite aufwendige Steuerungsprogramme sparen.

Natürlich kommt es zu Rucklern bei der Bewegung der Gegner, da die Übertragungsrate im Netzwerk nicht hoch genug ist.

Deswegen muss man die Position der Computergegner interpolieren/extrapolieren und damit versuchen die Bewegung schön weich zu machen. Das ist natürlich auch etwas ungenau, da ich ja hochrechne, wo beim nächste Datenpaket der Gegner sein wird, und das muss nicht immer richtig sein. Trotzdem sind die Unterschiede nur minimal und wenn man es richtig macht sieht man es kaum.

Das Photonnetzwerk übernimmt einem diese Arbeit sogar. Zu anderen Netzwerken kann ich nichts sagen.

[MaZy]

Sorry hat gedauert darauf zu reagieren.

 

@malzbie

Ich habe jetzt nicht gesagt, dass man die Bewegung (Position, Rotation) nie senden soll, sondern, dass man nicht immer braucht zu senden. Da hast du natürlich recht. Bei Photon PUN läuft es natürlich ganz anders ab. Bin jetzt davon ausgegangen, dass man auch den Server selbst entwickelt und keinen Cloudserver benutzt.

 

Naja du sagst, wenn man "oft" braucht, dass man das dauerhaft senden kann. Kann man machen, aber bei vielen Spieler könnte das Probleme machen. Man muss halt gucken wo man es benutzt

 

Außerdem UDP ist nicht mehr so low. Auf jeden Fall nicht bei Photon, UNet usw. Du hast bestimmt schon mal von Reliable gehört. Reliable garantiert bei UDP, dass ein Paket auf jeden Fall ankommt. Ist quasi eine abgemagerte Funktion von TCP.

In Wikipedia wird das auch beschrieben: Reliable_User_Datagram_Protocol

UNet hat sogar bei Channel 0 sogar Standardmäßig Reliable Sequenced.

 

Dies kann man bei Inputs, die einmal gesendet werden auf jeden Fall verwenden, denn da sendet man eigentlich nur 0 oder 1 bzw ein byte. oder für negative Werte sbyte (sbyte hab ich aber nie getestet).

Ich kann bei einem Source-Spiel Garry's Mod mich sehr gut daran erinnern, dass das Spiel in einer Lanparty bei mir für ca 10. eingefroren war, aber ich hatte vorher W für Vorwärts gedrückt. Naja auf anderen PCs bin ich halt wie Wild durch die Welt geflogen. Source Server von Valve hat nun mal W registriert ^^. Aber da gibt es auch noch viel komplexere Berechnungen. Auf jeden Fall gehen die so ähnlich auch vor.

 

Aber was ich eigentlich mit meinem vorherigen Post eigentlich sagen wollte war, dass viele anscheinend immer das gleiche Problem am Anfang haben. Sie denken, dass man einfach so die Inputs drinne lassen kann und der Remoteplayer wird nicht gesteuert, wenn sie die jeweilige Taste drücken. Da hab ich dann eben das Auto als Erklärung genommen.