Kleine Engine

[interpreter]

nix da schrieb:

interpreter schrieb:

@nix da: http://de.wikipedia.org/wiki/Ironie

Ich rede von mehr von ihm als von Dir.

nix da schrieb:

Was definiert ihr denn bitteschön als "Engine"?

2. Komischer Satz.

[interpreter]

Optimizer schrieb:

Warum ist hier eigentlich alles static? Und wozu hast du dann überhaupt noch nen Destruktor?

Und warum is der virtual? Von der Klasse abzuleiten macht ja eh Null Sinn.
Was ich mit meinem 1. Posting ausdrücken wollte, ist, dass wir zu deinem Code wenig sagen können, da man ja praktisch nichts sieht.
Das, was ich sehe gefällt mir allerdings nicht. Wie Optimizer bereits angemerkt hat, sehe ich keinen Sinn darin alles statisch zu machen. Und was soll diese Klasse überhaupt machen? Sie hat ja keinerlei Funktionalität.
Desweiteren ist dar Klassenname Quark - die Engine ist ja die Summe deiner Funktionen, und nicht eine Klasse. Außerdem HAT eine Engine keine xSize (warum nicht gleich width?) oder ySize - das hat der Bildschirm oder ne Surface...

[FUNPAQ]

Danke für eure Antworten.

Ist mir schon klar das diese "Engine" nicht perfekt ist. Es ist ja auch mein erstes mal das ich irgendwas in dieser Richtung mache
Es ist daher alles static, weil ich das irgendwo mal gelesen habe (u.a. in diesem Forum) und auch in einigen Beispielen so gesehen habe, und da ich mir u.a. wegen diesem static nicht sicher war wollte ich das hier mal posten. (Man findet ja immer nur Beispiele zu sehr komplexen Engines mit OpenGL usw.)
Davon abgesehen macht die Klasse sehr wohl etwas. Sie erstellt eine Matrix, welches das Spielfeld sein soll (Daher auch der Destruktor^^). (Wäre Spielfeld ein besserer Name für die Klasse?)

Also die Klasse Engine/Spielfeld:
- Braucht nicht static sein.
- Muss nicht vererbt werden.

Es kann also eine normale Klasse sein, die eine Matrix speichert auf die ich mit entsprechenden Methoden zugreifen kann?

Nachtrag:
Falls ihr Seiten/Bücher mit einfachen Beispielen habt (also nichts mit 3D usw. ganz einfache 2D-Engines für Konsolenanwendungen, eben für den Einstig in das Prinzip von dem ganzen) bitte postet diese.

[TGGC]

Nee, komm, das gibt nur Ärger. Geh besser nochmal 'ne Woche weg, und such dir was im Netz. Dann fängst du an zu programmieren und bei Problemen kannst du gern fragen.

Bye, TGGC (Zu viele Primitve hier.)

[Blue-Tiger]

FUNPAQ schrieb:

Danke für eure Antworten.

...Sie erstellt eine Matrix, welches das Spielfeld sein soll (Daher auch der Destruktor^^). (Wäre Spielfeld ein besserer Name für die Klasse?)

Also die Klasse Engine/Spielfeld:
- Braucht nicht static sein.
- Muss nicht vererbt werden.

Es kann also eine normale Klasse sein, die eine Matrix speichert auf die ich mit entsprechenden Methoden zugreifen kann?

dann das ganze wirklich besser anders, ist vielsagender.

Und du solltest WIRKLICH erstmal Wissen, was die Dinge ueberhaupt bedeuten, bevor du sie einsetzt (static und virtual). Schliesslich gibts die Woerter nicht nur zum Spass, die haben auch was zu sagen

zu deinen Fragen:
1. kein Static
2. es wird nichts vererbt in deinem Source (wie bitte kommst du auf Vererbung - sicher dass dir ueberhaupt klar ist, was das bedeutet?)
3. Es kann nicht nur eine normale Klasse sein, es soll sogar

[FUNPAQ]

@TGGC:
Wieso? In den Beispielen welche ich bisher gesehen habe gab es immer ein Array was das Spielfeld darstellte? Es geht mir ja nur um das Prinzip, nur eben dazu finde ich kein wirkliches Beispiel, da geht es dann immer gleich um OpenGL usw. aber so tief möchte ich Games gar nicht behandeln ich möchte nur einen kleinen grundlegenden Überblick haben.

Übrigens static ist mir schon klar was das bedeutet, sonst würde ich das nicht nutzen . Variablen mit static sind für jedes Objekt der Klasse, sprich diese gibt es unabhängig von einzelnen Objekten der Klasse (selbst wenn kein Objekt angelegt wurde):
Wenn ich z.B. 10 Objekte der Klasse test habe, dann gibt es eine Variable mit static nur einmal.
Und da das Spielfeld sowieso immer existiert könnte es ja static sein. Zumindest habe ich ein Beispiel gesehen wo es eine solche Klasse gab.

Übrigens ein Beispiel mit einer solchen "static-Klasse":
http://www.c-plusplus.net/forum/viewtopic.php?t=74787&highlight=engine

[Gast]

Und da das Spielfeld sowieso immer existiert könnte es ja static sein.

Echt? Also ich kann mal ein großes Spielfeld haben, dann wieder ein kleines... bleibt es bei der immer gleich? Oder bleibt es sogar immer das selbe? Ziemlich unflexibel das Ganze. Und warum ist das Spielfeld keine eigene Klasse?

FUNPAQ schrieb:

Übrigens ein Beispiel mit einer solchen "static-Klasse":
http://www.c-plusplus.net/forum/viewtopic.php?t=74787&highlight=engine

Hat ja keiner dort gesagt, dass des gut ist. Ganz im Gegenteil, hier wurde das static auch kritisiert.
Im übrigens benutzt du Begriffe, wie z.B. Engine, obwohl du sie nicht verstehst. Das macht es nicht leichter, dir zu helfen. Geh das ganze mal langsamer an und mach dich erstmal über Programmieren allgemein und nicht über Spieleprogrammierung im speziellen schlau.

[Trienco]

[quote="Optimizer"]Echt? Also ich kann mal ein großes Spielfeld haben, dann wieder ein kleines... bleibt es bei der immer gleich? Oder bleibt es sogar immer das selbe? Ziemlich unflexibel das Ganze. Und warum ist das Spielfeld keine eigene Klasse?[/quote]

es gibt nur ein spielfeld und mehrere instanzen machen keinen sinn.
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.

singletons können in manchen situationen durchaus sinnvoll sein (z.b. wenn ein objekt viel speicher verbrät und die eine instanz nicht ständig gebraucht wird, oder unklar ist, ob es nicht irgendwann doch mehrere instanzen geben können soll), aber manche bekommen sobald es heißt "gibts nur einmal" dieses unseelige funkeln in den augen.

ich würde mich z.b. auch an den vollkommen unnötigen zugriffsfunktionen stören. oo puristen geht einer ab, wenn zu jedem int x noch ein GetX und SetX rumfliegen, aber sofern es für x keine einschränkungen in der "wertemenge" gibt und keine dicken designänderungen zu erwarten sind ist das ganze extrem überflüssig (und ich danke stroustrup dafür, sich in einem interview zu derart überzogenem oo ein paar kommentare gemacht zu haben).

engine: das wort wird nicht nur hier viel zu schnell benutzt. sobald jemand nen würfel durch einen levele schieben kann, redet er von seiner "engine", ohne richtig zu merken, daß eine "engine" für einfache spiele vollkommen sinnlos ist. wer eine dicke 3d engine schreibt, wenn er nur ein original getreues 2d pong machen will, der hat zuviel freizeit (nicht, wenn wer allerdings eine 3d engine schreiben will und ein pong als einfachen "testfall" benutzt).

so gesehen ist das viele static eigentlich noch was, was ich nachvollziehbar finde. es soll im wesentlichen global sein, gekapselt sein und private elemente ermöglichen. singletons sind für sowas overkill.

der protected konstruktor und der virtuelle destruktor machen sinn, wenn die klasse wirklich flexibel sein soll. irgendjemand könnte eine klasse ableiten, die dann eben auch tatsächlich instanziiert werden soll und members hat, die NICHT static sind. allerdings behaupte ich jetzt mal, daß es eher unwahrscheinlich ist, daß die bestehenden members dann wirklich weiter static bleiben sollen.

[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();