spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also wenn du am Ende eine fertige Engine haben willst, welche du auch später noch verwenden magst und soweit fertig sein soll, dann ist eine DLL sicher nicht das falsche. Du könntest auch einfach die Source mitkopieren und bei den anderen Projekten einfügen und einbinden, aber das ist rein kompiliertechnisch nicht sehr sinnvoll.

Da gibt es ansich keine platformunabhängige Lösung da unterschiedliche Plattformen unterschiedliche dynamische Linker verwenden.

Jedoch brauchst du für andere Plattformen wiederrum eigene Build Scripts in denen du dann z.B. für Linux .so Dateien statt .dll Dateien generieren kannst.

Die simpelste Variante ist es statische Bibliotheken zu benutzen, diese werden direkt in die Anwendung hinzugelinkt ohne eine extra .dll Datei bei der Ausführung zu benötigen.
Eine DLL bietet natürlich den Vorteil, dass du nur die .dll Datei für kleine Bugfixes in der Engine neu kompilieren musst. Bei statischen Bibliotheken müssen alle Programme die die Bibliothek verwenden neu gelinkt werden.

Also ich habe im Moment eine statische Bibliothek mit recht allgemeinem Kram, allerdings ist es da wieder dof, wenn man z.B. die Spriteklasse einen Ressourcenmanager zum Laden der Texturen benutzen lässt, kann man später die Spriteklasse nicht mehr einzelnt benutzen. Lädt das Sprites die Texturen selber, wird in meinem Spiel der Ressourcenmanager nicht benutzt, was ich auch nicht will.
Wenn man also die kleinen Sachen die man immer braucht, wiederverwendbar machen will, sollte man überlegen, wie viele Abhängigkeiten sie haben, und eine Balance zwischem schönen Zusammenspiel und schöner Einzelbenutzbarkeit finden.

Desweiteren habe ich viele Klassen des Spiels parallel im Spiel und im Editor. Natürlich gibt es dann oft Sachen, die im Spiel oder im Editor jeweils mehr Sinn machen, aber wenn man im Editor aus der Szene mehrere Objekte in einem Bereich auswählen kann, hat man gleich eine Funktion für die KI, um zu gucken, welche Gegner so in diesem Bereich sind.

Insgesammt habe ich dadruch jetzt eine recht ordentliche Aufgabentrennung, immerhin ist das Spiel normal Echtzeit und Fullscreen, läuft aber im Editor in einem kleinen Unterfenster und wird nur bei Änderungen aktualisiert.

Und naja, wenn man Eben alles schön aufteilt, in allgemeine Dateien für eine statische Lib, Spielverwaltungsdateien für Editor und Spiel Spiellogik für Spiel usw. dann muss man eben ein bisschen strikter trennen, wärend man, wenn man alles in einem Projekt hat, oft einfach aus Bequemlichkeit kleinere Abhängigkeiten einbaut.

Wenn das so ist, würde ich dir eher zu einer statischen Lib raten. Wie es geht?
1. Projekt erstellen->auf statische Lib umstellen
2. Source zu Projekt hinzufügen
3. Projekt in Projektmappe hinzufügen
4. In der Projektmappe die Abhängigkeiten entsprechend setzen (hat zur folge, dass es immer richtig gelinkt wird. Achtung: die Runtime lib ist oft ein Stolperstein, da alle Projekte die gleiche nutzen sollten)

Vorteile: recht simpel und mit CodeBlocks geht es analogt für Linux.
Nachteil: man kompiliert eben immer alles neu, aber ist eigentlich nicht soo tragisch, da die anderen Projekte normalerweise nur neu gelinkt werden müssen.

Zitat von »"Jonathan_Klein"«

Also ich habe im Moment eine statische Bibliothek mit recht allgemeinem Kram, allerdings ist es da wieder dof, wenn man z.B. die Spriteklasse einen Ressourcenmanager zum Laden der Texturen benutzen lässt, kann man später die Spriteklasse nicht mehr einzelnt benutzen. Lädt das Sprites die Texturen selber, wird in meinem Spiel der Ressourcenmanager nicht benutzt, was ich auch nicht will.
Wenn man also die kleinen Sachen die man immer braucht, wiederverwendbar machen will, sollte man überlegen, wie viele Abhängigkeiten sie haben, und eine Balance zwischem schönen Zusammenspiel und schöner Einzelbenutzbarkeit finden.

Das ist denke ich ein Problem bei dem Design Patterns wunderbar ins Spiel kommen. Es gibt eine Menge Pattern um Code wiederverwendbar, flexibel und erweiterbar zu gestalten.
Wenn man zudem noch Interfaces nutzt kann man die Implementierungen für andere Zwecke austauschen. (z.b. Kann dann die Sprite Klasse mit einer anderen Implementierung der Texturklasse arbeiten. So lange das Interface richtig implementiert ist.).

Da gibt es ziemlich viele Möglichkeiten und man sollte immer Abwägen inwieweit man das ganze wiederverwendbar machen möchte. Sonst sitzt man da wirklich stundenlang an eigentlich simplem Klassen und investiert mehr Zeit als ein Kopieren und anpassen für ein neues Projekt kosten würde.

Ich denke was zu dem Thema am meisten hilft ist ein Buch über Softwarearchitektur und ein kleiner Haufen Erfahrung.

Edit:
Keine Angst Brainshack, ich denke in deinem Fall ist das ganze nicht so komplex. Wenn du deine Spielengine als ganzes wiederverwenden willst ist das wesentlich einfacher zu realisieren als wenn man, wie Jonathan, einzelne Komponenten dieser Engine wiederverwenden will.