Leaderboard

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

Hallo, ich arbeite an einem neuen Spielprojekt. Titel: Ghostly Heist Es geht um einen "Einbrecher", der Sicherheitssysteme überprüfen soll. Dafür muss er in die entsprechenden Gebäude einsteigen und die Wertsache versuchen zu entwenden. Natürlich laufen dort Sicherheitsleute umher, denen er nicht begegnen darf. Diese haben einen Sichtbereich, der in Form eines Kegels angezeigt wird. Im Augenblick steht ein Level spielbar zur Verfügung. Damit es mehr Motivation gibt den Level evtl. mehrmals zu spielen habe ich vier unterschiedliche Spielmodi vorgesehen. 1) Normaler Modus (einfach) 2) Meisterdieb (schwer) 3) Zeitmodus (in einer vorgegebenen Zeit muss der Level geschafft werden) 4) Highscoremodus (die schnellste Zeit führt den Highscore an) Die Modi 1-3 funktionieren schon. Der Highscoremodus im Moment noch nicht. Hier könnt ihr euch einen Überblick über die Version 0.2.0 verschaffen: [url='http://www.pchobbyspieleschmiede.de/gestern/GhostlyHeist_0.2.0.rar']Ghostly heist 0.2.0[/url]

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.

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.

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

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^^