Programmierung eines 2.5D Point&Click Adventures ohne Spieleengine machbar?

[EgoStrive]

Ich bin jetzt seit knapp einem Jahr am Java programmieren und habe einige Ratespiele, sowie Labyrinthe und eben den Standardkram programmiert. Nun will ich mal ein ambitionierteres Projekt wagen: ein eigenes Point&Click Adventure. Dabei würde ich gerne so viel wie irgend möglich selber machen.
Nun zu meiner Frage: Ist es möglich eine Art von Spiel mit Aussehen und Mechanik ähnlich eines Black Mirror oder Syberia nur mit Java Code und nem Grafikprogramm auf die Beine zu stellen? Oder ist es vollkommen unrealistisch das ohne eine Engine wie Wintermute, Vision, etc. ... umzusetzen?
Wenn letzteres zutrifft, welche Engine würdet ihr empfehlen?
Mir wäre es ohne lieber. Ich weis, dass das sehr sehr viel mehr Arbeit erfordert, aber ich mache das auch, um mich als Programmierer weiterzuentwickeln, weshalb ich halt so viel es irgend geht selber coden will.
Ich hoffe ihr könnt mir weiterhelfen Danke schonmal für jeden Ratschlag!

 

[lordofdonuts]

Hallo Syberia,

der Gedanke ist in der Tat ambitioniert und ich spreche mal direkt ein Nein aus. Ohne Engine kommst du nicht weit, das gilt fuer ueber Labyrinthe usw. hinausgehende 2D-Spiele wie fuer 3D-Spiele. Dein angesprochenes 2.5D verwendet 3D-Modelle und fixiert eigentlich nur die Kameraperspektive.

Wenn du es ernst meinst, gibt es so etwas wie die eierlegende Wollmilchsau mit einer grossen Community, vielen Tutorials und fertigen 3D-Modellen, nur halt ohne Java.
https://unity3d.com/

Generell rate ich dir bei so einem Vorhaben, kein Java zu verwenden. Das ist fuer diesen Anwendungsfall ein ungeeignetes Werkzeug. Dass du dich als Entwickler selbst fortbilden willst ist loeblich, aber dazu gehoert auch, zu erkennen, ob ich lieber etwas anderes verwende.
Mit Zeit und Geduld koennte sich das generelle Nein langsam in Richtung "eventuell schon" oeffnen. Dir muss bewusst sein, dass du ohne Engine an einem Punkt bist, wo du dir die Ressource (Grafikkarte) holen musst und z.B. definierst, wo du ein Dreieck zeichnest, wann du das Dreieck wieder entfernst, wie du das Dreieck effizienter zeichnest, ... und eigentlich das Rad neu erfindest.

Nichtsdestotrotz kannst du fuer grafische Spielereien die Java 3D-API verwenden.
http://www.oracle.com/technetwork/articles/javase/index-jsp-138252.html

Oder du nimmst dir eine lib, die das schon etwas fuer dich abstrahiert und performance-optimiert hat. Sozusagen eine Engine
z.B.
https://www.lwjgl.org/ (hieraus entstand Minecraft!)
http://slick.ninjacave.com/ (fuer 2D - ist aber leider schon tot)
http://jmonkeyengine.org/ (setzt auf lwjgl auf)

Ich empfehle dir auch weiterfuehrende Literatur bzgl. Design Patterns.
http://gameprogrammingpatterns.com/

Ich wuensch dir viel Spass.

 

[lordofdonuts]

Hallo EgoStrive,

Hallo Syberia,

vezeih mir, sollte eigentlich "Hallo EgoStrive" lauten. Hab nebenbei Syberia gegoogelt, kannte ich garnicht.

 

[Joose]

Generell rate ich dir bei so einem Vorhaben, kein Java zu verwenden. Das ist fuer diesen Anwendungsfall ein ungeeignetes Werkzeug. Dass du dich als Entwickler selbst fortbilden willst ist loeblich, aber dazu gehoert auch, zu erkennen, ob ich lieber etwas anderes verwende.

Bei welcher Art von Vorhaben? Ein Spiel zu programmieren oder einer bestimmten Art Spiel?
Java ist da keinesfall ein "ungeeignetes Werkzeug" dafür. Man muss sich halt nur bewusst machen das Java im Gegensatz zu (zum Beispiel) C++ gewisse Nachteile hat.

 

[EgoStrive]

Ja, ich hatte mir schon gedacht, dass das ohne Engine ein Ding der Unmöglichkeit wird... Java ist halt derzeit die einzige Programmiersprache, die ich halbwegs zufriedenstellend beherrsche, dazu kommt noch ein bisschen Python (ist ja auch nicht allzu schwer).
Das Vorhaben will ich sicher in die Tat umsetzen! Wenn ich dazu noch was in Java hätte machen können, wäre das genial gewesen, aber ich schaue mich dann mal bei unity3D und Wintermute um.
Danke schonmal für eure Ratschläge!!!

 

[lordofdonuts]

Hallo Joose,

vorweg: ich beziehe mich jetzt ausschliesslich auf Spieleentwicklung fuer den PC und mir ist bewusst, dass vor allem dank Android Java in Punkto Spiele wieder an Bedeutung gewonnen hat.

Bei welcher Art von Vorhaben? Ein Spiel zu programmieren oder einer bestimmten Art Spiel?

Ich hab das bewusst so formuliert, weil es keine Aussage ist, die immer zu 100% zutrifft. Ein TicTacToe kann ich in Java problemlos machen, 2D-Sidescroller habe ich auch schon in Java realisiert, aber sobald es aber darum geht, wie laut OP angedacht, 3D-Modelle zu laden, braucht man schon etwas mehr.

Man muss sich halt nur bewusst machen das Java im Gegensatz zu (zum Beispiel) C++ gewisse Nachteile hat.

Das sind Nachteile wie Unberechenbarkeit der Performance aufgrund der JVM. Beim grossen Ausreisser Minecraft sieht man auch hin und wieder, wie das Spiel stockt, weil der Garbage Collector laeuft. Und daher ruehrt meine Meinung, Java sei hier das falsche Werkzeug. Man kann dazu auch Workarounds basteln, nur wozu sollt man sich das selbst schwerer machen, als es sein muss?
Dazu kommt, dass Minecraft erstens die low-level engine lwjgl verwendet, viel mehr Optimierungspotential gibts da nicht und zweitens gleichzeitig grafisch jetzt auch nicht wirklich anspruchsvoll ist.

Bei C/C++ muss ich mich zwar mit Ressourcenfreigabe selbst auseinander setzen, dafuer hab ich das dann auch selbst im Griff und keine JVM, die mir in die Parade faehrt. Verwende ich eine Engine (z.B. Unity), die mir diese Arbeit auch noch abnimmt, muss ich nicht einmal mehr das.
Dann kommen noch Dinge wie - zugegebenermassen historisch bedingt - die dahinterstehende Community mit Tutorials etc...

Es gibt da noch viele andere Punkte, auf die ich jetzt nicht eingehe, weil ich EgoStrive keine Angst machen will wenn du das anders siehst, sei es so.

Das Vorhaben will ich sicher in die Tat umsetzen! Wenn ich dazu noch was in Java hätte machen können, wäre das genial gewesen, aber ich schaue mich dann mal bei unity3D und Wintermute um.

Wenn du dir in Java leichter tust, kannst du dir auch mal die anderen von mir verlinkten Engines anschauen. Mit jMonkeyEngine wirst du einen gewissen Lerneffekt erleben und hast aber gleichzeitig ein paar Tools, die dir die Arbeit erleichern.

 

[JuKu]

Bei welcher Art von Vorhaben? Ein Spiel zu programmieren oder einer bestimmten Art Spiel?
Java ist da keinesfall ein "ungeeignetes Werkzeug" dafür. Man muss sich halt nur bewusst machen das Java im Gegensatz zu (zum Beispiel) C++ gewisse Nachteile hat.

Ich gehe sogar soweit zu sagen, dass Java genauso schnell sein kann, wie C++ (es gibt Use Cases, wo Java 3x so schnell ist, wie C++!), wenn man weiß, was man tut.
Ansonsten ist C++ einfacher.

Das sind Nachteile wie Unberechenbarkeit der Performance aufgrund der JVM. Beim grossen Ausreisser Minecraft sieht man auch hin und wieder, wie das Spiel stockt, weil der Garbage Collector laeuft. Und daher ruehrt meine Meinung, Java sei hier das falsche Werkzeug.

Gleiche Aussage wie oben:
Die JVM ist nicht unberechenbar, sie ist nur unberechenbar, wenn man nicht weiß, was man tut.
Es gibt genug Profiler Werkzeuge, die einem aufzeigen, wo das Problem liegt. Außerdem sollte man die Assets z.B. gar nicht im On-Heap (also vom GC verwaltet) haben, sondern Off-Heap, dann hat der GC damit nämlich gar nichts zu tun, deine Assets sind dann unabhängig vom GC. So macht das z.B. auch libGDX.
Der GC ist kein Grund, nur eine Ausrede.

Und Minecraft als Beispiel zu wählen ist auch nicht besonders toll.
Jeder Java Programmierer weiß, dass Notch nicht der beste Entwickler war, als er Minecraft entwickelt hat.
Das Problem war nie die Programmiersprache oder der Computer, das Problem saß vor dem Computer!
Er war auch nie der "nerdige Entwickler" und wollte auch nie so etwas großes bauen, das schreibt er auch selbst z.B. hier:
http://de.ign.com/minecraft-vita/95...minecraft-hier-ist-sein-kompletter-abschiedsb

Minecraft wurde einfach nicht effizient programmiert. Ich gebe dir aber natürlich recht, dass es leichter ist, ein Spiel mit C++ zu entwickeln, wo man keinen GC hat - dafür muss man sich aber eben selbst um alles kümmern und gerade Anfänger bauen dann sehr viele Memory Leaks rein. Aber Java ist definitiv das richtige Werkzeug für High Performance Anwendungen, sonst würde Google nicht seine ganzen Datenbanken in Java programmieren, die echt effizient laufen müssen.

Man kann dazu auch Workarounds basteln, nur wozu sollt man sich das selbst schwerer machen, als es sein muss?
Dazu kommt, dass Minecraft erstens die low-level engine lwjgl verwendet, viel mehr Optimierungspotential gibts da nicht und zweitens gleichzeitig grafisch jetzt auch nicht wirklich anspruchsvoll ist.

Minecraft basiert auf LWJGL, hat aber genug Fehler / Probleme oberhalb von LWJGL. LWJGL 3 ist schon recht effizient, da alles native passiert (deswegen brauchst du ja auch die ganzen Dynamic Link Libraries / native dependencies usw.), quasi genauso wie wenn du es mit C / C++ machen würdest. Lediglich die Game Logik schreibst du dann noch in Java.

 

[lordofdonuts]

Mal ganz provokant gefragt, welches andere Spiel ausser Minecraft gibt es, das mit Java geschrieben wurde und zum Kassenschlager wurde? Was eignet sich noch als Beispiel ausserhalb von Android?

Wenn man nicht weiss, was man tut, kann man mit C/C++ sogar noch mehr kaputt machen als mit Java. Ich setz da mal eine gewisse Grundkenntnis voraus. Ich will garnicht wissen, was bei EA, Ubisoft, Valve und Konsorten fuer Leuchten herumwerken, wenn ein Bugfix A einen neuen Bug B am anderen Ende der Welt aufreisst.
Mit schoenem Code gewinnst in der Spieleentwicklung eben keinen Blumentopf, es soll halt zum Zeitpunkt x moeglichst funktionieren.

Dass jemand, der weiss, was er tut, mit Java Code produzieren kann, der an die Effizienz von C/C++ herankommt und vice versa, bestreite ich nicht.

sonst würde Google nicht seine ganzen Datenbanken in Java programmieren, die echt effizient laufen müssen.

Wir hatten 2013/2014 auf unserem Produktivsystem (tomcat) ein massives Problem mit genau dem erwaehnten Garbage Collector, der alle paar Tage einen Leistungseinbruch bis hin zum Stillstand erzeugt hat. Besser wurde das erst mit Java 8. Es gibt eben Dinge in der JVM, ueber die man keine 100%ige Kontrolle hat. Mit den Profiler Tools konnten wir toll auf einem 30" Display zusehen, wie sich die Last gestiegen ist, aber nichts dagegen tun, ausser aufs Ausfallrechenzentrum umzuleiten.
Was Google und andere Anbieter von High Availabilty und High Performance Anwendungen naemlich machen, ist, diese Probleme einfach mit Hardware zu erschlagen. So, wie viele grosse Unternehmen solche Performanceprobleme in ihren Rich Client Applications, die virtualisiert am Thin Client laufen, auch tun. Das ist oft billiger, als einen oder mehrere Entwickler damit zu beschaeftigen, diese Leaks zu finden.

Ich will jetzt niemandem Java madig machen, es ist auch mein Lieblingswerkzeug fuer fast alles, aber es gibt eben gewisse Dinge, die lassen sich nicht leugnen.

 

[mrBrown]

Wir hatten 2013/2014 auf unserem Produktivsystem (tomcat) ein massives Problem mit genau dem erwaehnten Garbage Collector, der alle paar Tage einen Leistungseinbruch bis hin zum Stillstand erzeugt hat. Besser wurde das erst mit Java 8. Es gibt eben Dinge in der JVM, ueber die man keine 100%ige Kontrolle hat. Mit den Profiler Tools konnten wir toll auf einem 30" Display zusehen, wie sich die Last gestiegen ist, aber nichts dagegen tun, ausser aufs Ausfallrechenzentrum umzuleiten.
Was Google und andere Anbieter von High Availabilty und High Performance Anwendungen naemlich machen, ist, diese Probleme einfach mit Hardware zu erschlagen. So, wie viele grosse Unternehmen solche Performanceprobleme in ihren Rich Client Applications, die virtualisiert am Thin Client laufen, auch tun. Das ist oft billiger, als einen oder mehrere Entwickler damit zu beschaeftigen, diese Leaks zu finden.

Der GC ist mit Java 8 der gleiche geblieben, ich wüsste nicht was sich an dem großartig geändert haben soll...
Aber generell sind die meisten Performaceprobleme nicht schuld der Laufzeit oder der Sprache, sondern der Programmierer, ob in C++ oder Java

 

[lordofdonuts]

Der GC ist mit Java 8 der gleiche geblieben, ich wüsste nicht was sich an dem großartig geändert haben soll...

Dann rate ich dir zu etwas Lektuere:
http://javaeesupportpatterns.blogspot.co.at/2013/02/java-8-from-permgen-to-metaspace.html

 

[mrBrown]

Dann rate ich dir zu etwas Lektuere:
http://javaeesupportpatterns.blogspot.co.at/2013/02/java-8-from-permgen-to-metaspace.html

MemoryLayout hat sich geändert, GC ist ein beiden Fällen der Parallel GC - vermutlich hätte es da auch geholfen, die PermGen größer zu setzen oder ne andere JVM zu nutzen...

 

[lordofdonuts]

PermGen laufend vergroessern ist natuerlich eine Spitzenloesung. Im naechsten Schritt dann Speicher nachruesten, oder? Das ist genau der Punkt den ich "mit Hardware erschlagen" meine. Aus den Augen, aus dem Sinn.

 

[mrBrown]

PermGen laufend vergroessern ist natuerlich eine Spitzenloesung. Im naechsten Schritt dann Speicher nachruesten, oder? Das ist genau der Punkt den ich "mit Hardware erschlagen" meine. Aus den Augen, aus dem Sinn.

Den Rest des Satzes überlesen?
Der GarbageCollector, über den du da schimpfst, ist da eben nicht das Problem, sondern das Memory-Layout.

 

[lordofdonuts]

Dann hiess von mir aus das Problem Memory-Layout statt Garbage Collector. Schlagend wurde es in dem Fall halt erst, als der GC lief.

Wenn ihr meint, dass das heute kein Problem mehr darstellt, hab ich eben dazu gelernt. Ist doch toll. Wollt mir dieses jMonkey Zeug eh schon mal genauer anschauen.

 

[CreepyPvP]

Außerdem sollte man die Assets z.B. gar nicht im On-Heap (also vom GC verwaltet) haben, sondern Off-Heap, dann hat der GC damit nämlich gar nichts zu tun, deine Assets sind dann unabhängig vom GC. So macht das z.B. auch libGDX.
Der GC ist kein Grund, nur eine Ausrede.

Was meinst du damit? Wie könnte man so etwas bewerkstelligen?