Damon93

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

Super, danke für eure beiden Antworten. Habe die Teile noch nicht so richtig verstanden. In vielen Tutorials werden die als das ultimative mittel für die Game Architektur beschrieben... daher dachte ich, es ist eine gute Idee, all meine Einwohner damit zu erzeugen. Ich plane das aktuell so, dass ich eine Stadt habe, mit Häusern und in jedem haus n Personen leben. Diese Personen/Einwohner haben natürlich auch einen Job bei einem der n Unternehmen innerhalb der Stadt. Die Einwohner selbst werden vom Spieler nicht gesehen (wird keine Modelle für sie geben). Sie "existieren" also so gesehen erstmal nicht. Dennoch haben Sie Namen, Einkommen etc. Dementsprechend vermute ich, benötige ich ein EmptyGameobject für jeden Einwohner oder? Falls ja, dann muss ich in meinem UnternehmensScripts eine Liste mit Angestellten führen und diese Liste über den Inspektor mit den EinwohnerEmptyGameobjects befüllen oder? Damit die connection zwischen Unternehmen und Angestelltem da ist. Und jetzt hatte ich mir halt gedacht, dass es vllt auch einen schöneren Weg gibt, diese Einwohner <-> Unternehmens Beziehung abzubilden. EDIT: Während ich den Text gerade schreibe, fällt mir auf, dass ich das Ganze in meiner Vorstellung über Delegates lösen wollte. Also Unternehmen kennen Angestellte nicht. Und Angestellte reagieren auf Events vom Unternehmen. Je mehr ich aber drüber nachdenke und auch über eure beiden Kommentare, macht es super viel Sinn, dass das Unternehmen die Angestellten einfach kennt... machts irg. wie auch einfacher Danke euch zwei. ich werde mal weiter programmieren und schauen ob ich nochmals nen Knoten im Hirn bekomme

Guten Abend zusammen Nach langer Zeit komme ich auch mal wieder mit einer Frage. Zum Szenario. Ich habe in meiner Scene n Unternehmen. Jedes Unternehmen kann n Einwohner in einer Anstellung haben. Die Unternehmen zahlen den Angestellten ein Gehalt x. Um meine Einwohner/Angestellten zu verwalten habe ich mir überlegt ScriptableObjects zu verwenden. So kann ich properties wie firstName, bankAccount, salary etc. meiner Meinung nach einfach verwalten. Jetzt kann es in meinem Spiel passieren, dass bspw. ein Unternehmen durch ein Ereigniss, dass Zufällig im Spiel auftreten kann, Gehaltskürzungen vornimmt. Wie wäre jetzt ein sauberer Weg, dieses GehaltskürzungsEvent an die betroffenen Angestellten zu senden? Muss mein Unternehmen eine Liste von Gameobjects (Einwohnern) halten um zu wissen welche Einwohnener auch Angestellte sind? Oder kann man das irg. wie über Actions machen? Dazu möchte ich erwähnen, dass ich 1 ScriptableObject habe -> EinwohnerScriptableObject Dies erstelle ich nun n mal für jeden Einwohner und passe die properties wie firstName etc. an. Kann ich zur Laufzeit wenn das GehaltskürzungsEvent auftritt, Werte wie salary aus dem ScriptableObject ändern, sodass diese auf Dauer geändert bleiben? Vllt noch kurz zu meinem Denkproblem -> Angenommen ich habe 100 Unternehmen und 10000 ANgestellt, dann müsste ich ja für jedes Unternehmen die Angestellten in die Liste von Gameobjects packen um eine Referenz auf den Angestellten zu bekommen. Das erscheint mir nicht nur unheimlich kompliziert, sondern auch mühsam und fehleranfällig. Ich hoffe ich konnte mein Problem gut schildern und freue mich auf feedback

Ebenfalls von meiner Seite aus ein Gutes und Gesundes Jahr 2023 an alle @Sascha: Schlechter als 2022 wäre tatsächlich eher doof^^

wirklich niemand eine Idee? oder hab ich mein Problem zu schlecht formuliert?

Hallo Freunde , nach einiger Zeit melde ich mich auch mal wieder in diesem Forum zu Wort oder besser zu Frage Kurz und knapp ich hatte grad eine tolle idee für ein Spiel. Dieses soll über smartphones oder tablets spielbar sein und zwar mit freunden zusammen. Funktionalität wäre: Irg. ein Freund erstellt eine art lobby in dem game, und alle Spieler in seiner Nähe (möglicherweiße im selben Wlan oder per Bluetooth oder Hotspot) sehen diese Lobby und können sich darauf connecten. Der Host fungiert also als Server. So wie das damals bei WC3 der Fall war - falls ihr euch erinnert Schaltet der Host sein Game aus, ist das Spiel logischerweiße bei allen vorbei, da der Server weg ist. Ist dies bei smartphones überhaupt möglich und wenn ja wären ein paar buzzwords nice :D? Muchas gracias schon mal

Super Video und absolut hervorragend erklärt! Was mich noch interessieren würde wäre, wie du ein solches Video erstellst? Z.B. wenn du vom solid in den wireframe mode schaltest, oder wenn du den Boden mit Wellen (3:15 min)animierst etc... machst du das alles in z.B. Blender oder Unity selber oder gibt es da tools für?

Sieht super aus! Tatsächlich könnte die Spielmechanik ebenfalls super interessant sein. Bleib auf jeden Fall mal dran und halte uns auf dem Laufenden Wie chrische5 schon gesagt hat: Du hast einen krassen Output an Projekten^^. Machst du die Modelle alle selber oder sind die gekauft?

Ah okey haha ja da hab ich an ganz was anderes gedacht Trotzdem sehr cool!

Sehr cooles Paket Sascha! Heißt das, dass wenn ich dein Paket verwende ich mich nicht darum kümmern muss welche Objekte in den Pool kommen und welche nicht? Falls ja, wie findest du die Objekte welche in den Pool gehören? Klingt für mich nach ziemlich viel Reflection?! Oder habe ich da was grundlegend falsch verstanden?

Sodele hier ist auch schon mein erstes Gameobject.... eine Axt Und hier ein Baumstamm

Hey Leute, ich bin grad an nem game dran und werde hier immer mal wieder meine erstellen Objekte vorstellen. Diese sind allesamt Handpainted Über Kritik und Verbesserungsvorschläge bin ich immer dankbar!

Sieht schick aus! Kleine Frage am Rande...weiß Peak dass du seine Creatin Boxen verwendest?^^

So nach langer Zeit meld ich mich in diesem Thread auch mal wieder zu Wort und stelle euch meine neuste Wood Texture vor. Wie immer ist Kritik gerne gesehen! (Habe versucht den WoW Style bisschen zu kopieren)

Das fände ich richtig spitze! Lass dir damit bitte nicht zu viel Zeit hahaha

Son Videotutorial wie ihr eure Räume baut fände ich auch mal Interessant

Hatte nur gedacht, da du das Spiel ja bereits released hast und solch ein Sound sollte er im aktuellen Build bereits enthalten sein deine Gamer eventuell abschrecken könnte. Des Weiteren finde ich es nicht unbedingt ersichtlich aus deinem Video, was nun großartig verändert wurde? Vllt kannst du da mal ein paar Änderungen aufzählen oder vllt wo du gerade dran bist

Ok also der Sound geht gar nicht^^ Klingt als würde ein 3 beiniges Pferd durch die Gegend rennen! Achte darauf deine Sounds dem Terrain anzupassen etc. Hab dir schon weiter oben gesagt... nehm nicht diese fertigen Sounds irg. wo her! Mach selber welche. Leg das Microphon auf den Boden vom Wald und lauf dran vorbei. Fertig is nen cooler sound! Ansonsten... DRAN BLEIBEN!!!

Servus hab grad gesehen das du dein Spiel raus gebracht hast und gebe dir direkt mein Beileid für die vielen negativen Kommentare auf Steam! Will dir auch gleich bisschen Feedback geben was du besser machen könntest ohne großartigen Aufwand und zwar abgesehen von Ingame Bugs etc...! Finde das Prinzip des Spiels sehr gut, aber was fehlt ist der Charme des Spiels. Das spiel hat kein Flair... es wirkt alles sehr statisch und und weit weg von einem early access titel. Beispiele: 1) Das Hauptmenü sieht einfach langweilig aus. Sieht aus wie Standard Buttons mit bissl farbe. 2) Ebenso der Titel. Einfach nur grüne schrift ist wenig ansprechend. Die Idee mit der Palme als "I" find ich aber sehr gut. 3) Das Schiff sollte sich auch wirklich bewegen und nicht nur hinter sich Wasser aufwirbeln lassen. 4) Keine Identifikation mit dem Character möglich 5) Allgemeine Dinge Lösungen: 1) Den Buttons ne geile Texure geben z.B: Holzbretter in denen die Zeichen eingeritzt sind oder sowas (die Holzbretter vllt vermodert oder so) 2) Auch beim Titel bisschen mehr power rein bringen... andere schrift art und nicht nur eine eintönige Farbe 3) Schiff wirklich auf und ab bewegen lassen segel flattern lassen vllt noch Ruder aus den Luken raus machen und die sich bewegen lassen 4) Geb dem Character Arme... mach nen schönen First Person draus! Lass den Character Holz wirklich hacken, steine wirklich schlagen die Bewegungen müssen sichtbar sein! Geb ihm noch paar Sound sowas wie Atmen! oder wenn er Holzfällt nen stöhnen. kannst alles super leicht aufnehmen geh einfach selber mal mit ner axt aufn baum los und power dich richtig aus... und das nimmst dann auf (nur nen Beispiel). 5) Geb der Umwelt mehr Leben... Mehr Tiere , Fische, Plfanzen, Bäume, kleine Eye Catcher wie schöne Höhlen mit kp mini Wasserfällen oder so... Hoffe du nimmst das nicht böse die Kritik, aber ich kenne das selber wenn man Entwickelt dann will man das Game irg. wann raushauen und da sieht man die ganzen Makel irg. wann nicht mehr! Weiterhin viel Erfolg!!!! An sich gute Spielidee!