3D Jumpspiel

[Ference]

Hallo zusammen

Ich möchte als Eigenprojekt ein Jumpspiel in 3D (Egoperspektive) schreiben.

Die Aufgabe ist es in einem endlosen Turm nach oben zu streigen, während die Treppen unter einem
wegbrechen...pro Stufe gibt es Punkte und das Spiel geht solange bis man runterfällt.

Meine Frage ist mit was ich am besten die 3D grafik schreibe und auf was ich sonst noch so
aufpassen muss

Bin für jeden Tipp/Idee dankbar ^^
Ference

 

[Robokopp]

Also von 3D hab ich keine Ahnung, aber ich hab mal selbst ein solches Spiel auf Basis des Quaxlis Tutorial geschrieben.

Mein größtes Problem war, dass ich mir keine Gedanken über die Handhabung der Levels gemacht hab und dann am Ende gepfusche dabei rauskam.

Ich hatte glaub ich 3 verschiedene Ebenen reingecoded, war halt überhaupt nicht erweiterbar.

Deswegen überleg dir von vorneherein wie die Datenstruktur aussehen soll und wie die Level verarbeitet werden, sonst ist das ganze zum Scheitern verurteilt.

Ein weiteres Problem war das Sprungverhalten hinzukriegen, dafür brauchst du halt ein paar physikalische Formeln.

Aus Performancegründen solltest du nur die Objekte zeichnen und auf Kollision prüfen, die im Fenster sichtbar sind, also von y=0 bis y=displayHeight

Außerdem solltest du noch eine Funktion einbauen, die die Fallgeschwindigkeit der Blöcke erhöht, wenn sich die Figur ganz oben am Bildschirmrand befindet.

Die Grundlagen für den Rest bietet wie gesagt das Quaxli Tutorial

 

[Network]

1.:
Fang nicht mit dem Gedanken an "Ich möchte ein Spiel in 3D programmieren". Wenn du sofort mit dem Vorsatz anfängst, begrabe ich dein Projekt gerne jetzt schon. Ein Spiel ist auch nichts anderes als viele viele Daten die verarbeitet werden, während der 3D-Part dann ganz am Ende diese Daten versucht hübsch darzustellen.

Mit anderen Worten, programmiere erstmal die Logik deines Spiels (Vorlage Quaxlis-Tutorial wie soetwas aufgebaut ist) und stelle die Daten (Spielwelt, Spielfigur, Koordinaten oder was du selbst als programmierer auch immer brauchst) in simplen 2D Zeichnungen dar.
Wenn du dann mit der kompletten Spiellogik fertig bist, wechsle die Zeichenklasse am Ende auf 3D um.
3D ist kompliziert dauert lang zum erlernen und wird schnell frustrierend. Wenn du die Ausdauer nicht besitzt hast du wenigstens dein Spiel in 2D.

2.:
Planung ist alles, wirklich alles. Wenn du weisst wie die Architektur eines Spiels auszusehen hat (Quaxlis-Tutorial(Wird sehr oft empfohlen weil sehr leicht verständlich, kurz und in Java)) dann plane erstmal.
Schreibe dir auf, welche Klassen du brauchst (Namen), was diese Klassen für Aufgaben erfüllen sollen und welche Objektreferenzen sie dafür benötigen.
Bsp:
Klasse: Spielfigur
Aufgaben: Auf Spielereingaben reagieren, auf Bodenplatten hüpfen(Kollisionsüberprüfung), sich auf Spielfeld zeichnen
Referenzen: Ein Container mit allen derzeit möglichen Bodenplatten (Klasse: Spielfeld?), Zeichenklasse

Vieleicht sogar als Flussdiagramm.
Wenn du die Struktur hast, wird das Codeschreiben sehr leicht von der Hand gehen.

3.:
Vollkommen optional, aber lasse dir irgendwie deinen Code und deine herangehensweise von anderen überprüfen wenn du willst. Sei es hier im Forum mit deinem jetzigen kompilierten Projekt plus Sourcecode oder von irgendwen anderst den du kennst. Kritik führt zu Verbesserungen. Freunde nebenbei sind meist schlechte Kritiker.

Gruß
Net

 

[Kr0e]

Nimm Unity3D. Dir geht es ja offenbar um ein Resultat und nicht um das Wissen wie 3D Spiele generell funktionieren.

Mit Unity3D könntest du dein Vorhaben in 3 Tagen oder so erledigen. Kein GRund sich mit Java und LowLevel 3D Programmierung rumzuschlagen

PS:

Freunde nebenbei sind meist schlechte Kritiker.

Ich finde Freunde sind die besten Kritiker. Die meisten haben nämlich keine Ahnung von Programmieren und setzen hohe Anforderungen bis sie zufrieden sind, geben oft Tipps bzw erkennen Bugs die der Programmierer gar nicht wahr nimmt, weil er vom debuggen den Wald vor lauter Bäumen nicht sieht

 

[Ference]

Mit unity komm ich nicht so gut zurrecht , noch ..
Wenn ich etwas habe poste ich es hier ..

Ich habe jetzt jmonkey engine mal runtergeladen ...

 

[Rite]

Unity ist super, kann ich nur weiterempfehlen. Freund können übrigens gute oder schlechte Kritiker sein, je nachdem wieviel Ahnung sie haben und wie direkt sie mit ihrer Meinung rausrücken.

 

[Kr0e]

monkey engine is ok... aber naja. Nich mal im untersten 5% Bereich mit Unity vergleichbar was Produktivität und Reliability angeht,...

Jeder kommt mit Unity zurecht. Setz dich einen Nachmittag dran, les ein paar tuts und ich wette abends hast du schon iwas lustiges zusammengebastelt.

 

[Ference]

okey, kennt jemand ne gute tutorial seite? ansonsten bemühe ich halt google ^^

 

[Kr0e]

Die Seite von Unity3d hat massig Tuts...

 

[Network]

[OT]Ich hoffe einfach mal eure Ratschläge Unity3D zu verwenden sind tatsächlich ernst gemeint und ihr habt euch mit der JMonkeyEngine selbst auch mal ernsthaft auseinandergesetzt, wenn ihr diese hier so stark runtermacht gegenüber Unity3D.
Ich habe Unity3D niemals verwendet und werde deshalb auch keine Für- oder Gegenargumente bringen.

Das Problem bei solchen Dingen ist ja immer diese "Religion" der Sprachen, bei der die Programmierer immer sich gegenseitig versuchen zu bekehren ohne jemals die andere Seite kennengelernt zu haben, die eventuall sogar besser ist. Mich macht es persöhnlich sehr stutzig, dass eine auf Mono basierende Engine so toll sein kann, aber wie gesagt - nie verwendet.

Werde sie aber mal testen und ich komme wieder, wenn sie nicht so ist wie versprochen.

Nich mal im untersten 5% Bereich mit Unity vergleichbar

[/OT]

 

[Kr0e]

Die 5% waren auf die Produktivität und Reliability bezogen.

Ich habe mich damals viel mit JME beschäftigt, auch als es noch die 2er Version war.

Du musst hier stark unterscheiden... JME ist ne Engine mit einem (und da stimmt mir vermutlcih jeder zu) mega-miesem Editor auf Netbeansbasis. Abstürze, Speicherverlust etc.. Wenn JME dann nur als Library verwenden.

Und hier kommt Unity ins Spiel. Unity ist eine Game Engine + dem besten Editor den ich je gesehen habe. Habe schon mit Unreal Kit und CryEngine 3 für Free Games beschäftigt.

Ich bin vermutlcih nicht jemand, der die Sache objektiv betrachten kann. Habe einfach soviel mit JME gemacht und mich ständig über dies und das geärgert. Andauernd iein Bugfix oder Workaround...

Unity3D bietet dir eine extremst solide Basis und dazu noch Support für C# ! Endlich Syntactic-Sugar beim Programmieren


PS: @Network:

Die Engine basiert nicht auf Mono. Die Engine ist wie jede andere vernünftige Engine in C++ geschrieben. Mono wird nur als Logic-Ebene benutzt. Das schreiben der Skripte , des Spielverhalten etc etc.

Außerdem: Was ist falsch an Mono ? Endlich C# Crossplattform gestützt durch Xamarin als Firma. Mono ist Teil vieler kommerzieller großer Projekte und hinkt meistens nur wenige Version hinter .NET her.

 

[Network]

[OT]
Ich hoffe du wirst verstehen, dass ich mich nicht weiter darauf einlassen werde. Das endet dann in so einem "Welche Sprache ist besser"-Fight, und in unserem Unternehmen haben wir diesen "Showdown" gut jedes halbe Jahr einmal+ sobald ein neuer Mitarbeiter die Türschwelle übertritt.

Gruß und aus
Network

PS: Sorry hatte wohl zuviel von dem Zitat abgeschnitten
[/OT]

 

[Kr0e]

[OT]
Ich rede doch gar nicht von Sprachen :-? Sondern von den beiden Engines Unity3D und jME. C# und Java sind sowieso sehr ähnlich, insofern sehe ich bei den Sprachen keinen wirklichen Unterschied.

Jetzt hole ich ein wenig aus, was Engines generell betrifft:
--------------------------------------------------------

Und warum mein C++ Kommentar ? Grafikengines sind im Prinzip Libraries die ausschließlich auf Libraries zugreifen, welche nativ in C/C++ geschrieben sind.

-------wrapper-------

D.h.: Wenn du eine Grafikengine in einer Sprache schreiben willst, die NICHT C/C++ ist, hättest du nun ein Problem: Wie rufe ich OpenGL, OpenAL, OpenCL und vlt noch andere Sub Engines wie PhysX oder FMOD, Rakent etc zu ?

Hier kommen dann die Leute, die sagen "Wrapper!" Aber Wrapper sind meiner Meinung nach schon von der Grundidee her falsch:

1. Wrapper bedeuten overhead für jeden nativen Call (Das Marshalling der Methodenargumente und Rückgabewerte ist zwar auf einen Call gesehen nicht teuer, aber man ruft diese Methoden ja nicht nur einmal auf )

2. Wrapper sind recht umfangreiche Gebilde mit teilweise vielen tausend Methoden. Das muss irgendjemand warten. Klar, es gibt hier Generatoren für... Aber Fakt ist, hier kommt extra Arbeit auf einen zu.

3. Firmen bauen nicht auf LWJGL oder JOGL weil dies zu unsichere Projekte sind, um sein eigenes Produkt darauf zu stützen. Ich rede hier nicht von Open Source sondern insbesondere von der Community. Habe damals aber festgestellt, dass die LWJGL-Community viel aktiver ist, als JOGLs.

---------GC----------

Java, C# und die meisten anderen JIT Sprachimpl. haben GC. Das ist ansich eine sehr tolle Sache und Java als auch C# haben hier sehr ausgeklügelte Mechanismen.

ABER: GC bedeutet kurzzeitiges Stoppen der Ausführung. Es gibt auch hier gute Ansätze von Java und C# aber das ist allles nicht so, wie manuelles Speicherhandling. Ich sage nicht, dass manuelles besser ist, nur im Bereich Spiele, Grafik ist das gewichtiger Faktor.

GC schlägt natürlich nur zu, wenn du was allokiierst. Sprich JStackAlloc (oder wie auch immer das heißt) für Stackalloziierung etc und man ist schon fast aus dem Schneider. C# bietet sogar von Haus aus Stackalloc.

-----------------------

Viele dieser Gründe sind unter anderem dafür verantwortlich, dass C++ für die Engine selbst benutzt wird und eine modernere Sprache wie Java, C#, Python etc für das Skripten des Spiels benutzt wird.

---------Fazit---------

Mein kleines Fazit ist: Benutze das richtige Wergzeug für den richtigen Job.

- Du willst ein 3D Spiel erstellen und willst es vermarkten ?
-> Nimm eine fertige lösung und zahl ggf sogar dafür. Wenn dein Spiel gut is, wird es sich lohnen.

- Du hast akademisches Interesse an 3D Programmierung ?
-> Nimm jME oder mach was eigenes ... Lernen kann man am besten von ganz unten aufwärts.


Jede(s) Sprache/Tool hat seine Berechtigung (meistens). Deswegen sind religiöse Ansichten hier Unfug.

Man sollte einfach nicht versuchen, ein eckiges Schwein durch ein rundes Loch zu bringen !

Amen!


[/OT]

 

[Guest2]

[ot]Moin,

imho sollte man das zumindest bei OpenGL-Wrappern differenzierter betrachten:

1. Wrapper bedeuten overhead für jeden nativen Call (Das Marshalling der Methodenargumente und Rückgabewerte ist zwar auf einen Call gesehen nicht teuer, aber man ruft diese Methoden ja nicht nur einmal auf )

Aber auch nicht allzu oft. Letztendlich ist es doch mehr oder weniger immer dasselbe: Shader binden, Texturen binden, UBO /SSBO binden, VAO binden, zeichnen. Ab und an mal ein anderer Buffer oder ein FBO. Wenn der Overhead eines Wrappers zum Problem wird, hat der Entwickler aktuelles OpenGL schlicht nicht verstanden.

2. Wrapper sind recht umfangreiche Gebilde mit teilweise vielen tausend Methoden. Das muss irgendjemand warten. Klar, es gibt hier Generatoren für... Aber Fakt ist, hier kommt extra Arbeit auf einen zu.

Auch unter C kann man nicht direkt auf OpenGL Funktionen linken. Die Verwendung von OpenGL geschieht dort über Funktionspointer. Beispiel:

typedef void (APIENTRYP PFNGLUSEPROGRAMPROC) (GLuint program);
PFNGLUSEPROGRAMPROC glUseProgram;
glUseProgram = (PFNGLUSEPROGRAMPROC)wglGetProcAddress("glUseProgram");
[..]
glUseProgram(handle);

Deshalb verwendet man unter C/C++ auch Loading Librarys (GLEW, GL3W,...). Das ist nicht viel anders als Wrapper, nur dass es in Java eben keine Funktionspointer gibt und der Aufruf selbst durch JNI getunnelt werden muss. Der Wartungsaufwand ist aber gleich.

3. Firmen bauen nicht auf LWJGL oder JOGL weil dies zu unsichere Projekte sind, um sein eigenes Produkt darauf zu stützen. Ich rede hier nicht von Open Source sondern insbesondere von der Community. Habe damals aber festgestellt, dass die LWJGL-Community viel aktiver ist, als JOGLs.

Das sehe ich allerdings ähnlich. Meistens geht es um viel Geld und dann wird gerne auf Bewährtes gesetzt. Aus wirtschaftlicher Sicht kann das sinnvoll sein. Aus technischer Sicht nicht immer.

Viele Grüße
Fancy[/ot]