Du bist nicht angemeldet.

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!

Unity, ist das noch Programmierung?

Werbeanzeige

ERROR

Alter Hase

  • »ERROR« ist der Autor dieses Themas

Beiträge: 417

Wohnort: Paderborn

Beruf: Informatik Student

  • Private Nachricht senden

11

04.11.2014, 11:28

@NachoMan: Das hört sich schon mal sehr gut an :) Danke für die Erläuterung.

@KeksX: Natürlich wäre es wunderbar, aber wenn man sich Statistiken von Hobby Entwicklern so anguckt :D. War da nicht gestern bevor ich ins Bett bin noch ein viel längerer Text :hmm:

@Hello Kitty!: Eine Stunde nur stehen lassen? Dann ist der doch noch Stein hart. Deine nächste Fertig-Torte solltest du länger stehen lassen, dann schmeckst du bestimmt auch den Unterschied zwischen Erdbeer und Kirsche ;)

@LetsGo: Das ist ja sicher auch teilweise der Sinn einer Engine, wenn ich trotzdem jede Kleinigkeit selber machen muss, könnte ich ja einfach bei SFML bleiben :)

@David: Danke mal wieder für die Erklärungen :). Die Metapher hört sich schon viel schöner an. Deinen Kommentar zu LetsGo finde ich auch sehr hilfreich :)

@Sacaldur: Ja, genau das ist mein Problem bei dem Wort Script. Mit den CMS hast du natürlich recht, ich habe selber auch komplexere Dinge, als eine normale Website, mit PHP gemacht, aber habe irgendwie immer noch eine negative Bewertung zu dem Wort "Script" im Kopf. Auch deinen Kommentar zu LetsGo finde ich hilfreich und dem stimme ich (leihenhaft!) genauso zu wie Davids :)


Also soll es so sein, ich werde mich mal mit Unity auseinander setzen.

Kennt denn jemand von euch ein sehr gutes Tutorial? Ich weiss, es gibt drölfzig im Internet und ich habe auch schon gegooglet, aber es kann ja sein, dass hier jemand ein sehr sehr gutes kennt. Ich werde C# nutzen und im Tutorial, kann das ruhig vorausgesetzt werden. Auch das Wort "Tutorial" ist oft negativ verankert. Ich meine damit einfach eine Videoreihe, welche mir die Engine in einem Beispielprojekt näher bringt :)

Im Allgemeinen will ich mich aber auch schon mal herzlich bedanken, dass ihr euch die Zeit nehmt und mir helfen wollt :thumbup:

KeksX

Community-Fossil

Beiträge: 2 107

Beruf: Game Designer

  • Private Nachricht senden

12

04.11.2014, 11:34

Ich hatte den Text rausgenommen, da David eigentlich schon alles perfekt gesagt hatte. Ich stimme ihm da nämlich vollkommen zu.
WIP Website: kevinheese.de

Julian Mautner

Alter Hase

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

13

04.11.2014, 17:38

@ERROR
Ich kann dir nur sagen, dass Code Design und allgemein System Architektur auch in Unity extrem wichtig sind. Dazu kommt noch die Projektorganisation im Editor selbst, die alles andere als trivial ist, sobald dein Projekt etwas größer wird. Obwohl wir uns bei Son of Nor viel Gedanken zu diesen Themen gemacht haben, sind extrem viele Sachen mehr als suboptimal gelöst. Unser nächstes Projekt wird dahingehend sehr viel sauberer werden (hoffentlich) ;) Was ich sagen will ist, dass du dir neben all den "normalen" Überlegungen zu Systemarchitektur und Design auch zusätzlich Gedanken machen musst, wie das alles mit Unity zusammenpasst. Auf der einen Seite wirds mit Unity zwar einfacher, aber auf der anderen Seite musst du auch um die zahlreichen Hürden und Unzulänglichkeiten von Unity herumbaun, womits sich letztendlich gleich bleibt.
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

FSA

Community-Fossil

Beiträge: 1 989

  • Private Nachricht senden

14

04.11.2014, 17:50

Son of Nor 2 geleaked? ;)

Zitat

Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.

Schrompf

Alter Hase

Beiträge: 1 470

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

15

04.11.2014, 18:16

Das ist übrigens auch meine Sorge mit Unity: was, wenn ich an irgendeine Grenze stoße? Und wenn ich in den Facebook-Gruppen die Diskussionen über Performance von 3D-Szenen mitlese, bekomme ich den Eindruck, dass diese Grenzen bei Unity extrem früh kommen.

Für Dein Tower Defense-Spiel ist das aber sicher nicht relevant. Da hilft Dir die Engine, viel schneller voran zu kommen. Der einzige Nachteil, den ich dann noch sehe, ist dass die darin gesammelten Erfahrungen u.U. in Deinem Lebenslauf wertlos sind, wenn Du Dich dann in irgendeiner Software-Bude bewirbst.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

16

04.11.2014, 19:09

Schrompf das sehe ich ein wenig anders. Erfahrungen sammelt man ja unabhängig von der Engine. Wenn natürlich bestimmte Engines gefordert sind ist es gut damit schon gearbeitet zu haben, aber so schnell wie sich die Technologie entwickelt braucht man da nicht unbedingt frühzeitig mit anfangen. Wenn ich überlege was ich vor 2 Jahren so gemacht habe und was ich damit heute anfangen kann (nicht privat sondern bei der Arbeit), das ist immer so eine Sache. Unabhängig von der dahintersteckenden Technologie sammelt man aber Erfahrungen in der Entwicklung allgemein und vor allem im Gamedesign. Ob einen das jetzt weiter bringt ist natürlich eine andere Sache.
Was die Grenzen von Unity angeht, ich kenne deine persönlichen Erfahrungen ja nicht. Was die Performance angeht so habe ich schon einiges gehört, dabei war das meiste beim hören schon als Schwachsinn zu entlarven. Jetzt bin ich nicht so aktiv in der Unityszene und beschäftige mich seit längerem eher mit anderen Projekten als mit Spielen, von daher kann ich zu deinen Quellen grad nichts sagen. Nichts desto trotz denke ich ist Unity einen Blick wert. Wer weiß ob die Probleme die es anscheinend gibt für dich überhaupt von Interesse sind.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

KeksX

Community-Fossil

Beiträge: 2 107

Beruf: Game Designer

  • Private Nachricht senden

17

04.11.2014, 19:32

Zitat von »Schrompf«

Das ist übrigens auch meine Sorge mit Unity: was, wenn ich an irgendeine Grenze stoße? Und wenn ich in den Facebook-Gruppen die Diskussionen über Performance von 3D-Szenen mitlese, bekomme ich den Eindruck, dass diese Grenzen bei Unity extrem früh kommen.


Hängt vermutlich damit zusammen, dass die Leute glauben man müsste in Unity nichts optimieren. Da gehen die Drawcalls abnormal hoch und wenns dann irgendwann zu langsam wird, ist erstmal Unity schuld. Ist jedenfalls meine Erfahrung und wenn man sich die Twitch-Streams etwaiger Unity-Entwickler ansieht, ist das echt oft der Fall.
WIP Website: kevinheese.de

Laguna

Treue Seele

Beiträge: 262

  • Private Nachricht senden

18

07.11.2014, 11:23

Zitat von »David Scherfgen«

Unity-Programmierung ist ganz normale C#-Programmierung.
Deine "Scripts" sind stinknormale C#-Klassen, die ganz normal (schon wieder dieses Wort) kompiliert werden.
Ich schlage vor, du probierst es einfach mal aus.

PS: Und selbst wenn es nur ein "Script" wäre, dann wäre das doch auch Programmierung?!


Kurz zu meinem Hintergrund:
Ich habe früher mit C++ gearbeitet, bin dann aber zu C# umgestiegen und habe auch mehrere Projekte in Unity fertiggestellt. Ich habe nicht informatik oder etwas ähnliches studiert, sondern bin größtenteils Autodidakt und habe empirisch gelernt, was Projektstrukturen und Klassendesign angeht.


Die Aussage stimmt rein prinzipiell schon, nur muss man bei Unity eben doch etwas aufpassen. Möchte man mit Templates arbeiten und Dinge eben noch "schön" im Unity Editor zusammenklicken können, kann man sich meistens nicht wie gewohnt Vererbungsstrukturen aufbauen, da das im Unity Editor aktuell nicht unterstützt wird (oder zumindest habe ich nicht herausgefunden, wie das funktioniert).

Ich habe oft das Gefühl, dass Unity den Nutzer ermutigt, nicht eine Player Klasse zu schreiben, die dann eben alles macht, sondern viele kleine Klassen wie PlayerMovementController, PlayerHealth, PlayerWeapons, SpriteFlash, SprieWobble, MoveOnGrid, CollisionController etc... die dann an das Player-Entity (ein Unity Objekt) "angehängt" werden.
Man kann jetzt sagen: "Na das ist doch super, composition over inheritance", aber irgendwie läuft das meinem Bauchgefühl für OOP zuwieder. Es fühlt sich einfach nicht so wirklich nach "echtem programmieren" an.
Das ganze sind natürlich C# Klassen, aber der Kontext, in dem sie benutzt werden, ist eben ein anderer.

Gut, das alles ist Kritik auf hohem Niveau und Unity ist ein super Werkzeug, mit dem man wirklich vorzüglich arbeiten kann. Gerade die Userbase, die Dokumentation und die Community ist eine der besten, die man im Internet finden kann. Um kreativ Spiele zu entwickeln und diese einer breiten Öffentlichkeit zugänglich zu machen (Portabilität ist DAS Argument für Unity), ist es spitze und kann uneingeschränkt empfohlen werden!

So Far...
Laguna
Portfolio runvs.io | Gamejolt | itch.io | PEWN | Twitter

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

19

07.11.2014, 12:42

Zitat von »Laguna«

Möchte man mit Templates arbeiten und Dinge eben noch "schön" im Unity Editor zusammenklicken können, kann man sich meistens nicht wie gewohnt Vererbungsstrukturen aufbauen, da das im Unity Editor aktuell nicht unterstützt wird (oder zumindest habe ich nicht herausgefunden, wie das funktioniert).

Darf ich fragen, was du konkret probiert hast?
Ich habe bisher wie gewohnt Vererbung verwenden können und musste dabei nur ein paar Unity-speziefische Sachen berücksichtigen. Nachfolgend die Dinge, die mir gerade eingefallen sind:
  • Damit man die Skripte am Ende einem GameObject zuweisen kann, muss dieses direkt oder indirekt von "MonoBehaviour" abgeleitet sein.
  • Will man ein GameObject nach einer Komponente durchsuchen, kann man standardmäßig keine Interfaces angeben, sondern nur Component abgeleitete Klassen. (-> abstrakte Klassen, statt interfaces, sofern möglich)
  • Unity kann keine Strukturen Serialisieren, man ist in bestimmten (und sehr speziellen) Fällen also zur Verwendung von Klassen gezwungen.
  • Um einem Member einen Wert zuweisen zu können, muss dieser entweder public sein oder das Attribute SerializeField besitzen. (Properties können vom Editor aus nicht belegt werden.)
Ich bin mir ziemlich sicher, dass es auch für deine Fälle Lösungsmöglichkeiten gibt. ;)

Zitat von »Laguna«

Ich habe oft das Gefühl, dass Unity den Nutzer ermutigt, nicht eine Player Klasse zu schreiben, die dann eben alles macht, sondern viele kleine Klassen wie PlayerMovementController, PlayerHealth, PlayerWeapons, SpriteFlash, SprieWobble, MoveOnGrid, CollisionController etc... die dann an das Player-Entity (ein Unity Objekt) "angehängt" werden.
Man kann jetzt sagen: "Na das ist doch super, composition over inheritance", aber irgendwie läuft das meinem Bauchgefühl für OOP zuwieder. Es fühlt sich einfach nicht so wirklich nach "echtem programmieren" an.
Das ganze sind natürlich C# Klassen, aber der Kontext, in dem sie benutzt werden, ist eben ein anderer.

Es kommt drauf an. Es gibt Fälle, in denen eine Zusammensetzung wesentlich besser wäre, es gibt aber auch Fälle, in denen das nicht der Fall ist. Als Entwickler besitzt man die Verantwortung dafür, seine konkreten Fälle richtig einschätzen und so die richtige Entscheidung treffen zu können. Meiner Meinung nach hat Unity also nichts mit einem übermäßigen Aufsplitten der Funktionalität zu tun, sondern nur der Entwickler, der so vorgeht.
Spieleentwickler in Berlin? (Thema in diesem Forum)
---

Zitat von »Jonathan_Klein«

Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

20

07.11.2014, 12:51

Zitat von »Laguna«

Die Aussage stimmt rein prinzipiell schon, nur muss man bei Unity eben doch etwas aufpassen. Möchte man mit Templates arbeiten und Dinge eben noch "schön" im Unity Editor zusammenklicken können, kann man sich meistens nicht wie gewohnt Vererbungsstrukturen aufbauen, da das im Unity Editor aktuell nicht unterstützt wird (oder zumindest habe ich nicht herausgefunden, wie das funktioniert).

Wenn ich es nicht total falsch in Erinnerung habe, zeigt der Editor doch problemlos geerbte Properties etc. an. Wo klemmt es denn da bei Vererbungshierarchien?

Das man, wenn man den Editor nutzt etwas aufpassen muss, kann ich zustimmen. Ich hab eine zeit lang rumprobiert, welche Konstrukte sich direkt über den Editor anzeigen und editieren lassen. Bin dann zu einer halbwegs guten Lösung gekommen, bei der ich für die Anzeige im Editor eine separate Klasse nutze. Mit Hilfe eines DI Frameworks lässt sich das dann einigermaßen bequem mit den Stellen wo sie benötigt werden verknüpfen. So bleibt auch (abgesehen von dem Editor Glue) der Code Unity frei.

Zitat von »Laguna«

Ich habe oft das Gefühl, dass Unity den Nutzer ermutigt, nicht eine Player Klasse zu schreiben, die dann eben alles macht, sondern viele kleine Klassen wie PlayerMovementController, PlayerHealth, PlayerWeapons, SpriteFlash, SprieWobble, MoveOnGrid, CollisionController etc... die dann an das Player-Entity (ein Unity Objekt) "angehängt" werden.
Man kann jetzt sagen: "Na das ist doch super, composition over inheritance", aber irgendwie läuft das meinem Bauchgefühl für OOP zuwieder. Es fühlt sich einfach nicht so wirklich nach "echtem programmieren" an.
Das ganze sind natürlich C# Klassen, aber der Kontext, in dem sie benutzt werden, ist eben ein anderer.

Das Prinzip hört auf den Namen Entitiy-Component-System und wird recht häufig im Zusammenhang mit Spielen erwähnt und eingesetzt. Es macht bei Unity in Verbindung mit dem Editor auch unglaublich viel Sinn. Für ein Musik Spiel habe ich eine Komponente geschrieben, die auf Musik Events die zugeordnete Animation abspielt. Da die Komponente unabhängig von dem Verhalten oder Einsatz des Objekts ist, kann es beim Erstellen der Level so ziemlich überall verwendet werden.

Und selbst wenn es nicht wiederverwendbare Komponente sind, macht es Sinn. Eine Herausforderung bei der Softwareentwicklung ist es, eine Struktur in den Code zu bringen, damit dieser besser lesbar aka wartbar ist. Eine 500 Zeilen Funktion ist nur schwer zu überschauen. Also verteilt man es auf mehrere Funktionen, deren Name erkenntlich macht, was sie tun. Bei einer Klasse mit 100 Funktionen hat man aber auch keinen Überblick mehr und teilt es entsprechend in weitere Klassen. Hier muss man natürlich wieder aufpassen das man die Benennung und Aufteilung logisch nachvollziehbar macht.

Werbeanzeige

Ähnliche Themen