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

Anfängerfragen zum Programmieren mit PureBasic.
Phil
Beiträge: 32
Registriert: 05.07.2006 10:46

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

Beitrag 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
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag 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.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Phil
Beiträge: 32
Registriert: 05.07.2006 10:46

Beitrag 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?
Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Beitrag 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...
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
Phil
Beiträge: 32
Registriert: 05.07.2006 10:46

Beitrag 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 :)
Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Beitrag 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
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag 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.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag 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.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
#NULL
Beiträge: 2238
Registriert: 20.04.2006 09:50

Beitrag 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.
my pb stuff..
Bild..jedenfalls war das mal so.
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag 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
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Antworten