Umfrage Frameworks

Übersicht

Sonstiges

Smalltalk

	Firstdeathmaker Betreff: Umfrage Frameworks	Mo, Okt 26, 2009 9:18 Antworten mit Zitat
Eher an die Fortgeschrittenen gerichtet: Thema: Wie strukturiert Ihr eure Programme? Ich denke mal das ist ein wichtiges Thema, kommt man bei einem neuen Projekt doch immer wieder zu der Frage: Benutze ich ein altes Grundgerüst? Programmiere ich es komplett neu, da ich Schwierigkeiten hatte es zu benutzen, es an einer Stelle einfach total versagt hat oder mir vom Design heutzutage nicht mehr so wirklich gefällt? Ich will also einfach mal so Ideen sammeln, und vielleicht auch codes, wie ihr eure Programme strukturiert oder ob und welche Grundframeworks ihr so benutzt. Meine Antwort: Also ich wurde bei meinem Standartframework von Diesem Beispiel inspiriert, habe es allerdings immer weiter verfeinert, und bin heutzutage aber fast soweit es wieder aufzugeben. Der Grundgedanke ist der, dass man sein ganzes Spiel in sog. Gamestates unterteilt (Hauptmenü, Levelauswahl, Game, Credits etc.) von welchen dann immer nur einer aktiv ist und vom Gamemanager verwaltet wird. Wenn man den State wechseln möchte, muss man dies über den Gamemanager tun. Darüber hab ich eine GUI gebastelt, welche viele Standartfunktionen unterstützt und teilweise XML-Stylesheets verarbeitet, sodass Grafiker und Programmierer unabhängig voneinander arbeiten können. Natürlich muss man komplexere Sachen trotzdem noch hardcoden, aber für Buttons und Hintergründe reicht es allemal. Ich habe allerdings festgestellt, das es manchmal doch etwas unflexibel ist, da man ja sein ganzes Spiel immer in diese Blöcke unterteilen muss. Es ist also nicht möglich bzw. kontraproduktiv, wie z.B. bei Razoon ein Menü über dem Spielfeld zu bauen und dann daraus direkt ins Spiel zu wechseln, oder verschiedene Gamestates wie MainMenue und Highscore direkt ineinander übergehen zu lassen. Auch aufgrund der neuen Multithreading-Fähigkeit von BMax hatte ich daher immer wieder über eine feinere Strukturierung in Prozesse nachgedacht, wodurch es z.B. möglich wird on-the-fly Leveldaten nachzuladen, wärend dem Spiel zu speichern ohne das es pausiert werden muss etc., allerdings wird das ganze dann ganz schnell sehr kompliziert, und mir ist bisher noch keine gute Möglichkeit eingefallen das zu designen. Naja, jedenfalls bin ich hier mal auf eure Konzepte und Ideen gespannt.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Betreff: Umfrage Frameworks

Mo, Okt 26, 2009 9:18
Antworten mit Zitat

Eher an die Fortgeschrittenen gerichtet:

Thema: Wie strukturiert Ihr eure Programme?

Ich denke mal das ist ein wichtiges Thema, kommt man bei einem neuen Projekt doch immer wieder zu der Frage: Benutze ich ein altes Grundgerüst?
Programmiere ich es komplett neu, da ich Schwierigkeiten hatte es zu benutzen, es an einer Stelle einfach total versagt hat oder mir vom Design heutzutage nicht mehr so wirklich gefällt?

Ich will also einfach mal so Ideen sammeln, und vielleicht auch codes, wie ihr eure Programme strukturiert oder ob und welche Grundframeworks ihr so benutzt.

Meine Antwort:
Also ich wurde bei meinem Standartframework von Diesem Beispiel inspiriert, habe es allerdings immer weiter verfeinert, und bin heutzutage aber fast soweit es wieder aufzugeben. Der Grundgedanke ist der, dass man sein ganzes Spiel in sog. Gamestates unterteilt (Hauptmenü, Levelauswahl, Game, Credits etc.) von welchen dann immer nur einer aktiv ist und vom Gamemanager verwaltet wird. Wenn man den State wechseln möchte, muss man dies über den Gamemanager tun.
Darüber hab ich eine GUI gebastelt, welche viele Standartfunktionen unterstützt und teilweise XML-Stylesheets verarbeitet, sodass Grafiker und Programmierer unabhängig voneinander arbeiten können. Natürlich muss man komplexere Sachen trotzdem noch hardcoden, aber für Buttons und Hintergründe reicht es allemal.

Ich habe allerdings festgestellt, das es manchmal doch etwas unflexibel ist, da man ja sein ganzes Spiel immer in diese Blöcke unterteilen muss. Es ist also nicht möglich bzw. kontraproduktiv, wie z.B. bei Razoon ein Menü über dem Spielfeld zu bauen und dann daraus direkt ins Spiel zu wechseln, oder verschiedene Gamestates wie MainMenue und Highscore direkt ineinander übergehen zu lassen.

Auch aufgrund der neuen Multithreading-Fähigkeit von BMax hatte ich daher immer wieder über eine feinere Strukturierung in Prozesse nachgedacht, wodurch es z.B. möglich wird on-the-fly Leveldaten nachzuladen, wärend dem Spiel zu speichern ohne das es pausiert werden muss etc., allerdings wird das ganze dann ganz schnell sehr kompliziert, und mir ist bisher noch keine gute Möglichkeit eingefallen das zu designen.

Naja, jedenfalls bin ich hier mal auf eure Konzepte und Ideen gespannt.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	aMul Sieger des Minimalist Compo 01/13	Mo, Okt 26, 2009 13:40 Antworten mit Zitat
Ich mache mein Grundgerüst eigentlich jedes mal von Grund auf neu. Natürlich gibt es Zeilen die da immer dabei sind, zum Beispiel eine Hauptschleife, aber abgesehen davon gestalte ich es so, wie es für das Projekt am besten passt. Das heißt also, dass ich für größere Sachen objektorientierter arbeite, während kleine Spielereien mit eienr einfachen Struktur auskommen. Generell kann ich aber sagen, dass es sich meiner Meinung nach immer lohnt möglichst objektorientiert zu arbeiten. Das macht nicht nur Spaß sondern sorgt auch für Übersichtlichkeit, Flexibilität und Wiederverwendbarkeit.
Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben! advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans! Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! \| RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 \| Stereoskopie in Blitz3D \| Teleport-Animation Screensaver

aMul

Sieger des Minimalist Compo 01/13

Mo, Okt 26, 2009 13:40
Antworten mit Zitat

Ich mache mein Grundgerüst eigentlich jedes mal von Grund auf neu.
Natürlich gibt es Zeilen die da immer dabei sind, zum Beispiel eine Hauptschleife, aber abgesehen davon gestalte ich es so, wie es für das Projekt am besten passt.
Das heißt also, dass ich für größere Sachen objektorientierter arbeite, während kleine Spielereien mit eienr einfachen Struktur auskommen.

Generell kann ich aber sagen, dass es sich meiner Meinung nach immer lohnt möglichst objektorientiert zu arbeiten. Das macht nicht nur Spaß sondern sorgt auch für Übersichtlichkeit, Flexibilität und Wiederverwendbarkeit.

Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben!
advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans!
Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! | RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 | Stereoskopie in Blitz3D | Teleport-Animation Screensaver

	Kernle 32DLL	Mo, Okt 26, 2009 15:25 Antworten mit Zitat
Bei mir kommt es drauf an. Wenn ich kleinere Projekte mache dann nutze ich dafür natürlich nicht ein massives Engine Gerüst von mir, sondern programmiere eine kleine schlanke Basis. Aktuell arbeite ich quasi parallel zu meinem Hauptprojekt an desen Technischer Basis, einer einfachen Klasse namens TEngine, die quasi das Herz des ganzen Enginegerüsts ist. Die Klassen liefert einen Satz von Funktionen und Methoden, u.a. zum Debugen oder auch um Instanzen miteiner zu verknüpfen. Alle anderen Klassen sind von dieser Basisklasse abgeleitet. Generell versuche ich immer je nach Aufwand von vorherigen Projekten Dinge weiterzuverwenden. Bei B3D habe ich das sehr sehr oft gemacht, bei BMax geht das bei mir schlicht noch nicht, da ich noch nichts habe was ich wo anders weiterverwenden könnte (ich habe nur ein BMax Projekt bisher). So long, Kernle
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Mo, Okt 26, 2009 15:25
Antworten mit Zitat

Bei mir kommt es drauf an. Wenn ich kleinere Projekte mache dann nutze ich dafür natürlich nicht ein massives Engine Gerüst von mir, sondern programmiere eine kleine schlanke Basis.

Aktuell arbeite ich quasi parallel zu meinem Hauptprojekt an desen Technischer Basis, einer einfachen Klasse namens TEngine, die quasi das Herz des ganzen Enginegerüsts ist. Die Klassen liefert einen Satz von Funktionen und Methoden, u.a. zum Debugen oder auch um Instanzen miteiner zu verknüpfen. Alle anderen Klassen sind von dieser Basisklasse abgeleitet.

Generell versuche ich immer je nach Aufwand von vorherigen Projekten Dinge weiterzuverwenden. Bei B3D habe ich das sehr sehr oft gemacht, bei BMax geht das bei mir schlicht noch nicht, da ich noch nichts habe was ich wo anders weiterverwenden könnte (ich habe nur ein BMax Projekt bisher).

So long,
Kernle

Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog]
Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89
Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

	E. Urbach ehemals "Basicprogger"	Mo, Okt 26, 2009 18:50 Antworten mit Zitat
FDM hat Folgendes geschrieben: Auch aufgrund der neuen Multithreading-Fähigkeit von BMax ...welche ich getestet habe und man eigentlich nur als Schrott bisher bezeichnen kann. Der GC ist viel zu langsam, er unterbricht das Programm und es ruckelt, man kann Threading momentan nur mit GCSetMode 2 und ohne Einsatz von GCCollect() benutzen, wodurch der Sinn vom GC verschwindet. Das war zumindest meine Erfahrung mit BMax 1.34. Zurück zum Thema. Ich benutze auch eine GameState-Aufteilung und kann nicht klagen: Code: [AUSKLAPPEN] [EINKLAPPEN] Type TGameState Abstract Method Init() Abstract Method Update() Abstract Method Remove() Abstract Method ToString:String() Abstract End Type Ein GameState wechselt zum anderen über die Manager-Klasse, die SetGameStateByName(name:String) bereitstellt. Wie gesagt, bisher entspricht diese Aufteilung genau dem, was ich benötige und ich bin nicht - wie in deinem Menü > Highscore Beispiel - an Grenzen gestoßen. Übrigens kann man dein Menü > Highscore Beispiel z. B. so lösen, dass du dem zweiten GameState Informationen zum Framestatus übermittelst oder einen extra "Switch"-GameState einbaust. Nicht gerade die beste Lösung, aber funktionieren würde es.
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Mo, Okt 26, 2009 18:50
Antworten mit Zitat

FDM hat Folgendes geschrieben:

Auch aufgrund der neuen Multithreading-Fähigkeit von BMax

...welche ich getestet habe und man eigentlich nur als Schrott bisher bezeichnen kann. Der GC ist viel zu langsam, er unterbricht das Programm und es ruckelt, man kann Threading momentan nur mit GCSetMode 2 und ohne Einsatz von GCCollect() benutzen, wodurch der Sinn vom GC verschwindet. Das war zumindest meine Erfahrung mit BMax 1.34.

Zurück zum Thema.

Ich benutze auch eine GameState-Aufteilung und kann nicht klagen:
Code: [AUSKLAPPEN]

Type TGameState Abstract
Method Init() Abstract
Method Update() Abstract
Method Remove() Abstract
Method ToString:String() Abstract
End Type

Ein GameState wechselt zum anderen über die Manager-Klasse, die SetGameStateByName(name:String) bereitstellt. Wie gesagt, bisher entspricht diese Aufteilung genau dem, was ich benötige und ich bin nicht - wie in deinem Menü > Highscore Beispiel - an Grenzen gestoßen.

Übrigens kann man dein Menü > Highscore Beispiel z. B. so lösen, dass du dem zweiten GameState Informationen zum Framestatus übermittelst oder einen extra "Switch"-GameState einbaust. Nicht gerade die beste Lösung, aber funktionieren würde es.

The box said, "Requires Windows XP or better", so I installed Ubuntu | Linux is NOT Windows
Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

Zuletzt bearbeitet von E. Urbach am Di, Okt 27, 2009 13:35, insgesamt einmal bearbeitet

	TimBo	Mo, Okt 26, 2009 19:27 Antworten mit Zitat
Hi, also bei mir sieht der Mainloop meisten so aus Beispiel: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] Select Pointer Case 1 menue() drawmap() Case 2 drawmap() physiks() End Select ich bin noch nicht an die Grenzen der Flexiblität gestoßen. Benutze BB3D und daher kann ich eh kein OOP verwenden. Greez TimBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mo, Okt 26, 2009 19:27
Antworten mit Zitat

Hi,

also bei mir sieht der Mainloop meisten so aus
Beispiel:
BlitzBasic: [AUSKLAPPEN]

Select Pointer
   Case 1
      menue()
      drawmap()
  Case 2
      drawmap()
      physiks()
End Select

ich bin noch nicht an die Grenzen der Flexiblität gestoßen.
Benutze BB3D und daher kann ich eh kein OOP verwenden.

Greez
TimBo

mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10
Stolzer Gewinner des BCC 25 & BCC 31
hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

	Firstdeathmaker	Mo, Okt 26, 2009 21:57 Antworten mit Zitat
Erstmal danke für alle eure Antworten. @ Basicprogger: Ja, ich benutze das Multithreading von BMax auch nicht wirklich, hab aber immer noch die Hoffnung das es sich bessert. Und klar kann man sich das trotzdem zurechtbasteln, nur wird beim ändern des Gamestates unweigerlich ein kleiner Ruckler auftauchen. Die Gamestates dienen ja auch ein wenig der Absicherung gegen Speicherleaks etc, daher sollte man sie nicht mit Globalen Instanzen umgehen, auch weil das weitere Speicherleaks über den GC nach sich zieht wie ich feststellen musste. @TimBo: Unter BB würde ich es ähnlich machen, nur dass ich am Anfang für die verschiedenen States Konstante definieren würde, sodass nicht mehr Select.. case 1, case 2 da stehen würde, sondern select case MAINMENUE, select HIGHSCORES.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Mo, Okt 26, 2009 21:57
Antworten mit Zitat

Erstmal danke für alle eure Antworten.

@ Basicprogger: Ja, ich benutze das Multithreading von BMax auch nicht wirklich, hab aber immer noch die Hoffnung das es sich bessert. Und klar kann man sich das trotzdem zurechtbasteln, nur wird beim ändern des Gamestates unweigerlich ein kleiner Ruckler auftauchen. Die Gamestates dienen ja auch ein wenig der Absicherung gegen Speicherleaks etc, daher sollte man sie nicht mit Globalen Instanzen umgehen, auch weil das weitere Speicherleaks über den GC nach sich zieht wie ich feststellen musste.

@TimBo: Unter BB würde ich es ähnlich machen, nur dass ich am Anfang für die verschiedenen States Konstante definieren würde, sodass nicht mehr Select.. case 1, case 2 da stehen würde, sondern select case MAINMENUE, select HIGHSCORES.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	ComNik	Mo, Okt 26, 2009 22:16 Antworten mit Zitat
Also Forgeschritten bin ich nicht aber ich kann vielleicht trotzdem was beisteuern. Ich plane mein erstes wirklich größeres Spiel und einzig für das Spiel habe ich angefangen ein Game-Framework zu schreiben. Das ist im Moment aber so flexibel, dass ich es problemlos in anderen Spielen verwenden könnte. Mein Plan für die Zukunft sieht aber eher so aus: - Bis Weihnachten das Framework zu 50% fertigstellen - Mit der Entwicklung des Spiels anfangen - Während der Entwicklung das Framework fertigstellen - Ich hab ca. 1 Jahr Entwicklungszeit eingeplant (eigentlich zu wenig aber aufgrund des Frameworks...) - Wenn das Spiel fertig ist wollte ich das Framework veröffentlichen Dann hab ich noch ein größeres Projekt in C++ dem ich mich dann voll widme. BlitzMax ist zwar genial wird aber dann nicht mehr meine Hauptsprache sein. [EDIT:] Ich glaub ich versteh was anderes unter Framework als FDM :/ Also ich mein das so, dass das Framework mir viel Arbeit abnimmt: Im Moment besteht es aus: - Physik Engine (inzwischen neu geschrieben, 20%) - Partikel Engine (inzwischen 60%) - GUI (siehe Worklog... ca. 50%) - MapEngine (ca. 70%) - Licht&Schatten Engine (ca. 50%) ein paar kleinere Hilfsfunktionen... Als erstes wird die Physik Engine fertiggestellt. Das Spiel selber wird auch über einen GameManager gesteuert. Die GameStates haben jeder eine Update und eine Render funktion (grob gesagt). [/EDIT] lg ComNik
WIP: Vorx.Engine

ComNik

Mo, Okt 26, 2009 22:16
Antworten mit Zitat

Also Forgeschritten bin ich nicht aber ich kann vielleicht trotzdem was beisteuern. Ich plane mein erstes wirklich größeres Spiel und einzig für das Spiel habe ich angefangen ein Game-Framework zu schreiben. Das ist im Moment aber so flexibel, dass ich es problemlos in anderen Spielen verwenden könnte.

Mein Plan für die Zukunft sieht aber eher so aus:
- Bis Weihnachten das Framework zu 50% fertigstellen
- Mit der Entwicklung des Spiels anfangen
- Während der Entwicklung das Framework fertigstellen
- Ich hab ca. 1 Jahr Entwicklungszeit eingeplant (eigentlich zu wenig aber aufgrund des Frameworks...)
- Wenn das Spiel fertig ist wollte ich das Framework veröffentlichen

Dann hab ich noch ein größeres Projekt in C++ dem ich mich dann voll widme. BlitzMax ist zwar genial wird aber dann nicht mehr meine Hauptsprache sein.

[EDIT:] Ich glaub ich versteh was anderes unter Framework als FDM :/
Also ich mein das so, dass das Framework mir viel Arbeit abnimmt:
Im Moment besteht es aus:
- Physik Engine (inzwischen neu geschrieben, 20%)
- Partikel Engine (inzwischen 60%)
- GUI (siehe Worklog... ca. 50%)
- MapEngine (ca. 70%)
- Licht&Schatten Engine (ca. 50%)

ein paar kleinere Hilfsfunktionen...

Als erstes wird die Physik Engine fertiggestellt.

Das Spiel selber wird auch über einen GameManager gesteuert. Die GameStates haben jeder eine Update und eine Render funktion (grob gesagt).
[/EDIT]

lg
ComNik

WIP: Vorx.Engine

	Firstdeathmaker	Mi, Okt 28, 2009 10:04 Antworten mit Zitat
"Framework" ist ein weiter Begriff, meine Ausführungen gingen eher auf den Core ein. Nichtsdestotrotz muss man natürlich seine Zusatzmodule einbinden. Nur wie macht man das am besten? Der Ansatz über die Gamestates hat ja gerade den Vorteil, dass man die verschiedenen Teile sauber voneinander trennen kann. Wenn man jetzt aber z.B. ein Musikmodul schreibt, sollte dass ja nicht in jedem State neu gestartet werden müssen. Vielmehr möchte man ja, dass die Musik ständig läuft, sich aber in bestimmten Situationen ändert. Dazu fallen mir jetzt so spontan folgende Lösungen ein: 1. Man baut die Musikengine so auf, dass Sie global existiert und nur über Funktionsaufrufe gesteuert wird. Dadurch verliert man allerdings die eindeutige Datenzuordnung zu bestimmten Frames, d.h. wenn man in einem Spielabschnitt eine Menge Sounds benötigt, müssen diese immer in der Engine vorhanden sein, ausser man programmiert hier eine weitere Datenorganisation mit ein. 2. Man baut die Musikengine Objektorientiert und erzeugt an übergeordneter Stelle (z.B. in einem EngineManager) eine Instanz derselben. Den EngineManager müsste man natürlich für alle Gamestates verfügbar machen. 3. Man erzeugt einmal eine Instanz, und reicht diese von State zu State weiter. Der Nachteil dabei ist der, dass man eben immer extra weitergeben muss. Ist daher ziemlich unpraktisch. Ich weis nicht wie ihr das seht, aber meiner Meinung nach sollte eine saubere OO Lösung am Ende über nur noch ein einziges globales Objekt instanziiert werden. Alle anderen Objekte sind dann in diesem verlinkt (also eine Art Baumstruktur). Daher tendiere ich in meinen Frameworks immer eher zu Lösung 2. Problem besteht halt darin, dass man aufpassen muss, die benutzten Engines am Ende eines States auch aufzuräumen.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Mi, Okt 28, 2009 10:04
Antworten mit Zitat

"Framework" ist ein weiter Begriff, meine Ausführungen gingen eher auf den Core ein. Nichtsdestotrotz muss man natürlich seine Zusatzmodule einbinden. Nur wie macht man das am besten? Der Ansatz über die Gamestates hat ja gerade den Vorteil, dass man die verschiedenen Teile sauber voneinander trennen kann.

Wenn man jetzt aber z.B. ein Musikmodul schreibt, sollte dass ja nicht in jedem State neu gestartet werden müssen. Vielmehr möchte man ja, dass die Musik ständig läuft, sich aber in bestimmten Situationen ändert. Dazu fallen mir jetzt so spontan folgende Lösungen ein:

1. Man baut die Musikengine so auf, dass Sie global existiert und nur über Funktionsaufrufe gesteuert wird. Dadurch verliert man allerdings die eindeutige Datenzuordnung zu bestimmten Frames, d.h. wenn man in einem Spielabschnitt eine Menge Sounds benötigt, müssen diese immer in der Engine vorhanden sein, ausser man programmiert hier eine weitere Datenorganisation mit ein.

2. Man baut die Musikengine Objektorientiert und erzeugt an übergeordneter Stelle (z.B. in einem EngineManager) eine Instanz derselben. Den EngineManager müsste man natürlich für alle Gamestates verfügbar machen.

3. Man erzeugt einmal eine Instanz, und reicht diese von State zu State weiter. Der Nachteil dabei ist der, dass man eben immer extra weitergeben muss. Ist daher ziemlich unpraktisch.

Ich weis nicht wie ihr das seht, aber meiner Meinung nach sollte eine saubere OO Lösung am Ende über nur noch ein einziges globales Objekt instanziiert werden. Alle anderen Objekte sind dann in diesem verlinkt (also eine Art Baumstruktur). Daher tendiere ich in meinen Frameworks immer eher zu Lösung 2.
Problem besteht halt darin, dass man aufpassen muss, die benutzten Engines am Ende eines States auch aufzuräumen.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	E. Urbach ehemals "Basicprogger"	Mi, Okt 28, 2009 15:26 Antworten mit Zitat
@FDM: Ich bin derselben Meinung. Bei mir sieht die Methode 2 ungefähr so aus: Code: [AUSKLAPPEN] [EINKLAPPEN] resManager.Get("shared-image.png") ...in dem Fall mit der Musik... Code: [AUSKLAPPEN] [EINKLAPPEN] objManager.Get("TMusicManager") Siehe Ogre3D ResourceManager. So muss man die Engine nicht jedes mal neu starten und Bilder werden auch nicht doppelt geladen, wenn sie in zwei GameStates verwendet werden.
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Mi, Okt 28, 2009 15:26
Antworten mit Zitat

@FDM: Ich bin derselben Meinung. Bei mir sieht die Methode 2 ungefähr so aus:
Code: [AUSKLAPPEN]

resManager.Get("shared-image.png")

...in dem Fall mit der Musik...
Code: [AUSKLAPPEN]

objManager.Get("TMusicManager")

Siehe Ogre3D ResourceManager.
So muss man die Engine nicht jedes mal neu starten und Bilder werden auch nicht doppelt geladen, wenn sie in zwei GameStates verwendet werden.

	ComNik	Mi, Okt 28, 2009 17:01 Antworten mit Zitat
Also bei der Physik Engine macht es wenig Sinn da immer ein neues Objekt zu erstellen. Das beste Beispiel wäre wohl die Particle Engine die eine übergeordnete Klasse namens "WP_ParticleManager" hat. Für jeden State könnte mann eine Instanz des Particle Managers erstellen und dieser ein paar Emitter ("WP_ParticleSystem") hinzufügen welche mit vorgefertigten Effekten versehen werden. Also das macht vielleicht nicht so viel Sinn (bei einer Partikel Engine) aber man könnte theoretisch ein paar Partikel Systeme (z.B kreisförmige Explosion, kleine Flamme) für eine Instanz des Managers erstellen und ein paar andere (z.B elektrischer "blitz", wasserfontäne) für eine zweite. Die erste fügt man dann dem GameState "MainMenu" hinzu wenn man (aus sonderbaren gründen) beim klicken eines Buttons eine Explosion haben will Und die andere Instanz kommt dan zum "Game" State also zum Hauptspiel. Ich hoffe man versteht was ich meine (ist ja eigentlich das was FDM sagte). Inwieweit sich das auf andere Module sinnvoll übertragen lässt sei dahingestellt, aber es hat seine Vorteile. lg ComNik
WIP: Vorx.Engine

ComNik

Mi, Okt 28, 2009 17:01
Antworten mit Zitat

Also bei der Physik Engine macht es wenig Sinn da immer ein neues Objekt zu erstellen.
Das beste Beispiel wäre wohl die Particle Engine die eine übergeordnete Klasse namens "WP_ParticleManager" hat. Für jeden State könnte mann eine Instanz des Particle Managers erstellen und dieser ein paar Emitter ("WP_ParticleSystem") hinzufügen welche mit vorgefertigten Effekten versehen werden. Also das macht vielleicht nicht so viel Sinn (bei einer Partikel Engine) aber man könnte theoretisch ein paar Partikel Systeme (z.B kreisförmige Explosion, kleine Flamme) für eine Instanz des Managers erstellen und ein paar andere (z.B elektrischer "blitz", wasserfontäne) für eine zweite. Die erste fügt man dann dem GameState "MainMenu" hinzu wenn man (aus sonderbaren gründen) beim klicken eines Buttons eine Explosion haben will Rolling Eyes

Und die andere Instanz kommt dan zum "Game" State also zum Hauptspiel.

Ich hoffe man versteht was ich meine (ist ja eigentlich das was FDM sagte). Inwieweit sich das auf andere Module sinnvoll übertragen lässt sei dahingestellt, aber es hat seine Vorteile.

lg
ComNik

WIP: Vorx.Engine

	Firstdeathmaker	Mi, Okt 28, 2009 18:14 Antworten mit Zitat
Bei einer Partikelengine könnte man jedoch genausogut auch eine globale Instanz erzeugen, und wenn ein Gamestate beendet wird, ruft er eine Clear() methode auf, mit der alle aktuellen Partikel gelöscht werden.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Mi, Okt 28, 2009 18:14
Antworten mit Zitat

Bei einer Partikelengine könnte man jedoch genausogut auch eine globale Instanz erzeugen, und wenn ein Gamestate beendet wird, ruft er eine Clear() methode auf, mit der alle aktuellen Partikel gelöscht werden.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	ComNik	Mi, Okt 28, 2009 19:41 Antworten mit Zitat
Meine funktioniert so: Man erstellt beliebig viele Instanzen der Manager Klasse. Diese verwaltet automatisch alle Partikel Systeme, setzt "verflogene" Partikel wieder an den Anfang wenn sie andauernd "fliessen" sollen. Wenn alle Partikel eines nur einmal laufenden Systems verbraucht sind löscht der Manager das System etc... Ich hab nur gute Erfahrungen mit diesem System gemacht. Und natürlich benutze ich nur eine globale Instanz aber das sollte ein Beispiel sein, da mir auf die Schnelle keine weiteren Module einfielen in denen ich das System nutze. Ich hab auch lange abgewägt ob ich alle Ressourcen global lade oder einen Ressourcenmanager schreibe. Da ich mit der Entwicklung noch nicht angefangen hab ich noch Zeit, aber es wird wohl ein Manager. lg ComNik
WIP: Vorx.Engine

ComNik

Mi, Okt 28, 2009 19:41
Antworten mit Zitat

Meine funktioniert so:
Man erstellt beliebig viele Instanzen der Manager Klasse.
Diese verwaltet automatisch alle Partikel Systeme, setzt "verflogene" Partikel wieder an den Anfang wenn sie andauernd "fliessen" sollen. Wenn alle Partikel eines nur einmal laufenden Systems verbraucht sind löscht der Manager das System etc...

Ich hab nur gute Erfahrungen mit diesem System gemacht. Und natürlich benutze ich nur eine globale Instanz aber das sollte ein Beispiel sein, da mir auf die Schnelle keine weiteren Module einfielen in denen ich das System nutze.

Ich hab auch lange abgewägt ob ich alle Ressourcen global lade oder einen Ressourcenmanager schreibe. Da ich mit der Entwicklung noch nicht angefangen hab ich noch Zeit, aber es wird wohl ein Manager.

lg
ComNik

WIP: Vorx.Engine

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Umfrage Frameworks

Betreff: Umfrage Frameworks