Leaderboard

Viele von euch werden es wohl mitbekommen haben. Unity ändert seine Preispolitik. Ab 2024 will Unity etwas vom Kuchen ab haben. Momentan ist es so: Man nutzt die Free Version von Unity. Bis zu einem Firmenverdienst von 100.000$ ist alles ok. Verdient man mehr, muss man eine Kaufversion erwerben. Man nutzt die Plus Version (kostet ~ 300€). Hier hat man bis zu 200.000$ keine Probleme. Verdient man mehr, muss man sich die Pro kaufen. Man nutzt gleich die Pro Version. Ab 2024 wird es so sein: Die Einnahmen sind jetzt nicht mehr auf die Firma bezogen, sondern auf das Spiel selbst. Egal welche Version man nutzt, die Einnahmen, die man mit einen Spiel generiert werden jetzt wichtig! Bei der Free Version gibt es eine Einnahmengrenze von 200.000$ (in den letzten 12 Monaten pro Spiel). Bei der Pro sind ein 1.000.000$ (in den letzten 12 Monaten pro Spiel). Zusätzlich zu den Einnahmen werden auch die Verkäufe des Spiels gezählt. Diese werden erst ab 2024 gezähl. Alles was davor Verkauft worden ist, soll nicht berücksichtigt werden. Es gibt ab dann keine Plus Version mehr. Nur noch die Free Version und die Pro bzw. Enterprise Version. Bei beiden Versionen gibt es einen Schwellenwert der verkauften Spiele, ab dem es überhaupt erst dazu kommen kann, dass Unity an dir mitverdienen wird. Die Free Version hat einen Schwellenwert von 200.000 Die Pro einen Wert von 1.000.000 Einheiten. Gezählt wird, wie gesagt ab dem Januar 2024 ab dann für immer. Was bedeutet das jetzt? Wenn ihr ein Spiel erstellt habt und es verkauft, dann wird jeder Verkauf gezählt. Sobald dieses Spiel irgendwann den Schwellenwert überschritten hat, ist eine Bedingung für den mitverdienst erfüllt. Ab jetzt wird geschaut ob ihr in den letzten 12 Monaten mehr als die Obergrenze verdient habt. Wenn nicht, müsst ihr auch nichts abgeben. Wenn es aber so ist, wird geschaut, wie viele Spiele ihr den letzten Monat verkauft habt. Und für jedes Spiel will Unity dann etwas von euch haben. Habt ihr die Free Version, dann müsst ihr (pro verkauftem Spiel im letzten Monat) 20 Cent bezahlen. Habt ihr die Pro Version, dann ist der Preis gestaffelt. Es fängt mit 15 Cent für die ersten 100.000 Spiele an und verringert sich dann auf 7 Cent und dann noch weiter. Die Enterprise hat noch billigere Tarife. Siehe Tabelle. Hier ein kleines Beispiel: Ihr habt die Free Version. Euer Spiel wurde insgesamt 210.000 mal verkauft. - Bedingung 1 ist erfüllt. Ihr habt damit in den letzten 12 Monaten 350.000$ eingenommen. - Bedingung 2 ist erfüllt. Im letzten Monat habt ihr 10.000 Spiele verkauft. Dann müsst ihr 10.000 * 0.2 = 2.000$ an Unity bezahlen. Im nächsten Monat wird wieder geschaut, wieviel ihr in den letzten 12 Monaten eingenommen habt. Seid ihr dann wieder über der Grenze, dann wird wieder geschaut, wieviele Einheiten verkauft wurden und von diesen Einheiten bekommt dann Unity wieder seinen Anteil. Fallt ihr aber aus der Obergrenze raus, weil die starken Verkaufsmonate jetzt länger als ein Jahr her sind, braucht ihr für dieses Spiel auch nichts mehr bezahlen. Ist das jetzt gut oder schlecht? Zum einen ist es gut, weil man jetzt pro Spiel berechnet wird und die Grenze nach oben geschoben wurde. Die meisten von uns werden niemals 200.000$ mit einem Spiel in einem Jahr einnehmen. Es ist aber auch schlecht, denn wenn man wirklich mal einen Glückswurf haben sollte und ein Spiel richtig abgeht, denn dann kann es richtig teuer werden. Den es ist ja so, dass Spiele von kleinen Studios für viel weniger Geld verkauft werden als die Spiele von den großen Studios. Es macht einen Unterschied, ob man die Einkommensgrenze mit ganz vielen billigen Verkäufen überschreitet, oder mit wenigen teuren. Wenn das Spiel 10$ kostete, dann sind 20 Cent pro Verkauf 2%. Bei 60$ sind es aber nur 0,3% ! Um die Einnahmengrenze zu sprengen muss man aber bei 10 Euro 6 Mal soviel EInheiten verkaufen. Und dies würde sich dann auch in der Kalkulation niederschlagen. Es ist also ein unfaires Prinzip, weil es nicht um den Preis einer Einheit geht, sondern nur um Summen. Was mich persönlich ärgert ist der Wegfall der Plus Version. Ich habe die eigentlich nur, weil ich das Unity Logo nicht im Intro haben wollte. 300€ waren ok. Aber knappe 2000€ für ne Pro zahle ich nicht. Jedenfalls nicht, wenn ich nicht an die Einnahmengrenze ran komme. Wenn ich da ran käme, dann würde ich die Pro kaufen, denn dann hätte ich die Grenze auf ne Million angehoben und da muss man erst mal hin kommen. Es gibt noch viele Unklarheiten, denn Unity sagt nicht, wie sie an die Zahlen der Einheiten kommt. Es ist klar, dass jedes Spiel an Unity was sendet. Aber was das alles beinhaltet weiß nur Unity selbst. Demoversionen sollen nicht mit einberechnet werden. Mehrfach installationen sollen auch nicht mit einberechnet werden. Wir werden sehen, was die Zukunft bringt.

Für alle, die sich immer noch wundern, warum der Backlash so groß ist: Ein Spiel zu entwickeln, vor allem eines, das Geld verdienen soll, ist oft eine Angelegenheit von mehreren Jahren. Manchmal eines, manchmal mehrere, manchmal sogar zweistellig. Wenn man ein Spieleprojekt anfängt, und sogar noch mehr wenn man ein Studio aufbaut, das man dann nach und nach mit Menschen bestückt, die Spiele entwickeln können, dann ist die Wahl der Engine ein extremes Committment. Man geht, auch wenn man zuerst vielleicht nix bezahlt, eine Partnerschaft mit der Engine ein. Sollte Unity morgen nicht mehr existieren, würden dadurch in sehr vielen Studios überall auf der Welt jahrelange Arbeit und unfassbare Mengen an Geld über Nacht einfach weg sein. Deshalb ist die Wahl einer Engine für ein Spiel oder ein Studio etwas, das extrem auf Vertrauen basiert. Egal, wie gut die Engine ist - wenn die Firma dahinter nicht vertrauenswürdig ist, erhöht sich dadurch das Risiko, dass dein Projekt in die Brüche geht. Du setzt deine Existenz und/oder die deines Teams aufs Spiel. Was Unity diese Woche gemacht hat, ist ein unfassbarer Vertrauensbruch. Sie haben eine dumme Änderung angekündigt. Eine gute Metrik für die Bezahlung einer Middleware wie Unity ist immer "wenn du gewinnst, gewinnen wir mit dir". Auch wenn es sich um einen Randfall handelt (laut Unity selbst aber immerhin stolze 10% aller Entwickler!), dass man auf viele Installationen und niedrige ARPU (average revenue per user) setzt, hat das Unity-Management hier bewiesen, dass sie diesen Grundgedanken nicht verfolgen. Wer diese valide Schiene bisher gefahren ist, kann mit Unity schlicht keinen Gewinn mehr erzielen. Diese Entscheidung ist ein Beweis dafür, dass Unity die Unterstützung aller Entwickler nicht als Priorität versteht. Das Vertrauen, dass Unity Einsicht zeigen sollte, sollten sie irgendwann mal dir mit ihrer Idiotie Schaden zufügen, ist damit weg. die Änderung extrem schwach kommuniziert. Die Veränderungen warn sehr unklar und auch jetzt sind noch entscheidende Fragen offen. Die technische Umsetzung unterliegt der Geheimhaltung. Und wie zum Geier eine vermutlich nach Hause telefonierende Engine überhaupt unter europäischem Datenschutz funktionieren soll, versteht auch keiner. intern von vielen Mitarbeitern schon vor der Veröffentlichung große Kritik geerntet. Es heißt, dass vieles von dem, was Leute jetzt entrüstet schreiben, bereits vor Dienstag intern angemerkt wurde. Es hieß wohl "Antworten kommen". Stattdessen wurde der Plan einfach umgesetzt. Viele Unity-Entwickler kündigen jetzt. bereits auf Twitter angekündigt, dass sie jedes Jahr die Preise re-evaluieren und anpassen wollen. Das Committment, unvorhersehbar und unzuverlässig zu sein, ist stark. angekündigt, dass diese Änderung auch Leute betrifft, die sich schon von Jahren für Unity entschieden haben. eine ältere Version der TOS (terms of service) auf Github klangheimlich gelöscht, die besagt, dass man eine neuere TOS-Version ablehnen kann, wenn man auf der entsprechenden Engine-Version bleibt. Sie halten sich also nach Möglichkeit nicht an ihr eigenes Wort. Wenn das nicht illegal ist, weiß ich auch nicht weiter. Um das einmal klipp und klar zu sagen: Unfgefähr niemand beschwert sich darüber, Unity mehr Geld geben zu müssen. Das Problem, das wir hier haben ist, dass Unitys Chef-Etage der Welt bewiesen hat, dass sie weder die Fähigkeit, noch das Interesse haben, vertrauenswürdig zu sein. Und diese Vertrauenswürdigkeit ist, wie gesagt, extrem wichtig für eine Engine. Selbst, wenn Unity alles morgen wieder zurück nehmen würde, würde mir jeder, der professionell in der Spielebranche arbeitet, unterschreiben, dass Unity seit dieser Woche einfach einen unfassbaren Risikofaktor darstellt. Das hat dann auch nix mehr mit beleidigt oder wütend zu tun - das ist einfach eine ganz übliche wirtschaftliche Kalkulation. Dass Unity für viele Anwendungszwecke immer noch einfach die beste Engine ist, wird sie auf lange Sicht nicht davor retten, jetzt zunehmend in der Versenkung zu verschwinden. Mehr und mehr Studios kehren Unity den Rücken zu, also werden weniger und weniger Unity-Entwickler gesucht. Wer heute in die Spieleentwicklung will, kann sich gerne Unity anschauen, aber tut gut daran, mindestens noch eine andere Engine kennen zu lernen. Auch nicht zuletzt, weil Unity im Gegensatz zu mehreren Konkurrenten in den letzten Jahren technisch ziemlich stagniert ist. Glaubt mir bitte, dass ich hier nicht irgendwie leichtfertig Unity schlecht Rede. Ich benutze diese Engine seit 2008. 15 Jahre. Seit Version 2.3. Wenn Leute sich öffentlich entrüstet von Unity abwenden, dürft ihr davon ausgehen, dass hier nicht einfach nur die Gefühle hochkochen. Wegen wütend werden wirft man nicht 5, 10, 15 Jahre Erfahrungen über Bord. Ich schaue mir für mein aktuelles Hobbyprojekt gerade Godot an. Das passt ganz gut zum Projekt. Ansonsten warte ich ab, was mein neuer Arbeitgeber für das Studio entscheidet. Vielleicht bleibe ich ja dann dort bei Unity. Aber ein gutes Wort für sie einlegen werde ich, abgesehen von Fakten, in dieser Sache nicht.

Hi, meinst du sowas? Vector3 direction = mousePosition - origin; Vector3 target = origin + Mathf.Min(targetLength, direction.magnitude) * direction.normalized;

Hallo, ich beende erstmal meinen Retro-Plattformer. Es sollten insgesamt 10 Level werden. Allerdings sind mir jetzt keine vernünftigen Maps mehr eingefallen. Somit sind es sieben unterschiedliche Maps geworden. Ich denke das reicht um es als „fertig“ spielbar zu bezeichnen. Wenn ich noch ein paar zündende Ideen für weitere Level habe, dann setze ich die einfach dazu und gibt eine neue Version. Das Spiel ist mit Tastatur und Gamepad (empfohlen) spielbar. Die Tastaturbelegung habe ich von ADWS auf die Pfeiltasten geändert. Somit kann dann mit beiden Händen gespielt werden. Das war bei der ersten Version noch nicht der Fall. Hier der Download zum Spiel: Cunning Fox 1.0.0

Moin an alle! Ich bin seit gestern in diesem Forum aktiv und moechte mein erstes (fast fertiges) Projekt in Unity vorstellen. Link zu einem youtube Video. Den Wuerfel habe ich mit Blender erstellt.

Ohne eine halbwegs brauchbare Beschreibung des Problems wird das nix.

Aaaalso... Vererbung würde so aussehen: public abstract class AbstractMenu { public abstract void show(); } public class BookMenu extends AbstractMenu { @Override public void show() { System.out.println("Bücher"); System.out.println("======"); System.out.println("Gib den Namen eines Buches ein."); } } Und dann nutzt man das so: AbstractMenu menu = new BookMenu(); menu.show(); Das ist halt Polymorphie - du hast irgendein Objekt, dessen Klasse von einer Superklasse erbt. Aber du hast im Zweifelsfall keine Ahnung, welche der erbenden Klassen es ist. Du weißt nur die Superklasse (AbstractMenu) und weißt deshalb, dass du eine Methode "getName" hast, die du aufrufen kannst. Du baust dir also eine Variable, die irgendein Menü referenziert, und sagt diesem Menü, dass es sich anzeigen oder auf einen Input reagieren soll. Das implementierst du dann auf dir beliebige Weise anstatt von "getName". Weiß ja nicht, wie das aussehen soll. public class Game { private AbstractMenu currentMenu; public void openMenu(AbstractMenu menu) { currentMenu = menu; currentMenu.show(); } } Das geht ganz gut und ist, wenn man den Dreh erst mal raus hat, auch ziemlich intuitiv. In der echten Welt haben wir ja auch immer Dinge, die einer übergeordneten Klasse angehören: Feuerwehrautos, Polizeiautos und Sportwagen sind alles Autos. Und deshalb weißt du, dass du ein Lenkrad vorfinden wirst, egal, in welche Art von Auto du einsteigst. Komposition lässt dieses Konzept erst einmal links liegen und sagt "es gibt halt ne Klasse und die enthält Daten, und diese Daten bestimmen dann das Verhalten. Das ist das, was Unity mit GameObjects und Komponenten macht, aber es müssen nicht immer gleich Komponenten sein. public final class Menu { private string openText; public Menu(string openText) { this.openText = openText; } public void show() { System.out.println(openText); } } Hier hast du eine Menu-Klasse. Sie ist nicht abstract, und es wird nicht davon geerbt (darum auch gleich final). Du fütterst sie einfach mit Daten, und dann macht sie damit etwas. Anstatt sowas zu machen: AbstractMenu mainMenu = new MainMenu(); AbstractMenu bookMenu = new BookMenu(); machst du dann: Menu mainMenu = new Menu(mainMenuText); Menu bookMenu = new Menu(bookMenuText); Natürlich muss man die Daten nicht unbedingt über einen Konstruktor rein füttern, sondern könnte das Objekt sich Sachen aus einer Datenbank/Datei auslesen lassen oder mehrere Setter-Methoden aufrufen oder so. Komposition ist manchmal besser, weil es Fälle gibt, wo Vererbung auf seine Grenzen stößt. Wenn du z.B. zwei sehr ähnliche Menüs hast, bei denen sich ein spürbarer Teil ihres Codes überschneidet, dann kannst du eine gemeinsame Superklasse machen: public abstract class MediaMenu extends AbstractMenu { // Hier kommt das Zeug hin, das alle MediaMenus gemeinsam haben } public class BookMenu extends MediaMenu { // Nur das Buch-spezifische Zeug } public class DVDMenu extends MediaMenu { // Nur das DVD-spezifische Zeug } Wenn dann aber die Überschneidungen anfangen, kreuz und quer zu gehen, oder sogar innerhalb einer Hierarchie Konflikte sind, dann wird's eklig. Z.B. könntest du eine Hierarchie haben wie ... > InteractableEntity > Vehicle > FlyingVehicle > Helicopter > ApacheHelicopter und jetzt merkste aber, dass du einen ApacheHelicopter haben willst, mit dem man nicht interagieren kann, weil er als Deko in einer gescripteten Sequenz funktionieren (aber sonst alles noch können) soll. Dann würdest du am liebsten die InteractableEntity aus dieser Kette heraus nehmen, kannst es aber nicht. Also musst du ein bool oder so in InteractableEntity einbauen, mit dem du alles, was diese Klasse macht, ausschalten kannst. Ist auch irgendwo Käse. Wenn du jetzt mal an Unity denkst: Da kannst du alle diese voneinander erbenden Klassen als einzelne Komponenten anlegen. Und wenn dein Code sauber ist, kannst du die Interactable-Komponente einfach vom GameObject löschen und poof! - du hast genau, was du willst. Das ist ein bisschen eine Zusammenfassung von diesem Artikel. Wenn du jetzt Komposition benutzen willst, dann ist das natürlich knuffig und nett, da Strings reinzustecken, aber Klassen können sich ja auch komplett in ihrem Verhalten unterscheiden. Das mit Komposition zu machen, da wird's überhaupt erst interessant. Du kannst z.B. Objekte mit bestimmten Verhalten in deine Menu-Objekte stopfen. Das kann dann sehr ähnlich zu Unitys Komponenten sein. Und man kann dann auch sehen, dass Vererbung trotzdem noch eine Rolle spielen kann, auch wenn es nicht mehr das "Leitkonzept" ist. In Unity gilt ja auch, dass MonoBehaviour von Behaviour von Component von Object erbt. Aber mal ein Beispiel. Du bist ja in der Konsole. Das heißt wohl, dass du string-Inputs hast und dann darauf reagierst, richtig? Das könnte man so machen: public final class Menu { private final Dictionary<string, AbstractReaction> reactions = new Dictionary<>(); public void addReaction(string input, AbstractReaction reaction) { reactions.add(input, reaction); } public void reactToInput(string input) { AbstractReaction reaction = reactions.get(input); if (reaction != null) { reaction.invoke(); } } } Dann kannst du dir deine Menüs so zusammensetzen (oder eben "komponieren"): Menu mainMenu = new Menu(); mainMenu.addRection("Bücher", new Reaction( ... )); Wie du jetzt Reactions baust, ist dir überlassen. Java kann ja seit ner ganzen Weile funktionale Dinge machen. Das wäre so ein grober Überblick

Dein Problem könnte sein, dass ein Destroy nicht sofort passiert, sondern erst nach ablauf des Update-Loops. Du zerstörst also den letzten Level, welcher aber bis zum Ende des Loops noch da ist, instanzierst einen neuen Level, hast jetzt also 2 Level gleichzeitig drin, suchst nach deinen Punkten, die jetzt 2 Mal drin sind, und findest die alten, schon gefundenen, Punkte. Jetzt erst wird der alte Level aus der Szene raus genommen und deine gefundenen Punkte sind weg. Was dir helfen könnte, wäre ein DestroyImmediate. Das wird aber ausdrücklich nicht empfohlen! https://docs.unity3d.com/ScriptReference/Object.DestroyImmediate.html Suchen die Punkte doch einfach mal im LateUpdate und guck ob dann alles in Ordnung ist.

Hallo, Welche Fehlermeldung du genau erhältst wäre schon hilfreich. Ich rate mal ins blaue. In der class MathQuestion hast du public List<int> fakeAnswers; eine Liste referenziert die aber noch auf null zeigt. In der anderen Classe greifst du mit question.fakeAnswers.Add(_result); auf die fakeAnswers Liste zu die noch nicht Initialisiert ist. In der class MathQuestion hättest du mit public List<int> fakeAnswers = new List<int>(); die Liste Initialisiert Sorry, Sascha war mal wie immer 1 Minute schneller😉 Gruß Jog

Ich finde Mermaid sehr interessant, um z.B. einen Talentbaum zu visualisieren. Hab mal ein Beispiel gemacht, hat gut funktioniert: graph TD SURV[Wildnis] --> SURV_P1 SURV[Wildnis] --> SURV_COM SURV[Wildnis] --> SURV_DIV SURV_P1[Giftresistenz I\n<font size=1>-20% Schaden durch Gift</font>] --> SURV_P2 SURV_P2[Giftresistenz I\n<font size=1>-35% Schaden durch Gift</font>] --> SURV_P3 SURV_P3[Giftresistenz I\n<font size=1>-40% Schaden durch Gift</font>] SURV_COM[Kompass\n<font size=1>Du kannst ein Kompass bauen</font>] SURV_DIV[Tauchen\n<font size=1>Du kannst 100% länger tauchen</font>] COMBAT[Kampf] --> COMBAT_HEALTH COMBAT[Kampf] --> COMBAT_ARROWS COMBAT_HEALTH[Lebenspunkte I] COMBAT_ARROWS[Zielen I\n<font size=1>Pfeile sind genauer</font>] X[Alchemie] --> AL1 X[Alchemie] --> PT1 AL1[Kräuterkunde I\n<font size=1>Stufe 1 Kräuter sammeln</font>] --> AL2 AL2[Kräuterkunde II\n<font size=1>Stufe 2 Kräuter sammeln</font>] --> AL3 AL3[Kräuterkunde III\n<font size=1>Stufe 3 Kräuter sammeln</font>] --> AL_MASTER PT1[Heiltränke I\n<font size=1>+20% wirksamer</font>] --> PT2 PT2[Heiltränke I\n<font size=1>+40% wirksamer</font>] --> AL_MASTER AL_MASTER[Alchemie Grossmeister\n<font size=1>Du erhältst beim brauen die doppelte Menge Tränke</font>]

Ich wollte nur noch mitteilen, dass es so geklappt hat! Die Startkoordinaten und die jeweiligen Bilddimensionen werden bei unterschiedlichen Monitorauflösungen neu berechnet! // Screensize der orthogonalen Kamera ist 6 // Kamera Units vertikal: Camerasize (6) * 2 = 12 Units werden von der Kamera vertikal erfasst // Kamera Units horizontal: 12 Units / 9 * 16 = 21.3333 Units werden von der Kamera horizontal erfasst float propX = 12f / 9 * 16 / sprite.GetComponent<SpriteRenderer> ().bounds.size.x; // Verhältnis von Screenbreite und Bildbreite float propY = 12f / sprite.GetComponent<SpriteRenderer> ().bounds.size.y; // Verhältnis von Screenhöhe und Bildhöhe int width = (int)(Screen.width / propX); int height = (int)(Screen.height / propY); int startX = (int)(Screen.width / 2 - width / 2); int startY = (int)(Screen.height / 2 - height / 2);

Hallo, es gibt etwas Neues vom Projekt. Bisher hatte ich nur eine Bevölkerungsgruppe, die Siedler. Alle Gebäude und Einrichtungen wurden von Siedlern bedient. Die Ausbaustufen der Häuser beinhalteten auch nur eine größere Anzahl von Siedlern. Ziel war es somit nur eine ausreichende Anzahl von Siedlern in der Stadt/Dorf zu haben. Durch die unterschiedlichen Bevölkerungsgruppen entsteht jetzt eine größere Dynamik. So besiedelt dann nach einem Aufstieg der Unterkünfte nur die nächste Bevölkerungsgruppe diese Unterkunft. Die vorhergehende Gruppe muss dann ausziehen. Desweiteren werden dann die Produktionsgebäude von unterschiedlichen Bevölkerungsgruppen bedient. So wird es neben den Siedlern dann Bauer, Arbeiter/Handwerker, Bürger und Gelehrte geben. Als Aufstiegsvoraussetzungen wird neben den Verschönerungen dann auch Bildung und Kultur geben.

Hallo, Ich wünsche euch allen, 12 Monate Gesundheit, 52 Wochen Glück, 365 Tage ohne Stress, 8784 Stunden Liebe, 527040 Minuten Freude, 31622400 Sekunden Programmieren ohne Bug, In diesem Sinne Frohe Weinachten.⛄ Gruß Jog

Hier ist noch ein älteres Projekt basierend auf Raycast:

Vielen Dank für den Gedankenanstoß in Sachen Maskieren. Ich habe es mit einer Maske, die die in einer coroutine skaliert wird, umgesetzt. Eine Maske hat den Vorteil, dass ich nur eine einzige, unabhängig von der Farbe des Blocks, benötige. Nun entspricht der visuelle Effekt genau meinen Vorstellungen, also dem Original.

Da mir das mit dem Highscoremodus zu aufwändig ist, habe ich diesen durch ein Erfolgssystem ersetzt. Hier fünf der zu erreichenden Erfolge. Es kommen noch weitere dazu.

Hallo, irgendwann muss man loslassen. Mein kleines Siedlerspiel ist jetzt final. Ich hoffe ich habe die meisten Bugs gefunden und beseitigt. Jedenfalls stehen dem Spieler jetzt acht Missionen zur Verfügung in denen er seine Dörfer und Städte aufbauen und weiter entwickeln lassen kann. Ein Sandkastenmodus steht noch nicht zur Verfügung. Den werde ich aber noch nachschieben. Hier der Link zum Download der Version 1.0.0: http://www.pchobbyspieleschmiede.de/besiedlung/OrfayasBesiedlung_1.0.0.rar

Ich wünsche euch ein schönes Osterfest. In diesem Zusammenhang habe ich ein kleines Spielprojekt erstellt. Der Osterhase hoppelt durch die Stadt, sucht eifrig nach den Eiern matt. Doch überall sind Absperrungen, die seine Suche nur noch erschweren. Er hüpft um Zäune, springt durch Türen, versucht verzweifelt, Eier zu erspüren. Doch all sein Suchen ist vergeblich, die Eier scheinen unsichtbar, verschwiegen. Doch plötzlich, ach was ist das dort? Ein kleines Ei, versteckt am Ort. Der Osterhase ist voller Freud', hat doch noch ein Ei gefunden heut'. In diesem kleinen Knobelspiel müsst ihr dem Osterhasen helfen, alle in den Level verteilten Eier einzusammeln. Es erwarten euch 18 kleine Level, die teilweise zum Knobeln einladen: Hier der Downloadlink: Easter Adventure

Korrekt! Aber du kannst Typen eben nicht nur über generische Parameter kommunizieren, sondern auch über einen normalen System.Type-Parameter. Statt public void Foo<T>() machst du public void Foo(System.Type type) Du kannst generische Parameter auch problemlos mit typeof() zu einem System.Type-Objekt umwandeln. So als Beispiel: public bool Foo<T>(System.Type type) { return typeof(t) == type; } Das gibt dann true zurück, wenn man das so aufruft: Foo<Light>(typeof(Light)) // oder Foo<Light>(GetComponent<Light>().GetType()) Umgekehrt braucht man halt leider Reflection und sollte das vermeiden. Aber man kann oft von der anderen Seite ankommen, z.B. so: class MyGenericClass<T> { public System.Type GenericType => typeof(T); } Objekte dieser Klasse geben die mit der Property "GenericType" den Typ zurück, den du beim Erstellen für T übergeben hast: var thing = new MyGenericClass<Light>(); Debug.Log(thing.GenericType.Name); // "Light" Damit geht eine ganze Menge. Du könntest zum Beispiel beim Start alle deine Objekte laden und sie in ein Dictionary packen. Das Dictionary kann so aussehen: private Dictionary<System.Type, List<MyGenericClass<>> genericClassObjectsByGenericType = new Dictionary<...>(); Und dann lädst du da alle geladenen Objekte rein und sortierst sie nach ihrem generischen Typ: foreach (var loadedObject in allLoadedObjects) { var type = loadedObject.GenericType; List<MyGenericClass<>> list; if (genericClassObjectByType.TryGetValue(type, out list)) { list.Add(loadedObject); } else { list = new List<MyGenericClass<>>(); list.Add(loadedObject); genericClassObjectByType.Add(type, list); } } Und wenn du dann alle Objekte eines bestimmten generischen Type haben willst, holst du sie dir einfach aus dem Dictionary: public List<MyGenericClass<>> GetAllObjectsForType(System.Type type) { return genericClassObjectsByType[type]; } Da fehlt noch die Ausnahmebehandlung, falls der Typ nicht gefunden wird. Und ich hab das jetzt so runtergetippt, kann sein dass die Syntax mit <> nicht ganz richtig verwendet wird. Aber ich hoffe, die Idee ist einigermaßen klar. Ja schon, aber eine Datenstruktur wachsen zu lassen ist besserer Stil als ein switch-case, das ständig erweitert werden muss. Vor allem, weil du bei einem Dictionary einfach mit der Schleife über alle Typen gehen kannst (siehe oben), anstatt deinen switch-case-Code jedes Mal anzufassen.

Moin! Dafür, dass das gar nicht so einfach passieren dürfte, habe ich dieses Problem, dass beim zweiten Mal Laden etwas anders ist als beim ersten Mal, schon echt oft gesehen. Hast du irgendwo DontDestroyOnLoad drin, z.B. in deinem Spawn- und Endpunkt-Scripts oder so?

Hallo, ein paar Neuigkeiten zu meinem Aufbauspiel Orfayas Besiedlung. Insgesamt sind es acht Mission geworden. Dazu werde ich noch zwei Freispielmissionen zur Verfügung stellen. Es wird jetzt nicht nur eine Bevölkerungsschicht geben. Neben den Siedlern gibt es Bauern, Arbeiter und Gelehrte. Die Gebäude, die der Spieler errichtet, werden unterschiedliche Gruppen von Bewohnern benötigen. So benötigt z.B. eine Kartoffelfarm Bauern und eine Kohlemine Arbeiter. Der Spieler muss für eine Gleichgewicht sorgen, damit alle Gebäude mit den benötigten Bewohnern versorgt werden. Das UI habe ich diesbezüglich überarbeitet. Somit kann der Spieler jederzeit sehen wie viele Siedler oder Arbeiter er aktuell hat. Hier ist der Download zur Version 0.7.0.: https://www.pchobbyspieleschmiede.de/besiedlung/BSO_0.7.0.rar Discord: https://discord.gg/PHZFBptfxJ In dieser Version sind es nur sieben Missionen, die spielbar sind. Die einzelnen Missionen sind auch noch nicht komplett fehlerfrei. Vom Gameplay her schon, aber ggf. sind noch ein paar Fehler im grafischen Aufbau vorhanden. Die werde ich aber noch mal konkret überarbeiten, wenn ich alle Missionen im Spiel habe.

Moin! Ich bin mir nicht ganz sicher mit "teilen sich dasselbe Material" meinst. Anhand der folgenden Fragen vermute ich, du meinst, dass da eine fortlaufende Textur zu sehen ist, die sich über mehrere Tiles erstreckt? Der Ansatz mit dem Mesh könnte theoretisch funktionieren, aber ich stelle mir das schwierig vor, das performant zu halten. Ich denke, der bessere Weg sind World Space-Texturkoordinaten. Shader haben ja Koordinaten, mit denen sie das Pixel der Textur finden, das sie an eine gegebene Stelle rendern wollen. Da das für die meisten Fälle Sinn ergibt, nehmen die meisten Shader dafür die UV-Map des 3D-Modells. Ein 2D-Objekt ist hierbei auch nur ein flaches 3D-Modell. Jedenfalls muss man dabei aber nicht bleiben - man kann den Shader beliebige Zahlen verwenden, nachschauen oder ausrechnen lassen, um diese als Texturkoordinaten zu verwenden. So kannst du z.B. auch einfach die World Space-Koordinate eines Pixels nehmen und diese als Textur-Koordinate nutzen. Ist zwar 3D, aber hier kannst du dir das mal ansehen: Wie du siehst, ist die Textur immer an derselben Stelle der Welt und nicht, wie sonst, des Objekts. Wenn er hier den Würfel kopiert und die Kopie neben das Original packt, dann passen die beiden Würfel direkt aneinander. Mit dieser Technik kannst du deine Tiles völlig beliebig in die Welt klatschen, und die Textur ist immer gleich. Wenn du dir mal deinen zweiten Screenshot genauer ansiehst, siehst du auch, dass das so gemacht sein dürfte. Denn die Textur wiederholt sich nach 16-order-so Tiles: Also, lange Rede, kurzer Sinn: Baue dir oder finde einen Sprite Shader mit World Space-Texturkoordinaten.

Ja ...aber jetzt verstehe ich deine Problematik besser und verstehe deinen Gedankengang und muss dir Recht geben. Es ist eine Überlegung wert.....🙄

Naja, "sichtbar" ist eine der Arten, in der man in einer Szene eine Rolle erfüllen kann. Eine unsichtbare Wand, um den Spieler daran zu hindern irgendwo lang zu hüpfen, oder eine AudioSource, aus der Windgeräusche kommen, dürfen genauso in die Szene. Aber davon abgesehen: Genau. Nö. Ein Objekt gehört niemals einem anderen Objekt. Wir lassen Structs da gerade mal außen vor, aber Objekte sind auf dem "Heap", einer Datenstruktur, die dein Spiel im Arbeitsspeicher anlegt. Und die ist genau so organisiert, wie der Name suggeriert: Es ist ein "Haufen". Da sind einfach alle Objekte draufgeschmissen und fertig. Jeder kann dein Objekt referenzieren, jeder kann damit arbeiten. Das einzige, was hier einschränkend wirkt, ist die Kontrolle über die Referenz. Wenn irgendein Code nicht weiß, an welcher Speicheradresse dein Objekt ist, dann kann er es auch nicht finden. Sobald du die Referenz aber hast, kann dein Code alles mit dem Objekt tun, was man eben so damit tun kann. Auch, wenn das Objekt, dass dein Einwohner-Objekt erzeugt hat, aufhört zu existieren, ist das egal. So eine Art Verbindung zwischen einem Objekt und wo es herkommt, oder überall schonmal benutzt wurde, gibt es einfach nicht.

Evtl. bin ich ja auf nem falschen Weg, aber in ActivatePicture werden die 9 GameObjects "bildTeil0" bis "bildTeil8" privat (weil nicht public) declariert. Daher kannst Du doch eigendlich nichts im Editor zuweisen und dann bleiben die GOs leer.

Also ich sehe hier mehrere kritische Fehler. Erst mal: Du solltest nicht jedes Update den RPC call machen. Das nicht gut, außer willst nur weniger Spieler supporten und du denkst nicht so an Performance. Check vorher mal den Delta Wert bzw, ob die neuen und alten Werte nicht dasselbe sind (z.b. oldHorizontal != horizontal), dann MovementServerRpc ausführen. Zweitens: Also MovementServerRpc, gerade sieht es noch ok aus, aber ich würde NIEMALS die Werte was der Client schicken kann, weiter verwenden. Da könnte theoretisch auch 1000f stehen statt 1f, wenn man das gehackt bekommt. Da du das in Vector3 packst könnte da halt ungewollte Werte stehen. Ich wette mit dir, dass ich bei dir bereits Cheat Engine verwenden könnte ^^. Am besten tut man das so. Du schaust ob horizontal / vertical inputs -1 oder 1 sind. Erstens sendest du hier einmal über das Netzwerk und nicht mehrmals. Spart man schonmal minimal Performance. Beim GetAxis steigt ja float von 0 auf 1 also wird mehrmals gesendet. Das ist aber jetzt optional udn nicht so wichtig. Ist nur ein Tip am Rande. Zweitens dann noch clampen auf -1 und 1 auf dem Server. Von da aus kannst du sagen ja möchte nach vorn oder nach hinten. Was auch immer. Den Rest hast schonmal gut gemacht. Das mit nextMove ist schon mal eine simple Lösung kann man machen. Ich benutze das auch so ähnlich, wenn ich lerpe oder smoothe Bewegung einbaue (z.B. schwebende Autos, Raumschiffe usw.). Allerdings reicht das ja noch nicht aus. Die Bewegung muss solange ausgeführt werden bis neue Inputs reinkommen. Also ruhig nextMove = Vector3.zero; raus nehmen. Bei Source Engine z.B. hab ich gemerkt, dass die Spieler sich auch solange bewegen bis neue Inputs kommen. Sollte das Spiel mal einfrieren für paar Sekunden und du hast in der Zeit bereits losgelassen, läuft man aber im Spiel (auf dem Server) dennoch immer weiter. Ich denke mal das ist bei vielen Spielen so. FixedUpdate sollte in dem Fall nur auf dem Server möglich sein. Wie wird es denn auf dem Clients synchronisiert?

Also wörtlich übersetzt sagt dir Unity, dass die Timestamp Werte nicht wie erwartet sind und dass das Video höchstwahrscheinlich nicht richtig abgespielt wird. Wenn ich es richtig sehe, müsste die Meldung gelb sein und nicht rot. Also könnte das Video trotzdem laufen. Wie auch immer. Beim Umwandeln nach H.264 ist etwas schief gelaufen. Es könnte sein, dass Handbreak noch ein paar Einstellungsmöglichkeiten hat, die du probieren kannst. Es kann aber auch sein, dass man nur schlecht oder gar nicht von H.265 nach H.264 umwandeln kann. Es ist ja oft so, dass neuere Versionen irgendwelche Datenformate nicht zurück gewandelt werden könne, weil in ihnen Infos drin sind, die bei alten Formaten einfach nicht berücksichtigt werden. Ich würde an deiner Stelle mal ein Videobearbeitungsprogramm wie z.B. Premiere versuchen. Solche Programme müssten in der Lage sein alles zu wandeln bzw neu zu erstellen. Wenn aber das VR an sich eine Sache ist, die in H.264 nicht existiert, dann wird's nix! Versuch macht kluch!

Ohh...ich hoffe das funktioniert mal bei mir, wenn ich für unterschiedliche Zielgeräte erstellen will Hast du das mal dazu gelesen -> https://forum.unity.com/threads/unityframework-bitcode-error-with-google-mobile-ads.1371879/ Nur ein Vorschlag...vielleicht bringt es dir was?

Layer scheinen mir schon sinnvoll dafür, damit du die Animationen kombinieren kannst. Man könnte jetzt natürlich überlegen, für jeden der Raketenwerfer ein eigenes Objekt mit eigenem Animator zu machen, aber Layer sollten auch gehen. Davon unabhängig ist Macanim aber schon dafür gedacht, dass du Parameter benutzt statt Play(). Dann kannst du auch vernünftig Transitionen zur Laufzeit debuggen.

Hallo, hier ein Zeitraffervideo vom Bau der Burg des Barons. Das Modell ist noch nicht fertig. Im Augenblick werden Erdlöcher ausgehoben, Marmor zum Bauort getragen und dann von den entsprechenden Arbeitern die Teile der Burg errichtet.

Das Buch von Rheinwerkverlag habe auch, fand es allerdings nicht wirklich spannend. https://learn.unity.com/pathway/junior-programmer fand ich allerdings recht hilfreich. Das fängt praktisch bei Null an, arbeitet sich durch diverse Themen und beinhaltet die ganzen Assets.

Empfehle ich dir nicht...sicher hat Unity so seine Eigenheiten, aber es ist für dich eine Plattform auf dem du aufbauen kannst. Erstelle doch einfach mal ein 3D Objekt und bewege es mit den Tasten Dann bewegst du es z.B. über Sin/Cos Dann fängst du an mit Arrays und erstellst GameObjekte die in diesem Array gespeichert werden Dann gehst du das Array durch und löscht das Objekt aus dem "Spielfeld" usw... So lernst du C# und gleichzeitig mit Unity umzugehen... ist meine Meinung...ich empfehle jedem Anfänger mal Snake zu programmieren. Du hast da so ziemlich alles was ein Spiel ausmacht. Ein Spielfeld...Futter für die Schlange...die Schlange die sich bewegt. Mache dir Gedanken wie der Computer es schafft die Schlange zu zeichnen und zu bewegen....einfach mal anfangen.

Das große Problem am "Programmieren lernen mit Unity" ist, dass du dabei 2 Dinge lernen musst/willst. Das Eine ist das Programmieren selbst. Also quasi eine Sprache zu erlernen. Aber eben nicht nur die Vokabeln sondern auch die richtige Anwendung. Das Andere ist die Besonderheit in Unity, die Objekte, Module und Funktionen zu steuern und Informationen über sie abzufragen. Wenn man sich Tutorials für Unity anschaut, dann wird mehr oder weniger das Können der Programmiersprache vorraus gesetzt und es geht meist nur um die Besonderheiten in Unity. Diese sind zwar alle mit der Programmiersprache verzahnt, aber sie sind eben Obendrauf! Wenn man das Programmieren nicht verstanden hat, kommt man mit den Besonderheiten in Unity nicht weit. Deswegen würde ich empfehlen entweder erstmal nur die Grundlagen des Programmierens zu lernen (unabhängig von Unity). Oder aber mit Unity zusammen, aber dann (egal ob das Projekt einem gefällt oder nicht) nach jedem Schritt zu schauen, ob man verstanden hat was da passiert. Einfach mal eine ähnliches Szenario aufbauen und das Gelernte gleich anwenden. Auch wenn es erst einmal sinnlos erscheint. Schritt für Schritt! Aber das musst du machen! Es einfach nur abtippen um dann zu sehen, dass es bei dir genauso funktioniert reicht nicht. Du musst es zerlegen und analysieren. Es wird dann bestimmt irgendwann Klick machen. Und dann ist alles klar! Es wird immer Dinge geben, die du erst mal nicht verstehst. Aber du wirst mit jedem Mal schneller zur Lösung kommen. Und dann kannst du das Wissen auf alles was du willst anwenden. Du bist bestimmt nicht dumm. Es hat einfach nur noch nicht "klick" gemacht!

Du brauchst eine Bedingung um die Animation zu beenden bzw. zu stoppen. Entweder setzt du einen Haken bei "Has Exit Time" oder du erstellst einen Parameter und verknüpfst diesen mit der "Animation". Was willst du den eigentlich genau machen? Edit: ich würde Warnungen nie mit einer Präprozessor-Direktive deaktivieren...es gibt schon einen Grund für die Warnung und außerdem ist das nicht schön

Hallo, Einen Hab ich noch 😉 LateUpdate Wird zwar oft nicht verwendet oder vergessen dass es die überhaut gibt, ist aber in machen Situationen wichtig. Die Methode LateUpdate() wird aufgerufen, nachdem alle Update-Funktionen aufgerufen wurden, aber noch vor dem Rendern. Dies ist nützlich, um die Skriptausführung zu ordnen. Zum Beispiel sollte eine Verfolgerkamera, in der LateUpdate() Methode implementiert sein, da Objekte nachverfolgt werden, die möglicherweise in Update oder FixedUpdate Funktionen bewegt wurden. Dies sollte sicherstellen dass, alle verfolgten Objekte bewegt wurden, bevor die Kamera aktualisiert wird, um ein „Nachspringen“ der Kamera zu vermeiden. Gruß Jog

Falls Englisch für dich okay ist... http://blog.13pixels.de/2019/what-exactly-is-fixedupdate/ FixedUpdate ist das MonoBehaviour-Event, mit dem du wirklich Framerate-unabhängig wirst. In einigen Fällen reicht Update auch, z.B. weil es um einen linearen Ablauf geht oder der Unterschied nicht für das Spiel entscheidend ist. Wenn z.B. eine Knopf-Animation bei unterschiedlicher Framerate minimal anders aussieht, ist das meistens kein Beinbruch. Update hat allerdings dieselbe Frequenz, auf der das Spiel rendert. FixedUpdate nicht. Du kannst mehrere Updates (und damit auch Renders) zwischen zwei FixedUpdates oder mehrere FixedUpdates zwischen zwei Updates haben. Wenn du merkst, dass du FixedUpdate nutzen willst, dann musst du mit etwas Code das Stottern beseitigen. Wenn du dir mal den Inspektor der Rigidbody-Komponente anschaust, siehtst du da die Eigenschaft "Interpolate". Die macht genau das, weil Rigidbodys mit der Physik-Engine auf FixedUpdate laufen, aber dann bitte auch nicht stottern sollen. In meinem Artikel oben hab ich ein Script verlinkt, das das für beliebige Objekte machen kann.

Über die Feiertage wollte ich mich mal wieder intensiv mit meinem Problem der Bewegung eines EndBosses beschäftigen, jedoch komme ich einfach nicht weiter. Ich scheitere schon ganz am Anfang und habe keine Lösung gefunden. Ich möchte den Endgegner in das Bild reinfliegen lassen, aber nicht an einem Stück. Es besteht aus drei Teilen (zwei Flügel und dem Rumpf) Wenn es sich zusammengesetzt hat, dann soll die eigentlich Bewegung beginnen und der Endgegner über das Bild fliegen. Ich bekomme es jedoch nicht hin die Flügel richtig zu animieren. Es wird immer nur eine Animation ausgeführt. Entweder fliegen beide Flügel von Rechts in das Bild oder von Links, aber der eine von Rechts kommen und der andere von Links. Die Hierarchie vom Boss sieht so aus. Und jeder Flügel hat eine Animation und nur einen Animationscontroller. Hier ist ein Versuch zu sehen das alles über Layer zu machen. Hat jedoch nicht funktioniert. Ich kann beide Animationen nicht gleichzeitig ausführen. Wenn einer einen Tipp hat wie man das macht, dass wäre wirklich toll.... Danke und viele Grüße Gombolo...

Hallo zusammen, ich freue mich, dass ich dieses Forum gefunden habe. Ich heiße Ago, bin 39 Jahre alt und lebe in München. Meine Muttersprache ist Bosnisch. Ich bin in Deutschland geboren bzw. aufgewachsen und arbeite seit 2004 bei einer Münchner Polizeidienststelle als Schreibkraft/Angestellter. Durch meinen Beruf bin ich sehr fit in der neuen deutschen Rechtschreibung und beherrsche das 10-Finger-System, was beim Programmieren natürlich auch sehr hilfreich ist. Das Programmieren habe ich seit einigen Monaten entdeckt. Mein Vater ist Rentner und interessiert sich ebenfalls für das Programmieren, hat viele Bücher und belegt in Udemy diverse Kurse. Im Februar dieses Jahres kam es dazu, dass ich plötzlich Panikattacken bekommen habe. Ich war dann zwei Wochen krankgeschrieben. In dieser Zeit war ich bei meinen Eltern, um nicht allein zu sein. Und um auf andere Gedanken zu kommen, habe ich mir gedacht, dass ich mal in die Welt des Programmierens eintauche, und seitdem hat es mich erwischt. 🙂 Meine Panikattacken sind seitdem auch verschwunden und bis jetzt – zum Glück – nicht mehr aufgetaucht. Ich hatte dann ein paar Monate nicht geübt, sodass ich wieder von vorn anfangen musste. Im Oktober 2022 habe ich mir einen Wunsch erfüllt und viel Geld dafür gespart/investiert: Ich habe mir einen nagelneuen Gaming PC mit allem Drum und Dran gekauft. Und seitdem übe ich täglich (!) C# bzw. in Unity Spieleprogrammierung, da es einfach mit dem neuen Computer viel mehr Spaß macht und es mit dem großen Bildschirm ergonomischer ist. Wenn ich mal Lust habe, zocke ich natürlich auch, das ist ja klar. 🙂 Mir ist nun auch bewusst geworden, wie viel Arbeit und Energie eigentlich dahintersteckt, um ein Spiel zu programmieren. Ich finde das Programmieren auch deswegen super, weil man auch logisch nachdenken muss. Und das ist natürlich auch ein gutes Training für unser Gehirn bzw. für unser Gedächtnis. Wenn der Code dann funktioniert und z. B. der Player das macht, was man wollte, werden natürlich auch Endorphine ausgeschüttet und man ist dann noch motivierter. 🙂 Ich bin mega begeistert von der Spielengine Unity und finde es toll, dass es so viele Tutorials diesbezüglich gibt und jeder sich gegenseitig unterstützt. An dieser Stelle möchte ich auch an euch ein herzliches Dankeschön aussprechen, dass ihr euch gegenseitig helft. Zurzeit arbeite ich das Buch „Einstieg in Unity, 2D- und 3D-Spiele entwickeln“ (Autor Thomas Theis) Schritt für Schritt durch, das ich sehr gut finde und jedem empfehlen kann. Eine neue Auflage ist laut dem Autor in Planung und kommt, denke ich, irgendwann im Jahr 2023 raus. Was ich auch zum Nachschlagen empfehlen kann, ist das Buch „Spiele entwickeln mit Unity 5“ vom Autor Carsten Seifert. Es gibt manche Sachen, die ich derzeit noch nicht so ganz verstehe, z. B., was es bedeutet, wenn eine Variable static ist oder was „static“ generell bedeutet, aber ich denke, dass es mit der Zeit dann irgendwann klick machen wird. Mein Ziel ist es, wie bei vielen anderen sicher auch, ein eigenes Spiel zu entwickeln, ein Rollenspiel wäre natürlich der Hammer. Da ich hilfsbereit bin und euch auch gerne unterstützen möchte, werde ich das natürlich machen, falls ich eine Frage sehe, die ich, wenn meine Programmierskills ausreichen, beantworten werde. Und wer z. B. einen Lektor für Texte benötigt, die in euren Spielen vorkommen, sagt einfach Bescheid und ich werde sie nach Fehlern durchsehen bzw. lektorieren – kostenlos natürlich. Ich wünsche euch allen weiterhin ganz viel Programmierfreude und bleibt weiter an den Tasten bzw. gebt niemals auf! Viele Grüße Ago

Also ich sehe da 2 Wege. Eintweder du gehst davon aus, dass alle Objekte zu Beginn in der obersten Ebene sind, oder sie sind zu Beginn in der untersten Ebene. Es ist ja eine Frage der Verortung. Also wie und wo können Sprites übereinander liegen. Geht es da nur um eine Art Inventory, dann ist es ja leicht zu wissen, welche Sprites an welcher Position liegen. Und wenn sie dann gestackt würden, dann müsste(n) das(die) Sprite(s) im Layer jeweils eins nach unten. Immer nur das Sprite im obersten Layer kann angeklickt werden. Das wäre einfach für den Test und ginge ohne Liste. Wird das oberste Sprite aufgehoben, dann müssten alle da drunterliegenden eine Ebene höher im Layer. Das wäre ein kleiner Befehl (event) für alle Sprites im entsprechenden Fach. Ist es aber irgendwie in einer Spielewelt, wo zufälligerwiese Sprites voreinander liegen würden, dann wird das schon schwieriger, denn jetzt musst du es irgenwie schaffen, diesen Haufen zu gruppieren. Da sehe ich klare Vorteile bei einer oder mehreren Listen, die immer dann da sind, wenn es zu Anhäufungen von Sprites kommt. Was ich aber noch wichtig fände, ist die Tatsache, dass man nicht unendlich viele SortingLayer anlegen muss. Man braucht vielleicht 3 für das Stacken. Das oberste Sprite soll natürlich immer oben gezeichnet sein. Das da drunter dann auch so, dass es optisch direkt unter dem Obersten liegt. Aber alle weiteren Sprites des Stacks können gemeinsam im untersten Layer liege. Ist vollkommen egal, wann welches gezeichnet wird. Nur musst du dann intern wieder eine Liste haben, die die richtige Reihenfolge für alle Sprites darstellt. Und dann ist es wirklich gut, wenn in der Liste das Oberste gelöscht würde und alle anderen nachrutschen. Die jetzt obersten 2 Sprites verschieben sich um einen Layer, fürs optische, und alle weiteren bleiben im untersten Layer. Der Test, welches Sprite denn anklickbar ist, ist ja ganz einfach über die Liste zu ermitteln.

Da bieten sich die Trigger an. Du brauchst also einen oder mehrere Collider, die über der Wiese liegen. Denen gibst du einen Tag, z.B. Grass und stellst den/die Collider auf Trigger. Wenn dein Player da rein läuft, werden Triggerevents gestartet. Die kannst du im Code nutzen. Das OnTgriggerEnter() Event wäre dann dafür da, zu sagen, dass du ab jetzt auf dem Grass bist. Beim verlassen des Triggers, würde OnTriggerExit() aufgerufen werden, was dir sagt, dass du das Gras wieder verlassen hast. https://docs.unity3d.com/ScriptReference/Collider.html Schau beim Link und scroll runter zu den Messages. Da findest du alles Nötige.

Hallo, meine Überarbeitungen jetzt nochmal in einem kleinen Video beschrieben.

Jaaa, gib her, da kann man ja nicht nein sagen

Moin! ScriptableObjects sind genau dazu da, eine Identität und oder Daten zu haben, die im Editor eingestellt und dann in den Build mitgenommen werden. Wenn man das Konzept ein bisschen streckt, dann kann man auch dynamische Daten drin haben. Aber auch das ist nur sinnvoll, wenn man auch die Identität nutzt. Falls das mit der "Identität" nicht so klar ist, so als Beispiel: Du kannst ein komplett leeres ScriptableObject nutzen, um Spielfiguren in Teams einzuteilen. Zwei Figuren, die dasselbe "Team-SO" referenzieren, sind im selben Team und machen sich gegenseitig keinen Schaden. Das meine ich mit Identität. Wenn ich jetzt aber so Felder wie "iD" und "StructurActual" sehe, dann nehme ich an, dass du hier ein Laufzeit-Objekt repräsentieren willst. Also ein Objekt, dass der Spieler während des Spiels erstellt. Zum Beispiel, indem er es im Shop kauft oder so. Das geht zwar, macht aber so seine Problemchen. Da du aber wiederum Felder wie "Description" hast, die recht eindeutig Daten beinhalten, die du im Editor eingibst, sind ScriptableObjects schon gut. Ich würde empfehlen, das aufzuteilen. Eine ScriptableObject-Klasse beinhaltet die statischen Daten, die du im Editor eingibst: public class ModuleInfo : ScriptableObject { public string name; public string description; public int maxIntegrity; } Und eine nicht-SO-Klasse kannst du zur Laufzeit instanziieren, um Laufzeit-Objekte zu repräsentieren: class Module { public readonly ModuleInfo moduleInfo; public int integrity; } Wie du siehst, referenziert es ein ModuleInfo-Objekt, das die statischen Daten beinhaltet. So kannst du auch wunderbar beliebig viele Triebwerke (also gleichartige Module) erlauben. Das ist wäre immer ein bisschen schwer, wenn du alle potentiellen Module im Voraus im Editor anlegen müsstest.

Hallo Schau dir mal das hier an: https://assetstore.unity.com/?q=localization&orderBy=1 Das sind auch kostenlose assets dabei und wenn du es selber schreiben willst, kannst du die Begriffe dort für google verwenden. Ich hatte mir selber was geschrieben und vorher 12Localization genutzt (und war damit eigentlich glücklich) Christoph

Klasse, hat geklappt. Ich sehe (und verstehe) das Problem jetzt auch. Ich schau mal, ob mir da was einfällt.

Moin! Höhö Also zuerst mal kannst du dir den Umweg über den Vector3 sparen. Du wandelst ein Quaterion in ein Vector3 um, nur um es dann wieder in das ursprüngliche Quaternion umzuwandeln. Vielleicht hast du das ja zur Veranschaulichung gemacht... aber nehmen wir es mal weg: Quaternion rotation = GetComponentInParent<Transform>().localRotation; transform.rotation = rotation; Und dann verkürzen wir das: transform.rotation = GetComponentInParent<Transform>().localRotation; Dann sehen wir, dass du die lokale Rotation Rotation des Parents nimmst, und sie als globale Rotation übernimmst. Ich vermute, dass das so nicht intendiert ist. Also eher: transform.rotation = transform.parent.rotation;

Kann es sein, dass du in deinem Projekt irgendwelche Sonderzeichen oder Umlaute nutzt, die nicht UTF8-konform sind? Also bei Variablennamen, Klassen/Scriptnamen oder Objektnamen. Ist halt Apple-Scheiße! Glaub mal nicht, dass die mit erweiterten Zeichensätzen richtig umgehen können.

Gehste Window -> Packagemanager Wenn der auf ist, dann oben wo wahrscheinlich Packages:In Project steht, mal drauf klicken und dann Unity Registry auswählen. Jetzt sollten alle möglichen Packages zu sehen sein. Inputsystem suchen, anklicken und dann unten rechts auf Install klicken.

Das ist genau das Problem. Auch der Server sollte keine ewig wachsenden Positionswerte nutzen. Und der Server hat auch keinen Grund, irgendetwas herum zu schieben, weil Dinge auf dem Server aussehen können wie sie wollen. Sagen wir also einfach mal, die Welt sieht auf dem Server so aus: Wenn einer oben aus A rausfliegt, kommt er unten bei C wieder heraus. Ohne Wenn und Aber. Auf dem Server ist die Position eines Spielers damit immer zwischen (0, 0) und (2, 2). Natürlich wird deine Platte nicht 1x1 groß sein, sondern irgendwie größer, aber du verstehst schon. Wenn dein Client und dein Server miteinander kommunizieren, dann solltest du dafür ein Protokoll haben. Klingt krasser als es ist - du definierst nur halt, auf welche Art kommuniziert wird. In diesem Fall heißt das, dass du einmal festlegst, in welchem Format die Positionen übertragen werden. Ich würde dazu tendieren, nur die Serverposition zu nutzen. Ein Client rechnet also aus, wo auf diesem Grid sein Raumschiff ist, und sendet es dem Server. Der Server sendet ebenfalls nur die Position auf diesem Grid an die Clients, und die rechnen dann aus, wo auf dem Fake-Boden das Raumschiff jetzt genau hingehört. Wenn ein Raumschiff jetzt auf (0.1, 1.9) ist, also ganz weit oben links, dann würde der Client ja Feld A nach unten rechts packen wollen: Du würdest also in Wirklichkeit das Schiff auf (1.1, 0.9) platzieren. Die "reale" Position ist aber weiterhin (0.1, 1.9). Von einem zum anderen und wieder zurück rechnen kann sehr anstrengend sein. Ich würde daher immer nur in eine Richtung rechnen. Du nimmst also einfach ein "reale" Position in einem Vektor: private Vector2 realPlanetaryPosition; Daraus kannst du dann sowohl die Anordnung der Felder als auch die Position des GameObjects ziehen. Wenn dein Spieler in irgendeine Richtung fliegt, wendest du die Geschwindigkeit auf diesen Vektor an und rechnest dann diese beiden Sachen (Anordnung und Transform.position) neu aus. Anschließend sendest du direkt diesen Wert an den Server. Oder auch nicht. Je nach dem, wie autoritär dein Server ist. Wenn dann der Server eine Position eines Raumschiffs an den Client schickt, muss dieser diese wieder verarbeiten. Wenn es sich nicht um den Spieler handelt, hat die Position des Raumschiffs ja keinen Einfluss auf die Anordnung der Felder. Aber die "reale" Position muss dann in Abhängigkeit der Feld-Anordnung in eine Transform.position umgerechnet werden. Ich hoffe, das hilft ein bisschen.

Ich verlinke Mal auf meine Antwort in einem anderen Thread: Meine Variable "velocity" ist ein Feld, also eine Variable, die Teil des Objekts ist. Deine Variable "movedirection" ist eine lokale Variable, die aufhört zu existieren, sobald die Methode (also Update) durchgelaufen ist. Es wird daher kein Wert von diesem Update in das nächste übernommen.