Programmplanung

[sobi]

Hallo alle zusammen,

mal ne ganz allgemeine Frage. Wie geht ihr vor, wenn ihr ein neues Programm schreibt. Was plant ihr, worüber macht ihr euch detailierte Gedanken, was kommt später hinzu, wenn ihr schon "am werkeln" seit?

Liebe Grüße, Simon

[STARGÅTE]

Bei mir ist das immer so :
- Kann ich meine Idee mit PB schreiben?
- Für welchen Bereich soll es sein (PC, LAN, INTERNET)?
- Kann ich die benötigte Grafik erstellen oder erstellen lassen?

Nach diesen 3 Fragen fange ich dann meistens an die ersten Zeilen zu schreiben.

Sobalt die Grundzeilen stehen, mache ich mir detailierte Gedanken, und mache dann diese Dinge:
- Schreiben von mehreren PB-Cods um Effekte oder Aussehen zu testen
- Erstellung von Beta-Grafiken
- Erstellung von Beta-Sounds
- Ansätze programmieren von verschiedenen Sachen die vllt mal vorkommen sollen.

Hier entscheidet sich meistens, ob ich das Programm zum Ziel bringe oder ob es unvollendet bleibt.

Wenn das Programm dann zum ersten mal Funktionstüchtig ist setzte ich mich daran diese Sachen zu machen:
- Erstellung von End-Grafiken
- Erstellung von End-Sounds
- Programmcode säubern (klappt meistens nie ^^)
- Verbesserungen

Nun stelle ich das Programm zum ersten mal ausgewählten Leuten vor und lasse mir Tips geben. Danach kommen dann nur noch:
- Verbesserungsphasen
- Erweiterungen
- Hilfe schreiben

[tmjuk]

Hallo,

ich habe mal gehört, dass bei den meisten Leuten wohl das "About"-Fenster zuerst fertig ist

Aber Spaß beiseite. Ich mache es so ähnlich. Wobei bei mir nie im Vordergrund steht, ob das wirklich fertig wird. Das ergibt sich dann sowieso mit der Zeit.
Also
- entscheiden, mit welcher Sprache man schreibt
- grobes Skizzieren in verschiedene Module (z.B. Eingabe, Ausgabe, Fehlerbehandlung, Dateihandling usw.)
- Herausstellung von Problembereichen und Lösung der Probleme anhand kleinerer Programme (z.B. Grafikausgabe o.ä.)
- geziehltes Schreiben der einzelnen Module
- Module einzeln testen (wenn's geht)
- zusammenführen der Module zur einer lauffähigen Testversion

Tja, und dann kommt die Phase des Testens und Verbesserns.

So versuche ich meistens vorzugehen. (Klappt aber oft nicht, wegen mangelnder Selbstdisziplin)

@ sobi : Wie machst du es denn?
Torsten

[ZeHa]

Bei mir spielt auf jeden Fall auch Papier eine große Rolle. Bei objektorientierten Sprachen kann man sich auf jeden Fall mal grob eine Übersicht über alle Klassen zurechtmalen. Aber auch bei PB programmiere ich mittlerweile einigermaßen objektorientiert (soweit das halt möglich ist), daher läßt sich das im Prinzip genauso handhaben.

Hin und wieder bin ich auch zu faul, Papier zu benutzen, daher mach ich mir dann Skizzen in Paint aber letztendlich ist es ja auch egal, Hauptsache, man macht sich überhaupt Gedanken um den Aufbau seines Codes.

Da ich hauptsächlich Spiele programmiere, muß ich mir im Vorfeld natürlich auch Gedanken um den Inhalt und um das Gameplay des Spiels machen. Das läuft ganz unterschiedlich ab, aber meist fange ich erst zu programmieren an, wenn ich eine klare Richtung vor mir habe. Dann wird ein kleiner Prototyp erstellt, der meist aber dann direkt zum Endprodukt ausgebaut wird.

Ganz am Anfang meiner Programmier-Karriere (auf dem C64 war das noch), da hab ich auch zuerst die Intros und Menüs usw. programmiert aber davon ist natürlich abzuraten. Die Reihenfolge der Elemente, die der User später so zu sehen kriegen wird, sollte nicht der Reihenfolge der Programmierung entsprechen. Sondern man beginnt mit dem Kern und baut dann nach und nach den ganzen Schnickschnack drumherum.

[AndyX]

ich progge immer zuerst die GameEngine/das eigentliche Spiel, wenn es halbwegs läuft kommen Gfx + Verbesserungen hinzu, und gaaaaanz am Schluss dann Sfx + Hauptmenü

[mk-soft]

Papier lege ich mir nicht mehr an. Pflegt man sowie so nicht.

Bei grösseren Projekten lege ich erst mal mehre Dateien an.
-Global.pb
-Struktruen.pb
-Funktionen.pb
-etc

Dann schreibe ich mit ausreichenden Kommentarzeilen die Basis.

Erstelle mir mit den Designer die Masken verteilt auf verschiedene Common Dateien.

Jage diese dann durch mein VisualGeneric um schon mal für alle Menus und Gadgets alle Events bereit zu stellen.
Binde die Funktionen mit den Events.

Somit habe ich die Basis mit Oberfläche vorbereitet.

FF

[STARGÅTE]

[...], und gaaaaanz am Schluss dann Sfx + Hauptmenü

*sich tot lach und auf den Boden schmeiß*

Das finde ich bei mir auch immer cool, nach dem das Spiel läuft, kommt bei mir dann immer die Frage "Da fehlt doch was" ... Die komplette Menüstruktur ^^

[Kaeru Gaman]

yo..
zumindest über das konzept der menustruktur sollte man sich von anfang an im klaren sein.

also z.b. sitzt es nachher in der selben hauptschleife, wenn ja,
wie regel ich das mit den flags, pack ich mein ganzen game krempel in ne proc
oder hab ich tausend codezeilen innerhalb von nem select/case....

man sollte schon mal nebenbei dran denken, vielleicht auch schon das Flag und nen vorab-button "play" einbaun...

...aber auf keinen fall ans design setzen.

[ZeHa]

Objektorientiert gesehen löse ich das immer so, daß ich ein Game-Objekt, ein Menü-Objekt, ein HighscoreScreen-Objekt usw habe, und immer nur eines kann aktiv sein. Meine "Haupt-Haupt-Schleife" macht dann nix anderes als immer nur den aktiven "Screen" zu updaten, egal ob das nun das Game oder das Menü ist. Was genau passiert, regeln die dann intern, und wenn gewechselt wird, wird der vorige Screen einfach auf "Sendepause" geschalten und der neue aktiviert.

[a14xerus]

So mache ich das auch
(wusste nur nicht, das das OO ist)
Aber da ich häufiger Programme als Spiele schreibe, ist das antürlich noch einmal anders.
Wobei ich auch da nur eine Eventloop habe, und je nachdem welche fenster aktiv sind werde andere Proceduren jeden Durchgang (oder zeit gesteuert) ausgeführt.

Zum "Vorbeireiten" meiner Projekte:

Zuerst überleg ich mir natürlich, was ich machen will (meistens Windows-Applikationen) und mit welchen Hilfsmitteln ich das bewerkstelligen will (externe DLL's (Z.B.: FMOD)).
Dann schreibe ich die Fenster Proceduren, und die Einstellungsprocedure (die die das schreiben und lesen der Datei, wo man seine individuellen Einstellungen später abspeichert, damit diese beim laden direkt bei der Fensterprocedure ausgeführt werden (zb Sprache)).
Dann kommt der Eventloop (immer Forever) udn die Procedure ende().
Der Eventloop besteht derzeit nur aus der "#Pb_event_closeWindow" abfrage.
Danach werden Proceduren geschreiben, die die einzelnen events wie gadget-klicks und menüeinträge übernehmen. Das Fenster wird dementsprechend erweitert.
Mein Mainloop besteht nur auf einer großen Select, die Cases immernur aus einem Proceduren aufruf.
Zb Procedure ButtonPlay() übernimmt das überprüfen auf "pause/play/stop/liste leer und ruft dann die Hauptfunktionen "PlaySound()"/"PauseSound()"/"ResumeSound()"/"LoadSound()" auf (kleines Beispiel).

so wird alles immer erweiter (zeitgestuerte Callbacks, mehr Proceduren, Sicherheitsproceduren (zeitmesser wg nicht reagieren etc (aber erst ganz am ende))evt DLL...)

Diese Art des Programmierens benutze ich seit Ca einem Halben Jahr udn ich komme gut zurecht (bei neinem Vorherigen Projekten kam ich sonst meistens in unerreichbar hohe CPU Auslastungen , unnötigen HDD zugriffen, endlosschleifen etc.
Unmöglicher Codestil eben