Sascha

meinInput.text = meineStringVariable; Wenn rechts vom = der Name einer Variablen steht, dann wird der Wert dieser Variablen genommen und auf der linken Seite zugewiesen.

Danke für die Infos, aber ich sehe da irgendwie keine Frage, auf die ich antworten könnte. Das einzige, was ich raten könnte: Den Inhalt von Input-Feldern kannste mit ".text = wasauchimmer;" ändern.

Ne, müssen tust du das nicht. Das hat malzbie gemacht, damit der Code, um den es eigentlich geht, im Tutorial nicht unnötig aufgebläht wird.

Dieses Script ist nur ein Beispiel von malzbie. Wie es aussieht, hängt davon ab, wie dein Spiel funktioniert.

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

Moin! Muss das unbedingt mit Vererbung gemacht werden? Komposition ist ja meistens n bisschen besser. Dinge vorher laden und dann die ganze Zeit bereit halten ist nur sinnvoll, wenn du ansonsten spürbare Ladezeiten hast (Spiel bleibt ne halbe Sekunde stehen wenn man das Menü öffnet) oder auf seinen Garbage aufpassen muss. In deinem Fall hast du solche Bedenken wohl eher weniger, also ist es schon vernünftig, die Objekte erst dann zu erstellen, wenn du sie auch brauchst.

Ach so... da hast du was verwechselt. Wenn man das Lighting in der Scene View ausstellt, dann kriegt man kein Directional Light, sondern so ein komisches Ambient Light, das alles je nach Winkel zur Kamera gleichmäßig anstrahlt. Das sollte wirklich heller sein, als es bei dir aussieht. Ich kann mir vorstellen, dass das je nach Render Pipeline einfach bugged ist. Oder einfach in deiner Editor-Version. Die entwickeln halt seit zu vielen Jahren immerzu mehr als sie QA-en können...

Moin! Du hast halt den Knopf, mit dem man das Licht an macht, sogar rot markiert...?

Moin und willkommen! Gimp geht immer. Das ist so das Open Source-Bildbearbeitungsprogramm. Alternativ kann man heutzutage auch den Grease Pencil in Blender benutzen, aber da hab ich bisher immer nur Flat bzw. Cell Shading gesehen. Farbverläufe sind da nicht so. Ansonsten kenne ich nichts wirklich mächtiges, was nichts kostet. Photoshop ist natürlich brutal teuer, geht aber auch günstiger. Wenn du ein iPad hast, kauf dir Procreate. Das ist so der heiße Scheiß unter Digital Artists dieser Tage. Wenn man jetzt aber kein iPad hat, würd ich dafür jetzt aber keins kaufen. Clip Studio Paint ist unter Zeichnern auf dem PC recht beliebt. Aber ohne Grafiktablet lohnt sich das eher weniger. Generell ist ohne Grafiktablet nicht viel los, wenn du zeichnen willst. Es gibt ja aber noch andere Stile. Z.B. kann man ja Pixel Art machen. Dafür kenne ich PixelMash, aber mit Gimp wirst du da auch einiges machen können. Sonst ginge auch Vektorgrafik, da kannst du dir z.B. Inkscape anschauen.

frontSprite und backSprite müssen public sein, damit andere Klassen darauf zugreifen können. Wenn du aber mit deiner Setup()-Methode in derselben Klasse sein solltest, brauchst du das nicht.

Groß- und Kleinschreibung ist wichtig. "frontSprite" ist nicht dasselbe wie "FrontSprite". Sobald du das repariert hast, wird der nächste Fehler sein, dass "frontSprite" nicht zugreifbar ist, weil es nicht public ist.

Moin, Die Klasse "PokemonBase" hast du ja vermutlich selber geschrieben. Diese Klasse enthält nichts, das "BackSprite" oder "FrontSprite" heißt. Müsstest du da also reinschreiben.

Ja, DU weißt das, aber für @Alex Greenwood war das vielleicht nicht klar Joa, ist die Größe des Colliders, aber die wird ggf. noch mit der Skalierung des Objekts durch die Transform-Komponente multipliziert. Wenn du wirklich exakte Maße brauchst (und das tut man gar nicht mal so oft...), dann solltest du am besten mit diesen Maßen im 3D-Programm arbeiten und das nur noch importieren. Aber du kannst die absoluten Maße eines Objekts anhand von Renderer.bounds auslesen. Da hast du eie AABB (Axis-Aligned Bounding Box), also den kleinsten möglichen, an den Achsen ausgerichteten ("nicht gedrehten") Quader, der dein 3D-Modell umschließen kann. Da kannste dann die Höhe von auslesen oder so. Identisch zu was?

Muss man sich aber natürlich nicht dran halten. Wenn du ein Sternensystem oder rote Blutkörperchen in der Ader in deiner Szene darstellen willst, dann wäre es irgendwo zwischen irrsinnig und unmöglich, sich daran zu halten. Am Ende musst du dich in deinem System für einen Maßstab entscheiden und konsistent bleiben. Wenn ich mich recht erinnere, waren in Unreal Tournament 99 die Charaktere 84 Einheiten hoch, in Unreal Tournament 3 128, und in Gears of War waren es 100. Solange du innerhalb des Spiels konsistent bleibst, ist es echt egal.

Moinsen! 👋 Mit dem Notebook nach draußen gehen geht super, solange man im richtigen Winkel zur Sonne sitzt