Ich schreibe dann mal auch was zu:
Ehrliche Meinung von mir: Ja. Meine Idee war es ja auch sich von libGDX loszulösen, und was eigenes zu starten.
Was braucht man denn großartig davon? Richtig - Die GL-Wrapperklassen von LWJGL für die Desktopumgebung. Für alles andere (Web, Mobile-Apps,…) ist der Rest gar nicht erst notwendig, da es schon eine GL-API gibt die direkt Native ist.
Meine Idee war es auch für jede Plattform eine gleichbleibende API zu schaffen sodass man mit diversen Export-Tools dann Plattformübergreifend builden kann.
Das ganze jedoch wurde verworfen, da der großteil des Teams dies als zu aufwändig eingestuft hatten - Gut dann bleiben wir halt bei libGDX.
Meine bedenken gegenüber von libGDX sind ohnehin, dass man die Backends selbst anpassen muss, jenachdem was man zur API hinzufügt oder dort verändert. Von daher sehe ich persönlich libGDX als unnötigen Ballast. Aber aus Fehlern lernt man ja bekanntlich, Probleme die möglicherweise vorhanden sind werden sich dann ja in nächster Zeit bemerkbar machen wo man sich dann ja sagt „Was haben wir denn da verbockt“
Und ich habe mich schon so gefreut, dass diese Diskussion abgeschlossen ist… 
Nein, natürlich verstehe ich, was ihr meint. Einerseits das mit dem Backends verändern - meiner Meinung nach wird dies nie passieren, da im Backend nur grundlegendes passiert, heißt etwa das Soundsystem des System erstellt, auf OpenGL verwiesen… somit sehe ich hier kein Bedarf nach Änderungen.
Die Sache mit den „Zu vielen Schichten“… wir haben bei LibGDX jederzeit die Möglichkeit, auf LibGDX eigene Klassen, wie Spritebatch zu verzichten, und was eigenes auf OpenGL etc. Basis zu schreiben. Somit hat man meiner Meinung nach nicht mehr Funktionsmöglichkeiten als auf anderer Basis - solltet ihr ein Beispiel haben, wo es nicht der Fall ist, könnt ihr mir das gerne zeigen.
Aber wir haben bereits ja im Forum abgestimmt, und bleiben auch erstmal auf LibGDX. Sollte irgendwann ein Punkt kommen, wo wir merken, dass LibGDX uns aktiv an bestimmten Sachen hindert, können wir ja erneut über eine eigene Basis diskutieren. 
Nur zum Klugscheissen: Man kann auch mit Opensource Geld verdienen, das schliesst sich nicht zwingend aus
Natürlich, Beispiele wären ein kostenpflichtiger Support, erweiterte Module oder auch, wie schon erwähnt, Spenden. Eins kann ich aber versprechen, zum aktuellen Zeitpunkt gibt es keine Pläne / Diskussionen über Kostenpflichtiges. 
[QUOTE]Ich will einfach nur rueberbringen, dass ein konkretes Spiel mehr Spass, mehr Lerneffekt, mehr Motivation und ueberhaupt bringt.
Ja schon recht. Aber wer sagt denn, dass des alles nicht bereits geschieht? Neben Simple Examples werden auch einige andere Beispiele erstellt, darunter wären Beispielsweise auch irgendwelche Sample Games.
Da kommen wir ohnehin nicht drum rum - Irgendwie muss man die Engine im Entwicklungsprozess ja testen und notfalls Optimieren.[/QUOTE]
Es gibt bereits einige Examples, wie schon erwähnt. Meiner Meinung nach ist das auch sehr wichtig: Die meisten Fehler bemerkt man nun mal erst, wenn man es aktiv ausprobiert. Desweiteren fallen einen so gute Ideen zur API etc. an.
Wir haben nun begonnen, über ein solches Projekt genauer zu diskutieren.
Ich hatte schonmal „Moorhuhn“ als Beispiel angesprochen. Da hätte man alles zusammen - auch Sachen, die bei TicTacToe NICHT dabei sind. Grafik (ggf. sogar 3D), Sound, Animationen, Interaktionen, und einen Multiplayermodus lutscht man sich da auch noch aus den Fingern. Gleichzeitig ist es so primitiv, dass nicht viel Arbeit in die übrige Spiellogik gesteckt werden muss. Es könnte wirklich als Demo der reinen Funktionalität der Engine dienen. Aber das ist ja nur ein (unverbindlicher) Gedanke.
Moorhuhn wäre mir so nicht eingefallen - Ist natürlich ein gutes Beispiel.
Wozu braucht man ueberhaupt eine Engine, um ein TicTacToe-Spiel zu entwickeln?
Damit man ein TicTacToe Spiel für Desktop, Web, Android & iOS programmieren kann, ohne sich dabei auch nur einmal richtige Gedanken über OpenGL, Portieren etc machen zu müssen, sondern sich nur um das Spiel an sich zu kümmern. Ich hoffe ihr versteht, was ich meine
