Technik in Adventures

[Marmorkuchen]

Hallo !
Ich entwickel gerade auch ein eigenes Adventure in Java (fast fertig), bin aber noch nicht ganz mit dem "Laufsystem" meines Charakters zufrieden. Wie machen das die Profis ? Werden Waypoints verwendet ?

grüße,
Mammo

[Fightmeyer]

Bin jetzt zwar kein Profi, da ich nur fertige Engines zum Adventure-Proggen nehme, aber vielleicht ist die Idee von AGS praktisch für Dich. Setz keine Wegpunkte, sondern definier eine begehbare Area. Vielleicht ist das für Dich einfacher umzusetzen.

[john_doe]

Im Prinzip gibt es zwei Ansätze, die ich ausprobiert habe:
1. Wie Fightmeyer sagt, der Ansatz aus AGS, den begehbaren Bereich zu "malen". Mit Hilfe von A* kann man dann relativ einfach den richtigen Weg von A nach B finden.
2. Ein Gitternetz ähnlich wie in AGAST. Die begehbaren Bereiche werden als Polygone (besser Dreiecke) definiert. Man kann daraus berechnen, welche Polygone miteinander verbunden sind und welche Polygone man durchschreiten muß, wenn man von A nach B will. Man "geht" dann von Dreieck nach Dreieck. Diese Methode ist weniger rechenaufwendig und wurde so ähnlich auch in Maniac Mansion benutzt.

Methode 1 ist natürlich komfortabler für den Ersteller des Spiels, da man den Bereich auch in Photoshop als eigenen Layer machen könnte. Bei Methode 2 kann man als Bonus z.B. noch Tiefen- und Lichtinformationen mit den Eckpunkten der Dreicke verknüpfen, was man sonst separat machen müßte.

[Der Wanderer]

Ich finde es einfacher, ein Netz aus Knoten zu definieren, die miteinander Verbunden sind. Die Figur kann nur auf den Knoten des Netzes stehen bleiben, und auf den Verbindungen des Netzes laufen. Dann kann man jedem Knoten neben X/Y noch Attribute geben wie z.B. eine Z-Koordinate, einen Zoom Faktor für die Figur, Helligkeit usw. Wenn der Spieler irgendwo hinklickt, wird einfach der nächste Knoten herausgesucht, und ein Pfad vom aktuellen Knoten zu diesem Knoten berechnet, der dann durchlaufen wird.

Dadurch dass die Figur nur auf den Knoten stehen bleiben kann, ist es viel einfacher die Figur exakt dort zu platzieren, wo man sie haben will, z.B. für einen Dialog oder beim Anschauen eines Objektes.

Durch die zusätzlichen Attribute eines Knoten sind dann solche Dinge möglich wie ein Baum, um den man herum gehen kann, also einmal ist er VOR der Figur, und einmal HINTER der Figur, je nach Z-Koo des Knotens. Mit einer Fläche, die gemalt wird ist das schwierig. Man könnte hier die Y-Koo nehmen, aber man stelle sich z.B. eine Leiter vor dem Baum vor, die man hochklettert, dann wäre die Figur beides mal auf der gleichen Y-Koo (einmal hinten und einmal auf der Leiter), und einmal sollte sie verdeckt werden und einmal nicht.
So ist es auch möglich, dass die Figur beim Nach-Hinten-Laufen kleiner wird (Knoten hat Zoom Faktor) und beim Hochklettern der Leiter nicht.
Ein weiterer Pluspunkt für das Netz ist, dass ein evtl. Side-Kick immer der Figur hinterherlaufen kann, ohne an einer Ecke festzuhängen. Man muss ja nur den Pfad zur Figur berechnen, und der exisitert ja wenn die Spieler Figur es auch geschafft hat dort hinzulaufen.

Meiner Meinung nach hat der Spieler bei dem Netz System auch nicht das Gefühl, eingeengt zu sein, wenn man das Netz einigermassen fein macht. Ich denke z.B. MonkeyIsland ist so gemacht. (und meine Monkeyscript Engine auch

[Gast]

Danke für die interessanten Ansätze ! Mit A* habe ich schon versucht was zu implementieren aber diese Sache ist auch leider erstmal gescheitert :/ Bei der Sache mit den Knoten muss ich dann auch noch drüber nachdenken wie ich das am besten in meinem Projekt einfügen kann !

[KhrisMUC]

@Der Wanderer:
AGS z.B. benutzt Flächen und keine Knoten, aber unmöglich ist es deswegen noch lange nicht, eine Leiter vor einen Baum zu plazieren und diese hochzugehen, wenn man auch hinter dem Baum langgehen kann.
Neben den walkable areas gibt es walkbehind areas mit in echtzeit versetzbaren baselines, und mit einem entsprechenden Skript ist das Ganze sogar relativ einfach zu realisieren.

Zugegeben, Knoten sind sehr praktisch, wenn die Wege der Figur relativ komplex sind, aber bei einfachen Hintergründen ist es doch recht nervig, eine größere Fläche mit zig Knoten zu überziehen. Und dann noch jeden einzelnen Knoten mit einem Zoom-Faktor versehen? Dann lieber einmal 60%-90% schreiben.

Zusätzlich möchte ich die Möglichkeit nicht missen, meine Figur im Walk-Modus pixelgenau plazieren zu können bzw. umgekehrt die Position der Figur pixelgenau abfragen zu können.

@Marmorkuchen:
Was genau war das Problem mit A*? Gerade mit Java sollte es gut zu lösen sein.
(Kann aber sein, dass ich es unterschätze, ich bin damals im Programmierpraktikum drei Tage am Algorithmus für die längste Handelsstrasse im Catan-Spiel gesessen...)

[john_doe]

Hmm...das mit den Knoten ist dann quasi die 3. Methode
Zu A* müßte es dutzende Besprechungen und Beispielcode geben. Vieles davon ist zwar in C/C++, dürfte aber als Grundlage reichen.
Schau mal bei http://www.gamedev.net und http://www.flipcode.com um, da gibt's viel dazu.

[Lebostein]

Bei meiner neuen Engine verwende ich einen Mix aus Dreiecksflächen (bestehend aus 3 Knoten) und Balken (bestehend aus 2 Knoten) um auch schmale Pfade gut abbilden zu können. Ich habe mich für das Knotenprinzip entschieden weil:

1. Man dort ganz einfach Parameter wie Helligkeit, Licht, Zoom oder einen z-Wert jedem Knoten zuordnen kann und sich damit eine einfache Interpolation der Werte auf der Dreiecksfläche bzw. der Line realisieren lässt

2. Man entsprechende Flächen bzw. Linien mit einer Variable verknüpfen und einzelne Bereiche je nach Situation zu- und abschalten kann (Zum Beispiel kann eine Brücke erst nach einer bestimmten Aktion passiert werden, indem der Pfad über die Brücke "abschaltbar" ist.)

3. Ich auch schmale Pfade definieren will, die der Figur den Weg exakt vorschreiben, so wie es bei Simon 1 & 2 grundsätzlich gemacht wurde (mit Pixeln sind schmale Pfade nur sehr schwer realisierbar)

4. Es nicht besonders rechenaufwändig ist und jede Menge Algorithmen existieren, z.B.: http://graphics.cs.ucdavis.edu/~okreylo ... nding.html

Außerdem hab ich schon immer Spaß und Freude an der Vektoralgebra gefunden

[KhrisMUC]

1. Was ist denn der Unterschied zwischen Helligkeit u. Licht?

Bei AGS braucht man keinen z-Wert, da man selbstverständlich mehr als eine walkable area hat und so den zoom unabhängig von der y-Koordinate festlegen kann. Zusätzlich kann man aber den z-Wert der Charaktere verändern und diese so schweben lassen.

2. Somit kann man natürlich auch einzelne areas beliebig an und ausschalten.

3. Limit bei AGS sind 3 Pixel, das ist schmal genug für exakte Wege.

4. Wenn der A* erstmal läuft, sind Pfade mit areas noch einfacher zu berechnen (da z.B. die ständig neue Interpolation wegfällt).

Aber bitte, verwendet ruhig Knoten, soviel ihr wollt

[Lebostein]

1. Was ist denn der Unterschied zwischen Helligkeit u. Licht?

Ganz einfach: Die Helligkeit gibt an, wie hell die Figur dargestellt werden soll, mit Licht habe ich die Farbe des Lichts gemeint, wenn man zum Beispiel durch ein Rotlicht-Viertel geht, erhält der Charakter einen rötliche Schimmer, wenn man an einem radioaktiven Fass Restmüll vorbeigeht, kann man ja dort eine grüne Lichtquelle ansetzen usw., unabhängig von der Helligkeit....

Und die Frage ob Pixel oder Knoten, ist eigentlich wurscht. Solange es gut aufgebaut ist und tadellos funktioniert wäre es mir als Anwender eigentlich egal...

[Gast]

Im Prinzip gibt es zwei Ansätze, die ich ausprobiert habe:
1. Wie Fightmeyer sagt, der Ansatz aus AGS, den begehbaren Bereich zu "malen". Mit Hilfe von A* kann man dann relativ einfach den richtigen Weg von A nach B finden.

ich hab die ganze Sache jetzt so versucht:

http://www.freakonline.de/problem.gif

will nicht so ganz funktionieren :/ ich arbeite gerade dran vielleicht kriegichs gleich hin. Arbeitet an einem angelehnten A* Algorithmus