Ich schau mir den Thread nun auch schon ne Weile an und möchte kurz meinen Senf dazugeben. Viel wird es nicht, ihr kennt mich, ich bin meist minimalistisch veranlagt (siehe OpenParty). ^^

Das erste, wozu ich etwas sagen möchte, war dein Vergleich mit VCL, der LCL und DirectX.
Bei LCL passt der Vergleich, bei VCL und DirectX ist er unangebracht. Warum? Das sind zwar beides sehr große Projekte/Bibliohekten/Programme, aber sie sind für viele Dinge nutzbar. VCL macht bei mir z.B. die gesamte Multimediawiedergabe. Aber auch mit reiner Videowiedergabe ist es immer wieder nutzbar, vielfältig und man braucht kaum noch andere Abspielsoftware. DirectX wird von den meisten Spielen genutzt. Aber die Wahrscheinlichkeit mehrere Spiele mit deiner Engine auf einer Hardware laufen zu haben, ist klein.
Für große Spiele/Projekte mag das nicht von Belang sein, aber mit sinkender Projektgröße steigt der Overhead relativ gesehen. Für meine Projekte wäre deine Engine somit total ungeeignet, weil sie einfach zu heftig wäre. Aber die Zielgruppenfrage hattest du ja schonmal aufgegriffen. An dieser Stelle der Tipp/Hinweis, dass du darauf achten solltest, dass deine Zielgruppe nicht zu klein ist. Es wird ja so oder so VIEL Arbeit werden, wenn meine Projekte kein Schwein spielt, ist das weniger Zeitverlust.

Die andere Sache ist das Konzept. Ich weiß nicht, ob ich es so recht gerafft habe, aber irgendwie ist mir das alles nicht abstrahiert genug. Ich fände es am besten, wenn der Nutzer für einen Aspekt (z.B. Audio) ein Plugin auswählt und danach nichts mehr damit am Hut hat. z.B.

"Erstaunlicherweise" scheint das SDL sehr zu ähneln, fällt mir gerade auf. Und Objectorientiert ist es auch nicht, aber egal, es ging ums Prinzip. Nach der Auswahl des Plugins war es egal, welches man wählte. Es könnte nur halt sein, dass ein Plugin manchmal garnichts machts oder am besten eine Fehlermeldung ausgeht, wenn die eine oder andere Funktionalität nicht geht.

So, das waren just meine 2 Cents dazu. Ansonsten: Wenn du es schaffst, das _so_ fertig zu stellen UND Leute zu finden, die die Bibliothek nutzen, fände ich das durchaus cool - bezweifle es aber stark.

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Natürlich gibt es solche Probleme und diese habe ich auch schon bedacht. Hierzu bedarf es keiner Führungsperson die mehr Stimmenrecht hat sondern die früh genug erkennt, dass man sich im Kreis dreht und durch verschiedene Möglichkeiten diesem entgegen wirkt und wieder in die Diskussion zurück führt.
Es bedarf zwar einer Hierarchie in der Verwaltung aber keiner in der Ausführung.

Wir haben bei PTS z.B. über 20 Menschen die zusammen Arbeiten(Professoren, Doktoren, Studenten, Arbeiter, Jung, Alt und in zig verschiedenen Sprachen) und ja es gibt eine Unterscheidung zwischen Member und Helper, dieser liegt aber nur da drin, dass die Member die Verwaltungsarbeit für die Helper übernehmen und sonnst nichts anderes tun als Helper. Dies erlaubt den Helpern sich auf ihre Arbeit zu konzentrieren und nicht ständig an Meetings teil zu nehmen, externe Kontakte zu pflegen, Doku an zu legen und weiterer Schriftlicher Kram. Die Arbeit und Diskussion selber wird innerhalb eines Teams geführt und der Fortschritt von z.B. Programmierern wird dann halt den Leitern der anderen Gebiete wie Mechanik weiter gegeben und in den Dokus fest gehalten.

Strukturen sind Projektabhängig und man kann eine passende am Anfang des Projektes finden. Auf der letzten LinuxTag gabs ein recht interessanten Vortrag zum Thema Projektmanagement in OpenSource Bereich. Auf dem LinuxTag davor gabs ein Interessanten Vortrag von SourceForge selber zu einen ähnlichen Thema und diese haben sich schon von den Strukturen unterschieden, die z.B. Im Buch Softwareentwicklung von O'Reilly angesprochen wird.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Zum ersten ist es nicht meine Engine und zum 2. ist es meiner Definition nach garkeine Engine sondern ein Framework. Irrlicht, Ogre, ID Tech 3 oder UE3 sind Engines wärend allegro, directx und SDL Frameworks sind.


Ja und weil wir alle es so schön finden haben wir auch darüber schon geredet und ich habe auch schon mögliche Lösungen gezeigt.

Das Prinzip entspricht einer Frontend-Backend Lösung und erfüllt folgende der 3 Forderungen "-Die Schnittstelle Platformunabhängig bleibt. " ist die Lösung nun noch Objekt Orientiert und steht unter BSD Lizenz, dann ist es genau das was auch mir Vorschwebt.
SDL unterstützt keine dynamische erweiterung sondern nur feste implementierungen wie OpenAL oder ALSA oder ... und OpenAL wiederrum macht das gleiche. Das ist kein erweiterbares backend das ist eine Liste von festgelegten Implementierungen auf eine Schnittstelle und wenn man eine weitere hinzufügen will muss der Hauptcode geändert,neu compiliert und verteilt werden.
SDL steht unter lgpl und bietet keine C++ Implementierung, das spricht gegen eine SDL erweiterung aber man könnte durchaus einen Spinoff von SDL machen und z.B. SDL++ ins leben Rufen.
Diese würde unter BSD Lizenz genau den gleichen Code implementieren und den ganzen restlichen Features die noch gebraucht werden. Dies wäre genau das was ich vorgeschlagen habe nur das es dann nicht wie Aktuell DirectZ sondern SDL++ heisst. Es hätte auch Vorteile der Namensassoziation, SDL hat einen sehr guten Ruf aber eine grauenhaftes Managment, wie ich schon glaube erwähnt habe. das Update von SDL 1.2 auf SDL 1.3 dauert mitlerweile wieviele Monate-Jahre ? Ich habe schon vor langer Zeit aufgehört zu zählen. Die Patches für viele dinge wie OpenGL3.x, fixes für Bugs im Fenster und Eventsystem liegen schon ewig vor, Vorschläge wie Multi Windowsupport wurden abgenickt aber nie in Angriff genommen, das Managment ist meiner Meinung nach schlicht weg nicht mehr vorhanden. Die API allerdings 1zu1 in C++ um zu setzen geht nicht mehr, dazu wurde SDL zu lange nicht mehr gepflegt und wie schon erwähnt wird die dynamische Erweiterung nicht unterstützt, welche große auswirkung auf die Konstruktoren hat. Im obigen Codebeispiel sieht man es sehr gut. Wärend die funktionalität und zerstörung nahezu übernehmen lässt ist die Erzeugung nicht mehr möglich.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also wenn du mit sowas wie SDL++ anfangen willst, dann solltest du dir zuerst Unterstützung im SDL Lager besorgen. DIe wissen vermutlich am besten, was bei SDL zukünftig gemacht werden sollte, welche Fehler es gab und was man von Anfang an hätte anders machen müssen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Die Liste, der zu Ansprechpartner hat sich dann auf Allegro, Boost, Ogre, Irrlicht, SDL erweitert. An SDL Entwickler und Nutzer hab ich echt nicht gedacht, wobei das ja so nah liegt ^^.
Ich will den Gedanken hinter SDL in C++ Umsetzen, SDL selber ja nicht, da diese an einigen stellen schlicht inkompatibel sind, darum meinte ich ja SDL++.
Momentan arbeite ich mich in SF Architektur ein, ich hab mal ein Beispielprojekt Angelegt und bis auf mit dem fest verdrahtetem Website Eintrag ist das echt flexibel und übersichtlich.
Morgen werde ich mal bei Google rein gucken und erstmal mir gedanken machen, wie ich an die einzelnen Leute heran treten werde.
Heute werde ich allerdings noch ein simples Handout fertig machen, woran man mal Übersichtlich sieht, was nun eigentlich das Ziel des Projektes ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Google hat das ganze ein bisschen übersichtlicher als SF gemacht allerdings vermisse ich da die Community wie bei SF.
Von den gebotenen Services ist SF auch ein bischen besser allerdings sind SF Services auch nicht die schnellsten, es sind zwar große Leitungen da aber wenig Verarbeitungskapazitäten. Ein SVN Checkout mit 0 Datein dauert da schon mal einige Sekunden, selbst das Login oder andere Aktionen sind zur Primetime recht träge. Google hat da durch das Cloud Computing und den noch nicht so großen Nutzern keine derartigen Probleme.
Ich selber bin hin und her gerissen und kann mich bisher nicht für eine der Varianten entscheiden.

Im Anhang hab ich eine erste Version eines Handouts gepackt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich hatte schon vergangene Woche das Karmarama Projekt freezed und sämtliche Daten Online gestellt, da ich künftig keine Zeit mehr für dieses finden würde. Allerdings hatten ich gestern auch ein kurzes Gespräch mit dem Projektleiter von PTS und es ist geplant die Softwareentwicklung nun schon zu beginnen, da sich einige Task gefunden haben, die jetzt schon erledigt werden müssen. Noch dazu haben gestern alle Mitglieder ihre Accounts für das neue Managmentsystem bekommen und da stehe ich nun auch als Lead für sämtliche Software drin, was in ein größeren Mail aufkommen an mich begonnen hat. Dies bedeutet ich habe nun wirklich keine Zeit mehr. Der eigentliche Plan in der bisher gedachten Zeitspanne(bis Anfang nächsten Jahres) noch das Projekt soweit an zu kurbeln, dass sich auch eine andere Führungsperson findet ist ins absolut unrealistische gewandert. Da ich sonnst nicht mehr die Möglichkeit hätte auch noch was anderes zu tun als nur Arbeit. Was kurz bedeutet ich kann dieses Projekt nicht weiter begleiten und ich vermute mal das wird das Ende des Projektes sein. Gut nur das es noch nicht begonnen hat und niemand wirklich Zeit verloren hat.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich lese auch interessiert hier mit und bin gespannt was es wird
Klingt mir sehr nach einer Art Spring für Gamedevelopment. Wenn es sowas wird, wär toll

In deinem Handout solltest du aber die Rechtschreibung überarbeiten, bevor du es jemandem gibst, der eventuell über ein Budget entscheidet, ich weiß ja nicht, wie das läuft, ob ihr euch Sponsoren oder sowas sucht oder alles auf freiwilliger Basis geschieht

Öhm, wenn ich das richtig verstanden habe, hat er das Projekt einen Beitrag zuvor auf Eis gelegt...

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Aehm ja ich hab nicht aufmerksam gelesen, hatte gedacht, das gesamte Auf-eis-legen bezog sich auf karmarama aber ja offenbar auch auf dieses konzept
schade eig

Ja, er hat das Projekt fallengelassen. Aber ich denke auch schon lange über so etwas nach.

Ich habe einen ganz anderen Zugang zu diesem Problem: ich denke seit über einem Jahr über die Struktur einer 3D-Engine nach. Mein derzeit aktueller Entwurf gefällt mir schon recht gut: es handelt sich um eine Struktur, die nur aus Schnittstellen besteht, wobei die Anzahl der Schnittstellen unbegrenzt ist. Ob die jetzt gut sind oder nicht kann ich noch nicht mit Sicherheit sagen, denn die Schnittstellen selber stehen noch gar nicht fest. Der Entwurf ist aber vielversprechend in Bezug auf eine bestimmtes Problem: er soll verhindern, dass die Struktur ausbricht und unkontrollierbar wird, denn das scheint mir ein Hauptproblem bei Engines zu sein. Ich verfolge das KISS-Prinzip: "Keep it simple, stupid", aber man muss zuerst eine komplexe Grundlage schaffen, damit man nachher einfach sein kann.

Es muss auch gar nicht festgelegt sein, ob diese Schnittstellen DLL's oder auch nur einfache Pascal-Units sind (ich hab mit C nicht viel am Hut). Man kann auch eine Plattform-abhängige Schnittstelle dranstöpseln. Man MUSS sogar zumindest eine solche verwenden, nämlich das Operating System.

Ich stelle mir das so vor: die Engine funktioniert von Anfang an, denn alle notwendigen Schnittstellen können sofort mit funktionierenden Plugins versehen werden, z.B. Dummy-Plugins. Am Anfang gibts eben nur ganz einfache Plugins, die allmählich durch komplexere ersetzt werden können. Dadurch kann man eine Multiskalen-Engine erzeugen: mit einem einfachen Plugin-Satz kann man z.B. OpenGL 1.1 + simple Bewegungen verwenden, mit einem komplexeren Plugin-Satz OpenGL 2.0 + eine ausgefeilte Physik und so weiter. Man soll sich seine Engine also individuell zusammenstöpseln können. Diese Engine hat das Zeug in sich, eine Evolution durchmachen zu können, wobei die "alten" Plugins auch ihre Daseinsberechtigung haben.

OpenGL hat eine Version herausgebracht? OK, die Engine kriegt eine weitere Grafik-Schnittstelle, aber wir behalten uns die alte. Microsoft bringt eine neue API heraus. Na und? Die Engine kriegt eine zusätzliche Operating-System-Schnittstelle. So einfach ist das.

An so einer Engine könnten viele Leute ganz unabhängig voneinander arbeiten. Wenn jemand eine Verbesserung einbringt, hätten wir alle etwas davon, aber im Augenblick haben wir gar nichts, weil jeder wieder auf Null aufsetzen muss. Das, was "State Of The Art" ist, entfernt sich immer weiter von uns und wir müssen zusehen, wie es langsam hinter dem Horizont verschwindet. Eine Engine, wie ich sie oben beschrieben habe, wäre eine Möglichkeit für uns, den Abstand wieder zu verringern.

Das ist wirklich schade aber leider ist meine Zeit auf 15h am Tag begrenzt und beide Projekte sind mir einfach zu wichtig als dass ich es ohne mehr Freizeit machen will. Wenn wirklich noch wer Interesse hat dieses Projekt in dieser oder ähnlicher Form in angriff zu nehmen, kann ich allerdings noch ein bisschen die PTS Strukturen missbrauchen und behilflich sein. Wenn es darum geht wie man andere Personen/Projekte anspricht, Übersetzungen und Grafiken zu organisieren, dann könnte ich das einfach an die entsprechenden Personen weiter leiten und mit mein Lieb gucken und Freundschaftsbonus es noch durch bekommen.

Als Spieleentwickler sollte man sich auch auf diese Aufgabe konzentrieren können und sich nicht mit Frameworkarbeit rum plagen. Gerade bei so beliebten Gengres wie MMO, wo man dann viel auf Netzwerk, Skalierung und Globalisierung angewiesen ist, wäre man nur am Basiscode schreiben.
Dabei ist das Zeitaufwändigste in die API sich ein zu arbeiten. Es ist schon ein Unterschied, ob man erstmal 3-4 Dokumentationen angucken muss, ein paar Stunden googlet,nur um geeignete Bibliotheken zu finden oder ich schlicht eine einzige Doku aufschlage bzw. je nach IDE sogar nur über den Symbolbrowser schon entsprechende Namespaces und deren Klassen finde.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Evolutionäre Engines sind vom Prinzip her zwar schön anzuschauen, aber letzten Endes wird man immer irgendwo einen Kompatibilitätsmodus mit einbauen müssen. Besser ist es meiner Meinung nach, wenn die Basis eine bestimmte Voraussetzung vorgibt und man die Möglichkeit hat externe Libs verhältnismäßig leicht einfügen kann. Meist bedeutet das je nach Lib allerdings trotzdem das viele Bereiche angefasst werden müssen.

Oder man schreibt sich eine Engine für sein spezielles Szenario, wobei man dann meist beim nächsten Projekt vor dem Problem hängt seine Engine anpassen zu müssen. Egal wie man es dreht oder wendet, die Komplexität wird man nicht los. Und ich denke man sollte besser einen soliden Kern haben und die komplexen Logiken dann in den jeweiligen Modulen lösen. Somit bleibt primär nur das Modulsystem im Kern zu lösen und meist noch ein VFS das alle Module nutzen sollten.

my2cents.

_________________
(\__/)
(='.'=)
(")_(")

Ich habe in diesem Bereich schon Erfahrung gesammelt. Die glPasGUI hat es geschafft, Linux und Windows unter einen Hut zu bringen. Das war nicht einfach, aber letztendlich war es möglich.

Was haben ein Frosch und ein Löwe gemeinsam? Sie haben beide vier Beine. Sie müssen Nahrung zu sich nehmen und geben diese Nahrung auch wieder ab. Sie erzeugen Nachkommen, wenn auch auf verschiedene Art und Weise. Das Wichtigste bei einem solchen Ansatz ist, nach Gemeinsamkeiten zu suchen, nicht nach den Unterschieden.

Es gibt natürlich allgemeine Engines, Ogre ist wohl die hier bekannteste und ich selber hatte mit X-Dream auch eine Allgemeine Engine gebaut.
Das Problem daran ist, die Engines sind echt gewöhnungsbedürftig und man weiß nicht woran man ist.
Bei spezialisierten Engines, diese sind wesentlich häufiger und haben den Vorteil, dass man sich einmal ein Gedanken über Inhalt macht und dann genau die Dinge Implementiert. Qualitativ ist solch Code wesentlich besser, da weitere Zeit in Verbesserung des Code gesteckt wird.
Die meist Lizenzierte Engine auf der Welt, in den letzten 2Jahren war UnrealEngine3, diese wurde als Shooter Engine konzipiert aber wird auch für ganz andere Gengre lizenziert. Epic Games hatte dann vor einer weile UE3 um ein MMO Modull erweitert, welches Netwerkkomponente erweitert hat und einige weitere Services in den Server Modul rein packt. Diese wurde ebenfalls gut Lizenziert und wird auch nicht nur für Shooter lizenziert.
Die Spielegengre unterscheiden sich überwiegend nur in der Logikimplementierung und diese kann man ja sehr einfach über Scripte austauschen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004