Hallo,

Bei Robotic3D handelt es sich um eine Neuauflage eines alten (nie veröffentlichten) Dos Spiels von mir (auch wenn mir momentan das Spielkonzept fehlt). Dies ist eine erste Alphaversion. Das Grundgerüst (vielleicht kann man es als Engine bezeichnen) steht soweit, hier ein paar Eckdaten:

• Die einzelnen Level bestehen aus Blöcken denen eine Textur zu jeder Seite zugewiesen werden kann. Eine Kollisionsprüfung findet statt.
  
• Decke und Boden bestehen aus Flächen, die auch verschiedenen Texturen aufnehmen können.
  
• Türen schließen automatisch und nur, wenn der Spieler nicht dazwischen steht.
  
• Sich mitdrehende Objekte können durchlässig (bspw. Lampen) oder undurchlässig (bspw. Bäume) sein.

Ich habe bis jetzt nur eine kleine Demo des Programms mit fertigen Texturen aus dem Netz (die Deckenlampen sind von mir ) erstellt, ihr könnt also noch nicht allzuviel machen.

Mit den Pfeiltasten wird gesteuert. Durch Drücken von [Strg] kann nach links rechts gelaufen werden, Türen öffnen sich mit [Leertaste], wenn man genau daran steht.

Ein Problem macht mir noch die Geschwindigkeit. Ich habe einen recht guten Rechner und bei mir läuft das ganze recht flott. Wenn ihr weniger Frames als ich habe, dann lauft ihr auch langsamer, da die Geschwindigkeit von den Frames abhängig ist (soll später per Timer gemacht werden, aber dann fings bei mir etwas an zu ruckeln, was den Bildaufbau angeht. Bin halt noch Neuling in der Welt von OpenGL).


Feedback natürlich erwünscht


MfG Pr0g

ganz nett, es würde aber mehr spass machen, die korridore entlang zu wandern wenn die geh- und dreh-geschwindigkeit deutlich höher wäre. ausserdem die geschwindigkeit mit der die türen aufgehen... strafen wär auch nicht schlecht, genauso gucken mit der maus...

Wie gesagt, die Geschwindigkeit ist momentan Frameabhängig, ich habe ~300 Frames, da läuft das Spiel normal, bin aber an einer Lösung am arbeiten.

Strafen kannst du, wenn du [Strg] gedrückt hälst, während du mit den Pfeiltasten Links und Rechts läufst.

Die Maus könnte ich auch noch einbinden, obwohl sie bei dem Spiel eigentlich nicht so viel gebraucht wird, ist aber vielleicht besser, da man an eine Maus bei 3D Spielen gewöhnt ist

das spiel hat bis jetzt noch keinen sinn oder?

uall@ogc hat folgendes geschrieben:

das spiel hat bis jetzt noch keinen sinn oder?

Momentan ist es nur eine Demo, um zu zeigen, was man im Spiel bisher für Elemente realiseren kann und so. Erst wenn alles so läuft, wie sein soll, wird das ganze dann zu einem Spiel ausgearbeitet.

Ich habe jetzt mal eine neue Version hochgeladen, in welcher die Geschwindigkeit des Spielers und der Türen auch mit niedrigen Frames gleich sein sollte. Habe das ganze bei mir getestet, in dem ich die FPS per Sleep von 300 auf 30 gesenkt hatte.

Das ist richtig gut...

Bin mal gespannt was du daraus machst. Schonmal an einen Shooter gedacht? Das gröbste hast du ja jetzt...

Noch habe ich an nichts konkretes gedacht. Im alten DOS Spiel ging es darum Objekte einzusammeln (alle in einem Level) und Schlüssel für Türen (es gab aber auch nur ein Lebel ), doch das würde wohl im jetztigen Spiel keinen großen Spaß machen

Ist das absicht, das sowas geht? ich stand an der Wand und hab Strg "gestraft"

Nein, das ist ein Bug, ist mir auch schon passiert.

berechnest du auch nur das was der spieler sehen kann oder immer die ganze map?

Momentan die ganze Map, soweit bin ich noch net. Optimierungen sollen noch kommen.

wie wäre es mit raytracing, geht des ?

F34r0fTh3D4rk hat folgendes geschrieben:

wie wäre es mit raytracing, geht des ?

Was soll da gehen? Für Echtzeit-Raytracing fehlt den meisten wohl einiges an Rechnerleistung, außerdem habe ich noch keinen Raytracer geschrieben.

ok bissl aufwendig, hast recht, ermöglicht aber viel und auf lange hinsicht wahrscheinlich auch bessere performance für die zukunft siehe q3:rt

Ich wollte aber keinen Raytravcer, sondern ein OpenGL Spiel erstellen. Was bringt es mir, wenn heute kein Rechner das Spiel darstellen könnte

ja meinte ja nur ^^ aber gibt es denn sonst noch für möglichkeiten ?

Raytracing ist wahrscheinlich einfacher zu programmieren als Rendering, wenn man beides von 0 an schreiben müsste. Jedoch ist ja der Vorteil, dass du fürs Rendering OpenGL hast und vor allem ein Grafik-Chip, der dir sozusagen alles rechnet. Das mit Quake 3, da waren 20 PCs parallel am rechnen und das gab dann schlueendlich 20fps bei 512x512.
Eine einfache Physik-Engine wär doch aber noch was. Ist im Prinzip mit "normaler" Physikkenntnis möglich. Es gibt aber auch SDKs, siehe www.novodex.ch/.
Ich freu mich schon auf die kommenden Jahre, wenns dann PPUs (Physics Processing Unit) und Raytracing Chips gibt...

F34r0fTh3D4rk hat folgendes geschrieben:

ja meinte ja nur ^^ aber gibt es denn sonst noch für möglichkeiten ?

Auf was willst du denn hinaus? Die Grundlage der grafischen Ausgabe stand doch nie zur Debatte.

doch:

Zitat:

Momentan die ganze Map, soweit bin ich noch net. Optimierungen sollen noch kommen.