spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich denke, dass das Schreiben der Klassen bzw. Herausfinden welche Funktionen gebraucht sind, den meisten Spaß macht, wenn man es sich alleine überlegt!

Nimm dirn Blatt und en Stift und dann denk nach und schreib alles auf
Wenn du dann soweit bist das du denkst das könnte so klappen, dann fängst du mit
der programmierung an.
Und wärend du programmierst fallen dir dann Fehler im Konzept auf die du dann überarbeitest.

So mach ich das jedenfalls!

MfG Marcel

Richtiges Klassendesign ist auch zu einem großen Teil Erfahrungssache. Ansich ist es Anfangs gar nicht so dum, einfach drauf los zu programmieren, dann merkt man recht schnell, was funktioniert, und was eben nicht.

Weil ich dazu neige:
Lass die Klassen nie zu groß werden! Wenn sie zu groß ist, wirst du es schon merken. Du merkst es eben, wenn du merkst, dass diese gewisse Klasse mit Summe X Klassen auch zu machen wäre.
Dadurch könntestkannst du deinen Code besser wiederverwenden.
Ansonsten überlegen was wirklich nötig ist. Wenn du was nicht brauchst, hau's sofort raus und denk dir nicht, dass du das später machst.
Joa. So im Großen und Ganzen wären das meine Tipps recht knapp und zusammengefasst auf den Punkt gebracht.

MfG
Check

Das interessante ist: Manchmal kann man auch zu viele Klassen haben. Da unterteilt man ein Problem in kleine Bestandteile, hat für jedes seine eigene Klasse und hat dann zwar die maximale Flexibilität, merkt aber später dass die eigentliche Logik auch in einer Funktion in 20 Zeilen gepasst hätte, man sich dank der vielen Klassen aber tot Tip vor lauter Klassendeklarationen, Konstruktore, Desktruktoren, Lade/Speicherfunktionen, Parameterweiterreichen, Getter/Setter usw... Oh und wiederverwendbar sind die Klassen dann irgendwie doch nicht, da sie alle viel zu stark voneinander abhängen.

Der Fehler ist wohl oft, zu denken, dass man nur weil man jetzt Objektorientiert Programmiert auch automatisch alle Vorteile hat, wegen deren Objektorientiertheit erfunden wurde. Aber naja, mit der Zeit wird es besser. Solange man jedes Jahr den eigenen Code vom letzten Jahr dämlich findet, weiß man, dass man stetig dazu lernt

eine Möglichkeit der Objektorientierten Analyse ist folgende:

man schreibt sich zunächst als Fließtext auf, was das eigene Spiel (oder generell Programm) beinhalten soll.
dabei sollte man aber keine Rücksicht auf die technische Umsetzung nehmen und beispielsweise die Anforderungen an die Spielelemente selbst und Anforderungen an beispielsweise die Menüs voneinander getrennt betrachten
beschreiben kann man dabei alle Dinge, die für das Spiel notwendig sind (Spieler, Gegner, Projektile, ...), wodurch sie sich auszeichnen (Projektile: verschiedene Farben, Formen und Größen; Spieler: das Aussehen des Spielers; Gegner: verschiedene Formen; Bosse: viele "Einzelteile", ...) und was sie können (Spieler: normal schießen, Superbombe, sterben, vertikel bewegen; Gegner: normal schießen, frei bewegen; Bosse: normal schießen, Raketen abfeuern, Laserstrahlen abfeuern,...)
sobald dieser Text, der letztendlich die Anforderungen an das Spiel beinhaltet, fertig ist, kann man ihn analysieren
Subjektive sind Hinweise auf mögliche Klassen (Spieler, Gegner, Boss, Projektil, ...)
verben sind Hinweise auf mögliche Methoden der Klassen (Spieler feuert Projektile -> Spieler.feuern())
und beschriebene Eigenschaften sind Hinweise auf Membervariablen (Gegner haben verschiedenes Aussehen -> Gegner.textur)
ich habe bewusst nicht geschrieben, dass es sich bei den 3 Dingen jeweils um Hinweise handelt, da beispielsweise nicht zwangsläufig aus Substantiven Klassen resultieren
wie bereits geschrieben wurde, ist Erfahrung immer relevant - in diesem Fall um eher auf die richtigen Klassen zu kommen
außerdem kann es immer mal wieder vorkommen, dass man feststellt, dass man sich doch sehr vermacht hat und eine andere Klassenstruktur vielleicht besser wäre

in einem solchen Fall sollte man sich nicht davor scheuen, einfach erstmal Zeit darin zu invenstieren, den gesamten Code umzubauen
man wird zwar im ersten Moment weit mehr Fehler haben als vorher, allerdings braucht man meist für die Behebung dieser diese Zeit

da du diese Vorgehensweise bisher vermutlich noch nicht angewendet hast, solltest du auch nicht zu viel Zeit darin verlieren
setze dich beispielsweise 1-2 Stunden lang daran, sowohl den Text zu schreiben, als auch ihn zu analysieren
man könnte eventuell auf weitere Ideen kommen, wenn man sich mehr Zeit nimmt, allerdings, wie bereits geschrieben wurde, solltest du auch ein wenig Erfahrung durch das "drauf los programmieren" sammeln
diese Vorüberlegung dürfte eine gewisse Grundlage liefern

nicht direkt ersichtlich ist bei dem Vorgehen beispielsweise eine Vererbungshirarchie
diese kann man daraus ableiten, dass verschiedene Dinge eine gewisse Menge an Eigenschaften oder ein gewisses Verhalten gemeinsam haben (Gegner und Bosse können sich frei bewegen und ihre Projektile schaden dem Spieler, aber nicht sich gegenseitig)


wie genau du vorgehst bleibt dir überlassen
ich würde es aber empfehlen, zumindest eine kurze Zeit in diese Art der Überlegung zu investieren, bevor das Programmieren los geht


ich habe für die Beispiele bewusst das Shoot'em'up heran gezogen, da ein solches in der Regel einfacher ist, als ein Rollenspiel
einfacher als ein Rollenspiel dürfte beispielsweise ein Action Adventure sein, wie beispielsweise die Zelda-Reihe