Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »BitShift« (25.09.2014, 10:29)
- 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.
- 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?
- 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?
- 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!
- 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.
Ist das Benutzen von Szenen für diesen Use Case denn üblich?Zitat
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.
Ich bin ja nicht unbedingt auf diese Vorgehensweise fixiert. So wie ich das verstehe, müsste ich also entweder basierend auf Szenen meine eigene Verwaltung schreiben oder in den AssetStore schauen. Ich dachte, vielleicht gibt's da ein Standardkonzept.Zitat
Es gibt hier aber auch schon einige fertige Systeme die auch deutlich schöner mit Delegates und Events arbeiten.
Okay, hatte da beim Stöbern da einiges gesehen.Zitat
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.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
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.)?
Ich vermute mal, dass es für das Thema aus Sicht Unitys keine "Standarddefinition" gibt. Ein Editor für so etwas ist sicherlich nice to have, aber im Prinzip brauche ich zur Zeit noch nicht einmal irgendwelche komplizierten Interpolationen oder komplette Animationen. Meine eigene Implementierung besteht eigentlich nur aus ein paar Klassen die einfache Transformationen innerhalb des Sprites ausführen., sollte aber auch kein großes Problem sein, dass mit Unity abzubilden, wenn das Workflowtechnisch überhaupt Sinn macht."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.
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.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.
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.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.
Okay, dass ist eh noch nicht in Greifweite hier, werde ich aber prüfen, wenn ich mir über die Implementierung Gedanken mache. Sind ein paar interessante Punkte dabei, aber ich bin dazu noch nicht weit genug drin.SendMessage würde ich nur dann verwenden, [...] 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. [...] Es gibt noch ein paar Dinge, die ich durchaus wissenswert finde.[...]
OKSzenen 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.
Da klingelt was... schaue ich mir mal an.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.
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.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.
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.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Werbeanzeige