ZFX + Developia

Zombie-Apokalypse hat begonnen:

Nachdem das Unity/Recast-Detour Navmesh für meine analytischen Zwecke zu undetailliert war (um genauer zu sein zu ungleichmässig trianguliert), habe ich nun noch einen Grid-basierten Suchraum implementiert. Hier werden die originalen UnityNavmeshdreiecke im regelmässigen XZ-Abstand gesampelt und anschliessend die Verbindungen berechnet. Dabei ist mir aufgefallen, dass das Raycasten auf dem Unitynavmesh fehlerhaft implementiert ist und -an Stellen, wo sich das Navmesh überlappt- nicht funktioniert (man kann von einem oberen Layer in den unteren erfolgreich Raycasten). Vermutlich ist das schon in der original Recast/Detour Implementierung drin und könnte somit auch für andere Engines gelten, die es integriert haben (z.B. Unreal 4 Engine).

Hier sieht man ein kleien Testlevel ohne AI Infos:

Hier mit Navmesh + Grid-SearchSpace-Nodes

Als letztes nur mit dem Grid-SearchSpace und beispielhaft automatisch generierte Hidden Position (rot, mit hellblauen Punkten als Ambush Kandidaten). Wie man sieht werden schon relativ vernünftige Position gefunden. Als Input für den Suchalgorithmus werden dabei die Raummitte (als Start für die Suche) samt Raum-BoundingBox (zum Eingrenzen der Suche) und einige Punkte die Eingangsbereiche markieren (weisse Punkte).

Dateianhänge gelöscht? :(

Hmm, nee, musste den Beitrag neu machen, hatte die Bilder schon hochgeladen und die URL stimmten noch, zumindest in meinem Browsercache ;). Danke für den Hinweis!

Rundenbasiertes Kampfsystem:

Chic! Rundenbasierte Spiele ohne sichtbar diskrete Positionierung finde ich ziemlich interessant. Das ist glaube ich schwer gut und eingängig hinzukriegen.

Ich hab den Screenshot mal aktualisiert, damit man auch ein bisschen was vom Bedienkonzept sieht. Einzele Punkte des Ringmenüs können auch weitere Unterpunkte haben.

Lass doch beide Screenshots drin :) Wen spielt man da gerade? Ist das Ringmenü da, um zu entscheiden, was man mit dem Gegner tun möchte? Die Kreise zeigen den Aktionsradius an?

As you wish :P

Man spielt in den beiden Screenshots jeweils den Char, der im Mittelpunkt eines Kreises steht. Die Kreise zeigen verschiedene Radien an:
Rot (nicht zu sehen): Nahkampfreichweite
Blau: Fernkampfreichweite
Weiß: Laufdistanz mit Aktionspunkt-Staffelung (Ein Ring ist +1 AP Kosten)


Zur generellen Bedienung:
Man klickt mit der Maus auf einen bestimmten Punkt (sei es Gegner, Boden, ...) und kann dann kontextabhängige Aktionen wählen.
Gegner kann man mit verschiedenen Arten angreifen, wenn man auf den Boden klickt bekommt man beispielsweise die Optionen Laufen/Gehen oder Item werfen.

Später wird es noch verschiedene andere Aktionen geben (Zauber, Techniken/Machinery, ...).

Chromanoid hat geschrieben:Chic! Rundenbasierte Spiele ohne sichtbar diskrete Positionierung finde ich ziemlich interessant. Das ist glaube ich schwer gut und eingängig hinzukriegen.

Zählst du Divinity dazu?

Wie hast Du denn das gemacht, dass der blaue Kreis sich an die Landschft anpasst?

@zimmer hat geschrieben:Wie hast Du denn das gemacht, dass der blaue Kreis sich an die Landschft anpasst?

Ich weiß nicht wie es MasterQ32 gemacht hat, aber ich hätte es evtl. so gemacht: Gib beim Zeichnen des Terrains die Weltkoordinaten desselbigen vom Vertex Shader über Interpolatoren an den Fragment Shader weiter. Als Resultat hast du nun perspektivisch-korrekt interpolierte Weltkoordinaten im Screenspace bzw. im Fragment Shader. Darauf schaust du, ob die interpolierte Koordinate innerhalb eines Höhen-unbeschränkten Zylinders um den Charakter liegt, d.h. du ignorierst die Y-Koordinate komplett und berechnest den Abstand zwischen Koordinate und Charakter-Position nur mithilfe der XZ-Komponenten. Ist dieser Abstand kleiner gleich des Zylinder-Radius färbe das Fragment etwas blau ein (Blending mit Terrain-Farbe), ansonsten färbe es nur mit der Terrain-Farbe ein. Anders kannst du dir es auch so vorstellen, dass du das Terrain und die Charakter-Position auf die XZ-Ebene projizierst und dann einen Punkt-innerhalb-Kreis Test machst ausgehend von der Charakter-Position. Willst du eine Textur auf das Terrain projizieren, nimm dafür einfach einen Höhen-unbeschränkten Quader und normalisiere danach die XZ-Komponenten vor dem Abtasten der Textur.

Alexander Kornrumpf hat geschrieben:

Chromanoid hat geschrieben:Chic! Rundenbasierte Spiele ohne sichtbar diskrete Positionierung finde ich ziemlich interessant. Das ist glaube ich schwer gut und eingängig hinzukriegen.

Zählst du Divinity dazu?

Ja, stimmt das habe ich gerade gar nicht auf dem Schirm gehabt. So richtig gut finde ich den Kampf nicht gelungen. Den meisten Spaß bekomme ich vor allem durch Elementzauber-Kombinationen und andere zustandsverändernde Attacken. Gerade bei Überraschungsangriffen finde ich das Umschleichen von den Sichtbereichen der Gegner eher frustrierend. Man ist der Steuerung an manchen Stellen einfach zu sehr ausgeliefert. Also ich finde das Spiel echt gelungen, aber an vielen Stellen kommt bei mir eher ein "hacky" Sandbox-Gefühl auf. Ich glaube unter anderem ist daran die sehr freie Steuerung schuld.

mnemonix hat geschrieben:Gib beim Zeichnen des Terrains die Weltkoordinaten desselbigen vom Vertex Shader über Interpolatoren an den Fragment Shader weiter. Als Resultat hast du nun perspektivisch-korrekt interpolierte Weltkoordinaten im Screenspace bzw. im Fragment Shader. Darauf schaust du, ob die interpolierte Koordinate innerhalb eines Höhen-unbeschränkten Zylinders um den Charakter liegt, d.h. du ignorierst die Y-Koordinate komplett und berechnest den Abstand zwischen Koordinate und Charakter-Position nur mithilfe der XZ-Komponenten. Ist dieser Abstand kleiner gleich des Zylinder-Radius färbe das Fragment etwas blau ein (Blending mit Terrain-Farbe), ansonsten färbe es nur mit der Terrain-Farbe ein.

That's a bingo!
Hab genau das gemacht, nur dass ich mir frac() noch nen alternierenden Farbverlauf für mehr als eine "Ring-Schicht" eingebaut habe. Gut zu sehen im ersten Screenshot.

@Chromanoid: Mal gucken wie das läuft und ob wir bei dem freien Bewegungsmodell bleiben. Muss man eben evaluieren, was wirklich für das gewünschte Erlebnis das richtige Feeling gibt.

Hab mir schn gedacht, dass es ein shader ist aber ich drücke mich immer davor zu lernen die zu programmieren :?

Im Endeffekt kommst du nicht drumrum, wenn du irgendwas in Richtung non-primitive Grafiken machen willst. Seien es komplexere Materialien, spezielle Effekte oder ab DirectX 10/OpenGL 3 einfach nur Texturen.

Shader sind ja jetzt auch wirklich nicht schwierig. Ich behaupte, nach einem Wochenende kannst du ein Objekt mit Textur und einfacher Beleuchtung per Shader rendern. Und danach geht es halt voll ab, weil du auf einmal fast alles machen kannst :)

Ich hab mir sogar ein Buch gekauft aber es geht am Anfang schon mit Matrizen Rechnung los und das habe ich in der Schule nicht gehabt, das ist soo trocken und ich fürchte ich muß denn Anfang nochmal lesen.
Vor einem Jahr wusste ich noch nicht, dass es Shader und finde es toll was man alles damit machen kann. Ich kann zwar für Materialien und Schatten, vorgefertigte Shader nehmen aber ich würde gerne wie Master, frei effekte schreiben können. Ich fands schon geil wie Er einmal soeine Fahne(2d Element) hoch und runter wedeln ließ, bei Ihn hört sich das so einfach an, die mit denen ich vorher gesprochen habe haben mir von der Programmierung abgeraten, weil das zu schwer sei

Es kommt drauf an, wie man an die Sache rangeht.
Shader an sich sind "einfach". Du hast mehrere Stages, du musst wissen, welchen Job die Stages haben (Vertex Shader, Fragment Shader) und welches Ziel du erreichen willst.
In 90% der Fälle wird dein Vertex Shader nur deine Koordinaten-Transformation machen (Weltkoords->Bildschirm) und ein paar Variablen durchreichen (Texturkoordinaten).
Dein Pixel/Fragment-Shader sorgt dann dafür, wie die Oberfläche deines Objekts aussieht (Einfarbig, Textur, mit Shading, ...)

Mach hier (http://www.conitec.net/shaders/) einfach mal die ersten 3 tutorials, damit kommst du schon relativ weit würde ich mal behaupten.

@zimmer hat geschrieben:... die mit denen ich vorher gesprochen habe haben mir von der Programmierung abgeraten, weil das zu schwer sei

Ganz ehrlich: Schwachsinn!! Es mag vieleicht dem ein oder anderen leicht oder schwer fallen, aber lernen kann man alles wenn man bereit ist etwas Zeit rein zu stecken. Und für ein bisschen Programmieren muss man auch kein Genie sein. Shader an sich sind einfach. Aber du hast die Freiheit so komplizierte Dinge damit zu tun wie du willst. Die Matrizen im Shader sind übrigens meistens einfach nur die Transformation (Drehung, Verschiebung, Perspektive, ...) von Objekt- in Welt- und Bildschirmkoordinaten. So viel muss du darüber am Anfang nicht wissen, hald nicht davon abschrecken lassen. Eine (richtige) Multiplikation und gut is ;D

Ich hab mich vor ein paar Wochen auch in Shader eingearbeitet (meine letzten Gehversuche lagen viel Jahre zurück) und kann auch nur sagen das es eigentlich recht einfach ist damit los zu legen. Für den Anfang reicht es auch wenn man sich ein minimales Tutorial nimmt was nicht viel mehr macht als die "fixed function pipeline" per Shader zu implementiert (die kennst du ja schon). Da sind die Shader erst mal unter 10 Zeilen lang und sehr überschaubar. Von dort an kann man sich dann zu den Sachen hinarbeiten die man eigentlich machen will. Ich finde auch das Shaderprogrammierung ein sehr dankbares Thema ist: Man braucht nur wenige Zeilen und rudimentäres Knowhow und kann schon Unmengen coole Sachen machen. Und da man heutzutage auch recht viele Freiheiten in den Shadern hat (z.B. "dynamic branching" also "if" und Schleifen) kann man auch erst mal vollkommen sorglos herumexperimentieren.

Für einen Einstieg kannst du dir ja mal einen oder mehrere der diversen WebGL Shader Editoren, die so im Internet herumschwirren, anschauen und ausprobieren, um mal ein bisschen ein Gefühl zu bekommen was man damit so alles machen kann. Über die OpenGL/WebGL/ES API selbst kannst du dich dann später immer noch über diverse Tutorials/Artikel/Bücher informieren.

• http://shdr.bkcore.com/
• http://glslsandbox.com/
• http://webglplayground.net/
• http://pixelshaders.com/
• https://www.shadertoy.com/
• uvm.

Für eine kleine Übersicht, welche WebGL GLSL Direktiven und Instruktionen es so gibt, kann ich dir nur gerne die Quick Reference Cards der Khronos Seite ans Herz legen (s. WebGL PDF ab Seite 3).

P.S.: Ich finde es immer schade, dass es keine Unter-Kommentare für Posts gibt, wie man es z.B. aus Stackoverflow kennt. So wird der ganze Showroom total mit Offtopic verschmutzt. ^^

Danke aber ich mache mit Gamestudio in HLSL

Überarbeitung des Interfaces (und ein kompletter Rewrite mit meinem C#-Wrapper, damit der auch mal nen kleinen Entwicklungsschub bekommt):

Das ganze läuft jetzt über eine "Zwei-Klick-Steuerung". Zuerst wählt man die Aktion in der Toolbar aus, danach klickt man in der Kampfszene auf die Stelle an der man die Aktion ausführen will.
So werden einem die taktischen Möglichkeiten (die Terrainringe) angezeigt, ohne dass man dazu spezielle Aktionen machen muss. Zudem bedient es sich wesentlich bequemer als das Ringmenü.

Angriffe:


Laufen:

Jetzt den Terrainring vielleicht noch highlighten :) und einen halbdurchsichtigen Charakter die Aktion in einer Schleife demoartig ausführen lassen?

Was genau meinst du mit Highlighten? Hover-Effekt?

Und das mit dem Vorschau-Character find ich ne geile Idee! Dankeschön für den Vorschlag!

@Highlighten: Ja so ein dezenter Hover-Effekt wäre nicht schlecht. So vielleicht:

Klingt gar nicht mal SO blöd :P Ich werd schauen, was sich machen lässt.

Half-Edge-Koordinaten im Debugger ablesen und von Hand aufmalen macht mich bescheuert, darum habe ich mir schnell Debug-Visualisierung geschrieben. Evolutionär gesehen bin ich jetzt also so weit wie ein Affe, der mit einem Stock in der Elefantenscheiße rumpuhlt statt mit dem Zeigefinger. Aber immerhin. Das plöppt als modaler Dialog auf; und jedes Mal, wenn ich draufklicke, rechnet der Algorithmus einen Schritt weiter.

Zwischen durch etwas leicht Kost(ein Butterbrot)
ich hatte heute Morgen Langeweile :D
https://www.youtube.com/watch?v=MtVDoq-ioks