spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BitShift«

- Fortlaufende Transformationen
Ich habe Modifier implementiert, die z.B. fortlaufende Rotationen, Translations etc. ausführen, um wiederverwendbare Transformationen zu haben, die man zusätzlich starten, stoppen, resetten kann etc., um z.B. eine Sinusförmige Transation von Vector A nach Vector B durchzuführen. Bietet Unity hier so etwas ähnliches, evtl. schon mit UI zum Konfigurieren? Oder wie würde man so etwas in U. implementieren? Im Internet findet man immer wieder mal coole Lösungen, die fast beliebige Transformationen "zusammenklickbar" realisieren können.

Unity selber bietet erstmal nur absolute Animationen an. Für kleinere Kompositionen kann man die Objekthierarchie nutzen. Wenn Animation A auf dem Parent läuft und Animation B auf dem Objekt selber, dann hat man praktisch A + B. Wird aber irgendwann durch die Verschachtelung unübersichtlich.

Ansonsten gibt es einige (kostenlose) Tween Bibliotheken, mit den man beliebige Wertänderungen (Position, Rotation, Farbe etc.) mit verschiedenen Easing Einstellung und Verschachtelung nutzen kann. Allerdings habe ich da bisher keinen brauchbaren grafischen Editor für gesehen.

Zitat von »BitShift«

- Screenhandling
Unity meint mit Screens etwas ganz anderes, ich bin mir aber auch nicht sicher, ob eine Scene das Konzept ist, dass ich suche.
Unsere Screens sind voneinander unabhängige Objekte, die ein RootSprite beinhaltet, über das alle Sprite-spezifischen Aufrufe laufen (Sprite-Bäume). Über die Screens selbst werden dann z.B. Pause Screens, Main Menu, UI Overlay etc. realisiert und können übereinander gezeichnet werden (Praktisch für Übergänge oder UI Overlays, aufgrund anderer Koordinaten oder Camera Einstellungen etc. pp.).

Was wäre dafür das Gegenstück in Unity?

Mir ist nicht 100%ig klar wie du das mit dem RootSprite meinst. Aber du hast in Unity Szenen die du wechseln oder einfach zusätzlich laden kannst. Du könntest dir also z.B. den Pause Screen als eigene Szene bauen und diese dann zusätzlich laden um diesen anzuzeigen. Zum Entladen sollte deine Szene dann ein übergreifendes Root Objekt haben, damit du mit dem Löschen dieses Objekts die komplette Szene wieder entlädst, da es kein gezieltes Szene entladen gibt.

Zitat von »BitShift«

- Screen States bzw. Verwaltung von Zuständen
Üblicherweise hat man beim Handling oben genannter Screens das Problem, einen ganzen Haufen Zustände berücksichtigen zu müssen, über welche die Screens gesteuert werden. Wird der Pause Screen eingeblendet, muss der GameScreen pausiert werden, es werden verschiedene Übergänge angefeuert u.s.w. u.s.f., das wird schnell extrem unschön vom Handling (massig booleans, Screen-übergreifende Verwaltung, Event-Notification Chaos etc.)

Wir haben daher Screen States eingeführt, über die man recht bequem per Delegates auf Methoden in den jeweiligen Screens verweist, welche diese Logik abfangen, und von einem ScreenStateHandler verwaltet werden (Die Methoden geben ein boolean zurück, ob der "State" fertig ist oder nicht, darauf basierend wertet der Handler aus, welche States als nächstes ausgeführt werden. Die States wurden vorher wie benötigt verlinkt. Eigentlich programmiert man nicht mehr in einer Update Methode die Funktionalität aus, sondern in entsprechenden State-Methoden der Screens relativ atomar nach Zuständen).

Eigentlich würde ich von einer Allround Engine wie Unity ebenfalls ein Konzept für solche Probleme erwarten, gibt es da etwas?

Unity hat zwar ein Message System mit dem man in der Objekthierarchie Funktionen über den Name aufrufen kann und damit sowas wie ein Eventhandling System hat, aber über Reflection ist das relativ langsam und wegen der erzwungenen Objekthierarchie eher unfexibel. Es gibt hier aber auch schon einige fertige Systeme die auch deutlich schöner mit Delegates und Events arbeiten.

Zitat von »BitShift«

- 2D Animations
Ich hatte zu Unity 4.5 ein Video gesehen, in der Bone / IK-basierte 2D Animationen gezeigt wurden. Ist das eine Unity Standardfunktionalität oder gibt's das nur in der "dicken" Version?

Würde man eher externe Tools zum Animieren empfehlen, bzw. inwieweit bietet Unity hier Loader an?
Das ist sehr schwammig formuliert, aber ein paar Erfahrungen oder best practices wären schon super!

Dazu weiß ich gerade nichts genaues. Aber die Einschränkungen der Unity Free Version treffen hauptsächlich das Rendering (Beleuchtung, Render to Texture) und native Plugins.

Zitat von »BitShift«

- Controller / Input-handling
Ein ziemlicher Krampf zum selbst dengeln, was bietet Unity hier?
Ich habe gelesen, dass es kein allgemeines Touch Interface gibt und solche Sachen, finde ich etwas seltsam falls das so sein sollte.

Out of the box ist die Unterstützung von Touch eher wie der Ersatz einer Maus. Man bekommt zwar alle Touch Eingaben, aber sowas wie Swipes müsste man selber erkennen bzw. gibt es da sehr günstige (5-10€) Lösungen im Asset Store.

"Fortlaufende Transformationen"
Entsprechende Suchbegriffe wären "Interpolation" oder "Tweening". Es wurde bereits geschrieben, dass es im Asset Store bereits diverse Lösungen gibt, Unity selbst bietet da erstmal kaum etwas an bzw. es werden nur Funktionalitäten (siehe Lerp) angeboten, die aus den eigenen Scripts heraus aufgerufen werden können. Ich muss aber auch zugeben, dass ich bisher alles in die Richtung gehende eher selbst implementiert habe, auch wenn ich da am Ende keinen hübschen Editor hatte.


Screenhandling
Standardmäßig dürfte Unity nichts speziell dafür mitliefern. Bisher habe ich entweder nur verschiedene übergeordnete GameObjects verwendet (einen fürs UI, einen für den Spielinhalt etc.) oder ich habe das mit mehreren Kameras mit unterschiedlichen Culling Masks und verschiedenen Ebenen kombiniert. Die 2D Feature haben außerdem Ebenen für die Sprites mitgebracht, über welche man auch eine Reihenfolge definieren kann, nur könnte auch hier eine Kombination sinnvoll sein.

Scenen sind in Unity nicht primär für die Unterteilung zwischen UI, Ingameszene usw. gedacht, sondern bspw. für die Unterteilung zwischen den verschiedenen Leveln des Spiels, dem Hauptmenü etc.
Scenen lassen sich aber auch additiv dazuladen und genauso kann man für ein GameObject definieren, dass es beim normalen Laden einer Szene nicht entfernt werden soll, wodurch die Szenen nicht nur für die Levelunterteilung genutzt werden können. Da an einem Spiel oft genug mehrere Leute arbeiten, muss eine Unterteilung der bearbeitbaren Elemente gefunden werden. Eine Möglichkeit wäre es, bereits frühzeitig Prefabs zu definieren und jeden in seiner eigenen Testszene arbeiten zu lassen, eine andere wäre die Unterteilung in mehrere Szenen ("Hauptcharakter", "Levelumgebung", "HUD", ...), die zusammen dann das Spiel/Level ergeben.


Screen States
Da Unity standardmäßig keine "Screens" in deinem Sinne liefert, müsste man sich hier ebenfalls selbst bemühen. Letztendlich dürfte das entsprechende System sich kaum von eurem bisherigen Unterscheiden, nur dass bestimmte Unity-Dinge (GameObjects und Komponenten) berücksichtigt werden müssten

SendMessage würde ich nur dann verwenden, wenn es absolut keine Möglichkeit gibt, mit der man den Typ des Empfängers sicherstellen kann. Man kann in Unity problemlos "abtrakte Komponenten" (abstrakte Klassen, die von "MonoBehaviour" abgeleitet sind) definieren, wovon alle Ausprägungen abgeleitet sind. An der sendenden Komponente wird dann eine Variable vom Typ der abstrakten Komponente definiert und über den Editor können dadurch auch nur Objekte zugewiesen werden, die eine Komponente beinhalten, welche von dieser abstrakten Komponente abgeleitet sind. (Und da der Typ bekannt ist, können problemlos Methoden aufgerufen werden. Hat man nur eine einzige Komponente (bspw. "Player"), die in Frage kommt, ist auch keine Basisklasse erforderlich und die Sache ist noch einfacher.
Ein Anwendungsfall könnte eine Bibliothek sein, dessen Anwender nicht zu einer bestimmten Vererbungshierarchie gezwungen sein soll. Ein UI System könnte also Buttons liefern, die bei Betätigung ein SendMessage auf ein bestimmtes GameObject mit einer bestimmten Nachricht (Methodenname) aufrufen.
Wenn man dieses Nachrichtensystem richtig verwendet, dann sollten entsprechende Aufrufe ohnehin so selten auftreten (bspw. alle paar Sekunden/bei Benutzerinteraktion ein Aufruf), dass der Performanceunterschied nicht weiter relevant sein sollte.


Inputhandling
Für Maus, Tastatur und Gamepads bietet Unity bereits eine Abstraktion. Man definiert, welche "Achsen" es im Spiel geben soll und kann zur Laufzeit auf den aktuellen Wert dieser über den vergebenenen Namen zugreifen (Input.GetAxis). (Dabei wird automatisch eine gewisse Interpolationen auf Tasten der Tastatur angewendet, um kein Springen von "Mitte" zur "Links" oder "Rechts" zu haben. Ist das nicht gewünscht, kann man den "rohen" Wert direkt abrufen (Input.GetAxisRaw).) Die Achsen können genauso für normale Eingaben, wie Sprung- oder Schusstaste verwendet werden (Input.GetButton). Man kann ebenso direkt auf entsprechende Eingaben zugreifen, wenn man es denn unbedingt will, meiner Meinung nach sollte das aber nur für's Debugging verwendet werden.
Für Touchinput liefert Unity nur 3 Mittel: Input.touchCount, Input.touches und Input.GetTouch. (Man beachte, dass GetTouch den Index und nicht die "fingerId" erwartet. Will man einen Touch also längerfristig beobachten, muss man ihn aus der Liste der touches heraussuchen. Will man komplexere Gesten o. ä., muss man das selbst schreiben oder vorhandene Lösungen aus bspw. dem Asset Store verwenden.


Es gibt noch ein paar Dinge, die ich durchaus wissenswert finde.

• SerializeField kann man verwenden, um Member zu definieren, die von anderen Scripten aus nicht veränderbar sein sollen (private), aber vom Editor aus dennoch konfigurierbar sein sollen. HideInInspector würde eine Konfiguration von public Variablen über dne Editor verhindern, nicht aber das Speichern das Serialisieren.
  
• Mit RequireComponent kann man definieren, dass die eigene Komponente andere Komponenten am GameObject voraussetzt. Ein Script, welches das Verhalten der Kamera definiert, könnte so eine Camera voraussetzen.
  
• Erweiterungsmethoden können auch in Unity und für Unity-eigene Klassen interessant sein. (So könnte eine Erweiterungsmethode für ein Touch[] definiert werden, welches einen Touch anhand einer fingerId findet.)
  
• Es gibt zwar diverse Möglichkeiten, wie man in Unity Singletons umsetzen kann, ideal wäre aber eine Lösung, bei der man lediglich dafür sorgt, dass das GameObject mit der entsprechenden Komponente nur 1x in der Szene vorhanden ist. Entweder könnte es über die Szene alle relevanten Objekte (bspw. Raycasting oder Kollisionsprüfung) finden oder es kann eine Zuweisung im Editor vorgenommen werden.
  

Zitat von »BitShift«

Ist das Benutzen von Szenen für diesen Use Case denn üblich?
Es ist also auch möglich, mehrere Szenes parallel zu zeichnen (UI Overlay z.B.)?

Szenen dienen allgemein der Modularisierung. Es gibt dabei die beiden Möglichkeiten die Welt komplett durch eine Szene zu ersetzen oder den Inhalt der Szene der Welt hinzuzufügen. Und alles was in der Welt ist und nicht deaktiviert ist, wird gezeichnet. Mit dem zusätzlichen Laden einer Szene in die aktuelle Welt kannst du also praktisch den Inhalt mehrerer Szenen parallel zeichnen.

Was Tweening angeht empfehle ich den iTween Visual Editor, der mit iTween jede Menge möglichkeiten für Bewegungsanimationen liefert und dazu noch einen Editor hat, bei dem man innerhalb vom Objektinspektor iTween Animationen und Attribute dieser festlegen kann ohne mit Hashes arbeiten zu müssen.

EDIT: Link wäre auch nicht schlecht: https://www.assetstore.unity3d.com/en/#!/content/180

Zitat von »BitShift«

Okay. Ich muss gedanklich den Sprung schaffen, wie man in Unity Kameras / Matrizen / Koordinatenhandling und GameObjects handelt. In XNA kann ich über unsere Screens getrennte SpriteBatches ansprechen und über entsprechende Matrizen unterschiedlich Cameras simulieren, was halt extrem praktisch ist, wenn die Game-UI sich anhand des Viewports anpasst, und der InGame Screen sich völlig anders ausrichten muss. Solche Dinge müsste man für sich selbst also wieder definieren.

Bei einer Kamera in Unity kann man definieren, welche Position, Rotation und Skalierung (ob das überhaupt Auswirkungen hat?) sie hat, ob sie perspektivisch oder orthographisch sein soll, den horizontalen FOV Winkel bzw. die halbe Höhe, was dargestellt werden soll (cullingMask), wie und ob überhaupt gecleared werden soll, an welcher Stelle sich die Kamera befindet und wie viel Platz sie einnehmen soll (relativ zur Fenster-/Bildschermgröße), in welcher Reihenfolge die Kameras dargestellt werden sollen und noch ein paar andere Sachen, die an dieser Stelle wohl nicht weiter wichtig sind.
Wenn du für deine Kameras einstellst, was diese darstellen sollen, in welcher Reihenfolge sie dargestellt werden sollen und dass (bis auf bei der hintersten vielleicht) kein Clearing durchgeführt werden soll, kannst du so das erreichen, was du in XNA mit mehreren Spritebatches erreichen würdest.

Zitat von »BitShift«

Szenen sind also eher im einfachsten Sinne zu verstehen: Eine Definition mehrerer Ressourcen und Gameobjekte, die variabel geladen / entladen werden können? Sie bieten aber keine eigene Logik im dem Sinne, wie die Gameobjekte untereinander agieren etc.

Das Verhalten (also die Logik) wird über Skripte definiert. Skripte sind wiederum spezielle Komponenten, die den GameObjects angehangen werden können. Szenen sind im Grunde "nur" eine Ansammlung von GameObjects, aufgrund der angehangenen Komponenten kann man aber mit einer Szene im Grunde alles definieren, was man will. Eine Szene kann einfach nur einen Abschnitt des eigenen Spiels beinhalten, es könnte das Hauptmenü beinhalten, genauso kann es aber auch das gesamte Spiel beinhalten.
Wahrscheinlich bist du schon darüber gestolpert, dass man in Unity Prefabs anlegen kann. Diese stellen eine Vorlage für den Aufbau von GameObjects dar, anhand derer weitere Instanzen erstellt werden können (siehe Object.Instantiate). In den verschiedenen Szenen könnten Instanzen der Prefabs enthalten sein, die mit unterschiedlichen Werten versorgt wurden, bspw. für wiederkehrende Spielelemente, die sich nur in ihren "Werten" Unterscheiden.


Ich denke, dass der größte Unterschied bei der Programmierung wohl der sein dürfte, dass man keine "normalen" Klassen schreibt, sondern Scripte, und dass bestimmte Werte (public-Variablen oder mit SerializeField versehene Variablen) über den Editor gesetzt werden. Ansonsten sollten sich diese untereinander ungefähr genauso verhalten, wie auch normale Klassen in XNA oder einem beliebigen anderen Framework.