Lightcycle 3D

    • Konzeptfrage

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Lightcycle 3D

      Ich habe im November 2011, ein kleines Lightcycle Spiel vorgestellt (ganz ungeniert von Tron ab-inspiriert ^^ ).
      Multiplayer und 3D haben mich lange nicht losgelassen und diese Projekte sind nie über kleine Experimente und Konzeptionen hinausgewachsen. Vor kurzem habe ich ein 3D Auto Chrashderby Spiel machen wollen ganz im Stil vom alten Crash Derby und mit Treffer/Knautzonen etc. Und dachte über ein paar Waffen und Power Ups zusätzlich nach (nicht mehr so typisch Crash Derby-ish). Und dann habe ich die Idee von Lightcycles wieder aufgenommen.

      [video]http://www.youtube.com/watch?v=TFOoRVU2PRI[/video]

      Ich frage mich ob es für euch schon interessant aussieht? Ich bin mir mit dem Look noch nicht ganz so sicher, mal abgesehen, dass es sehr an der Performance nagt. Heute früh habe ich eine "Sprungmöglichkeit" eingebaut und ließ die z-Werte auch vom Server zum Client übertragen und dabei ist die Performance noch ein bissl gesunken. Dabei hätte ich gerne aber gerne mehrere befahrbare Ebenen.

      Jetzt kommt vielleicht eher eine Experten Frage, aber selbst ohne Shader ist die Performance inkl z-Achse nicht viel besser, da ich den Strahl den jeder Spieler hinterherzieht lokal in einem Grid speichere und bei 3 Werten (x,y,z) für jeden Eckpunkt statt nur 2 (x,y) das Grid pro Spalte exponentiell mehr Speicher verbraucht. Vielleicht hat ja jemand noch eine gute Idee wie man solche Werte abspeichern könnte und jeder Fahrer seinen (richtigen) Strahl hinter sich her zieht ohne dass jedes Segment ein eigenes Objekt wird und die Kollisionsabfrage trotzdem erhalten bleibt XD
      Bei Interess an einer Verbesserungsidee poste ich wie ich es genau gemacht habe, falls sich jemand auskennt.

      Primär geht es mir darum ob das Spiel optisch anspricht oder eher wegjagt :)

      ancient-pixel.com
      youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)
    • Schaut doch echt nice aus! Wenn da also Waffen und Power-ups dazukommen, kann dass sicher ein sehr lustiges Spiel werden. Insbesondere im Multiplayer.

      Jetzt kommt vielleicht eher eine Experten Frage, aber selbst ohne Shader ist die Performance inkl z-Achse nicht viel besser, da ich den Strahl den jeder Spieler hinterherzieht lokal in einem Grid speichere und bei 3 Werten (x,y,z) für jeden Eckpunkt statt nur 2 (x,y) das Grid pro Spalte exponentiell mehr Speicher verbraucht. Vielleicht hat ja jemand noch eine gute Idee wie man solche Werte abspeichern könnte und jeder Fahrer seinen (richtigen) Strahl hinter sich her zieht ohne dass jedes Segment ein eigenes Objekt wird und die Kollisionsabfrage trotzdem erhalten bleibt XD
      Bei Interess an einer Verbesserungsidee poste ich wie ich es genau gemacht habe, falls sich jemand auskennt.


      Liegt die schlechte performance jetzt eher am Zeichnen der Spielwelt/des Weg-strahls selber, oder an der Kolissionsabfrage mittels grids?
      Falls das aufbauen des 3D strahls ein problem ist, könnte man versuchen eigene vertex buffer zu verwenden. Ich habe es noch nicht getestet, aber es sollte möglich sein den Vertex-buffer nach für nach (step nach step) befüllen zu können. Mit den alten d3d_vertex_.... funktionen war das auf jedenfall nicht möglich. Hab das aber selber nicht getestet, von daher weiss ich nicht ob die neuen vertex-buffer das erlauben.

      Bei den Kolissionen wäre es wirklich besser eigene Objekte zu verwenden. Falls du durch die Grids jedesmal durchloops um Kolissionen abzufragen, kan ndas mit der dauer extremale Framerate einbrüche haben.
      Das durchlaufen von Grids/arrays in realtime ist eine (aus performancesicht) aufwendige sache. Vor allem wenn das Grid mit der Zeit immer größer wird.

      Da gibt es nun verschiedene Ansätze wie man das lösen könnte. Hier ein ansatz der an deine Methode anknüpft:
      Du könntest den Strahl aus Kolissionssicht in kleinere Objekte zu unterteilen. z.B: wenn du deinen Strahl erstellst und dabei alle paar steps die vertexkoordinaten abspeicherst, könntest du alle 4 neu erstellten Vertexe in ein grid eines neuen Kolissionsobjektes stecken.
      z.B: Vertex 1-4 ist in Objekt1 und Vertex 5-8 in Objekt2 usw...

      Nun hast du also kein riesiges Grid aus hunderten Elementen, sondern mehrere Objekte die kleinere grids mit einer fest definierten größe besitzen.
      Anhand der xyz koordinaten innerhalb eines objektes könntest du dir nun eine art "Bounding Box" errechnen, die auf xyz ebene den Bereich definiert, in dem die Vertexe des Grids sich befinden.
      Jetzt kommt der Trick:
      initialisiere in allen Kollissionobjekten eine Variable die sich z.B: "activated" nennt und setze diese auf true.
      Bevor du irgendwelche Kolissionsabfragen durchführst, setzt du mit dem with-statement (im step-event) die activated variable auf true, sodass diese vor jeglicher kolission auf true steht.
      Dann loopst du durch alle objekte (z.B: mit dem with statement) und überprüftst, ob sich der Spieler (also das fahrzeug) innerhalb der Boundingbox des kollissionsobjektes befindet, welches gerade verarbeitet wird.
      Dies sollte ein sehr einfacher und relativ schneller check sein, da die boundignbox ein simples rechteck ist und somit keine mathematisch komplexen rechenoperationen erforderlich sind.
      Wenn sich der Spieler NICHT innerhalb der Boundig box befindet, setzt du die "activated" variable auf false.

      Wenn dass passiert, kannst du nach diesen Bounding-box checks deine eigenen Kolissionsabfragen mit den Grids der Kolissions-Objekte machen.
      Dabei überspringst du in deinen Kolissionsabfragen alle objekte, bei denen "activated" auf false steht.
      Nach dem ende des step events setzt du wieder die "activated" variable von allen Kolissionsobjekten auf true und das Spiel beginnt von neuem.

      Auf die Art und weise werden koordinaten die sich außerhalb der Reichweite des Spielers befinden nicht abgefragt.
      Die Grid-abfragen würden von der anzahl an objekten abhängen die sich aus der Sicht der Bounding box mit dem Spieler überschneiden.
      Wenn also 1 Objekt 4 Koordinaten besitzt und durchnsittlich 3 Objekte gleichzeitig aktiv sind, so hast du durchschnittlich 3*4=12 Koordinatenabfragen pro Kolissionscheck.

      Ein ähnliches System verwende ich in Celaria. Dort verwende ich jedoch die instance activate und deactivate_region function um die Bounding-box checks auf der XY achse durchzuführen. (auf der z-achse ist es dann GML-code der die instanzen deaktiviert)
      Ich hoffe ich habe das halbwegs verständlich rüberbringen können. XD

      /Edit: Sorry für eventuelle Rechtschreib/Grammatikfehler. Hab das sehr schnell und chaotisch geschrieben.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von LEWA ()

    • Erinnert mich stark an das Spiel Armagetron Advanced, hab ich früher immer sehr oft gespielt :D

      Optisch ganz OK nur sieht dieses seitlich/kurven fahren etwas merkwürdig aus.
      Imagine taking your usual two century long nap minding your own business when suddenly some cunt wakes you up.
      You tell him to f*ck off of course but just when you finally managed to fall asleep again the same asshole comes knocking again. I'd attack that dick too.
    • @DragonXZ
      Meinst du das "gedrifte" oder das in die Kurve lehnen?

      @LEWA
      Sehr interessante Methode :) Ich denke ich kann so etwas ähnliches machen.
      Im Moment ist es so:
      Jeder Client schreibt in ein Grid welches (Anzahl der Clients) breit ist, alle 30 steps, in der Höhe des Grids alle x und alle y Koordinaten der Clients rein (also auf 2 zeilen), bevor er nach 30 steps die nächsten Koordinaten reinschreibt, verlängert er das Grid nach unten hin um 2 freie Plätze.
      Innerhalb der Vorschleife wo er alle anderen Spieler und deren modelle zeichnet, läuft er mit einer forschleife durch alle Grid einträge für den jeweils gerade zu zeichnenden Gegner (also durch eine bestimmte Spalte des grids) und verbindet immer x,y mit den nächsten ,xy einträgen. Er zeichnet die d3d_wall aber nur wenn sich diese innerhalb eines 1000 px radius um den eigenen Client befinden. Und auch nur in diesem bereich fragt er mit collision_line() ab ob sich der Client gerade zwischen zwei wandpunkten die gerade gedrawed werden befindet.

      Wenn ich dass in Objekte unterteile die immer auf einer 256x 256 Kachel die Strahlen in ein grid einträgt und nur dort mit dem Client interagieren können bzw gedrawed werden. Könnte es nur schwierig werden, welcher Client, welchen Strahl besitzt und es dürfen keine leeren Stellen zwischen einem Strahl in grid1 und grid2 entstehen.

      Aber ich verstehe, dass ich iwie die Last vom obj_client wegnehmen muss und das iwie zerkleinern muss mit wenigen Updates der grids pro step. Ich hatte ja gedacht, dass ich schlau bin wenn ich alles in einem Objekt und einem Grid mache^^

      ancient-pixel.com
      youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)