Ich habe vor libGDX für zwei einfache 2D-Spiele zu verwenden, insbesondere weil sie damit in HTML5 laufen können. Hat jemand Erfahrungen, Tipps, oder vielleicht sogar bessere Alternativen für mich?
Die Spiele sind nicht actionlastig, die Szenen sind nicht schwierig zu rendern, Geschwindigkeit ist eher unwichtig. Partikeleffekte wären schön, aber die gibt es wohl. Szenenwechsel und einfache Gestaltung von Nutzer-Oberflächen (Menü, Settings…) wäre nicht ganz unwichtig.
Ich würde dir Unity empfehlen. Das verwende ich für mein 2d-Game. Es ist sehr angenehm damit zu arbeiten und bietet dir praktisch alles was du brauchst. Schön find ich daran vor allem, dass man schnell (imho) gute Ergebnisse erzielen kann.
Ich will in Kotlin schreiben, C# ist für mich ein K.O.-Kriterium. Ich habe auch das Gefühl, dass Unity in meinem Fall “mit Kanonen auf Spatzen” wäre (weshalb ich auch jMonkeyEngine ausgeschlossen habe).
Würde ich jetzt nicht so sehen - weil genau für sowas sind die Engines ja eigentlich da 
. Ich hab keine Erfahrungen mit den anderen libs (JMonkey nur mal vor 100Jahren kurz angesehen). Aber ich glaub, wenn das Projekt doch mal weiter wächst, dann ist man froh wenn man direkt sowas wie Unity oder Unreal Engine im Einsatz hat. (Meine Meinung, kann natürlich auch komplett falsch sein. Keine Ahnung wie angenehm es ist Spiele mit libgdx zu entwickeln. Also Bullshit-faktor von mir könnte hier sehr hoch sein 
)
Das hingegen machts natürlich schwierig ^^. Ich hab mal geschaut - offiziell gibt’s leider nix. Unity erlaubt C# und JavaScript. Du könntes kotlin nach js kompilieren … aber ob man das will? Als ich damals für React Kotlin verwenden wollte, war das eher eine Qual als eine erleichterung - weswegen ich bei TypeScript geblieben bin.
Also wenn du dich weder mit C# noch mit JS anfreunden kannst, dann fährst du vllt echt am besten mit libGDX.
Ist @Apo nicht unser LibGDX Master of Desaster hier?
Also für kleine 2D Spiele finde ich libgdx absolut geeignet. Und der riesige Vorteil gegenüber kleineren Libs ist die riesige Community und die vielen Tutorials. Libgdx und Kotlin funktioniert auch sehr gut, deshalb würde meine Empfehlung auf jeden Fall LibGDX bei deinen Anforderungen lauten.
Tutoials für GUI in libgdx https://github.com/libgdx/libgdx/wiki/Scene2d.ui
Tutorials für Kotlin und libgdx https://github.com/libgdx/libgdx/wiki/Using-libGDX-with-Kotlin
Und auch in Richtung Particeleffekte haben die genug zu bieten (einen 2d und 3d Partikel Editor und einfache Klassen zur Erstellung).
Also lange Rede kurzer Sinn, ich bin absolut zufrieden mit LibGDX und bastle gerade weiter an meinem Profit Spiel und da sehe ich wie schnell es in Sachen 2D ist (auch wenn das nicht deine Anforderung war, aber es ist pfeilschnell).
Wenn du dich minimal mit Gradle auskennst und Java kannst (wovon ich auf jeden Fall ausgehe), kommst du super schnell rein und hast die ersten Ergebnisse innerhalb von Minuten - max. Stunden.
Ich muss das Thema nochmal aufwärmen. Ich habe für ein Spiel folgende Anforderungen:
Nun habe ich das Projekt mangels Alternativen mit libGDX angefangen, aber ich hasse es einfach, ShapeRenderer, SpriteBatch, Skins und das ganze Geraffel. Warum kann man das nicht hinter einer vernünftigen API verstecken?
Ich sehe aktuell folgende Alternativen:
Oder soll ich einfach die Zähne zusammenbeißen, mir intensiver Scene2D und/oder Nifty GUI reinziehen, ein paar Utils schreiben und mit libGDX weitermachen?
Ich bin gerade ziemlich unsicher. Es sollte doch nicht so schwer sein, im 21. Jahrhundert ein 2D-Spiel zu schreiben?
Hört sich nach dem an was Apo gemacht hat .
Also, wenn du bei kotlin bleiben möchtest, dann hört es sich für mich am sinnvollsten
an. Denn ich glaube, die anderen genannten sind nicht wirklich besser. Leider gibt es halt im Java-Bereich keine Engines die so einen Komfort bieten wie du es bei Unreal oder Unity hast.
Wobei du Unreal mit Kotlin kombinieren könntest:
Wobei das Project auch relativ tot ausschaut. Ka ob das noch funktionieren würde.
LibGDX scheint auf den ersten Blick aber alles zu bieten was man sich wünschen kann um ein 2D Spiel zu programmieren.
Mich würde mal interessieren was dich genau daran stört? Sonst würde ich wirklich vorschlagen mal mit Raw OpenGL anzufangen, dann ändert sich die Sicht auf die Dinge vielleicht ein bisschen 
Habe bestimmt noch einige Sachen vergessen…
Ich kenn mich mit libGDX nicht aus, weshalb mir das alles relativ wenig sagt. Aber zu zwei Punkten:
Was ich so aus der Dokumentation lesen kann, wirst du auf Klassen wie SpriteBatch nicht verzichten können, auf lange Sicht. GPUs vertragen sich leider nicht sehr gut mit OOP, da dort die Daten sequenziell und fragmentiert vorliegen. Das ist schön für eine CPU, aber eine GPU glänzt erst bei der parallelen Verarbeitung großer Datenmengen.
Je nach Engine ist das mehr oder weniger abstrahiert. Meine Engine geht da schon weiter und kann jeden beliebigen Rendercall automatisch batchen, aber das erzeugt natürlich auch einen entsprechend Overhead.
Zudem benötigst du so oder so einen statischen Zugang zur GPU, zum Rendern. Pixelbeschleuniger sind einfach unheimlich unangenehme Biester.
Das hört sich für mich aber so ziemlich genau richtig an was du da beschreibst. 
(Und in der Dokumentation dazu steht). Du registrierst die Listener und die werden jedes mal vor dem render()-call aufgerufen.
Um zum Beispiel einen Aktor in der Spielwelt zu selektieren und sein Menü anzuzeigen, könnte man jetzt den Mausklick auf Kollision mit einem beliebigen Aktor überprüfen, den in einer Variable zwischenspeichern und beim Rendern die „renderOverlay()“ Methode zum Schluss aufrufen. Mal ganz frei laut gedacht. 
Ich bin noch mal in mich gegangen. Dass die Arbeit mit libGDX an sich umständlich ist, ist für mich gar nicht so sehr das Problem, sondern eher, dass man wirklich kämpfen muss, eine klare Trennung von Model, Spiellogik und Darstellung durchzuhalten. Die API ist so gebaut, dass sie einen geradezu einlädt, alles zu einem einzigen Brei zu vermanschen, und das macht mich kirre. Aber es ist auch das, was ich von verschiedenen Seiten gehört habe: libGDX ist nicht schlecht, wenn man die richtigen Abstraktionen verwende, z.B.:
wir haben eine Menge Utils um scene2d herum gebaut, um die UI zu zähmen - insbesondere alles, was Layouting angeht.
…
was ich nur raten kann, ist zu versuchen, den Schmerz über sinnvolle Tools zu minimieren. Wir haben z.b. ein paar Helper, mit denen wir zur Laufzeit UI Elemente verschieben können, oder auch Reload / Reset des UI ohne Neustart.
(Ratschläge via Slack vom Autor von „Pathway“)