ein Spiel schreiben - was für eine Klassenstruktur/-hierarchie?
-
Kann mir jemand Literatur für Klassenstrukturen von Spielen empfehlen? Danke. :schland: :schland: :schland:
-
Ich empfehle, einfach mal einige Spiele zu schreiben.
Wenn du's noch nicht gelesen hast: http://www.amazon.de/Patterns-Elements-Reusable-Object-Oriented-Software/dp/0201633612/
Tu dir nur einen Gefallen und überspring die Seiten 127-134. Die bringen dich nur auf blöde Gedanken
-
*zu-faul-zum-nachschlagen-sei*
Was wird auf Seiten 127-134 erklärt? Singleton?
-
hustbaer schrieb:
*zu-faul-zum-nachschlagen-sei*
Was wird auf Seiten 127-134 erklärt? Singleton?jap
-
Was wären denn anwendungen für Singleton? mir war das ziemlich unsimpathisch. und ich kann mir schlecht eine wirklich hilfreiche funktion dafür vorstellen.
-
ueberall dort wo man ein hardware interface braucht (da hardware auch ein singleton ist), oder man einen sicheren ansprungpunkt jeder zeit braucht, bei mir ist das meistens:
-render device
-input device
-audio device
-file system
-logging
-crash handleraus performance und speicher gruenden hab ich noch einen
-string pooles ist nur religion singleton's schlecht zu reden, man sollte nicht alles immer benutzen, aber genau so wenig sollte man religious etwas, was nuetzlich waere, umstaendlich umgehen nur des umgehens wegen.
-
rapso schrieb:
es ist nur religion singleton's schlecht zu reden
Es geht darum, die Leute nicht auf die Idee zu bringen, dass man Singleton benutzen sollte, um globale Variablen zu vermeiden. Das ist letztlich ja auch ein "religiöses" Motiv: Jeder weiß dass globale Variablen vom Teufel kommen, da ist jedes Mittel recht, oder? Also bauen wir uns 100 Singletons und fühlen uns wie der Streiter der gerechten Sache. Religion hat beim Programmieren nichts verloren, und wenn man irgendwo "ist böse" als Begründung ohne jegliches Augenzwinkern liest, sollte man nicht weiterlesen.
-
Bashar schrieb:
rapso schrieb:
es ist nur religion singleton's schlecht zu reden
Es geht darum, die Leute nicht auf die Idee zu bringen, dass man Singleton benutzen sollte, um globale Variablen zu vermeiden. Das ist letztlich ja auch ein "religiöses" Motiv: Jeder weiß dass globale Variablen vom Teufel kommen, da ist jedes Mittel recht, oder? Also bauen wir uns 100 Singletons und fühlen uns wie der Streiter der gerechten Sache.
also bauen wir die religion aus und sagen "global variables und singletons sind vom teufel, tue mir einen gefallen und vermeide es um jeden preis".
Religion hat beim Programmieren nichts verloren, und wenn man irgendwo "ist böse" als Begründung ohne jegliches Augenzwinkern liest, sollte man nicht weiterlesen.
augenzwinkern bildet nicht, es lehrt schon garnicht zu differenzieren, da dies auf erfahrung beruht und ein anfaenger das nicht leisten kann.
deswegen sollte man eine vernuenftige erklaerung liefern, statt glauben zu initieren.
"vorteile sind"
"nachteile sind"
"es hat einen xyz ruf wegen"
"ich halte davon..."
"mach dir selber einen meinung darueber, wir sind programmierer, keine moenche"
-
Bashar schrieb:
rapso schrieb:
es ist nur religion singleton's schlecht zu reden
Es geht darum, die Leute nicht auf die Idee zu bringen, dass man Singleton benutzen sollte, um globale Variablen zu vermeiden.
Warum sollte man globale Variablen generell vermeiden? Ich habe gerne einen Logger global als Singleton. Genauso wie ich gerne den Zugriff auf die Konfiguration der Anwendung gerne über ein Singleton verfügbar mache.
Weiterhin kapsle ich nahezu jedes Interface einer dynamisch geladenen DLL über ein Singleton (so brauche ich mich nicht um den gemeinsamen Zugriff mehrere unabhängiger Programmteile auf die DLL zu kümmern, wer sie läd, etc. Ich kann sie einfach über "MyDLL::Instance().DllFunktion1() ansprechen)Ich finde das wesentlich schöner/übersichtlicher, als z.B. jeder Klasse die Zugriff auf einen Logger oder die Konfiguration benötigt eine Referenz auf diese Klassen im Konstruktor mit zu übergeben. Das versaut einem nur die Header-Files.
-
Den Logger sehe ich ja noch ein, aber wieso die Anwendungskonfiguration? Kann es da nur eine Anwendung geben? Wieso gehört die Konfiguration nicht zur Anwendung? Wenn es nicht "die" Anwendung gibt, sondern diese aus Unterteilen besteht, warum ist dann die Konfiguration überhaupt ein übergreifendes Objekt und nicht auf die Unterteile verteilt? Das ist vermutlich genau das, worauf Bashar hinaus wollte.
-
SeppJ schrieb:
Das ist vermutlich genau das, worauf Bashar hinaus wollte.
Nö, aber ich bereue es schon, das Thema überhaupt angeschnitten zu haben. Ach nein, goto ist übrigens auch ganz böse!
-
SeppJ schrieb:
Den Logger sehe ich ja noch ein, aber wieso die Anwendungskonfiguration? Kann es da nur eine Anwendung geben?
wie sonst? eine anwendung ist doch eine anwendung? ich glaube mehrere anwendungen in einem process zu starten ist eher eine ausnahme.
Wieso gehört die Konfiguration nicht zur Anwendung?
es gehoert zu einem process/anwendung z.b. ob man Direct3D oder OpenGL als output benutzen will ist ein teil der konfig und fuer die ganze anwendung/den ganzen process gleich. genau wie aufloesung, input settings etc.
ich wueste nicht wieso man sein program multi konfig faehig machen sollte. vielleicht ein beispiel?Wenn es nicht "die" Anwendung gibt, sondern diese aus Unterteilen besteht, warum ist dann die Konfiguration überhaupt ein übergreifendes Objekt und nicht auf die Unterteile verteilt? Das ist vermutlich genau das, worauf Bashar hinaus wollte.
ich verstehe das ehrlichgesagt nicht.
du startest ein spiel, einen editor oder einen game server, der hat seinen resolution, skin oder port. wozu mehrere instanzen dieser konfig und wie soll sich das auswirken? mehrere skins? resolutions? ports? ...? zur gleichen zeit?bei mir ist die konfig teil der konsole und lebt mit seinem environment das nur einmal vorhanden ist. es gibt mehrere wege das auszulesen oder zu veraendern was status quo ist, aber da ich keinen process als child starte etc. wie es bei linux waere, hab ich keine kapselung.
ich wuerde eher log als nicht singleton verstehen (da man pro subsystem einen channel mit unterschiedlichen priorities etc. filtern koennte), also bei konfigurationsvariablen.
-
rapso schrieb:
SeppJ schrieb:
Den Logger sehe ich ja noch ein, aber wieso die Anwendungskonfiguration? Kann es da nur eine Anwendung geben?
wie sonst? eine anwendung ist doch eine anwendung? ich glaube mehrere anwendungen in einem process zu starten ist eher eine ausnahme.
Wieso gehört die Konfiguration nicht zur Anwendung?
es gehoert zu einem process/anwendung z.b. ob man Direct3D oder OpenGL als output benutzen will ist ein teil der konfig und fuer die ganze anwendung/den ganzen process gleich. genau wie aufloesung, input settings etc.
ich wueste nicht wieso man sein program multi konfig faehig machen sollte. vielleicht ein beispiel?Wenn es nicht "die" Anwendung gibt, sondern diese aus Unterteilen besteht, warum ist dann die Konfiguration überhaupt ein übergreifendes Objekt und nicht auf die Unterteile verteilt? Das ist vermutlich genau das, worauf Bashar hinaus wollte.
ich verstehe das ehrlichgesagt nicht.
du startest ein spiel, einen editor oder einen game server, der hat seinen resolution, skin oder port. wozu mehrere instanzen dieser konfig und wie soll sich das auswirken? mehrere skins? resolutions? ports? ...? zur gleichen zeit?bei mir ist die konfig teil der konsole und lebt mit seinem environment das nur einmal vorhanden ist. es gibt mehrere wege das auszulesen oder zu veraendern was status quo ist, aber da ich keinen process als child starte etc. wie es bei linux waere, hab ich keine kapselung.
ich wuerde eher log als nicht singleton verstehen (da man pro subsystem einen channel mit unterschiedlichen priorities etc. filtern koennte), also bei konfigurationsvariablen.
Ich glaube wir verstehen beide was anderes unter Konfiguration. Ein DirectX- oder OpenGL-Output ist natürlich ein Singleton, da es aus technischen Gründen nur einen geben kann und der hat dann auch seine Konfiguration. Ich habe eher den Eindruck bekommen, dass Morle so Sachen als
globale VariablenSingleton modelliert, die man eigentlich eine Eigenschaft eines Objektes sein sollten, bloß weil sie die Gemeinsamkeit haben, aus einer Konfigurationsdatei gelesen zu werden oder in einem Einstellungsdialog aufzutauchen.
-
Selbstverständlich kann es beliebig viele Direct3D oder OpenGL "Outputs" geben, selbst auf meinem normalen PC...
-
dot schrieb:
Selbstverständlich kann es beliebig viele Direct3D oder OpenGL "Outputs" geben, selbst auf meinem normalen PC...
In einem Programm? Ich bin nicht so der Experte was Grafikprogrammierung angeht, aber ich hatte bei meinen bisherigen Experimenten den Eindruck bekommen, dass man nur einen Context pro Programm haben kann. Ich lasse mich gerne eines besseren belehren, meine Tutorials kamen mir nicht so dolle vor, aber ich hätte nicht gedacht, dass sie solche Grundlagen falsch machen. Es wurde nämlich betont, dass dies eine der wenigen Gelegenheiten ist, in einem Programm mal einen echten globalen Zustand zu haben.
-
SeppJ schrieb:
dot schrieb:
Selbstverständlich kann es beliebig viele Direct3D oder OpenGL "Outputs" geben, selbst auf meinem normalen PC...
In einem Programm?
Natürlich, denk nur z.B. an Multidisplayanwendungen
-
@SeppJ
Bei OGL ist das etwas doof gelöst.
Bei D3D kannst du so viele Devices und SwapChains und was nicht noch alles haben wie du willst.
Mach ein kleines Programm, pack zwei MediaPlayer Controls rein die je ein Video spielen => fertig ist das Programm das zwei D3D "Outputs" parallel verwendet.
Mal mit noch einen drehenden Würfel mit D3D drunter und es sind 3.
-
SeppJ schrieb:
....Ich habe eher den Eindruck bekommen, dass Morle so Sachen als
globale VariablenSingleton modelliert, die man eigentlich eine Eigenschaft eines Objektes sein sollten, bloß weil sie die Gemeinsamkeit haben, aus einer Konfigurationsdatei gelesen zu werden oder in einem Einstellungsdialog aufzutauchen.sowas wie: renderer waehlen, motion blur, HDR, shadow quality, texture size etc. ?
das laeuft bei den engines die ich kenne ueber globale konfigurationen.dot schrieb:
Selbstverständlich kann es beliebig viele Direct3D oder OpenGL "Outputs" geben, selbst auf meinem normalen PC...
hypothetisch kann man sicher auch eine ganze anwendung als eine klasse die ein singleton ist implementieren.
wenn wir nicht den normal/durchschnittsfall nehmen, bauen wir luftschloesser und dann hat overengineering freien lauf, dann braucht man garkein singleton und alles ist pure data driven.
-
rapso schrieb:
wenn wir nicht den normal/durchschnittsfall nehmen, bauen wir luftschloesser und dann hat overengineering freien lauf, dann braucht man garkein singleton und alles ist pure data driven.
Und genau diese Denkweise ist der Grund, wieso ich immer noch keinen Screensaver gefunden hab, der auf beiden meiner Bildschirme läuft
-
SeppJ schrieb:
Ich habe eher den Eindruck bekommen, dass Morle so Sachen als
globale VariablenSingleton modelliert, die man eigentlich eine Eigenschaft eines Objektes sein sollten, bloß weil sie die Gemeinsamkeit haben, aus einer Konfigurationsdatei gelesen zu werden oder in einem Einstellungsdialog aufzutauchen.Zum Verständnis: Die Konfiguration bezieht sich auf eine XML Datei, in der die einzelnen Anwendungsteile konfiguriert sind (z.B. IP Adressen eines TCP-Clients). Das Singleton kapselt den Zugriff auf diese Datei im Sinne von ".GetConfigValue(key)"
Und ich sagte übrigens auch, dass der Verweis auf die Konfiguration vom Designaspekt wohl besser ein Klassenmember der Klasse sein sollte, die etwas aus der Konfig lesen will, aber aus Gründen der Übersichtlichkeit eben bei mir oft ein Singleton sind.Es ergeben sich nämlich daraus andere Probleme: Man müsste die Referenz auf die Konfig dann immer mitschleppen damit man sie dem Konstruktor der Klasse übergeben kann. Unschön, wenn man z.B. die Klasse von Punkten im Programm aus erstellt, wo man die Konfiguration eigentlich gar nicht braucht und sie nur extra deswegen selbst "bis dahin" mitschleppen müsste.
Es ist IMHO nicht alles schwarz/weiss sondern durchaus grau.
-
rapso schrieb:
SeppJ schrieb:
....Ich habe eher den Eindruck bekommen, dass Morle so Sachen als
globale VariablenSingleton modelliert, die man eigentlich eine Eigenschaft eines Objektes sein sollten, bloß weil sie die Gemeinsamkeit haben, aus einer Konfigurationsdatei gelesen zu werden oder in einem Einstellungsdialog aufzutauchen.sowas wie: renderer waehlen, motion blur, HDR, shadow quality, texture size etc. ?
das laeuft bei den engines die ich kenne ueber globale konfigurationen.dot schrieb:
Selbstverständlich kann es beliebig viele Direct3D oder OpenGL "Outputs" geben, selbst auf meinem normalen PC...
hypothetisch kann man sicher auch eine ganze anwendung als eine klasse die ein singleton ist implementieren.
wenn wir nicht den normal/durchschnittsfall nehmen, bauen wir luftschloesser und dann hat overengineering freien lauf, dann braucht man garkein singleton und alles ist pure data driven.Ich bin der Meinung es macht auch einen Unterschied um was für eine Art Engine es sich handelt. Wenn es eine "general purpose" Grafik-Engine sein soll, dann ist es Kacke wenn diese Dinge globale Config-Settings sind.
Weil man dadurch in vielen Applikationen Schwierigkeiten bekommt, die "sowas mit Grafik" an mehreren Stellen brauchen, aber nicht unbedingt immer mit den gleichen Einstellungen. Da ist es angesagt wenn man sich von der Engine ein Ding holen Kann (Context oder wie auch immer man es nennen mag), und alle Einstellungen Ding-spezifisch und nicht global sind.Wenn man dagegen eine Game-Engine macht, kann man eher davon ausgehen dass es im gesamten Prozess nur einen "Client" der Engine gibt, nämlich das eine Spiel das in dem Prozess läuft.
In dem Fall kann man vermutlich viele Dinge global machen, und die damit gesparte Zeit sinnvoll in was anderes investieren.----
Am wichtigsten ist mir allerdings der Punkt: Singleton hat im Vergleich zu globalen Variablen zwar ein paar Vorteile. Der mMn. grösste Nachteil bleibt aber, nämlich dass es halt nur eine Kopie gibt. Daher ist "Singleton statt global" mMn.
nurgrösstenteils Augenauswischerei. Die Settings sind global? Na dann sind die halt global, kann man doch einfach so sagen. Wenns für ein Projekt Sinn macht, ist es doch auch kein Problem. Muss man nicht "Singleton" dazu sagen nur damit's besser klingt.
Bzw. sich nicht einbilden man hätte das grundlegende Problem der Sache gelöst, indem man ein Singleton drüberstülpt. Wenn es das Problem nicht gibt, muss man es nicht lösen. Und wenn es das Problem gibt, dann löst man es nicht mit einem Singleton.