spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn es nur um ein paar hundert Objekte geht, würde ich das schlicht halten. Gib jedem Deiner Objekte ein Kollisionsrechteck mit und prüfe nur bei Bewegung gegen die Rechtecke aller Objekte. Die Objekte würde ich in einem banalen std::vector ablegen, eine Liste (auch eine selbstgebaute) ist in praktisch allen Fällen eine schlechte Idee.

Für sowas ist dann eigentlich Vererbung gedacht. Du erfindest eine Basisklasse, die nur die Methoden und Attribute (in Deinen Worten: Datentypen) hat, die wirklich alle Objekte in Deiner Spielwelt gemeinsam haben. Das sind meist nicht wirklich viele. Ich würde folgendes empfehlen:



Von dieser Klasse könntest Du alle Objekte in Deiner Spielwelt ableiten: Monster, Spieler, Türen, Bäume, wasweißichnoch. Irgendwann kommt der Punkt, an dem man sich mit Ableitungen mehr Aufwand macht als nötig, dann empfehle ich zusätzlich einen komponenten-basierenden Ansatz, aber das ist noch lange hin. Und zurück zum Thema "Kollision": in die Basisklasse würde ich auch die Kollisionsform packen, vorausgesetzt, die allermeisten Deiner Objekte kollidieren auch. Wenn nur ein paar Deiner Objekte kollidieren, dann hat es den Nachteil, dass alle Deine Objekte etwas mit sich herumschleppen, dass die meisten nicht brauchen. In dem Fall bietet sich dann eine Ableitung von einer Schnittstelle "KollidierendesObjekt" an oder das Hinzufügen einer Komponente, die Kollisionsform und Verhalten bei Kollision regelt.

Hier kommen wir aber schon in den Bereich der Software-Architektur, bei dem man sich hervorragend streiten kann. Du wirst also von anderen Leuten evtl. andere Empfehlungen bekommen.

Das stimmt, das klappt so nicht. Die Aufgabe, alle uGaAs anzulegen, hat nicht die uGaA-Klasse. Eine Spielwelt besteht aus Spieler, Monstern, Hindernissen. Wer also sollte die uGaAs anlegen? Richtig: die Spielwelt. In C++ ist es sehr wichtig, sich bei langlebigen Objekten klarzumachen, wem sie gehören. In diesem Fall ganz einfach: der aktuelle Spielablauf hat eine Spielwelt, die Spielwelt hat Spieler, Monster, Hindernisse.

Und das Stichwort "langlebig" besagt auch, was noch an Deiner Überlegung falsch ist. Wie lange leben denn die Hindernisse in Deiner Spielwelt? Meistens so lange wie die Spielwelt selbst. Wenn Du am Anfang eine Spielwelt erstellst, also von Platte lädst oder live mit Hindernissen und dem Spieler bevölkerst, dann werden die BasisObjekte erzeugt. Und am Ende, wenn der Spielablauf fertig ist, wird die Spielwelt gelöscht. Und die Spielwelt räumt dann auch alle Objekte ab. Vielleicht kommen zwischendurch noch neue Objekte hinzu, oder manche Objekte werden vorzeitig gelöscht, aber das ist nebensächlich. Die längste mögliche Lebensdauer ist hier von Interesse. Demzufolge mein Vorschlag:



In Deiner Lösung oben legst Du die Objekte lokal an, sie werden automatisch abgeräumt, wenn der aktuelle Gültigkeitsbereich (also die Funktion Init()) zu Ende ist. Das sind sehr kurzlebige Objekte. Wir brauchen aber langlebige Objekte. Die Spielwelt und die Objekte darin müssen ja viele Frames hintereinander aktiv sein und gezeichnet werden. Also legen wir sie per new an:


Das ist ein Beispiel, also bitte nicht über-interpretieren. In jeder Zeile wird ein neues Objekt des benannten Typs erzeugt, es wird mit den gegebenen Parametern konstruiert (also der Konstruktor aufgerufen) und dann wird der Zeiger des Objekts an die Welt übergeben. An dieser Stelle geht das Objekt in den Besitz der Spielwelt über. Das steht dort nirgends, das kann C++ nicht leisten. Es ist eine Vereinbarung, die Du mit Dir selbst triffst: sobald ich ein Objekt an Spielwelt::AddObjekt() übergeben habe, gehört es nicht mehr mir, sondern der Spielwelt. Und die kümmert sich am Ende auch um die saubere Aufräumung.

Diese Lösung hat übrigens auch den Vorteil, dass der Spieler in seiner Arbeiten()-Funktion die Welt fragen kann, ob denn da ein Hindernis in seiner Wunsch-Bewegung ist. Jedes einzelne UGAA kann nur von sich selbst prüfen, ob eine Kollision mit einem gebenenen Rechteck erfolgt. Nur die Spielwelt kennt alle Objekte und kann demzufolge allgemeine Aussagen darüber treffen, ob eine Bewegung möglich ist.

Bleib dran! Du wirst mit der Zeit - also im Laufe der nächsten Jahre, ein paar Wochen reichen da nicht - ein Gefühl dafür bekommen, wie man die jeweilige Aufgabe in Klassen, Funktionen, Strukturen usw. aufteilt. Man neigt am Anfang eh dazu, nur wenige Klassen zu basteln und die dafür mit Funktionalität vollzustopfen. Ich kenne aber keine Methode, Dich davon abzuhalten... ich glaube, Du wirst es einfach ausprobieren müssen und nach und nach lernen, welche Strategien besser funktionieren als andere.

das wäre übrigens eine schlechte Idee, weil du eigentlich nur auf die Kollision beim letzten Element prüfst, weil du die vorherigen Werte überschreibst