öhm... kommt mir das nur so vor, oder sind die meisten Kommentare jetzt nur noch Verbesserungsvorschläge für das Leveldesign dieser einen Map? Ich denke mal, dass solche Vorschläge sinnvoller sind, wenn das Spiel selbst in einem stabilen und spielbaren Zustand ist (Feinschliff). So wie ich das jetzt mitbekommen habe gibts ja noch allerhand zu tun, was nicht mit dem Leveldesign zu tun hat.

Alles zusammen find ich die Grafik bisher großartig! Wirst du auch noch ein hübsches Wasser implementieren?

_________________
Klar Soweit?

Mir fiehl gerade bei einem Screenshot den du für den HUD-Wikiartikel gepostet hast auf, dass scheinbar deine Verteilerkästen und Leitungen nicht von der Tiefenunschärfe betroffen sind.
Oder täusch' ich mich da?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Bei Splinter Cell hat man alle Zeit der Welt. Ich weiß nicht welches Gameplay du planst. Aber wenn ich da an typische Situationen in Shootern denke wäre mir eine Taste auf dem Keyboard lieber, um schnell meinen Verfolger abschütteln zu können, als in einem Menü die richtige Option zu finden. Schließlich muss ich die Tür durch die ich gerade gelaufen bin ja auch noch schließen. Aber mach du mal. So ein Menü kann man immer gebrauchen. Vielleicht erstellt jemand ein Level, in dem man einen Kran bedienen Kann oder es gibt einen großen Sicherungskasten mit 20 kleinen Schaltern, die man in einem Menü unterbringen muss.

zur Not kann man ja auch Tastatur-Shortcuts für so ein Menü unterbringen, um häufige Funktionen schneller auszuführen.

_________________
Klar Soweit?

Aber dann auch bitte gleich mit Funktion. Soll heissen, dass die Leitungen vom Sicherungskasten über die Lichtschalter bis zu den Lampen gehen. Wobei mir da auch gleich ein Spielmodus einfällt. Capture-the-Sicherungskasten.
Der Sicherungskasten leistet beispielsweise maximal 10A. Jede Lampe zieht 1A. Sprich: Die Wächter müssen sich gut überlegen wo sie Licht anmachen und wo sie Strom sparen. Der Eindringling könnte nun den Sicherungskasten sabotieren.

littleDave wird noch durchdrehen bei so viele Tipps und Anregungen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Capture-the-Sicherungskasten

Jetzt günstig bei Amazon bestellen:
Gael - zwischen Gameplay und Realismus
Kapitel 1: Wer braucht schon Türen!
Kapitel 2: Sicherung zu Schwach oder Glühlampenverbot nicht durchgesetzt?
Kapitel 3: Kisten und Rohre, das 1x1 des Ego-Shooter-Level-Designs

Und wenn wir schon bei Glühlampenverbot sind...wenn zu viel geschossen wird melden sich militante Umweltschützer, weil das die Atmosphäre zu sehr mit Treibhausgasen belastet...

Man, alles was ich sagen wollte war doch, dass es iwie seltsam aussieht, wenn 2cm neben ner Lampe ein unbeteiligtes Kabel langläuft. Und jetzt sag mir keiner, dafür, dass zu bemerken, sei ingame keine Zeit...

Zumindest bekommt das ganze sogar einen Hauch "Green-IT"

Wir sollten uns langsam mal wieder Richtung "On-Topic" bewegen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Die Türen bzw. die Durchgänge der Türen sind bisher nur Platzhalter und daher auch nicht wirklich passend. Aber jede Tür bekommt noch einen gescheiten Türrahmen


Das mit den Schildern finde ich noch sehr gut - ich denke, dass lässt sich gut umsetzen.


Ich werde mal schauen, ob ich die Lampen noch irgendwie verkabeln werde. Das mit dem heruntergängen sieht sicher auch sehr gut aus, es gibt ja jedoch noch ein kleines Problem: sowas kann ich mit meinem Editor noch nicht erstellen, da ich vorhandene Geometrie noch nicht verbiegen kann.


Es fehlt ja noch komplett des erste und das zweite Stockwerk


Also Wasser weiß ich noch nicht, ob ich es einbauen will. Was beim Deferred-Renderer ja sehr einfach ist, ist Frame-Buffer-Distortion (also Refraktion), somit könnte man schon ein paar Pfützen mit Refraktion einbauen. Bei der Reflektion schauts da schon wieder etwas anders aus, da ich dafür einen weiteren vollen Render-Pass einbauen muss - also komplett den Deferred-Pass sowie nochmal komplett den Lighting-Pass. Ob das der Performance gut tut, weiß ich noch nicht


An sich hast du ja recht, doch irgendwann muss man sich ja auch um den Feinschliff kümmern - und wenn man sowieso gerade an der Map arbeitet, kann man doch gleich ein paar Details hinzufügen. Apropos andere Bereiche: ich hab da schon wieder was neues drinnen - hab ich am Ende von diesem Post vermerkt.


Hm, eigentlich nicht *gruebel* - ich schau mir das nochmal an.


Guter Einwand - jedoch gibts da auch eine gute Antwort darauf:



da kommt schon der nächste Spielmodus-Vorschlag wobei der erste noch nicht mal ansatzweise fertig ist - aber die Idee finde ich gut



Nochmal zu dem an sich berechtigtem Einwand von Sellmann (mit den weiteren Baustellen):
Ich habe da ja schon fast ein schlechtes Gewissen bekommen und daher habe ich ein extrem wichtiges Feature implementiert: Spieler-Kollisionen mit der Map

Ich habe nun eine AA-Bounding-Box eingebaut, die per Script um den Spieler gelegt wird. Diese BB ist dann für die Kollisionen mit der Map zuständig - auf Dreiecksbasis. Dazu hole ich mir erst alle Nodes vom Collision-Tree, die ich auf Kollisionen prüfen muss. Das sind dann meistens zwei Nodes mit jeweils ca. 50 bis 100 Dreiecken. Diese gehe ich dann durch und verarbeite dann aufgetretene Kollisionen. Somit kann man jetzt wirklich durch die Gänge laufen und nicht mehr durch Wände fliegen. Die Kollisions-Reaktion ist noch nicht perfekt, da es noch folgendes Problem gibt: in den meisten Shootern bleibt man ja nicht stehen wenn man gegen eine Wand laufen würde sondern gleitet an der Wand entlang - das funktioniert bei einfachen Flächen wie bei nackten Wänden schon prima. Sobald jedoch komplexe Gebilde vorhanden sind (wie ein rundes Rohr), klappt das noch nicht so ganz. Ich werde da nochmal nach hacken müssen.

Als nächstes werde ich dann noch Zonen einbauen, um wie bereits angesprochen, Türen öffnen zu können. Das wird wahrscheinlich wieder etwas dauern - sobald das dann aber funktioniert, mach ich mal wieder ein Update im Projekt-Thread. Wenn sich wer das "Laufen" anschauen möchte, kann es hier tun.

Grüße und danke für alle fleißigen Feedback-Schreiber

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Wenn du zu viele Details bei der Kollision abprüfst tut das der Realität keinen Gefallen.
Du kannst z.B. nicht hinter ein kleines Rohr rutschen als Spieler auch wenn die Apprallrichtung des runden Rohres das Vorsieht.
Mach doch einfach BB um die Levelbestandteile die sehr Fein auflösend sind. Wenn der hohe Kollisionsdetailgrad nicht dem Spiel dient, brauchst du ihn auch nicht wirklich.

Sag ich jetzt mal so.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ja, ich denke auch, dass es sich lohnt, die dargestellte Map und das Kollisionsmesh zu trennen. Wie Flash schon sagt, die Kollision muss garnicht so hoch aufgelöst sein. Ich denke, damit kannst du auch Performance sparen. Und so kannst du verhindern, dass sich der Spieler in Ecken verhaken kann.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ihr habt beide recht und ich bin gerade dabei, dass umzustellen. Ich habe mir dabei folgendes überlegt:

Es gibt zwei Kollisionsbäume - einen für Dreiecks-genaue Berechnungen (z.B. für Schüsse) und einen mit Vereinfachungen (also Bounding-Volumes). Jetzt ist es so: bei jedem Mesh kann ich angeben, für welchen Kollisionstyp die Dreiecke verwendet werden können. Wenn ein Mesh z.B. nur für den Detail-Baum gedacht ist, werden die Dreiecke nur in den Detaillierten Baum eingebaut. Wenn die Dreiecke für beide Bäume in Ordnung sind (z.B für einzelne Kisten), sage ich einfach, dass die Dreiecke in beide Bäume eingebaut werden sollen.

Somit kann ich jetzt auch sehr einfach beliebige Bounding-Volumes erstellen - z.B. für das Geländer: dafür habe ich einfach einen unsichtbaren Würfel über das Geländer gestülpt und angegeben, dass dieser Würfel nur für den einfachen Kollisions-Baum verwendet werden soll. Dem Geländer-Mesh an sich habe ich angegeben, dass dessen Dreiecke nur für den Detail-Baum benutzt werden sollen.

Beide Bäume sind einzeln verfügbar und nicht voneinander abhängig. So verwende ich dann z.B. bei der Spieler-Kollision einfach den "Simple Collision Tree".

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Prima, erinnert mich an die Half-Life 1 Engine. Die Level enthielten ebenfalls Kollisionsflächen für verschiedene Anforderungen. Eine exakte vor allem für Kleinteile wie Splitter, Funken, Granaten und dann drei weitere für verschiedene Objektgrößen. In dieser Hinsicht unterscheidet es sich von dem was du vor hast Dave. In Half-Life 1 waren quasi drei vorgegebene Objektgrößen bereits in die Level hineinkompiliert. Statt jedem Objekt eine Bounding Box zu geben reichte es einen einzigen Punkt im Zentrum auf Kollision zu prüfen.
Man kann sich das so vorstellen, dass je größer das Objekt wird, das Level enger wird. Genial, oder? Läuft natürlich super performant so ein System. War aber leider nicht erweiterbar und spätere Modifikationen wie etwa Natural Selection, die verschieden große Aliens darstellten hatten damit zu kämpfen dass nur drei Größen möglich waren. Und zwei sind schon logisch vorgegeben: "Mensch stehend" und "Mensch geduckt"
So passierte es dann, dass das breite "Onos" geduckt so schmal wurde wie ein stehender Mensch.

Ist etwas Off-Topic, aber ich finde so Anekdoten oft inspirierend.

2GB!??
Ich glaube da musst du nochmal was dran machen... Bei solchen Größen ist die OnlineVerteilung schwer. Am ehesten noch über Torrents aber da brauchst du auch erstmal ein paar Seeder.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

2GB sind zwar viel. Aber da erlebt man meist schlimmeres. Die blöde Demo vom letzten Need For Speed hatte auch nur 1,6 GB....
Ich denke auch, dass littleDave wirklich alle Dateien (also auch unkomprimierte TGAs, etc) in seinem Projekt-Ordner hat.


@littleDave: bzgl. Backup würde ich dir gerne CVS oder SVN ans Herz legen. Das Versioning selbst nutze ich nur wenig. Eigentlich nur als Backup.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next