spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Sieht schon sehr beeindruckend aus!

Aaaaalso, dann wollen wir doch einmal!

Zitat von »Bambi«

-Eine GUI im Editor ähnlich wie die in Autodesk Maya. Abkoppeln von Panels und andere schöne Usibility Sachen.

Das ist geplant. Aktuell ist alles starr hart reinprogrammiert weil es schneller ging. Editor ist halt noch echt am Anfang und soll erst einmal funktionieren und dann großartig werden!

Zitat von »Bambi«

-Content Streaming

Ist drin. Solange du früh genug bescheid weißt das du Assets laden musst, kannst du das dem resource coordinator sagen und im Zweifeslfall halt blockieren wenn du es _jetzt_ sofort brauchst. Natürlich geht es auch mehrere assets auf einmal laden.

Zitat von »Bambi«

-Virtual Texturing

Siehe weiter oben... Oder ein paar Seiten zuvor. Oder so halt.

Zitat von »Bambi«

-Asset-Pipeline (Feinheiten wie, wenn ich die Model-Datei änder in einem 3D-Programm, dass die Anwendung das regetriert und das Model in Rayne aktualisiert)

Theoretisch kannst du folder bereits mit Rayne beobachten und Änderungen angucken. Aber Asset updaten ist noch nicht drin. Kommt aber auch noch.

Zitat von »Bambi«

-Animationstechniken. Inverse Kinematik. Keyframing. Interpolation zwischen Animationen.

Keyframing ja, blending ja. Inverse kinematic... Ähhm, auch eher bald™

Zitat von »Bambi«

-Physic (Bullet Physic (open source) oder Havok ?)

Bullet. Aber wenn du ne Havok Lizenz hast, hey, es ist nicht schwierig eigene Scene Node attachments zu schreiben und es zu unterstützen. Das Bullet Modul ist auch nur ein sehr dünner Wrapper über Bullet selber damit es einfach in Rayne benutzbar ist.

Zitat von »Bambi«

-GUI (da würde mich echt interessieren, was ihr verwendet ?)

Unser eigenes UI system. Das ist, wie bereits erwähnt, eher dafür gedacht richtige UIs zu bauen als 2D spiele. Es ist nicht wie das von Unity sondern erlaubt Freiheiten über das layout und funktioniert halt mehr in Richtung eines richtigen echten UI frameworks wie Cocoa.

Zitat von »Bambi«

-Netzwerk

Da benutzen wir Enet für. Nils ist da gerade am basteln

Zitat von »Bambi«

-AI

Jep, recast/detour. Für unser Occulus Rift VR Jam Projekt haben wir ein Modul dafür gebaut das wir zwar noch etwas aufbereiten und generalisieren müssen, aber dann geht das auch alles.

Zitat von »Bambi«

Was verwendet ihr als Reflection-Library. Ich hatte mal cpgf http://www.cpgf.org/ getestet und war damit sehr zufrieden.

Wir haben eine eigene auf C++11 und type_traits basierende Lösung. Es ist nicht volle Reflection, aber es ist komplett compile time (und ohne zusätzliche tools a la Qt)

Zitat von »Bambi«

Was auch nützlich für euch ist wäre: https://code.google.com/p/crashrpt/
Damit kann man leicht Crashreports vom Endverbraucher zu euch senden an eure Email-Adresse. Somit habt ihr die Crash-Dump datei und andere Sachen die ihr vllt noch haben wollt vom User, um Fehler schneller zu finden.

Nicht das es so klingt als würden wir nur unsere eigene Suppe kochen, aber solche Log Dateien wirft Rayne raus: http://rayne3d.com/static/Log.html
Zugegeben, man kann eigene logging engines erstellen die anders Speichern oder direkt ingame ausgeben und es gibt log level (das oben ist verbose) etc. pp. Oh, und es ist multithreaded.

Zitat von »Bambi«

Hab mich mal in Forum angemeldet bei euch. Würde gern die Alpha testen.

Schick mir mal deinen Nutzernamen per email (justsid@rayne3d.com)

Webkit für die GUI anbinden? Webkit selber ist gigantisch. Und wie sind die Schnittstellen nach aussen?

So groß der Hype um Webtechnologien auch sein mag, in der Industrie ist Scaleform stärker vertreten (welches ironischerweise auf der Technologie basiert, die Flash verwendet ).

Und so verbreitet HTML + CSS (+ JS) auch sein mag, gibt es dennoch genug Dinge bzgl. Layouting, die durchaus besser sein könnten.
Will man ein Element vertikal zentrieren, welches dann auch noch eine dynamische Höhe haben soll, hat man mit CSS große Probleme.
Will man 2 Elemente nebeneinander/übereinander haben, die den gesamten Platz unter sich aufteilen, wovon aber nur die Größe des einen "bekannt" (angegeben bzw. abhängig vom Inhalt) ist, hat man eine unsaubere Lösungen
Will man die Breite eines Elements abhängig von der Höhe des Elternelements zuweisen, oder sollen sich prozentuale Angaben auf andere Elemente beziehen (auf sich selbst, auf ein anderes Element mit gleichen Parent, ...), reicht CSS alleine wieder nicht aus (oder man hat wieder unsauberes CSS).

Es ist zwar durchaus interessant, wie viel sich mit HTML5, CSS3 und JS machen lässt, aber deswegen ist diese Kombination nicht unbedingt für jeden möglichen Einsatzzweck auch wirklich geeignet...

Und was die Größe von Webkit angeht: ich weiß nicht, wie umfangreich es ist, allerdings sollte man das immer in Relation sehen. Bei den meisten Hobby-Entwicklern ist das entstehende Spiel meist so klein, dass man sich wirklich fragen sollte, warum ein wesentlich komplexeres System für das UI verwendet werden soll, allerdings ist es eine fertige Lösung, die kostenlos verwendbar ist und mit der sich viele (evtl. auch der Threadersteller) bereits auskennen (und es gibt sehr viel Dokumentation und man findet auf so ziemlich jede Frage eine Antwort).
Entscheidender sollte die Frage nach der Performance (Rechenzeit, Speicherauslastung) sein und ob diese (zuzüglich laufendem Spiel) sich in einem akzeptablen Maß befindet.

Zitat von »Bambi«

Leute Leute bevor ihr auf Webkit rumhackt. Es ging mir doch um eine HTML5 Spezifikation. Gerade die Web-Standards sind gut durchgeplant und bieten alles im Multimedia-Bereich. Und die HTML5 Canvas ist wirklich super zu bedienen sag ich mal .

Ich für meinen Teil habe nicht auf Webkit rumgehackt (ich habe es eher in Schutz genommen, wenn man so will).
Die Web-Standards haben sich über einen sehr langen Zeitraum (weiter-)entwickelt. Allerdings heißt das nicht, dass diese übermäßig gut für UIs in Spielen geeignet sind

Zitat von »Bambi«

Wenn es um AAA-Spiele geht und GUI. Ja da verwenden die meisten Scaleform. Weil sie es gewohnt sind und weil Flash-Tools genutzt werden können um klicki-bunti-spassi alles zusammen zu bastel wasteln.

Und viele wollen HTML verwenden, weil sie - das könnte dir bekannt vorkommen - es gewohnt sind.
Auch wenn entsprechende Leute eine HTML-Oberfläche hätten, würden diese immernoch ihre Tools verwenden, mit denen sie ausreichend produktiv arbeiten können. Sehr wahrscheinlich würden aber noch diverse Schwierigkeiten dazu kommen, weil bspw. die in Flash umgesetzten Animationen in ein anderes Format umgewandelt werden müssen, um auf dem HTML UI angezeigt werden zu können.
Es kommt dabei nicht darauf an, wie viel man über Zusammenklicken, wie viel über Tippen und wie viel über auf einem Bildschirm rummalen erreichen kann, sondern mit welchem Tool man Assets in geforderter Qualität des angestrebten Aussehens in möglichst kurzer Zeit erstellen kann. Tools also als "Klicki Bunti Spassi" zu bezeichnen zeugt nicht gerade von Sachverständnis, sondern von Verallgemeinerungen (es wird kein Code eingehackt, also ist es ein Zusammenklicken).

Zitat von »Bambi«

Aber das heisst nicht, das nicht neue Ansätze einzug halten und sie sogar besser sein können.

Grundsätzlich hast du schon recht. Der Fakt, dass Scaleform stärker verwendet wird, sagt nichts über zukünftig verwendete Technologien aus.
Mit meinem Beitrag wollte ich aber vor allem darauf hinweisen, dass es besser sein könnte, ein spezialisiertes System zu verwenden, bei dem dann diverse Aspekte besser umgesetzt sein könnten. Qt lässt beispielsweise eine Definition der Oberflächen über QML zu, wobei man gezielt Elemente referenzieren und Berechnungen durchführen kann.

Zitat von »Bambi«

damit lässt sich mehr machen als mit Scaleform.

Beispiele? Solange die Behauptung nicht unterlegt ist, kann ich sie auch nur als reine Behauptung ansehen.
Oder anders gefragt: was kann man mit Scaleform nicht machen, was mit HTML + CSS möglich ist?

Wow, Ich mag die Idee mal richtig
Auch finde ich das Geräusch beim Laden cool
Ich frage mich bloss was all die Äpfel und Pflaumen sollen ;P

Peace

Pflaumen?! Da gibts keine Pflaumen!

Das Spiel ist simpel: Man ist in einem weißen Haus und hat eine Shotgun um auf Obst und Gemüse zu schießen um das Level einzufärben. Doch wie lockt man Obst und Gemüse an? Simpel, wo in eurem Haus befindet sich das denn immer? In der Obstschale natürlich! Warum? Weil Obst magisch zu Obstschalen angezogen wird. Obstschalen haben nämlich extra pheromone um Obst anzulocken.

Also: Mit der Obstschale Obst anlocken -> draufballern -> Ausweg finden!