spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Richtig, wir hatten aber gesagt dass die Simulation dann auch selbst Aufgaben einstellen kann.
Wer eine Aufgabe erledigt entscheidet dann der (ich nenns erstmal so) Listener für sich selbst. Das kann Sim oder ein Entity sein, wobei die Sim dann aus einer Aufgabe kleinere machen kann.
Also das war nicht als Datenbus für User Input gedacht.

Ok, das Interface wirkte aber so.

Es ist auch nicht mein Ziel die Arbeit von einem von euch zunichte zu machen. Ich seh das hier gerade nur als dringendste Baustelle im gesamten Code, damit man eben mal eine richtige Basis hat, auf der man aufbauen kann. Ich erwarte nicht, dass mein Vorschlag übernommen wird, aber so wie die Basis im Moment ist, brauchen wir uns über Config, Ringmenü, usw. erstmal keine Gedanken machen.

Jop stimmt. Ich wollte nur nicht dass wir gleich zwei konkurrierende Systeme haben
Du machst das schon.

Ich werde heute abend mal die Projektdateien löschen, wenn ihr sie bei euch behalten wollt, zieht sie vor dem pull raus, fügt sie danach wieder ein und fügt sie zu gitignore hinzu.

Du meinst sln und co?
Die sind mitlerweile sowieso mehr als fehlerhaft. Mach nur

Ich seh gerade einige includen Header in die Source Dateien.
Wollen wir das wirklich so halten? Ich finde das unübersichtlich und include immer alles nötige in den Header, außer es geht nicht wegen zyklischer Abhängigkeiten.

Ich handhabe das so damit ich bei einer Änderung im Header nicht das komplette Projekt neu Compiler muss. Wo es geht -> forward declaration

Zitat von »DeKugelschieber«

Ich seh gerade einige includen Header in die Source Dateien.
Wollen wir das wirklich so halten? Ich finde das unübersichtlich und include immer alles nötige in den Header, außer es geht nicht wegen zyklischer Abhängigkeiten.

Du inkludierst Zeug in die Header, was in den Headern gar nicht gebraucht wird? Wie z.B. Dinge, die nur von der konkreten Implementierung einer Methode benutzt werden? Klingt sehr unschön. Wenn nicht, dann hast Du eh schon gemischte Header/Sources und der Vorschlag von anti-freak macht deutlich mehr Sinn.

Mir egal wie wirs machen. Nur einheitlich.
Und ja ich mache das so da meine Projekte selten über ein paar Sekunden kompilieren. Dafür muss man nicht in zwei Dateien suchen.

Kann heute leider nicht dran teilnehmen. Bis nächste Woche

EDIT:
Hab das grundlegende Entity/World system soweit fertig gestellt. Könnt ihr euch in feature/entities anschauen.
Eine kurze Erklärung dazu:
World ist ein großes Objekt, das alle Entities besitzt. Diese Entities können später auch gerne in verschiedene Listen gespeichert werden, sodass z.B. Entities die gedrawed werden müssen eine eigene Liste haben, usw.
Um eine Entity direkt in der Welt zu erzeugen, empfehle ich die template Methode World::createEntity zu nutzen, weil diese alle nötigen Arbeiten zur Erstellung durchführt. Natürlich kann auch direkt über die Konstruktoren erstellt werden, ist aber wieder mehr Schreibarbeit.
Jede Entity besitzt einen Ptr auf ein World Objekt (dieser kann auch ein nullptr sein, wenn sie in keiner world ist). Damit lässt sich aus den Entities heraus auf die darüber liegende Ebene zurückgreifen.

Ein paar Worte zu den Entities:
Eine entitie ist nicht zwingend ein Objekt, dass auf der Map platziert wurde. Es kann auch einfach eine übergeordnete AI für Gegner oder ähnliches sein. Z.b. ein globales System das für das Wachsen der Bäume oder ähnliches zuständig ist.
Entities können child Entities besitzen. Die haben bisher noch keinen besonderen Zweck, werden aber beim Scripten und AI Verhalten wichtig werden (ist zumindest so geplant). Ich stelle mir dabei ein hierarchisches Prinzip vor. Eine Entitie hat x children und kontrolliert diese. D.h. sie teilt ihre Probleme/Aufgaben auf ihre Children auf. Gibt es keine Children muss sie es selbst erfüllen. Eine Entity kann dabei maximal ein parent Entity haben, aber beliebig viele Children.

Ihr könnt euch gerne darüber unterhalten, stehe bei Fragen auch ab nächster Woche wieder im Chat zur Verfügung. Ansonsten besprechen wir das einfach nächste Woche