Kleine Engine

[FUNPAQ]

thx, du sagt es. Jeder macht es anders, und jeder ist mit einer anderen Lösung unzufrieden.

[Gast]

Ja, es gibt _gleichzeitig_ nur ein Spielfeld. Das ist der Punkt. Singleton hin oder her, das kann jeder anders realisieren. Aber ich würde halt für jedes neue Spiel auch ein neues Spielfeld anlegen, vielleicht spielt ein neues Spiel auf einer kleineren Karte, in einer anderen Umgebung, was auch immer?
static macht insofern keinen Sinn, weil es keine Daten sind, die sich alle Instanzen von "Engine" teilen. Überhaupt macht es keinen Sinn, dass eine Klasse "Engine" das Spielfeld verwaltet. Überhaupt macht es für mich wenig Sinn, dass es eine Klasse names "Engine" gibt. Ich finde das Design grottenschlecht. Ihr könnt meine Meinung natürlich auch einfach ignorieren.

ich sehe da 3 möglichkeiten:
den ganzen kram global machen oder in einen namespace stecken, dann schreien alle oo programmierer auf.
wie hier eine klasse machen und alles darin static. ergebnis ist das gleiche, nur zusätzlich zugriffskontrolle. da schreien alle oo puristen auf.
eine normale klasse machen und mit dem unsäglichen singleton-knüppel kommen, dann schreien alle anderen auf.

Irgendeine Klasse sollte IMHO das Spielfeld verwalten. Das heisst für mich, sie enthält einen Pointer auf das aktuelle Spielfeld. Befindet man sich gerade im Hauptmenü, ist der Pointer NULL. Amsonsten zeigt er auf das gerade gültige Spielfeld.

[Trienco]

Optimizer schrieb:

Ja, es gibt _gleichzeitig_ nur ein Spielfeld. Das ist der Punkt. Singleton hin oder her, das kann jeder anders realisieren. Aber ich würde halt für jedes neue Spiel auch ein neues Spielfeld anlegen, vielleicht spielt ein neues Spiel auf einer kleineren Karte, in einer anderen Umgebung, was auch immer?

nur, weil die sachen static sind müssen sie ja nicht gleich const sein. beim laden/erstellen wird eben die größe passend gesetzt, ein evtl. vorhandenes "feld" (sprich array) freigegeben und ein neues in der richtigen größe angelegt.

static macht insofern keinen Sinn, weil es keine Daten sind, die sich alle Instanzen von "Engine" teilen. Überhaupt macht es keinen Sinn, dass eine Klasse "Engine" das Spielfeld verwaltet. Überhaupt macht es für mich wenig Sinn, dass es eine Klasse names "Engine" gibt.

,-) ich hab von anfang an einfach mal so getan, als würde da nicht engine, sondern spielfeld stehen. und davon braucht es ja letztlich keine instanzen.

Irgendeine Klasse sollte IMHO das Spielfeld verwalten. Das heisst für mich, sie enthält einen Pointer auf das aktuelle Spielfeld. Befindet man sich gerade im Hauptmenü, ist der Pointer NULL. Amsonsten zeigt er auf das gerade gültige Spielfeld.

das wäre eben die klasse, die hier extrem unpassend "engine" heißt. nur gibt es keinen globalen spielfeld-pointer, sondern eine statische klasse (die man sich vielleicht besser als namespace mit zugriffsrechten vorstellt), die einen solchen pointer intern mitschleppt (den aufs array).

unterm strich dürften sich die möglichkeiten in der praxis aber höchstens darin unterscheiden, ob man jetzt spielfeld->laden(bla) oder spielfeld::laden(bla) schreibt (und im zweifelsfall auch außerhalb des eigentlichen spiels ein paar byte mehr oder weniger verbrät). wobei ich da für deine variante sogar wirklich singletons benutzen würde, um nicht an tausend stellen schreiben zu müssen
if (spielfeld) irgendwas.
wobei mir wahrscheinlich das ständige
spielfeld::instance().irgendwas auch schnell so auf die nerven gehen würde, daß ich häßliche tricks einbaue (z.b. lieber den () operator mißbrauchen, wofür mich dann jeder haßt, der den code lesen muß)
spielfeld()->irgendwas
ohne das zu probieren vermute ich allerdings, daß ich da eher gezungen werde, den op mit
spielfeld::operator()()
aufzurufen, was den sinn der sache irgendwie verfehlt

aber ich geb auch zu, daß mir der :: syntax einfach besser gefällt, für alles was kein "normales" objekt ist (sondern z.b. eher eine schnittstellen-sammlung).

wie oben so schön gesagt, "jeder ist mit einer anderen lösung unzufrieden".

[edit by="rapso"]quotes enabled[/edit]

[interpreter]

Trienco schrieb:

der protected konstruktor und der virtuelle destruktor machen sinn, wenn die klasse wirklich flexibel sein soll

Nein, macht er nicht. Von dieser Klasse abzuleiten ist absolut sinnfrei.

Überhaupt macht es für mich wenig Sinn, dass es eine Klasse names "Engine" gibt. Ich finde das Design grottenschlecht.

Nicht nur du

[Trienco]

interpreter schrieb:

Trienco schrieb:

der protected konstruktor und der virtuelle destruktor machen sinn, wenn die klasse wirklich flexibel sein soll

Nein, macht er nicht. Von dieser Klasse abzuleiten ist absolut sinnfrei.

so wie die klasse jetzt ist schon, aber so wird sie mit ziemlicher sicherheit nicht bleiben und falls tatsächlich mal sonderfälle von spielfeldern abgeleitet werden, die dann auch "individuelle" attribute haben und mehrfach instanziiert werden sollen würde ich das nicht von vornherein ausschließen. und das meine ich mit wirklich flexibel: auch für jetzt undenkbare fälle (mehr oder weniger) geeignet.

[interpreter]

so wie die klasse jetzt ist schon,

Und genau darum gehts. Kann ja wohl nur das beurteilen, was ich moment da ist.

aber so wird sie mit ziemlicher sicherheit nicht bleiben und falls tatsächlich mal sonderfälle von spielfeldern abgeleitet werden, die dann auch "individuelle" attribute haben

Dann ist es wieder eine andere Klasse.

Zu dem flexibel: Eine Klasse ist flexibel, wenn man sie in mehreren Bereichen einsetzen und/oder Umfeldern einsetzen kann und nicht, wenn man sie leicht umschreiben kann

[Trienco]

interpreter schrieb:

Und genau darum gehts. Kann ja wohl nur das beurteilen, was ich moment da ist.

naja, momentan ist da so ziemlich gar nichts. also gehe ich lieber davon aus, was da irgendwann mal sein könnte ,-)

Zu dem flexibel: Eine Klasse ist flexibel, wenn man sie in mehreren Bereichen einsetzen und/oder Umfeldern einsetzen kann und nicht, wenn man sie leicht umschreiben kann

da kann man sich sicher ausgiebig über die definition streiten. für mich ist sie flexibel, wenn man sie zur not auch gut erweitern und durch ableiten anpassen kann. z.b. wäre eine statische vektor-klasse mit private konstruktor (neben der absoluten hirnrissigkeit) absolut nicht flexibel, weil man nichtmal zusätzliche operatoren erweitern könnte.

[rapso]

Trienco schrieb:

interpreter schrieb:

Und genau darum gehts. Kann ja wohl nur das beurteilen, was ich moment da ist.

naja, momentan ist da so ziemlich gar nichts. also gehe ich lieber davon aus, was da irgendwann mal sein könnte ,-)

wenn du das so siehst, dann müßte man extrapolieren und weil die "engine" klasse, die eigentlich aber nur ne "map/level" ist anstatt OOP zu werden, eigentlich nur strukturiert programmiert ist (mit einer klasse drumherum). müßte man sagen dass die engine oder das spiel, wenn es weiter so gecodet wird, eine ziemlich üblen source haben wird.

Trienco schrieb:

interpreter schrieb:

Zu dem flexibel: Eine Klasse ist flexibel, wenn man sie in mehreren Bereichen einsetzen und/oder Umfeldern einsetzen kann und nicht, wenn man sie leicht umschreiben kann

da kann man sich sicher ausgiebig über die definition streiten. für mich ist sie flexibel, wenn man sie zur not auch gut erweitern und durch ableiten anpassen kann. z.b. wäre eine statische vektor-klasse mit private konstruktor (neben der absoluten hirnrissigkeit) absolut nicht flexibel, weil man nichtmal zusätzliche operatoren erweitern könnte.

eine klasse ist flexibel wenn man sie in verschiedenen bereichen einsetzen kann.
wenn man sie so codet dass sie leicht erweiterbar ist, nenn man das bei c++ "generisch"

wenn du hier schon fragst, ob du deine erste Engine richtig gemacht hast, und dann soviel kritik an immer den selben stellen kommen, dann versuch nicht an dem "fehlerhaften" festzuhalten, sondern verbessere dich und deinen source, denn sonst hast du nichts davon diesen thread gestartet zu haben

rapso->greets();

[Trienco]

[quote]eine klasse ist flexibel wenn man sie in verschiedenen bereichen einsetzen kann. wenn man sie so codet dass sie leicht erweiterbar ist, nenn man das bei c++ "generisch"[/quote]

da scheinen unsere definitionen wohl recht gegensätzlich zu sein. "generisch" ist für mich z.b. so ziemlich die ganze stl, weil man sie durch templates für alles mögliche einsetzen. ich wäre nie auf die idee gekommen, die als generisch zu betrachten, weil man von list gut ableiten kann.

[rapso]

Trienco schrieb:

eine klasse ist flexibel wenn man sie in verschiedenen bereichen einsetzen kann. wenn man sie so codet dass sie leicht erweiterbar ist, nenn man das bei c++ "generisch"

da scheinen unsere definitionen wohl recht gegensätzlich zu sein. "generisch" ist für mich z.b. so ziemlich die ganze stl, weil man sie durch templates für alles mögliche einsetzen. ich wäre nie auf die idee gekommen, die als generisch zu betrachten, weil man von list gut ableiten kann.

die stl ist generisch, da muss man garnicht verschiedener meinung sein. und ableiten ist nicht die einzige methode zum spezialisieren, ein "typedef std::list<int> intlist;" macht das auch.

rapso->greets();