Struktur
-
Also es gibt etwas was mich jetzt schon lange beschäftigt, deswegen frag ich hier jetzt einfach mal. ich hab jetzt schon ein paar jahre erfahrung mit c++ und directx und auch spieleprogrammierung, aber ein problem das sich mir immer wieder stellt ist wie man eine sinnvolle codestruktur findet. ich hab mir ja angewöhnt jedes objekt in eine klasse zu packen. das problem dabei ist meistens das wenn viele objekte gegenseitig interagieren ich nie weiss welches objekt denn nun ein member des jew. anderen sein soll..also welches objekt ein anderes besitzt.
ein (simples) beispiel wäre die karte oder das terrain und der spieler...soll die karte jetzt ein member der spieler-klasse sein, oder umgekehrt?
vom rein logischen standpunkt wärs wohl am sinnvollsten die karte den spieler "besitzen" zu lassen. das gibt aber probleme wenn der spieler die karte modifizieren soll.
daraus gibts ja mehrere lösungen...zum einen ich könnte die karte global machen oder ich könnt dem spielerkonstruktor nen zeiger auf die karten-klasse geben...aber globale variablen sind ja immer so verschrien
...wie strukturiert ihr euren spielecode? manchmal hab ich das gefühl das nur ich bei sowas probleme hab
. ich arbeite 50-60 stunden an einer struktur, bau ein paar spielrelevante dinge ein, und dann werf ich immer wieder alles über den haufen weil eine andere struktur doch besser wäre...manchmal hab ich auch das gefühl ne fliege mit ner atombombe zu killen...
ich versuche "fortschrittlichere" techniken zu verwenden als ich sie (wahrscheinlich) bräuchte...beispiel gamestates:
die einen lösen das problem mit der simplen variante. eine einfache variable, ein paar konstanten und dann halt nen langes switch-statement wo dann die jew. funktionen/methoden aufgerufen werden. die anderen schwören auf eine stateklasse von der dann für die jeweiligen states abgeleitet wird...ich bin jmd der eher zu letzteren gruppe gehört, das game dann zu 40% implementiert hat, und dann merkt das einen die stateklassen im weiteren codeaufbau zusehr einengen und sich tierisch darüber aufregt
.
was meint ihr dazu? bzw. was benutzt ihr und warum?wieder ne andre sache sind die objekte an sich. da frag ich mich auch immer: soll ich erst eine klasse schreiben die z.b. den ganzen directx-kram kapselt, und die einzelnen klassen dann mit diesem wrapper arbeiten lassen, oder soll ich das eher in jeder objekt-klasse eigenständig behandeln?
genau dasselbe trifft auf den input zu. egal ob er jetzt von der tastatur oder von der maus kommt. soll man in jeder klasse z.b. die tastatur abfragen, und dann die dinge behandeln die sie selbst angehen, oder soll man den ganzen input wieder in eine klasse kapseln und dann die einzelnen objekte benachrichtigen wenn was für sie anliegt?
bei diesen fragen komm ich einach auf keinen gescheiten nenner. deswegen dachte ich man könnte hier mal mit ein paar erfahreneren leuten darüber diskutieren.
btw: es kennt nicht jemand zufällig nen gutes opensource rpg, am besten eins was directx oder opengl benutzt? ich such sowas schon lange, weil ich einfach mal sehn will wie die profis sowas strukturieren. ich hab kein problem was auf den bildschirm zu bringen, ne karte darzustellen, oder den spieler, oder irgendwas auf der soundkarte zum dudeln zu bringen...mein problem besteht meist darin die ganzen teile zusammenzusetzen.
mfg
-
totalunwissender schrieb:
ein (simples) beispiel wäre die karte oder das terrain und der spieler...soll die karte jetzt ein member der spieler-klasse sein, oder umgekehrt?
vom rein logischen standpunkt wärs wohl am sinnvollsten die karte den spieler "besitzen" zu lassen. das gibt aber probleme wenn der spieler die karte modifizieren soll.
daraus gibts ja mehrere lösungen...zum einen ich könnte die karte global machen oder ich könnt dem spielerkonstruktor nen zeiger auf die karten-klasse geben...Wieso sind nicht Karte und Spieler Bestandteil von "Spiel" ?
Kauf dir am Besten ein Buch über Design Patterns. Das sollte dir vllt helfen.
-
Also erst einmal können Dir hier wahrscheinlich eh nur eine Handvoll Leute gescheite Antworten geben, da derartige Design-Mängel bei kleinen Hobbyprojekten meistens nicht so ins Gewicht fallen.
totalunwissender schrieb:
ein (simples) beispiel wäre die karte oder das terrain und der spieler...soll die karte jetzt ein member der spieler-klasse sein, oder umgekehrt?
vom rein logischen standpunkt wärs wohl am sinnvollsten die karte den spieler "besitzen" zu lassen. das gibt aber probleme wenn der spieler die karte modifizieren soll.
daraus gibts ja mehrere lösungen...zum einen ich könnte die karte global machen oder ich könnt dem spielerkonstruktor nen zeiger auf die karten-klasse geben...aber globale variablen sind ja immer so verschrien
...Bevor Du das einfach global machst - wie wär's mit der OO-Variante? Nimm ein Singleton.
Jeder kann nach der Karte fragen, und wenn sie noch nicht existiert, wird sie gebaut, ansonsten einfach returned.totalunwissender schrieb:
wieder ne andre sache sind die objekte an sich. da frag ich mich auch immer: soll ich erst eine klasse schreiben die z.b. den ganzen directx-kram kapselt, und die einzelnen klassen dann mit diesem wrapper arbeiten lassen, oder soll ich das eher in jeder objekt-klasse eigenständig behandeln?
Naja, ersteres ist zwar 'ne Heidenarbeit, aber eigentlich immer sinnvoll, da Du dann nicht an Dutzenden Stellen Code ändern mußt, beim Wechsel von DX9 auf DX10. Und Du könntest sogar auf OpenGL aufbauen wenn Du willst.
totalunwissender schrieb:
genau dasselbe trifft auf den input zu. egal ob er jetzt von der tastatur oder von der maus kommt. soll man in jeder klasse z.b. die tastatur abfragen, und dann die dinge behandeln die sie selbst angehen, oder soll man den ganzen input wieder in eine klasse kapseln und dann die einzelnen objekte benachrichtigen wenn was für sie anliegt?
Da eher letzteres.
Wenn jede Klasse für sich selbst DInput abfragt... das wäre doch übel.
Du könntest ja noch einen EventManager bauen, und DI setzt alle Tastendrücke etc. um und schmeisst dadurch "Events" in 'ne Queue des EventManagers.
-
Sgt. Nukem schrieb:
Bevor Du das einfach global machst - wie wär's mit der OO-Variante? Nimm ein Singleton.
Jeder kann nach der Karte fragen, und wenn sie noch nicht existiert, wird sie gebaut, ansonsten einfach returned.Das führt in der erfahrungsgemäß bei Leuten mit wenig Erfahrung immer dazu, dass plötzlich alle Klassen Singletons werden. Und ehrlich, ne Klasse für die Lvl-Map sollte kein Singleton sein. Damit wäre der Zweck des Ganzen recht verfehlt.
-
Hi,
ich glaube niemand kann dir wirklich algemeingültige Antworten auf deine Fragen geben.
Ich kenn das Gefühl, beim Proggen immer gleich alles richtig machen zu wollen und möglichst wiederverwertbaren Code anzupeilen.
"Solln die Objekte sich nun selbst zeichnen, oder soll das eine Render-Klasse machen?"
Dabei kommt man dann irgendwie gar nicht vorwärts, weil man ständig das Gefühl hat, es muss noch irgendwie besser gehen.Hier hat man einen Vorteil, wenn man vorher schon kleinere Projekte geschrieben hat.
Wichtig ist, das man es bis zum Ende bringt.
Natürlich macht man viele Fehler, die erst zum Schluss auffällig werden.
(Eins meiner erstes Spiele bestand aus einer CPP und 12-Headerdateien, weil ich nicht einsehen wollte, wozu man weiter CPP-Dateien braucht, wo man doch Quelltext so schön in Header auslagern kann
)
Beim nächsten Mal macht man es dann automatisch besser.
Es gibt Fehler, die muss man einfach gemacht haben.
-
Ahvolon[F-Bytes] schrieb:
Wieso sind nicht Karte und Spieler Bestandteil von "Spiel" ?
Kauf dir am Besten ein Buch über Design Patterns. Das sollte dir vllt helfen.
Ich hab bereits eins
.
Aber ne wirkliche Hilfe ist es nicht immer.
Aber die Frage ist z.T. auch immer ob der aufwand lohnt so ein pattern einzusetzen.
-
SeppSchrot schrieb:
Ich kenn das Gefühl, beim Proggen immer gleich alles richtig machen zu wollen und möglichst wiederverwertbaren Code anzupeilen.
"Solln die Objekte sich nun selbst zeichnen, oder soll das eine Render-Klasse machen?"
Dabei kommt man dann irgendwie gar nicht vorwärts, weil man ständig das Gefühl hat, es muss noch irgendwie besser gehen.Ja...ich weiss was du meinst. dieses gefühl hab ich öfters weil ich meistens versuch möglichst guten code zu schreiben.. leider führt das oft dazu das ich mehr arbeit hab vom jetzigen design auf das "bessere" zu wechseln als ich gebraucht hab um das alte design zu schreiben. manchmal denk ich mir das vieleis einfacher wäre wenn man sich über ein paar regeln einfach mal hinwegsetzt, und lieber etwas schlechteren code schreibt, statt wochen damit zu verbringen sein design andauernd umzuwerfen weil es immer schwierigkeiten gibt.
ne nette sache wär z.b. nen grafikwrapper, davon abgeleitet jeweils nen dx und ogl-wrapper, jew. dieselben interfaces, und man kann schön einfach die apis wechseln....wenns ja nicht soviel arbeit wär
-
Dieser Thread wurde von Moderator/in rapso aus dem Forum Spiele-/Grafikprogrammierung in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wie SeppSchrot schon sagte, gibt es keine absolute Antwort. Jedes Prinzip oder schlauer Spruch wird durch spezielle Situationen ausgehebelt. Und nur die Erfahrung sagt einem, das man genau dann die ausgetretenen Pfade verlassen muss.
Zum Beispiel die Idee, das man zunächst korrekten und dann (evtl. noch) schnellen Code schreibt, führt immer dann in in die Irre, wenn die zuerst gewählte Methode zu langsam für die Praxis und ungeeignet für Optimierung ist. Nehme man mal das Beispiel Fibonacci Zahlen. Ein Fan von Rekursion würde evtl. sofort mit dieser Idee kommen:
int f( int i ) { return i < 2 ? i : f( i - 1 ) + f( i - 2 ); }Diese Lösung sieht so elegeant aus, wie sie ineffizient ist. Ich denke mal, sie hat einen Aufwand von O(2^i). Eine Schleife kann es aber nahezu so elegant und verständlich in O(i) lösen, aber wer gibt schon gern den einmal gewählten rekursiven Ansatz auf, wenn man schonmal sowas tolles im Programm hat?
@Forengott: Warum werden die interessanten Themen hier wegverschoben?
Bye, TGGC (Denken, und gut ist.)
-
TGGC schrieb:
@Forengott: Warum werden die interessanten Themen hier wegverschoben?
das frag ich mich allerdings auch..
also kann man im prinzip sagen das man nur mit viel erfahrung die richtige methode/codestruktur bzw. das design von anfang an richtig wählen kann. und wahrscheinlich wird man selbst dann noch hin- und wieder in die lage kommen doch umzuwechseln wenn sich dieses design als nicht flexibel oder schnell genug erweist.
da werd ich wohl noch ein bisschen erfahrung sammeln müssen
