Unterschied gescriptete und programmierte Quests?

[Shadowrunner]

Ich hab schon so oft gelesen, das Spiele mit "nichtgescripteten" Quests und Ereignissen werben. Ich frage mich wo liegt denn hier der unterschied?

Ist das nicht egal ob das Ereigniss von einem Script oder vom Gameprogramm ausgelöst wird?

[chewie]

Egal ist es eigentlich nicht ganz.. obwohl man darüber auch streiten kann..

Aber mal zuerst:
Ich glaub nicht, das du wirklich "programmierte Quests" meinst - oder überhaupt auf Quests hinauswillst. Oder du verwechselst was.. 

Weil:
Quests müssen IMO immer gescriptet / programmiert werden
Quests können hardcoded ("programmiert") werden

Ich könnte mir vorstellen, das du auf neuere Games wie z. B. FarCry anspielst - wo keine Scripts auf die Aktionen des Spielers reagiert, sondern eine KI. Damit kann man eigentlich super werben - wenn es denn funktioniert.

Aber Quests rein auf KI-Basis ablaufen zu lassen, ist (zumindest für mein Vorstellungsvermögen) derzeit noch unmöglich. Die klassische Quest, kille Monster X, erhalte Gegenstand Y läuft nur einmal ab - und ist danach deaktivert. Das in einer KI umzusetzen ist irgendwie ziemlicher Schwachsinn.

Eine KI ist ja von Natur aus nicht auf bestimmte Dinge getrimmt, sondern soll so weit es möglich ist "allgemein" gehalten werden. So bekommt sie nicht beigebracht, wie man die Tür zur Küche öffnet, sondern wie man jede normale Türen aufbekommt.

Um unsere klassische Quest noch mal herzunehmen: Sie besteht fast nur aus bestimmten Variablen - gehe zu Ort A, Monster X muss getötet werden, Gegenstand Y ist Belohnung. Ort A , Monster X und Gegenstand Y haben jeweils eine bestimmte ID. Zudem kommen noch fixe Dialoge. Hier ein KI einzusetzten, ist wie gesagt meiner Meinung nach Unfug... Diese KIs sind vielleicht für Shooter (wie z. B. Oblivion) interessant, aber nicht für cRPGs...

Aber ich lasse mich gerne eines besseren Belehren :-)

[Baby_Rahab]

Das Problem bei KI-Basierten Quests ist wohl, daß manchmal einfach recht unrealistische Handlungen bei den NSCs passieren können, weil sich einfach zwei Verhaltensroutinen gegnseitig hochschaukeln oder anderweitig beeinflussen können, ohne daß der KI-Coder jemals daran gedacht hätte.

Falls wir nicht vor haben, 12 Monate an der Post-Produktion (sprich: Fehler ausbügeln) verbringen wollen, sollten wir bei den gescripteten Quests bleiben.

[High Elder]

Ich kann mir unter KI-Quest wenig vorstellen, wäre also auch für das alte System. Wenn ich mich recht entsinne war das so eine tolle Baum-Form, die im einfachsten Fall eine Linie mit 2 Punken ist: Auftrag bekommen, Monster töten - FERTIG

So einfach kann Spiele machen sein ;-)

[chewie]

@High Elder

So einfach kann Spiele machen sein ;-)

Jaja, die Nicht-Scripter haben leicht reden.. ^^

KI-Quests wären für wiederkehrende Dinge durchaus brauchbar - z. B. Karawanen oder "Jagd" - mal abwarten, wie sich was am einfachsten umsetzen lässt.  Immerhin haben wir Zugriff auf eine objektorientierte Scriptsprache (LUA) - AFAIK war das z. B. bei Fallout nicht der Fall...

[Hammerit]

Naja programmierte Quests sind nichts weiter als hardgecodete Quests, also Quests die fest in ihrer finalen FOrm im Sourcecode verankert sind, während scriptbasierte Quests Code- extern verändert werden können und über eine Scriptengine als Teilkomponente der Game Engine verwurstet werden. Große Unterschiede gibt es da nicht gerade (linearer Grundaufbau, aber mehrdimensionale Verschachtelung möglich). Scripte bieten aber die Möglichkeit schnell die Missionsdaten umzuändern ohne dabei im Sourcecode rumopern zu müssen, was sehr viel praktischer ist.

Meiner Meinung nach gehört zu einem Spiel im Fallout- Stil ein tree- basiertes Scriptsystem. Je weiter die Sache verschachtelt ist desto spannender können die Scripts werden und desto unlinearer wirken sie schließlich auf den Spieler. Weil machen wir uns mal nichts vor lineare Quests nach dem Prinzip Auftrag -> Lösung -> Belohnung sind langweilig. Je mehr der Spieler in die Mission selbst eingebunden wird desto realistischer und spaßiger wirkt das ganze (und zwingt den Spieler evt. das Spiel später erneut durchzuspielen um alternative Wege zu finden).

also:

Auftrag ->	Weg 1 ->	Lösung 1 ->	Belohnung 1(bei Auswirkung 1)
->	Weg 2 ->	Lösung 2 ->	Belohnung 2 (bei Auswirkung 2)

oder sogar:

Auftrag 1 ->	Weg 1 ->	Lösung 1 ->	Belohnung 1
->	Weg 2 ->	Auftrag 2 ->	Weg 3 ->	Lösung 2 ->	Belohnung 2

[chewie]

@Hammerit

Jap - das was du sagst stimmt - aber ich glaube immer noch, das Shadowrunner die Sache mit den KIs gemeint hat. (Am besten er meldet sich dazu selbst noch mal zu Wort  )

[..] Meiner Meinung nach gehört zu einem Spiel im Fallout- Stil ein tree- basiertes Scriptsystem.

[..] lineare Quests nach dem Prinzip Auftrag -> Lösung -> Belohnung sind langweilig

Ja - und ja. Das steht für uns ausser Frage. Klar kann es mal einfache Quests geben - aber alleine schon durch das System von Choice&Consequence wird es derartige simplen Quests nicht wirklich oft in Zero geben.

Schließlich wird Zero ein richtiges cRPG, und kein Hack`n Slay 

Wegen Scriptsystem / Baumstruktur der Quests

Was ich mit dem DQL letztlich erreichen will, ist eine Baumstruktur - die sich leicht pflegen lässt.

Sprich eine Quest ist ein Objekt, und sämtliche Bereiche dieses Objekts sind Datenfelder, die sich dynamisch mit einem Eintrag oder hunderten von Einträgen füttern lassen. Gespeichert wird das Ganze in einer Datenbank, die dann von der Scriptsprache (hier: LUA) ausgelesen wird, und in Objekte verpackt wird.

Letzendlich soll ein Objektcode in LUA die ganze Geschichte handhaben - ohne das man tausende von Location-Scripts erstellen muss.

Grüßsche,
chewie

[Hammerit]

aber alleine schon durch das System von Choice&Consequence wird es derartige simplen Quests nicht wirklich oft in Zero geben.

Schließlich wird Zero ein richtiges cRPG, und kein Hack`n Slay 

Sprich eine Quest ist ein Objekt, und sämtliche Bereiche dieses Objekts sind Datenfelder, die sich dynamisch mit einem Eintrag oder hunderten von Einträgen füttern lassen. Gespeichert wird das Ganze in einer Datenbank, die dann von der Scriptsprache (hier: LUA) ausgelesen wird, und in Objekte verpackt wird.

Weiß jetzt nicht ob ich dich richtig verstanden habe. Meinst du du legst eine Klasse (Quest) an, von der du dann die eigentlichen InGame Quests anhand der beim Initialisieren gesammelten Daten ableitest? An so was ähnlichem arbeite ich derzeit rum, jedoch vorrangig auf *.zdf Basis (*.zdf heißt nichts weiter als Zero Data File ... hat also nix mit dme gleichnamigen Fernsehsender zu tuen ) und natürlich in C++ ^^. Mein Ziel ist es einfach alle Daten die nicht zwingend im Sourcecode definiert werden müssen aus diesem zu verbannen und sie später erst bei Bedarf mittels Standardroutinen aus den *.zdf Dateien einzulesen und wenn sie nicht mehr benötigt werden den Speicher wieder freizugeben, um den ganzen Ablauf besser überblicken zu können. Ein netter Nebeneffekt ist der, dass alles wesentlich übersichtlicher wird (wer kramt schon gerne in zig tausend Zeilen Code rum) ^^.

Bei uns gibt es derzeit rund 10 Objektklassen (jeweils mit Childs zur Differenzierung) und eine ganze Reihe von Handler Scripten, die dann je nach Bedarf mit den Daten verfahren.

Die Missionen sind dabei nichts weiter als makro- Scriptkolonnen die unzählige Daten mit Hilfe spezieller und allgemeiner Handler Scripte verwursten und je nach Handlung des Spielers in verschiedene Richtungen weitertriggern können). Also im Grunde nix weiter als ein multidimensionaler Skriptbaum, der sich auch mit anderen Scriptbäumen verlinken kann wenns denn nötig ist ^^.

Generell gilt: Wenns was gibt was Verallgemeinert werden kann, dann sollte dies getan werden. Es macht wenig Sinn ein und denselben Ablauf mehrere Male hardzucoden wenn man es auch über code externe Scripte lösen kann. Meiner Meinung auch einer der Gründe dafür warum heutzutage keiner mehr sowas hardcoded. DIe Datenmengen sind einfach viel zu groß geworden ^^.

Naja das netteste Plus find ich aber ist, dass man die Syntax innerhalb der externen Datensätze (also bei uns innerhalb der zdf Files) frei bestimmen kann, was einem viel Frust durch eigentlich unnötige Reglementierungen erspart.

[chewie]

*g* Ich sollte meine Doku wirklich mal auf Lesbarkeit bzw. Verständlichkeit trimmen.. 

Was ich vorhabe (mal im Schnellverfahren erklärt):

- Ein Tool basteln, das programmiertechnisch unbedarften Leuten das Erstellen von Quests erleichtert (soweit noch ziemlich "normal")
- Das Tool ins Internet packen (basiert auf PHP + MySQL)
- Die Datenbank wird gefüttert, indem die Leute dort Quests, Items, Dialoge und NPCs erstellen, und diesen Content dann miteinander verknüpfen (Einfaches Beispiel: NPC-ID(10) + Item-ID(323) +  Quest-ID(10) + Dialog(11,12,13,14,15) ergibt einen Datensatz.
- Export der nun "gefüllten" MySQL-Datenbank in Sqlite
- Sqlite-Binding für LUA benutzen
- Sqlite-Daten in LUA durch eine Klasse jagen, Objekt erstellen

Das Ganze ist noch etwas komplexer, aber im Grunde soll das so ablaufen:

Player betritt eine Stadt -> LUA checkt die Datenbank, ob Quests vorhanden sind -> Player spricht NPC an -> LUA merkt, das dieser NPC mit einer Quest verknüpft ist, checkt einen Trigger, ob der Player sich die Quest erfragt hat, und aktiviert die Quest für den Player -> Player fängt an die Quest zu lösen -> LUA checkt Trigger und NPCs, die in der Questdatenbank liegen, sobald der Player diese auslöst.

Trigger und überhaupt alles, was zum Inhalt gehört, sind in der Datenbank, LUA hat nur die nackte Klasse(n - je nachdem, ob es sinnvoll ist, hier mehrere zu bauen) zur Verfügung.

Und verräts du mir mal, warum du an c++-Code herumschraubst, ihn auf Zero-Files zugreifen lässt, und von "Wir" redest? An welchem Projekt bastelst du genau? Ich bin verwirrt