Damon93

@malzbie Nochmals danke für das ausführliche Statement! Also was ich bisher von Godot gesehen habe, finde ich grade die Version 4 im 2D als auch 3D Bereich ziemlich gut. Und rein von der Art und Weiße wie sich die UI Bedienen lässt, ähnelt es schon sehr Unity. Klar hier und da sind ein paar Unterschiede, aber nichts was man nicht innerhalb von ein paar Wochen lernen kann. Von daher steht meine Entscheidung fest, mich auf Godot zu konzentrieren, schon allein deshalb weil Unreal im Grunde ja ähnliches abziehen könnte wie Unity^^ Ich bin ja auch schon seit ein paar Jährchen hier im Forum unterwegs und fande es prinzipiell früher ziemlich nice, wie aktiv hier alles war Das hat sich dann so ein bisschen gelegt, weil natürlich viele Fragen bereits geklärt wurden. Aber: Wir könnten ja auch die erste deutsche Godot Community werden (oder halt die x-te )

ach krass, das heißt selbst bei apps die komplett kostenlos sind, könnte Unity eine installation fee verlangen?

Wunderbar zusammengefasst @malzbie & @Sascha! Ich für meinen Teil habe seit dieser Schrecknachricht direkt angefangen mich mit Godot zu beschäftigen. Dies scheint für mich die beste Alternative zu sein, auch wenn ich das ganze Thema Spieleentwicklung nur aus Spaß betreibe und nicht aus monetären Gründen. Kleine Frage trotzdem: Wenn ich ein Spiel im Play Store habe (ca. 8 Jahre bereits^^) und natürlich kostenlos. Muss ich Angst haben, dass mir irg. wann ne Rechnung von Unity reinflattert?

Ach, in der Softwareentwicklung muss einem nichts peinlich sein Zu oft sieht man den Wald vor lauter Bäumen nicht, und dann kommt ein Kollege, wirft einen Blick drauf und findet den Fehler^^

Ich selber nutze Photoshop, aber Krita ist wie @malzbie sagt ebenfalls hammer! Damit kann man auch super schön und leicht tileable textures erstellen

1. Ja du kannst 2 Objekte und auch mehr zu einem machen. Würde ich hier aber nicht. Ich würde einfach in Blender den Rahmen der Brücke, also da wo das Auto drauf fährt, in Low Poly nach modellieren und dann in Unity als Collider verwenden. So Sieht deine Brücke schön aus, also aus den einzelnen Steinen und Blöcken, aber der Collider ist im Grunde eine leicht gekrümmte Plane ( je nachdem wie stark deine Brücke gekrümmt ist) und dein Auto fährt sauber drauf. Dann stört es auch nicht, falls eventuell ein Stein etwas herausragen sollte. Der wird dann nämlich einfach ignoriert und "durchfahren".

@gombolo hat leider nicht geklappt Trotzdem Danke für eine Antworten! Ich bleibe an dem Problem drann, und wenn ich eine Lösung finde (wird vermutlich irg. ne dumme Kleinigkeit sein), dann werde ich die Lösung hier posten.

Also das Objekt ist meiner Meinung nach schon recht Mid_Poly. Da sollte es nicht zu solchen Problemen kommen (teste es aber dennoch nochmal aus). Wurde auch mit Subdivision-Surface Modifier erstellt. Und wie gesagt, mit der build in render Pipeline sieht alles super aus. Sobald ich aber auf URP switche entstehen diese seltsamen Schattierungen. Da ich mich aber nicht mit URP auskenne, und ich schon an allen mir bekannten Reglern rumgespielt habe, bin ich da mit meinem Latein am Ende und werde vermutlich bei der build in render pipelin bleiben... Außer du hast noch ne Idee

Danke für die Antwort Normals zeigen alle nach außen. Verwende keinerlei Texturen, nur Materialen mit einer basic color. EDIT: Habe den Fehler "gefunden". Hatte bei meinem Projekt die URP verwendet. Habe dann mal zum Spaß ein neues Projekt mit dem build in renderer erstellt und siehe da, alles funktioniert - Keine seltsamen render Fehler. Vllt hilft diese Info ja dem ein oder anderem hier, der sich mit dem ganzen URP Zeug auskennt und könnte mir nen Tipp geben, woran es gelegen haben könnte? Für mich ist es auf jeden Fall nicht besonders logisch^^ Würde nämlich schon gerne URP verwenden...

Hallo Zusammen, habe aktuell ein seltsames Problem zu sehen in dem Bild. Diese weißen Striche mit dunklem Inhalt sind natürlich nicht gewollt. Wirkt auf mich wie die Edges des Objektes. Diese sind nur sichtbar, wenn ich nah an das Objekt ran zoome. Das Objekt kommt aus Blender und wurde als fbx exportiert/importiert. In Blender verwende ich smooth shading (weiß nicht ob das was damit zu tun haben könnte.) Jemand ne Idee woran das liegen könnte? EDIT: Sieht so aus, als würde es tatsächlich an dem smooth Shading liegen. Habe auch mal das Linke Objekt innerhalb Unity auf smooth shading gestellt, und dann sieht es gleichermaßen seltsam aus. Weiß jemand woran das liegen könnte?

Tatsächlich hatte ich während dem Verlauf dieses Threads ein paar Gedankensprünge gehabt - was vermutlich der Grund dafür war, weshalb ich meine Thematik nicht so perfekt schildern konnte Aber Ende gut, alles gut

@gombolo Aber dein ObjectManager ist ein MonoBehaviour nehme ich an? Now we are talking ! Danke @Sascha meine Eindruck war tatsächlich der, dass der initiale Impuls aus einem MonoBehaviour kommen muss. [RuntimeInitializeOnLoadMethod] war mir bis jetzt noch nicht bekannt. Und nein, ich werde natürlich MonoBehaviours weiterhin verwenden Mir ist nur wichtig, alle Möglichkeiten zu kennen mit den Vor und Nachteilen. Wie es in der Softwareentwicklung halt so ist, viele Wege führen zum Ziel, manche sind sch****, manche sind gut, und manche sind perfekt... aber viele führen ans Ziel Wie gesagt möchte ich ein bisschen tiefer Eintauchen, und als ich mit Unity vor ein paar Jahren angefangen habe (mit einer etwas längern Pause - bis jetzt) wurde so ziemlich alles mit MonoBehaviours gemacht (in so ziemlich allen Tutorials die es vor ca. 7 Jahren so gab haha), daher nochmals danke für deinen ausführlichen Beitrag. Jetzt habe ich ein paar Buzzwords, mit denen ich meine Recherche fortsetzen kann.

Bin seit 8 Jahren als Softwareentwickler im Bereich Backend-Entwicklung (Spring Boot mit Java und Kotlin tätig), sowohl als DevOps Engineer. Ich glaube an meinen Programmierfähigkeiten scheitert es nicht Wie man Listen erstellt und befüllt ist mir wie gesagt bekannt Hier liegt nicht mein "Problem". Ich werde einfach mal ein bisschen präziser, da ich glaube mich noch nicht klar genug ausgedrückt zu haben -> Da jetzt tipps rein kommen, wie ich Listen befülle^^ Also ich habe eine Klasse Einwohner. Nichts besonderes. Diese kann ich in Unity nun auf verschiedene Arten verwenden. public class Einwohner { public string Vorname {get; set;} //.. Und weitere properties public void GehaltErhoehen() { //ToDo: Implement } //... und weitere Methoden } Ich könnte eine andere Klasse haben z.B: GameManager. GameManager ist ein MonoBehaviour, heißt, er hängt an einem GO. public class GameManager : MonoBehaviour { public List<Einwohner> myList = new List() //.. Und weitere properties void Start(){ myList.add(new Einwohner()) } } Im GameManager instanziiere ich nun meine Einwohner. Denn wenn ich das Spiel starte, wird die Start() Methode vom GameManger gecalled und eine Liste mit einem Einwohner erzeugt. Mein GameManager hält nun also eine Liste mit X Einwohnern. Die zweite Option wäre, dass meine Einwohner Klasse selber von MonoBehaviour erbt. Somit würde die Einwohner Klasse als Componente auf einem GO liegen. Ich könnte jetzt also im Inspector die Properties wie den Vornamen etc. anpassen. Um den Einwohner einem Unternehmen zu zuweißen könnte ein Script so aussehen: public class Unternehmen : MonoBehaviour { // Die Einwohner GO würde ich nun über den Inspector per Drag and Drop dieser Liste hinzufügen. Ich benötige also kein new keyword mehr. public List<Einwohner> myList = new List() void Start() { //Hier könnte ich mir nun DInge ausgeben lassen myList.ForEach((einwohner) => { print(einwohner.Vorname()) }) } } @gombolo du sagst nun: Wo würde denn diese foreach-Loop bei dir liegen? In einem Script das von MonoBehaviour erbt? Aber zurück zu meiner Frage. Ich habe jetzt 2 Optionen aufgezeigt wie ich EInwohner verwalten könnte. einmal per MonoBehaviour an GO's drann, und einmal in einem MonoBehaviour (GameManager). Und hier kommt meine Frage, sind dies die einzigen 2 Möglichkeiten in Unity, wie ich Instanzen verwalten/ instanziieren kann? Am Ende muss ich ja immer auf einem MonoBehaviour eine Instanz von etwas erstellen. Oder? Denn angenommen, ich hätte ein weiteres Script, das nicht von MonoBehaviour erbt, und auch sonst nichts tut. Es liegt einfach nur so da^^ public class EinwohnerManager { public List<Einwohner> myList = new List() //.. Und weitere properties // Hier befülle ich via constructor meine Liste. void EinwohnerManager(){ myList.add(new Einwohner()) myList.add(new Einwohner()) } } Jetzt hätte ich in der Theorie in diesem Script meine Einwohner liegen. Meines Wissenstandes nach, wird der Constructor aber nie gecalled. Dieses Script müsste entwader ein MonoBehaviour sein, oder von einem anderen Script, welches ein MonoBehaviour ist instanzieert werden. Oder?

Ich muss jetzt einfach nochmal fragen, weil so ganz 100% habe ich es glaube ich noch nicht verstanden. 1. Ich habe die Option, GO's oder Empty GO's zu erstellen und dort mein EinwohnerScript als Component zu verwenden. Dann wird sobald ich den Start Knopf in Unity drücke eine Instanz vom EinwohnerScript erstellt und ich habe z.B. 20 Einwohner (20 GO's) in meiner Stadt, auf die ich immer ganz entspannt zugreifen kann (über das jeweilige GO). 2. Ich kann das EinwohnerScript ohne MonoBehaviour erstellen. Wenn ich nun den Start Knopf drücke, passiert erstmal gar nichts. Mein EinwohnerScript wird nicht instanziert. Ich muss es also erst in irg. einem Monobehaviour Script instanzieren. Zum Beispiel könnte ich ein GameManger GO erstellen und in dem Instanziere ich nun diese 20 Einwohner innerhalb der Awake oder Start Methode. Wenn ich nun aber in irg. einem anderen Script diese Einwohner verwenden möchte. Dann muss dieses auf das GameManager MonoBehaviour zugreifen, das meine Einwohner instanziiert hat. Das heißt, das MonoBehaviour, das meine Einwohner instanziiert hat, ist sozusagen der Parent von diesen Einwohnern, und ich komme nur über dies MonoBehaviour an die Einwohner drann (das meinte ich mit, die Einwohner gehören dem Monobehaviour Objekt). Vllt habe ich irg. wo einen dicken Knoten in meinem Hirn. Falls dem so ist, würde ich mich freuen wenn Ihr den lösen könntet Falls ich aber mit meinen beiden oben genannten Optionen den Nagel auf den Kopf getroffen habe, dann würde ich mich glaube ich eher für die Gameobject (1) entscheiden, da ich das Managen dieser Einwohner Instanzen damit komfortabler finde (kann dann über den Inspector properties verändern etc.). Und auch hier gilt wieder, falls ihr Option 2 besser findet, gerne sagen warum. Habe Unity bisher immer nur relativ Oberflächlich verwendet und möchte da jetzt endlich mal nen bisschen tiefer durchsteigen

Also verstehe ich das richtig: Da meine Einwohner zu keiner Zeit durch ein Modell sichtbar sind, brauche ich keine GameObjects? Was ich machen möchte ist, ich habe Häuser in denen Einwohner leben, und wenn der Spieler nun über ein Haus hovert oder drauf klickt, dann solll da nen Fenster auf gehenb wo steht hier wohnt XY, XY verdient Z Dollar und arbeitet bei ABC Firma. Dies wäre alles was von Einwohnern so gesehen sichtbar ist. Wie gesagt die Properties der Einwohner können sich dennoch verändern. Mir fehlt hier so ein bisschen die Instanziierung der Einwohner, wenn ich kein GO verwende. Denn die Alternative wäre ja, ich Instanziiere in jedem UnternehmenScript, innerhalb der Awake oder Start Methode eine Liste mit newWorker(). Das würde bedeuten, dass ein Einwohner fest an einem Unternehmen hängt, was ich so ja nicht möchte. Oder?. Denn Angenommen ein Einwohner verliert seinen Job, oder wechselt den Job, dann stoße ich hier doch auf ein Problem... oder? Nochmals Danke für euren Input! Hilft mir sehr