spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi, ich experimentiere im Moment mit einem anderen Kamera-Ansatz herum, den ich bisher häufiger mal angetroffen habe: Mehrere Spieler teilen sich eine Kamera, diese wird bewegt und gezoomt, so dass alle Spieler sichtbar sind. Allerdings ergeben sich dabei ziemlich absurde Szenarien. Ich habe mal ein paar Screenshots angehangen.
Mein Problem ist, dass sich Spieler prinzipiell beliebig weit von einander entfernen könnten. Bis zu einem gewissen Grad macht das auch Sinn - danach wird es nur noch absurd, weil die Kamera zu weit wegzoomen muss. Daher überlege ich wie ich den maximalen Spieler-Abstand am besten kontrolliere.

Die bisherige Idee: Wenn sich ein Spieler bewegen will wird geprüft, ob sein neuer Abstand zu den anderen Spielern noch erlaubt ist (quasi float const MAX_PLAYER_DISTANCE). Den Ansatz gibt es ja in verschiedenen Spielen. Allerdings sehe ich da ein Problem: Manchmal habe ich es (bei anderen Spielen) aber erlebt, dass man sich dann nicht mehr wegbewegen konnte. Beispiel mit drei Spieler: Spieler 1 bleibt stehen, 2 und 3 gehen hinter eine Wand (das ganze Szenario ist auch nochmal im Anhang). Danach geht Spieler 3 zurück zu 1. Das ganze Szenario spielt sich knapp am Rand der maximalen Entfernung ab. Dann geht die 3 entgegengesetzt zur 2 weg bis die maximale Distanz erreicht ist. Anschließend kann sich 2 nicht mehr bewegen ohne, dass 3 zurück kommt

Habt ihr eine Idee wie ich den Ansatz mit der Entfernungslimitierung umsetzen kann ohne dieses Problem zu erzeugen?

LG Glocke

/EDIT: Die einzige Möglichkeit die mir einfällt ist, statt der Distanz via Luftlinie die Distanz via Pathfinding zu nehmen.

/EDIT: Umfrage eingefügt

Zitat von »BlueCobold«

Zitat von »iSmokiieZz«

Ansonsten: warum sollte der grüne nicht mehr laufen können?

Weil da eine Wand ist und er um rundrum zu laufen sich zunächst weiter entfernen müsste?

Genau so sieht es aus!

Zitat von »ChrisvA«

Generell sollte die Kamera aber die Spieler nicht zu sehr in ihrer Freiheit einschränken, sonst baut sich da eher Frust auf...

Da gebe ich dir definitiv recht!

Zitat von »ChrisvA«

Ich hätte hier spontan auch mal auf die Legoreihe verwiesen, die das mit einem Mix gelöst haben

Der Ansatz sieht echt interessant aus!

Zitat von »Nox«

Es gibt noch den Ansatz des "Teleportierens". Sprich sobald sich die Spieler zuweit voneinander entfernen, wird ein Spieler zum anderen versetzt. Nicht gerade elegant, aber schnell implementiert.

Richtig "verpackt" vllt. gar nicht so schlecht... Aber für meinen konkreten Anwendungsfall leider nicht so sinnvoll..

Zur Idee mit dem Hybrid aus Shared- und Split-Screen: Bei zwei Spielern ist das vermutlich relativ einfach - auch wenn man die Möglichkeiten der Aufteilung (wie im verlinkten Video der Lego-Spiele gezeigt) in Betracht zieht. Ich versuch mir das ganze gerade für drei, vier oder mehr Spieler vorzustellen ... ein ständiges Gewechsel zwischen einer und n Kameras, wobei sich mehrere Spieler manchmal eine Kamera teilen. Spätestens wenn der dritte Spieler rechts "aus dem Bild" läuft, seine eigene Kamera bekommt, und dann nach unten und weit nach links läuft (ohne seine eigene Kamera zu verlieren), dann würden die Kameras u.U. getauscht werden - damit der Spieler der am weitesten links ist auch die Kamera hat, die am weitesten links ist usw. Ich glaube bei mehr als drei Spielern wird das ein ziemliches wirr-warr

Was wäre, wenn man als Kriterium der Distanz statt der größten Luftlinie zwischen zwei Spieler den längsten kürzesten Pfad nimmt (ok das klingt verwirrend ). Also konkret: Zwischen allen Spielern (1-2, 1-3, 1-4, 2-3, 2-4, 3-4 im Falle von vier Spielern) den kürzesten Pfad berechnen und für diese Pfadlängen das Maximum wählen - und mit dem maximalen Abstand vergleichen. Dann darf der blaue Spieler (siehe Beispiel oben) gar nicht so weit gehen, weil der Pfad zum weitesten entfernten Spieler (grün, der hinter der Wand sitzt), die maximale Entfernung überschreiten würde. Andersrum: Grün hat dann immer noch eine Chance sich zu bewegen - weil ein Pfad zu einem der anderen Spieler existiert, so dass die "Grenzsituation" entschärft werden kann.

Zitat von »Schorsch«

Wenn du eine Art Schnecke hast in die sich ein Spieler hineinbewegt so ist der Weg zwischen den beiden vielleicht groß, räumlich gesehen sind sie aber nah beieinander. Jetzt dürfen die Spieler nicht weiter gehen obwohl sie locker auf den Bildschirm passen. Das vor allem dem Spieler logisch zu verkaufen damit er sich nicht wundert und fragt warum das Spiel grad so rum bugt sollte nicht ganz so einfach sein.

Sehr guter Punkt!

Zitat von »Schorsch«

Wenn ja könnte man sich fragen wie die Level aufgebaut sind. Wenn ein Level eher aus abgeschlossenen Räumen besteht die miteinander verbunden sind so könntest du die Bewegung auf diese Räume beschränken. Möchte ein Spieler durch die Tür zum nächsten Raum so muss er darauf warten dass die anderen nah genug sind, bzw die anderen teleportieren sich möglicherweise nach. Statt Räumen können das natürlich auch kleinere abgeschlossene Gebiete sein die möglichst von der Kamera gesamt erfasst werden können.

Das mit den Räumen trifft es ganz gut. Mein Ziel ist es, die Spieler durch ein zufallsgeneriertes Dungeon streifen zu lassen (einen Prototyp für zufällige Räume und Gänge habe ich schon). Allerdings möchte ich nicht den ganzen Raum mit der Kamera erfassen. Auch der Ansatz mit "an der Tür warten" gefällt mir nicht ganz so sehr.. Soll ein Spieler Gegner über einen Gang oder aus einem Nachbarraum anlocken und die anderen warten im "Vorzimmer" (um irgendwelche strategischen Vorteile zu haben), wäre das etwas zu einengend.

Allerdings habe ich nie eine Art "Schnecke" (zumindest nicht im Kleinen): Die Räume und Gänge verlaufen streng orthogonal (d.h. nicht gedreht etc.) und Räume sind nicht ineinander verschachtelt. Kurz: Die Spielwelt ist wie bei klassischen Rogue-likes aufgebaut.

LG

/EDIT: Das ganze kann man sich so vorstellen, nur dass die Spieler i.d.R. nicht ganz so weit verstreut sind.