nicht angemeldet
Hi,
Bisher bin ich schon zwei Mal an einem größeren privaten Projekt gescheitert,
Nur zwei mal? Noch jung, was? ;-)
Na, das wird noch öfter vorkommen, mach Dir nix draus.
nicht mal die Tonnen an Kommentaren halfen die ich dazugschrieb.
Zuviel istauch nicht gesund.
Am liebsten wäre mir natürlich ein objektorientiertes Datenmodell
Warum? Nein, wirklich: welchen Grund hast Du ein objektorientiertes Datenmodell anzuwenden?
Wie geht ma so etwas eigentlich am besten an?
Üben.
Gibt es irgendwelche Eselsbrücken
Mmh... ja, es gibt da so einiges, aber keine Patentrezepte. Die "Standardwerke" über Datenstrukturen und Algorithmen wurden Dir ja schon empfohlen.
Aber eine Regel, die mit Sicherheit schon irgendwann einmal angesprochen wurde, die ich aber gerne noch einmal wiederhole: "Keep it simple, stupid!"
- keine komplexen Algorithmen für einfache Aufgaben
- auch für komplexe Aufgaben kann es einfache Algorithmen geben es ist jedoch unwahrscheinlich, wenn in Sedgwick et al nichts darüber zu finden ist.
- "Gut genug" ist gut genug und bedarf keiner Optimierung.
Natürlich habe ich immer grobe Vorstellungen darüber, was ich ungefähr wie strukturieren will, aber letztendlich scheitere ich dann doch letztendlich immer wieder an den Feinheiten.
Dann mußt Du Deine Vorstellungen verfeinern. Sammel zusammen, was Du benötigst und programmiere das.
Sowas Banales! Ts!
Moooment! ;-)
Ersteinmal sollst Du sammeln, was Du benötigst und nicht, was Du nicht benötigst. "Das Programm soll nicht abstürzen" ist keine gute Anweisung, denn ich kann Dir ein Programm schreiben, das die Platte putzt jedoch nicht abstürzt. War es das, was Du mit "Das Programm soll nicht abstürzen" bezweckt hattest? Wohl kaum, was? ;-)
Du möchtest doch ein Spielchen programmieren, ja? Mit einem Ball? Dann mal anhand eines Ballspieles: Pong gegen die Wand.
Was wird dazu benötigt? Ein Ball, eine Wand und ein Mittel mit dem man den Ball bewegen kann. Die nötigen Algorithmen sind "Einfallswinkel gleich Ausfallswinkel" und "Geschwindkeit gleich Weg durch Zeit".
Daraus kannst Du jetzt die Datenstrukturen ziehen:
So ein Ball hat einige Eigenschaften, ganz ohne wär's kein Ball. Da jemand damit spielen soll, muß er den Ball erkennen können. Der Einfachheit halber nehmen wir mal visuelle Wahrnehmung an, der Ball muß sichtbar sein. Das bedingt schonmal, das sich die Farbe des Balles deutlich von der Farbe des Hintergrundes unterscheidbar sein muß. Erste Eigenschaft ist also die Farbe und im Hinterkopf entsteht schon der erste Bezug, nämlich der zur Hintergrundfarbe. Ist der Ball kleiner als ein Pixel ist er nicht sichtbar, also muß er eine gewisse Größe haben. Zweite Eigenschaft ist somit die Dimension.
Der Ball hat somit neben seiner schieren Existenz noch zwei weitere Eigenschaften. Aber man könnte, wenn das Solitärpong einmal funktioniert auf die Idee kommen noch ein paar Gimmicks einzubauen. Z.B. ist von Bällen bekannt, das sie eine unterschiedlichen Grad an Elastizität haben können, nicht nur Farbe sondern auch Muster, verschieden rauhe Oberflächen usw. Es wäre demnach empfehlenswert die Datenstruktur "Ball" erweiterbar zu halten. Wie dies genau zu geschehen hat ist die Sache der Programmiersprache, bei C würde ich z.B. ein Struct vorschlagen, das läßt sich problemlos erweitern.
Die gleiche Prozedur wäre dann noch mit Wand und Schläger durchzuführen. Wenn Du dann anfängst Code zu schreiben oder vielleicht sogar schon vorher fällt Dir auf, das da noch Wesentliches fehlt. Verschiedene Fragen wie z.B. "Wie groß soll das Spielfeld sein?", "Was passiert mit Bällen, die außerhalb des Spielfeldes landen?", "Welche Anfangsgeschwindigkeit hat der Ball?" und "Wo kommt der Ball am Anfang her" tauchen auf und drängen unnachgiebig darauf beantwortet zu werden.
Ah, noch ein Tip von jemandem, der schon öfter darauf reingefallen ist: falle nicht auf Buzzwords rein, denke selber und zwar nach!
so short
Christoph Zurnieden