malzbie

@Damon93 Laut jetzigen und geplanten Regeln nicht! Wie Sascha aber anmahnt, ist das Vertrauen in die Firma nicht mehr da. Natürlich könnten die ihre Bedingungen immer anpassen und neue Kriterien setzen. Aber: Dass Unity Geld von dir verlangen wird, ohne dass du Geld eingenommen hast, wird nicht passieren. Sowas ist rechtlich überhaupt nicht abzubilden und außerdem würde das deren komplettes Geschäftsmodell zerstören und mit einem Schlag zum Untergang von Unity führen. Unity hat mit dem letzten Move sowieso schon so viel zerstört, dass die Zukunft dieses Unternehmens recht ungewiss ist. Wie Sascha schreibt ist das Vertrauen in Unity mächtig zerstört worden und das lässt sich nur schlecht wieder herstellen. Die Geldpolitik ist nicht so problematisch. Das war zwar der Hauptgrund für den Shitstorm, weil total schlecht kommuniziert wurde und sogar die obrige Tabelle zu Beginn anders beschriftet war. Es war nicht klar, dass es um die Einnahmen eines Spiels geht und es war auch nicht klar ob dann jeden Monat alle Einheiten wieder gezählt werden. Da haben manche Leute ausgerechnet, dass sie Millionen zu bezahlen hätten! Da war schon was los im Netz. Nachdem dann aber raus kam, dass man die TOS auf GitHub gelöscht hatte, ist den Leuten aufgefallen, dass es um viel mehr geht! Die Statements der Spielefirmen drehen sich jetzt nur noch um das verlorengegangene Vertrauen. Man kann nicht einfach ein neues Modell erstellen, was rückwirkend greift, also alle älteren Unityversionen mit beinhaltet, und stillschweigend die alten Vereinbarungen dazu löschen. Selbst wenn Unity zurückrundern würde, werden sie den Schaden spüren. Viele größere Firmen werden sich von Unity trennen. Dier Börse sieht das ähnlich. Der Aktienkurs ist seiter der Ankündigung um rund 10% gefallen. Ich könnte wetten, dass die Datenschützer inzwischen Witterung aufgenommen haben und sich jetzt mal anschauen werden, wie Unity denn die Installationen von Spielen überwacht. Das wird spannend! Ich warte einfach mal ab. Ich habe aber auch schon überlegt zu wechseln. Es ist aber so, dass Unreal sein Augenmerk auf AAA gelegt hat. Tolle Sache, wenn man was mit hochauflösenden Landschaften und grandioser Beleuchtung machen will. Im 2D Bereich sind die aber schwach. Dazu kömmt die Programmierung in C++ oder mit Blueprint. Godot ist im 2D Bereich super, aber 3D is dafür mangelhaft. Dann haben die auch noch schwächen im Importbereich. Alles was es sonst noch so gibt, ist recht nieschig. Ein Wechsel kostet viel Einarbeitungszeit, die ich als kleiner Entwickler eigentlich nicht habe. Ich bin schon seit ende 2009 mit Unity unterwegs und bin inzwischen richtig gut damit. Bis ich so gut mit einer anderen Engine umgehen könnte, würde sehr lange dauern. Aber was soll's. Wenn's sein muss, werde ich auch wechseln.

Gerne!

Viele von euch werden es wohl mitbekommen haben. Unity ändert seine Preispolitik. Ab 2024 will Unity etwas vom Kuchen ab haben. Momentan ist es so: Man nutzt die Free Version von Unity. Bis zu einem Firmenverdienst von 100.000$ ist alles ok. Verdient man mehr, muss man eine Kaufversion erwerben. Man nutzt die Plus Version (kostet ~ 300€). Hier hat man bis zu 200.000$ keine Probleme. Verdient man mehr, muss man sich die Pro kaufen. Man nutzt gleich die Pro Version. Ab 2024 wird es so sein: Die Einnahmen sind jetzt nicht mehr auf die Firma bezogen, sondern auf das Spiel selbst. Egal welche Version man nutzt, die Einnahmen, die man mit einen Spiel generiert werden jetzt wichtig! Bei der Free Version gibt es eine Einnahmengrenze von 200.000$ (in den letzten 12 Monaten pro Spiel). Bei der Pro sind ein 1.000.000$ (in den letzten 12 Monaten pro Spiel). Zusätzlich zu den Einnahmen werden auch die Verkäufe des Spiels gezählt. Diese werden erst ab 2024 gezähl. Alles was davor Verkauft worden ist, soll nicht berücksichtigt werden. Es gibt ab dann keine Plus Version mehr. Nur noch die Free Version und die Pro bzw. Enterprise Version. Bei beiden Versionen gibt es einen Schwellenwert der verkauften Spiele, ab dem es überhaupt erst dazu kommen kann, dass Unity an dir mitverdienen wird. Die Free Version hat einen Schwellenwert von 200.000 Die Pro einen Wert von 1.000.000 Einheiten. Gezählt wird, wie gesagt ab dem Januar 2024 ab dann für immer. Was bedeutet das jetzt? Wenn ihr ein Spiel erstellt habt und es verkauft, dann wird jeder Verkauf gezählt. Sobald dieses Spiel irgendwann den Schwellenwert überschritten hat, ist eine Bedingung für den mitverdienst erfüllt. Ab jetzt wird geschaut ob ihr in den letzten 12 Monaten mehr als die Obergrenze verdient habt. Wenn nicht, müsst ihr auch nichts abgeben. Wenn es aber so ist, wird geschaut, wie viele Spiele ihr den letzten Monat verkauft habt. Und für jedes Spiel will Unity dann etwas von euch haben. Habt ihr die Free Version, dann müsst ihr (pro verkauftem Spiel im letzten Monat) 20 Cent bezahlen. Habt ihr die Pro Version, dann ist der Preis gestaffelt. Es fängt mit 15 Cent für die ersten 100.000 Spiele an und verringert sich dann auf 7 Cent und dann noch weiter. Die Enterprise hat noch billigere Tarife. Siehe Tabelle. Hier ein kleines Beispiel: Ihr habt die Free Version. Euer Spiel wurde insgesamt 210.000 mal verkauft. - Bedingung 1 ist erfüllt. Ihr habt damit in den letzten 12 Monaten 350.000$ eingenommen. - Bedingung 2 ist erfüllt. Im letzten Monat habt ihr 10.000 Spiele verkauft. Dann müsst ihr 10.000 * 0.2 = 2.000$ an Unity bezahlen. Im nächsten Monat wird wieder geschaut, wieviel ihr in den letzten 12 Monaten eingenommen habt. Seid ihr dann wieder über der Grenze, dann wird wieder geschaut, wieviele Einheiten verkauft wurden und von diesen Einheiten bekommt dann Unity wieder seinen Anteil. Fallt ihr aber aus der Obergrenze raus, weil die starken Verkaufsmonate jetzt länger als ein Jahr her sind, braucht ihr für dieses Spiel auch nichts mehr bezahlen. Ist das jetzt gut oder schlecht? Zum einen ist es gut, weil man jetzt pro Spiel berechnet wird und die Grenze nach oben geschoben wurde. Die meisten von uns werden niemals 200.000$ mit einem Spiel in einem Jahr einnehmen. Es ist aber auch schlecht, denn wenn man wirklich mal einen Glückswurf haben sollte und ein Spiel richtig abgeht, denn dann kann es richtig teuer werden. Den es ist ja so, dass Spiele von kleinen Studios für viel weniger Geld verkauft werden als die Spiele von den großen Studios. Es macht einen Unterschied, ob man die Einkommensgrenze mit ganz vielen billigen Verkäufen überschreitet, oder mit wenigen teuren. Wenn das Spiel 10$ kostete, dann sind 20 Cent pro Verkauf 2%. Bei 60$ sind es aber nur 0,3% ! Um die Einnahmengrenze zu sprengen muss man aber bei 10 Euro 6 Mal soviel EInheiten verkaufen. Und dies würde sich dann auch in der Kalkulation niederschlagen. Es ist also ein unfaires Prinzip, weil es nicht um den Preis einer Einheit geht, sondern nur um Summen. Was mich persönlich ärgert ist der Wegfall der Plus Version. Ich habe die eigentlich nur, weil ich das Unity Logo nicht im Intro haben wollte. 300€ waren ok. Aber knappe 2000€ für ne Pro zahle ich nicht. Jedenfalls nicht, wenn ich nicht an die Einnahmengrenze ran komme. Wenn ich da ran käme, dann würde ich die Pro kaufen, denn dann hätte ich die Grenze auf ne Million angehoben und da muss man erst mal hin kommen. Es gibt noch viele Unklarheiten, denn Unity sagt nicht, wie sie an die Zahlen der Einheiten kommt. Es ist klar, dass jedes Spiel an Unity was sendet. Aber was das alles beinhaltet weiß nur Unity selbst. Demoversionen sollen nicht mit einberechnet werden. Mehrfach installationen sollen auch nicht mit einberechnet werden. Wir werden sehen, was die Zukunft bringt.

Willkommen! Also: Die Transform.position ist die Position, die ein Objekt in der Szene hat. Der genaue Punkt des Objektes ist aber abhängig von dem Pivot. Also dem Achsenmittelpunkt des Objektes. Dieser Pivot muss nicht zwangsläufig in der Mitte eines Objektes liegen. Zur Transform.position gibt es auch noch die Transform.localPosition. Diese Position wird dir im Inspector angezeigt. Wenn ein Objekt ein Vaterobjekt ist, also keinem anderen Objekt untergeordnet ist, dann ist die die localPosition das gleiche wie die position. Ist das Objekt einem anderen Objekt untergeordnet, also ein Kind des Vaters, dann ist das nicht mehr das gleiche. die localPosition, die dir im Inspector angezeigt wird, bezieht sich jetzt auf den Vater. Wenn da also bei XYZ 0,0,0 steht, dann hat das Kind die gleiche Position wie der Vater. Steht da 0,1,0 dann ist das Kind um 1 auf der Y-Achse zum Vater verschoben. Hätte der Vater die Position 10,2,0 dann hätte das Kind die Position 10,3,0 im Raum. Also bei Y 1 mehr und das ergibt die 3. Ich sehe bei deinem Aufbau, dass deine Objekte verschachtelt sind. Es sind also alles Kinder vom Lückentext und einige dieser Kinder haben weitere Kinder. Die sind alsi für die weiteren Kinder der Vater. Wenn du jetzt ein Objekt per Drag aufnimmst und bewegen willst, dann wird im Code wahrscheinlich das Objekt an die Maus geschoben, weil es beim verschieben die Mausposition als eigene Position übergeben bekommt und der Pivot der eigenen Position ist wohl die obere linke Ecke. Wenn du den Pivot nicht verschieben kannst (Was bei UI elementen eigentlich geht), dann musst du einen Offset einbauen. Also den Unterschied der Mausposition beim Klick zur Position des Wortobjektes beim Klick merken und bei der Bewegung immer mit einberechnen. Objektposition = mausposition + Offset. Beim Ablegen übergibst du dem DragObjekt die Koordinaten der Lücke. Das ist eigentlich ok. Aber ich kann nicht sehen, ob deine Lücke vielleicht doppelt so hoch wie der Blaue bereich ist. Genauso kann es sein, dass dein Vaterobjekt oder irgend etwas anderes als Zielobjekt genutzt wird. Du musst dir mal anschauen, wo deine Pivots liegen. EInfach das Objekt anklicken und im Inspector schauen, wo das Koodinaten-Kreuz angezeigt wird. Vielleicht findest du da schon den Grund der falschen Position.

Gerne!

Ich habe das Toolkit System noch nicht verwendet, habe mich aber eben eingelesen und ein paar kleine Videos geschaut. Das was du das in dem Flex-Bereich einstellst ist erstmal nur für das Unterlement wichtig. Das hat nichts mit der Auflösung des Screens zu tun. Bei Toolkit ist alles verschachtet, also alles bezieht sich auf das Vater objekt, wie es scheint. Ja und da musst du ansetzen. Beim UGui System hast du ja den Canvas als Vater, bei dem du einstellen kannst, ob und wie die unterelemente skaliert werden können/sollen. Das ist beim Toolkit in den Panelsettings zu finden. Dort gibt es einen Scalemode und 2 Referenzfelder wo du DPI ( Dots-Per-Inch) oder ähniches einstellen kannst. Beim UGUI kannst du sagen wie er skalieren soll, wenn ein Screen von der Referenzgröße abweicht. Das sollte beim Toolkit genauso sein. Es gibt da die eine Einstellung, wo es um konstante Physikalische Größe geht und da hast du dann als Referenzwerte DPI. Hier werden dann die Bildpunkte festgelegt. Im Endeffekt ist das auch nichts Anderes, als wenn du 2 24 Zoll Monitore vergleichst, wo der Eine eine HD Auflösung hat und der Andere 4K darstellen kann. Der eine Monitor hat soundsoviel Dots pro Inch, der andere Monitor hat 4 mal so viel. Nimmst du als Referenz die HD Auflösung, wird beim 4K Monitor alles vergrößert. Wo vorher ein Pixel geleuchtet hatte, sind es jetzt 4. Es ist also alles genau so scharf bzw. grob wie vorher. Wenn du aber als Referenz eine 4K Auflösung nutzt, dann wird sie beim 4K Monitor auch super scharf daher kommen. Beim HD Monitor wird aber alles unschärfer, weil er viel weniger Bildpunkte hat und dann jeder Punkt einen Mittelwert zugewiesen bekommt. Das alles natürlich nur, wenn du über ScreenSize skalierst. Wenn du auf konstante Pixel Größe oder konstante physikalische Größe einstellst, dann wird die Ui abhängig von den Pixeln, die da sind, angezeigt oder aber abhängig von den Dots angezeigt. Viele Pixel oder Dots auf dem Display bedeutet, die UI Elemente sind kleiner. Weniger Pixel oder Dots, die Elemente werden größer sein. Also wenn auf jedem Handy alles ungefähr gleich groß zu sehen sein soll, dann musst du mit ScreenSize skalieren. Gleich groß bedeutet, dass auf jedem Screen die gleiche Information zu sehen ist. Hast du einen kleinen Screen, ist alles natürlich klein. Logisch. Wenn du Constant Pixel Size nimmst, dann werden immer die Pixel im Bezug zu Pixel per Unit gleich groß angezeigt. Das muss nicht mit den Bildpunkten deines Screens übereinstimmen. Wenn du Constant Physical Size nimmst, dann geht es um die echten Bildpunkte (DPI). Du kannst in Unity ja unterschiedliche Auflösungen für dein Gameview einstellen und auch neue hinzufügen. Nimm dir mal gängige Handys und guck, was die so für Auflösungen haben. Und dann teste mal.

Na siehste!

Du solltest einfach nur mal 1-2 Werte nehmen und damit versuchen, Balken zu bekommen. Dein Problem ist ja nicht die Daten auszulesen, sondern einfach nur Balken zu erzeugen, die vom Minimalwert zum eingelesenen Wert gehen. Dein erstes Diagramm hat ja gezeigt, dass deine Werte gut interpretiert werden. Ich kann dir nicht sagen, wie das machen kannst, weil ich mit den Tools wie Igraph noch nichts gemacht habe. Ich gibt aber ein Tutorial von CodeMonkey, der in seinen Videos zeigt, wie man unterschiedliche Graphen erzeugt. Diese Videos sind nicht besonders gut gemacht, weil er viel zu schnell da durch rammelt und nicht viel erklärt. Trotzdem kannst du da bestimmt erkennen, wie er die Balken erzeugt und worauf es ankommt. Übrigens: Dein Thementitel hat eigentlich nichts mit deinem Problem zu tun. Ein Titel wie z.B.: "Wie erstelle ich ein Balkendiagramm" wäre bestimmt besser gewesen.

Hmm... Du musst dich noch ein wenig einlesen. Es ist alles nicht so einfach, wie man zuerst denkt. Ich will mal ein paar Dinge erklären: Unity hat eine Physik Engine, die hauptsächlich mit Collidern, Triggern, Raycasts und vorallem dem Rigidbody funktioniert. Der Rigidbody ist die Komponente, die einen Collider bewegen kann, mit anderen Collidern kollidiert, Trigger auslöst und alle Kräfte ( Reibung, Federung, Masse, Beschleunigung im Raum) erst ermöglicht. Der Character Controller (kurz CC) ist "kein" Bestandteil dieser Physik. Er macht zwar ähnliche Dinge, die Auswertung der Kräfte erfolgt aber ganz anders und ist auch unvollständig. Trotzdem kann der CC auch mit Collidern zusammenstoßen und Triggerevents auslösen. Er kann auch springen. Er kann aber nicht von irgendeinem Kollider abgestoßen werden, nur weil dieser Collider ein Gummimaterial hat. Es gibt eine Möglichkeit um mit einem CC auch von einem RB abgestoßen zu werden. Dafür musst du eine gewisse Option aktivieren: https://docs.unity3d.com/Packages/com.unity.charactercontroller@1.0/manual/dynamic-body-interaction.html?q=physical material Wie gut das funktioniert kann ich nicht sagen. Aber im Text steht ja schon, dass es zu einem kleinen Lag kommen kann. Ob die Eigenschaften eines physikalischen Materials richtig ausgewertet werden, weiss ich nicht. Übrigens: selbst wenn ein Collider kein phys. Material zugewisen bekommen hat, so hat er doch default Eigenschaften. Einen CC mit einem Rigidbody zu kombinieren, ist meines Wissens keine gute Lösung, weil dann 2 Dinge verknüpft werden, die sich gegenseitig stören. Ich muss aber gestehen, dass ich im Bezug auf den CC nicht mehr auf dem neuesten Stand bin.

Speicherst du denn den Aktivitätsstatus auch mit ab? Und übergibst du dann auch den Zustand an das Objekt, wenn dein Spielstand eingeladen wird? Wenn nicht, ändert das Objekt seinen Zustand nicht. Und da es ursprünglich inaktiv war, ist es nach dem laden auch inaktiv.

Das sind zwei komplett unterschiedliche Designs. Das rundenbasierende System ist recht einfach zu erstellen. Das System in Echtzeit ist herausfordernd, denn du musst dem Spieler die ganze Zeit über etwas geben, das er machen kann. Und selbst wenn er auf etwas wartet, wie z.B. einen Anbau oder Umbau, musst du ihm wenigstens etwas Visuelles anbieten. Bei den Siedlern ist gibt's den Wuselfaktor, wo sich ständig Leute bewegen und Dinge tragen. Bei TwoPoint Hospital und TwoPoint Campus ist so viel los, dass nie Langeweile aufkommt. Du kannst auch einen Hybrid aus beiden machen. Wo der Spieler selbst entscheidet, ob er irgendwo eingreifen will oder es einfach laufen lässt. Da gibt es sooo viele Möglichkeiten. Aber, was schwebt dir denn vor? Wieviel Zeit willst du ins Visuelle invenstieren. Soll es nur aus Infotafeln bestehen oder 2D mit animierten Gegebenheiten? Oder sogar 3D? Willst du sehen, wie die Besucher ins Hotel stürmen, oder soll alles nur anhand von Zahlen auf Infotafeln ablaufen? Willst du eher ein Casual Game bauen, wo das Management überschaubar ist, oder willst du ins kleinste Micromanagement hinein gehen, wie bei Dwarf Fortress? Viele Fragen. Sie sind jedoch entscheidend, denn das Grundgerüst ist einfach und recht schnell erstellt. Jede weitergehende Idee braucht aber Zeit. Dwarf Fortress hat inzwischen eine Entwicklungszeit von rund 20 Jahren und ist immer noch nicht fertig. Die 2 Jungs haben das Spiel selber nur mit ASCII Zeichen dargestellt, also nicht eine Grafik eingebaut. Das haben andere für die Jungs getan. Ich persönlich finde alle Ansätze gut und spiele auch gerne die unterschiedlichsten Arten. Die Simulation die ich persönlich am liebsten gespielt hatte, war MAD TV, bei dem man einen Fernsehsender managen musste. Nachrichten auswählen, Flime/ Serien leihen und ausstrahlen und Werbung schalten um Geld zu verdienen. Alles in 2D und das meiste waren Standbilder. Das Spiel hatte ein ganz besonderen Flow. Wenn du es nicht kennst guckstu hier: https://g.co/kgs/BGz89y So etwas stelle ich mir machbar vor und fände ich im Hotelbereich auch gut.

Ich war auch schon dran einiges dazu zu schreiben. Da Sascha nun das Meiste erklärt hat, will ich nur noch auf das Cloth-Modul zurück kommen. Ich habe es zwar noch nicht in Unity genutzt, aber bei den 3D Softwaren wie Cinema4D oder Blender funktioniert das eigentlich ganz genauso (nur viel besser berechnet, weil es nicht in Echtzeit geschehen muss). Bei Cloth werden von einem Objekt nur die Vertices, also die Mesh-Punkte, berechnet. In welcher weise dürfen sie sich zueinander bewegen, dürfen die Abstände vergrößert und verringert werden, wie weit dürfen sie sich verwinden und welche Masse hat der einzelne Punkt. Dann gibt es noch Ankerpunkte und diverse Parameter, die die Dicke des Stoffes, oder die Kollision mit anderen Objekten beeinflusst usw.. Ja, und je mehr Punkte man hat umso schöner aber auch rechenintensiver wird es. Es ist aber eben nur dieser eine Körper, der der Regel vom Cloth Modul folgt. Kind-Objekte werden nicht mit berechnet, weil es keine Beziehung vom Kind-Objekt zum Vertices des Cloth-Objektes gibt. Technisch wäre das sicherlich möglich gewesen, aber solche Mesh-Deformationen kosten so schon viel Leistung. Ich kenne kein Spiel, wo die Cloth Engine so sauber arbeitet, dass der Stoff nie andere Objekte durchdringt. Alles ist auf performance ausgelegt. Nicht auf physikalische Genauigkeit. Somit kann man das Ganze nur faken, indem man es so macht, wie Sascha es erklärt hat, oder aber die Bommeln an der Standarte nicht plastisch baut sondern sie als Teil des Tuches erstellt. Man kann aber auch alles extern animieren und die Animation dann in Unity einladen und abspielen. Das wäre aber ein mächtiger Aufwand und die Animationen wären auch immer nur für eine Situation erstellt. Bei dynamischen Änderungen in Unity bräuchtest du viele unterschiedliche Animationen. Diese wären dann aber trotzdem nie zu 100% passend. Also versuch mal Saschas weg.

Schickes Spiel. Ist die Idee von dir, oder ist es ein Remake? Wenn ich es richtig sehe, dann geht es nur um den Highscore, oder gibt es auch Ziele, die man erreichen muss? Sowas wie schaffe 3 Lava- Explosionen? Was bedeutet für dich denn "fast fertig"? Für mich fehlt da noch der visuelle und akustische Pep! Und ich schätze mal, dass da noch ein bis 2 Monde für drauf gehen würden. Das Dingen hat potential und da kann man noch richtig viel draus machen. Highscore Tabelle, Missionen, unterschiedliche Schwierigkeitsgrade wie z.B. "Würfel" mit 3 Seiten, 4 Seiten oder 8 Seiten, unterschiedliche Spielfeldformen oder Größen, Zeitrennen, und, und, und.... Aber auch so ist das schon ein solides Spiel für zwischendurch und es scheint auch gut zu funktionieren. Weiter machen!

Ich würde mir da jetzt nicht son Kopp machen, denn du wirst später irgendwann erkennen, dass ein Gang ins Menü das Spiel pausieren muss. Und auch da wirst du irgendwie gewisse Dinge anhalten müssen. Klar du kannst die Time.time auf 0 stellen. Das hält aber nicht alles an, was schon am tun ist. Wie z.B. Sounds. Also wirst du ein Event oder eine static Variable nutzen um die Pause auszuwerten. Genau so kannst du das auch mit dem Battle machen. Sobald der Kampf beginnt, wird z.B. eine static Variable "battle" auf true gesetzt. Diese Variable wird in allen wichtigen Scripts der Rollenspielwelt abgefragt. Z.B. gleich als erstes in der Update(). if(dingensScript.battle) return; Und schon wird alles nachfolgende in dem Script nicht mehr ausgeführt. Du musst also nicht unbedingt ganze Komponenten deaktivieren. Ich würde auch einen Dummy-Charakter für die Battlewelt nutzen, denn da steuerst du ja nichts aktiv. Das ist aber alles eine Sache des Spieldesigns und das ist die Schwierigkeit daran. Du musst dir überlegen, wie du gewisse Dinge steuern willst. Außerdem musst du dir jetzt schon Gedanken darüber machen, ob sich mit deinem Konzept auch noch Spielerweiterungen einfügen lassen, ohne extremen Mehraufwand zu generieren. Oft ist es so, dass das Konzept nicht gut genug ist und dann muss man nach einer besseren Lösung suchen und alles umstellen. Passiert mit auch immer wieder mal. Aber so ist das eben in der Entwicklung. Man denkt selten an alles.

Ich gehe davon aus, dass du eine 3D Variante baust. In dem Fall würde ich die Battleszene irgendwo hin bauen, wor der Spieler bei seinem Rollenspiel nicht hinkommen kann. Die kann ja ruhig ein paar km weit weg sein, oder über der Welt und darunter. Beide Szenerien haben je eine Kamera und beim Wechsel wird einfach die entsprechende Kamera aktiv und filmt dann das gewünschte Geschehen. Du kannst natürlich auch die Kamera immer zur gewünschten Position hin teleportieren und ausrichten. Ist vielleicht sogar besser, wegen dem Audiolistener, der nur einmalig in der Szene sein soll.