Seite 1 von 2

Größeres Projekt strukturieren; aber wie am sinnvollsten?

Verfasst: 05.07.2006 15:49
von Phil
Ich habe vor ein paar sehr einfache Spiele (ca. 500 Zeilen Code je Spiel) in einem Project unterzubringen. Das Programmieren der einzelnen Spiele klappt soweit ganz gut, leider weiß ich aber nicht wie ich das ganze am geschicktesten strukturiere, wenn ich die Spiele aus einem Menü heraus aufrufen möchte und nicht den ganzen Code in einer Datei haben möchte.

Mir sind schon ein paar Lösungsansätze eingefallen, jedoch stoße ich bei diesen immer wieder auf größere Hindernisse:

1. Ansatz: Ich packe jedes Spiel komplett als Prozedur in eine .pbi-Datei, welche ich dann im Menüprogramm (Haupt-Code) mit IncludeFile einbinde und anschließend aufrufe. --- Problem: Es ist dann nicht mehr möglich normale Subroutinen mittels Gosub aufzurufen und es ergeben sich lauter verschachtelte Prozeduren.

2. Ansatz: Ich packe jeden Spielcode komplett in eine .pbi-Datei und binde sie an der Stelle in das Menüprogramm mit IncludeFile ein, an der das Spiel aufgerufen werden soll. --- Problem: Damit hätte ich zwar oberflächlich gesehen mehr Ordnung und Übersicht; In Wirklichkeit ist der Code jedoch unübersichtlich, da Variablen ja im gesamten Hauptprogramm bekannt sind und es so leicht zu folgenschweren Mehrfachverwendungen kommen kann.

:D Würde mich freuen, wenn ihr mir mit einem Lösungsvorschlag weiterhelfen könntet oder einfach eure Meinung zu den beiden Ansätzen posted.

Grüße Phil

Verfasst: 05.07.2006 16:24
von Kaeru Gaman
1. also, wenn du gerne mit GOSUB arbeiten möchtest - was bei einem umfang von 500 zeilen auch nicht gerade tötlich ist - kannst du alles in die proc packen, also, einschließlich der per gosub angesprungenen subroutinen, das müsste gehen.

2. wenn du ganz ohne procs mit durchgehendem code arbeitest, benenne SÄMTLICHE variablen mit einem präfix.
als beispiel, mal angenommen, du hättest PacMan, Pong und Mario als games, dann beginnen alle variablen in PacMan mit PM_, alle in Pong mit PG_, alle in Mario mit MA_.
dadurch kannst du mehrfachverwendungen auch ausschließen.

grundsätzlich jedoch solltest du dich vielleicht an procedurales programmieren gewöhnen.

Verfasst: 05.07.2006 17:48
von Phil
@Kaero Gaman
Vielen Dank für die schnelle Antwort! :)

Zu 1.
Kaeru Gaman hat geschrieben:... kannst du alles in die proc packen, also, einschließlich der per gosub angesprungenen subroutinen, das müsste gehen.
Zumindest in PB V4.0 bekomme ich sofort als Fehlermeldung, dass GOSUB in Prozeduren nicht verwendet werden darf.

Zum proceduralen Programmieren:
Wenn ich also in Proceduren keine Unterprogramme (mit Gosub) verwenden kann, bleibt doch nur noch die Möglichkeit statt den Unterprogrammen Proceduren zu verwenden, diese also zu verschachteln.
Würdest du dann alle Proceduren ganz oben im Code einfügen - die Inneren zu erst und dann die Äußeren - oder einfach oben alle Proceduren mit Declare in beliebiger Reihenfolge deklarieren und die Proceduren selbst dann an den Schluss des Codes stellen?

Verfasst: 05.07.2006 17:53
von AND51
Und wenn du jedes in eine eigene EXE packst? Ich weiß nicht das hätte z. B. den Vorteil, dass Variablen nicht überschreben werden oder so...

Verfasst: 05.07.2006 19:01
von Phil
Das mit den eigenen .exe-Dateien hatte ich mir auch schon überlegt, aber leider flackert dann der Bildschirm beim Öffnen bzw. Schließen des jeweiligen Spiels. Es sind keine Übergänge, wie Einblendung usw. möglich, oder? Außerdem gestaltet sich die Übergabe von Variableninhalten von einem Spiel zum nächsten oder zum Menüprogramm schwieriger.
Wenn ich mich mit meinen Einwänden täuschen sollte (bin schließlich noch nicht lange dabei), bitte Bescheid sagen!

Nichtsdestotrotz: Danke für deinen Tipp, AND51 :)

Verfasst: 05.07.2006 20:09
von AND51
Bitte!

Tolle Fenster-Effekte sind mit dem API-Befehl AnimateWindow_() möglich, also Scheiß was aufs Flackern ;-)

Probier das hier mal aus:

Code: Alles auswählen

;OpenWindow(...)
; Achtung! Das Fenster unbedingt verstecken mit #PB_Window_Invisible!


AnimateWindow_(WindowID(#WIndow), anzahl_Millisekunden, #AW_BLEND)
Hier ist der ausfühliche Code im codeArchiv: http://www.purearea.net/pb/CodeArchiv/W ... ndow-FX.pb

Verfasst: 05.07.2006 20:35
von ts-soft

Code: Alles auswählen

XIncludeFile "PacMan.pbi"
XIncludeFile "Pong.pbi"
XIncludeFile "SuperMario.pbi"


Procedure Main()
  ; Init Stuff
  ; Menu
  ; was weiß ich
EndProcedure

Main()
So in etwa. Declarationen sind meist Geschmackssache, ich hab lieber die
Prozeduren in der Reihenfolge, wie sie logisch gebraucht werden. Mit anderen
Worten, ich fange unten an und gehe mit jeder Prozedure im Editor nach oben :wink:

Eine Zeile ausserhalb von Prozeduren sollte genügen in den meisten Fällen.

Verfasst: 06.07.2006 10:27
von Kaeru Gaman
wie ts vorgeschlagen hat ist sozusagen die "ideale" procedurale programmierung,
wirklich alles in Procedures zu packen, und nurnoch den Main()-aufruf im hauptcode zu haben.
afaik schließt das dann aber die verwendung globaler variablen komplett aus.
(jetzt bitte keine diskussion über das für und wider globaler variablen -
das hier ist eine anfängerfrage betreff des einstiegs in prozedurale strukturierung,
und nicht ihrer vollendeten anwendung. ;) )

natürlich wäre es am besten, jeweils die code-abschnitte zwischen Label und RETURN in eine proc zu packen.
wenn jeder der einzelcode max. 500lines hat, sollte das auch nicht das problem werden.
du musst aber sehr darauf achten, welche variablen du gemeinsam verwendest.
diese musst du entweder als argumente/parameter an die procs übergeben,
oder per Global bzw. Shared allen zugänglich machen.
ACHTUNG: bei Global oder Shared hast du wieder das problem von programmübergreifenden namensgleichheiten.

es wird zweifellos einige mühen kosten, mehrere auf GOSUB basierende kleinprogramme
auf prozedural umzustricken und in einen einzigen code zu packen, aber wenn du das geschafft hast, dann kannst du's wirklich. ;)

zu der lösung mit mehreren EXE:
die übergänge wirst du nicht auf die schnelle mit akzeptablem aufwand weich bekommen,
und das sollte auch nicht deine priorität sein.
der vorschlag von AND ist zwar eine gute anregung, aber das ist schon ein thema für sich.
außerdem hast du nichts davon gesagt, dass du mit fenstern arbeitest,
und für einen fullscreen ist AnimateWindow() afaik nicht anwendbar.
grundsätzlich ist aber parameterübergabe nicht das problem,
da du sowohl bei RunProgram() parameter angeben kannst,
als diese auch im aufgerufenen programm auswerten.

Verfasst: 06.07.2006 10:57
von #NULL
solange vom menu aus immer nur ein spiel gestartet wird, können bezeichner doch problemlos in mehreren spielen gleich sein. man muss nur darauf achten, dass sie beim start eines spiels eventuell noch veraltete werte besitzen, bzw dass sie nicht mit dem main/menu -teil kollidieren.

Verfasst: 06.07.2006 11:03
von Kaeru Gaman
#NULL hat geschrieben:solange vom menu aus immer nur ein spiel gestartet wird, können bezeichner doch problemlos in mehreren spielen gleich sein. man muss nur darauf achten, dass sie beim start eines spiels eventuell noch veraltete werte besitzen, bzw dass sie nicht mit dem main/menu -teil kollidieren.
parbleu - wo er recht hat, hat er recht!

wenn du zu beginn deiner einzelgames alle variablen sauber initialisierst,
ist es banane, wo sie sich überschneiden.

ó_ò . . >__<" dass mir das nich gleich aufgefallen ist... Wald und Bäume halt.. dz