Tehadon
Party und ne Karte
Sonntag, 1. März 2009 von peacemaker
Hallo,
es sind wieder einige Dinge geschehen, also, wird das ein etwas längerer Eintrag.
Ironstorm hat tatsächlich für uns Zeit geopfert, und die momentane Karte mal etwas schöner gemacht. Das Ergebnis hat mich sehr überrascht, also, hier mal das Ergebnis:
Das Ganze ist relativ storykonform.
Und eien kurze Erklärung zur Welt: Links seht ihr Issanûr, das alte Reich. Das Spiel selber startet in der Gefängnisinsel, wo der Spieler reingeschmissen wird. Und nein, er kann sich noch an allem erinnern, kein Gedächnisschwund, etc.
Bevor dies jedoch geschieht, gibt es noch einen Prolog. dieser Spielt auf Runthan, der zweiten Insel, genauer gesagt an der Grenze zum Niemandsland Al'Tjemen. Der Spieler spielt dort einen Elitesoldaten, und muss eine Invasion aus Al'tjemen abwehren.
Dann gibt es ja noch die Intenare. Diese wurden aus der nördlichen Einöde vertrieben, da dort zusehend die Nahrung knapp wurde, und auch sonst die Lebensbedingungen schlecht wurden.
Die Intenare planen Issanûr zu erobern, was sie zu dem Zeitpunkt, in dem das Spiel beginnt auch zu grossen Teilen getan haben.
Einzig bei den westlichen Dörfern, dem südöstlichen Marhem und dem Rebellenhauptquartier in Aarhem, sind noch unter Menschenskontrolle. Das ganze formt einen Nebenzweig der Story, hier ist die Aufgabe des Spielers dem Widerstand zu helfen.
Nun, alles weitere erklären wir dann bald, ich denke das reicht erstmal.
So, auf zum technischen Blabla.
Ich habe nun an der Kampf-KI der NPCs gearbeitet. Es gibt nun ein Party-System, das heisst Gruppen für NPCs.
Jede Party hat einen Leader, das ist der Stärkste NPC der Gruppe. Er teilt mithilfe des Message-Systems Befehle an die anderen NPCs der Party, beispielweise sorgt er dafür, das der Gegner schön umstellt wird, Bogenschützen Distanz halten, usw.
Es funktioniert in diesem Bereich bisher schon einiges. Ich erklärs euch in diesem Beispiel:
Der Spieler zieht mitten in einem Dorf eine Waffe. Da er noch keinen sonderlichen Rang oder Ruf hat, wird er auch sofort aufgefordert die Waffe wegzustecken. Tut er es nicht, wird er sofort angegriffen.
Alle NPCs im Dorf greifen ihn an, nun gibt es zwei Parties: die eine, wo der Spieler drin ist, und eine, wo die NPCs des Dorfes drin sind.
Das funktioniert schon mal, und auch das Neu-hinzukommen von NPCs funktioniert tadellos.
Tritt nämlich einer der Party bei, wird sofort geschaut, ob er sich als Leader eignet, und wird, wenn nötig, als auch solcher gesetzt.
In folgendem Bild seht ihr eine Auflistung in der Ingame-Debugkonsole. Die Rotmarkierten sind jeweils die Leader der Party. "Alois" heisst der Spielercharakter.
Es funktioniert relativ gut so weit, nur passiert es nach wie vor das sich NPCs auf die Füsse treten....
Der Spieler ist der, mit dem Knüppel in der Hand.
Und ja, ihr seht vlt, das die NPCs noch gar keine Waffen gezogen haben. Das war ein kleiner Bug, wurde mittlerweile gefixt, aber ich war dann doch zu faul ein neues Bild aufzunehmen.
Dann noch was.... Smaesh, einer unserer 3D-Männer, hat sich rangesetzt, und eine neue Version des Intenars gemacht. Das Ganze hat knapp 2000 Polys, und hat bereits ein Skelett samt Lauf-Animation.
Hier den Intenar in Action-Pose:
Wie ihr seht ist er komplett nackt, das liegt daran, das Rüstungen, Haare, etc. im Spiel später reingesetzt werden. Das Skelett ist relativ modular aufgebaut, sodass man leicht den Oberkörper mit nem Harnisch wechseln kann, etc.
So viel erstmal,
mfG
es sind wieder einige Dinge geschehen, also, wird das ein etwas längerer Eintrag.
Ironstorm hat tatsächlich für uns Zeit geopfert, und die momentane Karte mal etwas schöner gemacht. Das Ergebnis hat mich sehr überrascht, also, hier mal das Ergebnis:
Das Ganze ist relativ storykonform.
Und eien kurze Erklärung zur Welt: Links seht ihr Issanûr, das alte Reich. Das Spiel selber startet in der Gefängnisinsel, wo der Spieler reingeschmissen wird. Und nein, er kann sich noch an allem erinnern, kein Gedächnisschwund, etc.
Bevor dies jedoch geschieht, gibt es noch einen Prolog. dieser Spielt auf Runthan, der zweiten Insel, genauer gesagt an der Grenze zum Niemandsland Al'Tjemen. Der Spieler spielt dort einen Elitesoldaten, und muss eine Invasion aus Al'tjemen abwehren.
Dann gibt es ja noch die Intenare. Diese wurden aus der nördlichen Einöde vertrieben, da dort zusehend die Nahrung knapp wurde, und auch sonst die Lebensbedingungen schlecht wurden.
Die Intenare planen Issanûr zu erobern, was sie zu dem Zeitpunkt, in dem das Spiel beginnt auch zu grossen Teilen getan haben.
Einzig bei den westlichen Dörfern, dem südöstlichen Marhem und dem Rebellenhauptquartier in Aarhem, sind noch unter Menschenskontrolle. Das ganze formt einen Nebenzweig der Story, hier ist die Aufgabe des Spielers dem Widerstand zu helfen.
Nun, alles weitere erklären wir dann bald, ich denke das reicht erstmal.
So, auf zum technischen Blabla.
Ich habe nun an der Kampf-KI der NPCs gearbeitet. Es gibt nun ein Party-System, das heisst Gruppen für NPCs.
Jede Party hat einen Leader, das ist der Stärkste NPC der Gruppe. Er teilt mithilfe des Message-Systems Befehle an die anderen NPCs der Party, beispielweise sorgt er dafür, das der Gegner schön umstellt wird, Bogenschützen Distanz halten, usw.
Es funktioniert in diesem Bereich bisher schon einiges. Ich erklärs euch in diesem Beispiel:
Der Spieler zieht mitten in einem Dorf eine Waffe. Da er noch keinen sonderlichen Rang oder Ruf hat, wird er auch sofort aufgefordert die Waffe wegzustecken. Tut er es nicht, wird er sofort angegriffen.
Alle NPCs im Dorf greifen ihn an, nun gibt es zwei Parties: die eine, wo der Spieler drin ist, und eine, wo die NPCs des Dorfes drin sind.
Das funktioniert schon mal, und auch das Neu-hinzukommen von NPCs funktioniert tadellos.
Tritt nämlich einer der Party bei, wird sofort geschaut, ob er sich als Leader eignet, und wird, wenn nötig, als auch solcher gesetzt.
In folgendem Bild seht ihr eine Auflistung in der Ingame-Debugkonsole. Die Rotmarkierten sind jeweils die Leader der Party. "Alois" heisst der Spielercharakter.
Es funktioniert relativ gut so weit, nur passiert es nach wie vor das sich NPCs auf die Füsse treten....
Der Spieler ist der, mit dem Knüppel in der Hand.
Und ja, ihr seht vlt, das die NPCs noch gar keine Waffen gezogen haben. Das war ein kleiner Bug, wurde mittlerweile gefixt, aber ich war dann doch zu faul ein neues Bild aufzunehmen.
Dann noch was.... Smaesh, einer unserer 3D-Männer, hat sich rangesetzt, und eine neue Version des Intenars gemacht. Das Ganze hat knapp 2000 Polys, und hat bereits ein Skelett samt Lauf-Animation.
Hier den Intenar in Action-Pose:
Wie ihr seht ist er komplett nackt, das liegt daran, das Rüstungen, Haare, etc. im Spiel später reingesetzt werden. Das Skelett ist relativ modular aufgebaut, sodass man leicht den Oberkörper mit nem Harnisch wechseln kann, etc.
So viel erstmal,
mfG
Gameplay-Sektion
Samstag, 28. Februar 2009 von peacemaker
Nun haben wir in der Webseite auch eine Gameplay-Sektion eingerichtet, wo wir in Zukunft diverse Gameplayrelevante Dinge mit Beispielen zeigen wollen.
Das ganze ist hier zu finden, es gibt auch schon einen ersten Eintrag, der eine einfache "Töte NPC-Gruppen"-Quest zeigt.
mfG
Das ganze ist hier zu finden, es gibt auch schon einen ersten Eintrag, der eine einfache "Töte NPC-Gruppen"-Quest zeigt.
mfG
nav und tagebuch
Sonntag, 22. Februar 2009 von peacemaker
Hallo,
ich habe zwei neue Dinge gemacht, eines davon ist das statische wegsystem. Dies sorgt dafür, das NPCs vorberechnete Wege laufen können. Das ist beispielweise dort sinnvoll, wenn ein NPC von einem Dorf, zu einem anderen laufen muss, und dies nicht dynamisch erfolgt, sondern irgendwie im Skript aufgerufen wird.
Auch kann man das sehr gut für die Tagesabläufe, die sich ja immer wieder wiederholen benutzen, da die NPCs ja immer die gleichen Wege laufen.
Diese Wege werden einfach in eine *.nav-Datei gespeichert, man braucht im Skript nur eine kleine Funktion aufzurufen, schon wird die State-queue abgefüllt:
Code: [AUSKLAPPEN]
$isoran->staticNavWay ("QUE_ISORAN_MEET_XENADAS");
Das lässt den NPC Isoran die Route die aus der Datei QUE_ISORAN_MEET_XENADAS.nav gelesen wird, laufen.
Diese Route mal visualisiert:
Dann noch das Tagebuch. Ich habe nun das ganze etwas enger mit dem Questsystem zusammengeschweisst, sodass beisipelweise bein annehmen einer Quest automatisch ein Eintrag mit dem Questnamen als Titel und der Questbeschreibung als Inhalt erstellt wird.
Will man einer Quest einen Eintrag hinzufügen, eifnach:
Code: [AUSKLAPPEN]
$QUE_Test->addEntry ("Ich habe den Auftrag nun gelöst.<br>Das steht in einer neuen Zeile.");
Da die GUI noch keine Lisbtox unterstützt, hab ich vorerst Buttons genutzt. Das lässt sich aber entsprechend einfach abändern.
Dann hat noch NightPhoenix sich an einem besseren Skin für das Interface rangewagt. Rausgekommen ist das hier. Ob es dann verwendet wird, wird sich noch zeigen.
mfG
ich habe zwei neue Dinge gemacht, eines davon ist das statische wegsystem. Dies sorgt dafür, das NPCs vorberechnete Wege laufen können. Das ist beispielweise dort sinnvoll, wenn ein NPC von einem Dorf, zu einem anderen laufen muss, und dies nicht dynamisch erfolgt, sondern irgendwie im Skript aufgerufen wird.
Auch kann man das sehr gut für die Tagesabläufe, die sich ja immer wieder wiederholen benutzen, da die NPCs ja immer die gleichen Wege laufen.
Diese Wege werden einfach in eine *.nav-Datei gespeichert, man braucht im Skript nur eine kleine Funktion aufzurufen, schon wird die State-queue abgefüllt:
Code: [AUSKLAPPEN]
$isoran->staticNavWay ("QUE_ISORAN_MEET_XENADAS");
Das lässt den NPC Isoran die Route die aus der Datei QUE_ISORAN_MEET_XENADAS.nav gelesen wird, laufen.
Diese Route mal visualisiert:
Dann noch das Tagebuch. Ich habe nun das ganze etwas enger mit dem Questsystem zusammengeschweisst, sodass beisipelweise bein annehmen einer Quest automatisch ein Eintrag mit dem Questnamen als Titel und der Questbeschreibung als Inhalt erstellt wird.
Will man einer Quest einen Eintrag hinzufügen, eifnach:
Code: [AUSKLAPPEN]
$QUE_Test->addEntry ("Ich habe den Auftrag nun gelöst.<br>Das steht in einer neuen Zeile.");
Da die GUI noch keine Lisbtox unterstützt, hab ich vorerst Buttons genutzt. Das lässt sich aber entsprechend einfach abändern.
Dann hat noch NightPhoenix sich an einem besseren Skin für das Interface rangewagt. Rausgekommen ist das hier. Ob es dann verwendet wird, wird sich noch zeigen.
mfG
ein paar Dinge
Freitag, 20. Februar 2009 von peacemaker
Hallo,
ich habe eigentlich nicht allzu viel getan, wesshalb ich mich etwas kurz fasse.
Ich habe das Handeln an die neue GUI angepasst.
Es wird etwas bequemer sein als das alte, man kann nun einfach ein Item in das andere Inventar schieben. Wenn man ein Item selektiert, öffnet sich ein Tooltip, welches Name, Beschreibung, und Preis anzeigt.
Ihr seht vlt, das die Beschreibung unvollständig ist. Das ist ein kleiner Bug in der GUI, bei welchem bei den Labels immer das letzte Wort abgeschnitten wird. Laut Noobody wird aber auch das bald gefixt.
Und dann einfach noch ein Bild. Wirklich speziell ist es nicht, nach wie vor die gleiche Szenerie, das Gras hört wieder recht nahe an der Kamera auf, usw.
So viel erstmal,
mfG
ich habe eigentlich nicht allzu viel getan, wesshalb ich mich etwas kurz fasse.
Ich habe das Handeln an die neue GUI angepasst.
Es wird etwas bequemer sein als das alte, man kann nun einfach ein Item in das andere Inventar schieben. Wenn man ein Item selektiert, öffnet sich ein Tooltip, welches Name, Beschreibung, und Preis anzeigt.
Ihr seht vlt, das die Beschreibung unvollständig ist. Das ist ein kleiner Bug in der GUI, bei welchem bei den Labels immer das letzte Wort abgeschnitten wird. Laut Noobody wird aber auch das bald gefixt.
Und dann einfach noch ein Bild. Wirklich speziell ist es nicht, nach wie vor die gleiche Szenerie, das Gras hört wieder recht nahe an der Kamera auf, usw.
So viel erstmal,
mfG
Listbox und Styles
Montag, 16. Februar 2009 von Noobody
Grossartige Neuigkeiten!
Nach 2 Stunden coden und 3 Stunden Debuggen kann die GUI nun die Style.txt und die zugehörigen Grafiken in eine .style - Datei packen.
Dies bringt gleich mehrere Vorteile: Zum einen sind die Grafiken nicht in einem überquellenden Ordner, sondern schön in die Datei gepackt. Ausserdem kann nun niemand Grafiken oder die Style.txt klauen, falls mal jemand auf so eine Idee kommen sollte
Zudem verbessert dieses Vorgehen die Ladezeit um ein vielfaches. Der Grund? Bisher wurden die Grafiken, falls sie nicht eine 2er - Potenz Kantenlänge hatten, nochmals mit der richtigen Grösse abgespeichert und geladen, damit sie korrekt dargestellt werden (und um den CreateTexture - Bug zu umgehen). Das ist aber relativ langsam, weswegen der Style vorher ca. 2.5 Sekunden zum laden hatte.
Jetzt werden die Grafiken beim packen direkt mit der richtigen Grösse im Style abgespeichert.
Die Generierung der Fonts während Laufzeit frass auch gehörig Zeit, daher werden diese nun auch vorrausberechnet und in die Styledatei gespeichert.
Die Fonts waren übrigens auch der Grund für die 3 Stunden Debugging. Weil ein 512er Font mit 3 Bytes Farbkanal 0.75 Mb Speicherplatz frisst, kam mir die Idee, die Fonts zu komprimieren. Weil eine Fontgrafik sowieso nur Schwarzweiss ist, dachte ich mir, ich speichere einen Pixel in einem Bit. Ist das Bit 1, ist der Pixel weiss, ist das Bit 0, ist der Pixel schwarz. Das hat auch gut funktioniert (ein Font frisst jetzt nur noch 32 Kb), nur hatten die geladenen Fonts einfach mitten im Bild zufällig verstreute weisse Pixel, die eigentlich nicht dazugehören.
Ich hatte die ganze Speicher- und Laderoutine auseinandergenommen, nur um am Ende zu merken, dass ich eine falsche Annahme für Banks hatte.
Wenn man eine Bank nämlich mit Resizebank vergrössert, wird der neue Speicher NICHT mit nullen vorbelegt, sondern enthält zufällige Werte - was halt dort vorher im Arbeitsspeicher lag. Damit entstanden diese völlig unerklärlichen Pixelfehler, die ihren Tribut in einem völlig ausgelaugten Noobody forderten.
Die Bilder im Style werden übrigens nicht temporär entpackt oder so - es werden gleich die rohen Bilddaten im Style gespeichert, geladen und dann auf die Textur gezeichnet, damit man nicht mal schnell das Programm einfriert, bevor es die kurz entpackten Grafiken wieder löschen kann.
Die Style.txt wird ausserdem noch in Bytecode kompiliert, um zum einen die Grösse zu drücken und damit auch eine Art 'Verschlüsselung' entsteht, wie sie mal in einem Kommentar gefordert wurde.
Zweite Neuigkeit ist die Listbox.
Zu der gibt es nicht viel zu erzählen - sie funktioniert halt so, wie eine Listbox funktionieren sollte.
Die Itembox ist nicht wirklich neu, da sie ja schon im letzten Eintrag vorgestellt wurden.
Nur so als Hinweis: Wenn die Items aus dem Fenster gezogen werden, muss man sich nicht darüber wundern, dass sie verschwinden
Dann wird von der GUI nämlich angenommen, dass die Items jetzt auf den Boden gefallen lassen werden, löscht sie aus der internen Liste und ruft ein Event aus, dass jetzt Items gefallen lassen werden.
Eine kleine Demo: Download (die neuen Gadgets sind auf Tabseite 4 und 5).
PS: Ja, wir wissen, der aktuelle Style ist grässlich und passt überhaupt nicht zum Spiel. Wir haben nur noch keinen Grafiker frei, der sich darum kümmert
Nach 2 Stunden coden und 3 Stunden Debuggen kann die GUI nun die Style.txt und die zugehörigen Grafiken in eine .style - Datei packen.
Dies bringt gleich mehrere Vorteile: Zum einen sind die Grafiken nicht in einem überquellenden Ordner, sondern schön in die Datei gepackt. Ausserdem kann nun niemand Grafiken oder die Style.txt klauen, falls mal jemand auf so eine Idee kommen sollte
Zudem verbessert dieses Vorgehen die Ladezeit um ein vielfaches. Der Grund? Bisher wurden die Grafiken, falls sie nicht eine 2er - Potenz Kantenlänge hatten, nochmals mit der richtigen Grösse abgespeichert und geladen, damit sie korrekt dargestellt werden (und um den CreateTexture - Bug zu umgehen). Das ist aber relativ langsam, weswegen der Style vorher ca. 2.5 Sekunden zum laden hatte.
Jetzt werden die Grafiken beim packen direkt mit der richtigen Grösse im Style abgespeichert.
Die Generierung der Fonts während Laufzeit frass auch gehörig Zeit, daher werden diese nun auch vorrausberechnet und in die Styledatei gespeichert.
Die Fonts waren übrigens auch der Grund für die 3 Stunden Debugging. Weil ein 512er Font mit 3 Bytes Farbkanal 0.75 Mb Speicherplatz frisst, kam mir die Idee, die Fonts zu komprimieren. Weil eine Fontgrafik sowieso nur Schwarzweiss ist, dachte ich mir, ich speichere einen Pixel in einem Bit. Ist das Bit 1, ist der Pixel weiss, ist das Bit 0, ist der Pixel schwarz. Das hat auch gut funktioniert (ein Font frisst jetzt nur noch 32 Kb), nur hatten die geladenen Fonts einfach mitten im Bild zufällig verstreute weisse Pixel, die eigentlich nicht dazugehören.
Ich hatte die ganze Speicher- und Laderoutine auseinandergenommen, nur um am Ende zu merken, dass ich eine falsche Annahme für Banks hatte.
Wenn man eine Bank nämlich mit Resizebank vergrössert, wird der neue Speicher NICHT mit nullen vorbelegt, sondern enthält zufällige Werte - was halt dort vorher im Arbeitsspeicher lag. Damit entstanden diese völlig unerklärlichen Pixelfehler, die ihren Tribut in einem völlig ausgelaugten Noobody forderten.
Die Bilder im Style werden übrigens nicht temporär entpackt oder so - es werden gleich die rohen Bilddaten im Style gespeichert, geladen und dann auf die Textur gezeichnet, damit man nicht mal schnell das Programm einfriert, bevor es die kurz entpackten Grafiken wieder löschen kann.
Die Style.txt wird ausserdem noch in Bytecode kompiliert, um zum einen die Grösse zu drücken und damit auch eine Art 'Verschlüsselung' entsteht, wie sie mal in einem Kommentar gefordert wurde.
Zweite Neuigkeit ist die Listbox.
Zu der gibt es nicht viel zu erzählen - sie funktioniert halt so, wie eine Listbox funktionieren sollte.
Die Itembox ist nicht wirklich neu, da sie ja schon im letzten Eintrag vorgestellt wurden.
Nur so als Hinweis: Wenn die Items aus dem Fenster gezogen werden, muss man sich nicht darüber wundern, dass sie verschwinden
Dann wird von der GUI nämlich angenommen, dass die Items jetzt auf den Boden gefallen lassen werden, löscht sie aus der internen Liste und ruft ein Event aus, dass jetzt Items gefallen lassen werden.
Eine kleine Demo: Download (die neuen Gadgets sind auf Tabseite 4 und 5).
PS: Ja, wir wissen, der aktuelle Style ist grässlich und passt überhaupt nicht zum Spiel. Wir haben nur noch keinen Grafiker frei, der sich darum kümmert
Quests
Sonntag, 15. Februar 2009 von peacemaker
Hallo,
zuerst einmal hat Quantarie an seinem Terrain weitergewerkelt. Hier ein Rendering davon. Neu hinzugekommen ist der See und dieser Bereich in der Mitte...
Das ganze hat immernoch knapp 20 000 Polygone, ist also für ein Terrain dieser Grösse vollkommen okay. Desweiteren hat Quantarie nun auch den Vorschlag von EvilTwin umgesetzt. Der war denkbar simpel: bei den unteren Ebenen von einer Wand oä. wird die Textur oft gekachelt, da der Spieler diese ja von recht nahem sieht. Alle höheren Flächen, die er nie von allzu nahem sieht, werden wenig gekachelt, damit nicht zu starke Muster erkennbar sind. Das ganze mit einigermassen gutem Übergang, und schon siehts besser aus.
Dann hab ich das Questsystem wieder mal komplett auf den Kopf gestellt. Wie schon einmal angekündigt, habe ich die Statement-Referenzen inplementiert, sodass man diverse Bedingungen einer Quest definieren kann, welche auch Frame für Frame ohne Speedverlust geprüft werden.
Ein Vorteil von diesen Veränderungen ist auch Übersicht. Das Problem bei der alten Technik war, das die ganze Quest in zig Skripten verteilt war. Wenn es eine Tötungsquest war, wurde sie in einer Datei definiert, und in der NPC-Datei, beim onKill-Event beendet.
Das ist nun eigentlich komplett verhindert worden.
Ich zeig euch heute mal ein Beispiel, welches etwas umfangreicher ist. Eine Eroberung!
Das komplette Skript (Fragen, wenn was nicht klar ist) :
Code: [AUSKLAPPEN]
var $quest = createQuest ("Eroberung von Marhem", "");
// Quest ist erfolgreich, wenn Marhem derSpieler-Fraktion gehört
$quest->solve = sref ($marhem->ownerFrac == $hero->frac);
// Quest scheitert, wenn Rebellenboss beim Angriff stirbt
$quest->fail = sref ($rebelBoss->isDead ());
$quest->onStart = fref (quest_start);
$quest->onSolve = fref (quest_solve);
// Quest-Vars
$quest->setVar (QUEST_VAR_GIVE_XP, 600);
// Gibt dem Spieler 600 Erfahrungspunket, wenn erfolgreich
$quest->setVar (QUEST_REP_HERO_FRAC, $hero->frac);
$quest->setVar (QUEST_REP_HERO_FRAC_PT, 500);
// Erhöht Spielerruf bei Fraktion $hero->frac um 500
// Wenn quest angenommen wird
void quest_start ()
{
// Quest startet
// NPCs folgen dem Spieler
$rebel01->follow ($hero);
$rebel02->follow ($hero);
$rebel03->follow ($hero);
$rebelBoss->follow ($hero);
};
void quest_solved ()
{
$fracIntenare->heroRep = $fracIntenare->heroRep - 30;
// Senkt den Ruf bei der Fraktion, die von Stadt vertrieben wurde
};
Also, das neue daran ist eben dieses solve, fail, und dieses setVar. Mit setVar setzt man ein paar Eigenschaften, man braucht sie aber nicht umbedingt.
Dort kann man beispielweise Bedingungen festlegen, die angeben, wann die Quest angenommen werden darf, etc.
So viel dazu,
mfG
zuerst einmal hat Quantarie an seinem Terrain weitergewerkelt. Hier ein Rendering davon. Neu hinzugekommen ist der See und dieser Bereich in der Mitte...
Das ganze hat immernoch knapp 20 000 Polygone, ist also für ein Terrain dieser Grösse vollkommen okay. Desweiteren hat Quantarie nun auch den Vorschlag von EvilTwin umgesetzt. Der war denkbar simpel: bei den unteren Ebenen von einer Wand oä. wird die Textur oft gekachelt, da der Spieler diese ja von recht nahem sieht. Alle höheren Flächen, die er nie von allzu nahem sieht, werden wenig gekachelt, damit nicht zu starke Muster erkennbar sind. Das ganze mit einigermassen gutem Übergang, und schon siehts besser aus.
Dann hab ich das Questsystem wieder mal komplett auf den Kopf gestellt. Wie schon einmal angekündigt, habe ich die Statement-Referenzen inplementiert, sodass man diverse Bedingungen einer Quest definieren kann, welche auch Frame für Frame ohne Speedverlust geprüft werden.
Ein Vorteil von diesen Veränderungen ist auch Übersicht. Das Problem bei der alten Technik war, das die ganze Quest in zig Skripten verteilt war. Wenn es eine Tötungsquest war, wurde sie in einer Datei definiert, und in der NPC-Datei, beim onKill-Event beendet.
Das ist nun eigentlich komplett verhindert worden.
Ich zeig euch heute mal ein Beispiel, welches etwas umfangreicher ist. Eine Eroberung!
Das komplette Skript (Fragen, wenn was nicht klar ist) :
Code: [AUSKLAPPEN]
var $quest = createQuest ("Eroberung von Marhem", "");
// Quest ist erfolgreich, wenn Marhem derSpieler-Fraktion gehört
$quest->solve = sref ($marhem->ownerFrac == $hero->frac);
// Quest scheitert, wenn Rebellenboss beim Angriff stirbt
$quest->fail = sref ($rebelBoss->isDead ());
$quest->onStart = fref (quest_start);
$quest->onSolve = fref (quest_solve);
// Quest-Vars
$quest->setVar (QUEST_VAR_GIVE_XP, 600);
// Gibt dem Spieler 600 Erfahrungspunket, wenn erfolgreich
$quest->setVar (QUEST_REP_HERO_FRAC, $hero->frac);
$quest->setVar (QUEST_REP_HERO_FRAC_PT, 500);
// Erhöht Spielerruf bei Fraktion $hero->frac um 500
// Wenn quest angenommen wird
void quest_start ()
{
// Quest startet
// NPCs folgen dem Spieler
$rebel01->follow ($hero);
$rebel02->follow ($hero);
$rebel03->follow ($hero);
$rebelBoss->follow ($hero);
};
void quest_solved ()
{
$fracIntenare->heroRep = $fracIntenare->heroRep - 30;
// Senkt den Ruf bei der Fraktion, die von Stadt vertrieben wurde
};
Also, das neue daran ist eben dieses solve, fail, und dieses setVar. Mit setVar setzt man ein paar Eigenschaften, man braucht sie aber nicht umbedingt.
Dort kann man beispielweise Bedingungen festlegen, die angeben, wann die Quest angenommen werden darf, etc.
So viel dazu,
mfG
Glow, Inventar, und der Z-Buffer
Samstag, 14. Februar 2009 von peacemaker
Hallo,
mal wieder die neusten Errungenschaften für die treuen Worklogleser.
Als erstes ist dieser komische Z-Buffer-Bug nun weg. Es lag an der Grafikkarte, denn ich habe es auch an anderen PCs getestet, dort hat es dann ohne Probleme funktioniert.
Dann hat Noobody ein neues Gadget für die GUI gemacht: Itembox. Diese ist eigentlich nur für Inventar und andere Dinger die mit Items zu tun haben gedacht.
Das funktioniert auch relativ gut, wesshalb ich mir dachte seine GUI nun in Tehadon zu inplementieren.
Nach ein bisschen Includes auskommentieren etc, funktionierte es dann auch, hier das Inventar in Action:
(Der GUI-Style ist 100% provisorisch, uns ist schon klar das es nicht so gut passt)
Will man ein Item benutzen, schiebt man es einfach in diese unterste Reihe, und schon hat es der Spieler an.
Dann hab ich noch zwei Postprocessing-Effekte eingebaut, Blur und Bloom (bzw. Glow). Hier ein Bild in Action:
Das ganze läuft im Moment noch gar etwas langsam, aber auch das soll sich bald verbessern.
Soviel erstmal,
mfG
mal wieder die neusten Errungenschaften für die treuen Worklogleser.
Als erstes ist dieser komische Z-Buffer-Bug nun weg. Es lag an der Grafikkarte, denn ich habe es auch an anderen PCs getestet, dort hat es dann ohne Probleme funktioniert.
Dann hat Noobody ein neues Gadget für die GUI gemacht: Itembox. Diese ist eigentlich nur für Inventar und andere Dinger die mit Items zu tun haben gedacht.
Das funktioniert auch relativ gut, wesshalb ich mir dachte seine GUI nun in Tehadon zu inplementieren.
Nach ein bisschen Includes auskommentieren etc, funktionierte es dann auch, hier das Inventar in Action:
(Der GUI-Style ist 100% provisorisch, uns ist schon klar das es nicht so gut passt)
Will man ein Item benutzen, schiebt man es einfach in diese unterste Reihe, und schon hat es der Spieler an.
Dann hab ich noch zwei Postprocessing-Effekte eingebaut, Blur und Bloom (bzw. Glow). Hier ein Bild in Action:
Das ganze läuft im Moment noch gar etwas langsam, aber auch das soll sich bald verbessern.
Soviel erstmal,
mfG
GUI
Sonntag, 8. Februar 2009 von Noobody
Da ich mich in Tehadon nicht nur um die Physik kümmere, sondern auch um Dinge wie das Interface, widme ich meinen Erstlingspost hier im Worklog der GUI von Tehadon
Und zwar schreibe ich gerade an einer GUI für Tehadon auf Basis der Noo3D (eine Grafiklib, die ich mal geschrieben habe).
Diese soll später im Spiel eingesetzt werden für Dinge wie das Inventar, Gesprächsfenster und für was man alles so eine GUI braucht.
Im Moment beherrscht sie die Grundlegenden Dinge wie Radiobuttons, Checkboxen, Tabs, Labels, Buttons und selbstverständlich Fenster. Bei jedem Gadget lässt sich das Aussehen zum einen im Code über Flags steuern (zum Beispiel, ob der Text zentriert sein soll, rechts/links anliegt usw.), und zum anderen extern über die Styles.
Ein Style ist nichts weiteres als ein Type, der alle benötigten Informationen fürs Zeichnen enthält. Ein Style wird über eine externe Textdatei definiert und kann dann ins Programm geladen werden.
Am Anfang des Spiels lassen sich problemlos verschiedene Styles laden, die dann später on-the-fly ausgetauscht werden können - praktisch, wenn das Hauptmenü anders aussehen soll als die Ingame - GUI, oder für verschiedene Mods, die auch die GUI betreffen sollen.
Das erfordert, dass für jeden Style die benötigten Grafiken mitgeliefert werden - das macht das erstellen eines neuen Styles schwieriger, aber nur so wird die GUI erst richtig veränderbar.
Dank der 3D - Lib ist es kein Problem, die Grafiken für jedes Gadget zu skalieren oder neu einzufärben.
Ein Screenshot vom aktuellen Status:
Interaktiv mach es viel mehr Spass, daher habe ich eine kleine Demo zusammengestellt.
In der GUI.txt ist der benutzte Style drin - wer Lust hat, kann sich den Aufbau mal anschauen und selbstverständlich auch Dinge verändern (zum Beispiel Schriftgrösse, -farbe etc.).
PS: Es ist nur Zufall, das dieser Eintrag just in die Phase fällt, wo GUIs scheinbar einen Hype haben (im WiP sind doch glatt 5 Stück vorgestellt) - ich habe die Arbeiten daran schon vor dem Ansturm begonnen, ehrlich
Und zwar schreibe ich gerade an einer GUI für Tehadon auf Basis der Noo3D (eine Grafiklib, die ich mal geschrieben habe).
Diese soll später im Spiel eingesetzt werden für Dinge wie das Inventar, Gesprächsfenster und für was man alles so eine GUI braucht.
Im Moment beherrscht sie die Grundlegenden Dinge wie Radiobuttons, Checkboxen, Tabs, Labels, Buttons und selbstverständlich Fenster. Bei jedem Gadget lässt sich das Aussehen zum einen im Code über Flags steuern (zum Beispiel, ob der Text zentriert sein soll, rechts/links anliegt usw.), und zum anderen extern über die Styles.
Ein Style ist nichts weiteres als ein Type, der alle benötigten Informationen fürs Zeichnen enthält. Ein Style wird über eine externe Textdatei definiert und kann dann ins Programm geladen werden.
Am Anfang des Spiels lassen sich problemlos verschiedene Styles laden, die dann später on-the-fly ausgetauscht werden können - praktisch, wenn das Hauptmenü anders aussehen soll als die Ingame - GUI, oder für verschiedene Mods, die auch die GUI betreffen sollen.
Das erfordert, dass für jeden Style die benötigten Grafiken mitgeliefert werden - das macht das erstellen eines neuen Styles schwieriger, aber nur so wird die GUI erst richtig veränderbar.
Dank der 3D - Lib ist es kein Problem, die Grafiken für jedes Gadget zu skalieren oder neu einzufärben.
Ein Screenshot vom aktuellen Status:
Interaktiv mach es viel mehr Spass, daher habe ich eine kleine Demo zusammengestellt.
In der GUI.txt ist der benutzte Style drin - wer Lust hat, kann sich den Aufbau mal anschauen und selbstverständlich auch Dinge verändern (zum Beispiel Schriftgrösse, -farbe etc.).
PS: Es ist nur Zufall, das dieser Eintrag just in die Phase fällt, wo GUIs scheinbar einen Hype haben (im WiP sind doch glatt 5 Stück vorgestellt) - ich habe die Arbeiten daran schon vor dem Ansturm begonnen, ehrlich
Meshterrains
Samstag, 7. Februar 2009 von peacemaker
Nachdem auch die Gespräche zwischen den NPCs funktionierten, konnte ich mich, nachdem Quantarie mir seinen Terrain geschickt hat, einer etwas unbequemeren Aufgabe widmen: dem Einbau der Meshterrains.
Die Texturen des Terrains sind eigentlich noch nicht fertig, beispielweise fehlen noch die Übergänge zwischen den Wegtexturen. Auch ist das Tal in der Mitte gar etwas leer, aber dies wird sich nach Quantaries Aussage sehr bald ändern.
Wenig Blabla, dafür Bilder:
(Der Nebel ist etwas gar übertrieben, bei diesem Bild hatte ich die Weitsicht etwas zurückgestellt)
Und dann noch mit Gras volgeknallt. Es ist etwas schnell hingetan, desshalb siehts etwas unnatürlich aus.
Wie ihr vielleicht erkennen könnt, gibts den Fehler mit dem Z-Buffer immernoch. Ich habe heute lange gesucht, und einen grossteil des relevanten Sourcecodes durchgesehen, wirklich etwas finden konnte ich leider nicht.
Es könnte vielleicht sogar an meiner Grafikkarte liegen, ich werde das ganze mal an einem anderen PC testen müssen.
Ich hab mal wieder den Sourcecode durch den Zeilencounter geschmissen, mehr mal zu sehen ob sich da gross was geändert hat.
Das Ergebnis: 249 Sourcedateien, 45.657 Zeilen.
Aber es muss auch gesagt werden, das sehr viele Dateien gar nicht mehr geincluded sind.
So genug geprahlt, schlussendlich kommts ja immernoch auf das Endprodukt drauf an, und das ist unabhängig der Grösse des Sourcecodes :biggrin:
mfG
Die Texturen des Terrains sind eigentlich noch nicht fertig, beispielweise fehlen noch die Übergänge zwischen den Wegtexturen. Auch ist das Tal in der Mitte gar etwas leer, aber dies wird sich nach Quantaries Aussage sehr bald ändern.
Wenig Blabla, dafür Bilder:
(Der Nebel ist etwas gar übertrieben, bei diesem Bild hatte ich die Weitsicht etwas zurückgestellt)
Und dann noch mit Gras volgeknallt. Es ist etwas schnell hingetan, desshalb siehts etwas unnatürlich aus.
Wie ihr vielleicht erkennen könnt, gibts den Fehler mit dem Z-Buffer immernoch. Ich habe heute lange gesucht, und einen grossteil des relevanten Sourcecodes durchgesehen, wirklich etwas finden konnte ich leider nicht.
Es könnte vielleicht sogar an meiner Grafikkarte liegen, ich werde das ganze mal an einem anderen PC testen müssen.
Ich hab mal wieder den Sourcecode durch den Zeilencounter geschmissen, mehr mal zu sehen ob sich da gross was geändert hat.
Das Ergebnis: 249 Sourcedateien, 45.657 Zeilen.
Aber es muss auch gesagt werden, das sehr viele Dateien gar nicht mehr geincluded sind.
So genug geprahlt, schlussendlich kommts ja immernoch auf das Endprodukt drauf an, und das ist unabhängig der Grösse des Sourcecodes :biggrin:
mfG
Gesprächige NPCs
Freitag, 6. Februar 2009 von peacemaker
Hallo,
zwar hab ich in letzter Zeit eher wenig getan, aber ich denk es ist trotzdem genug, um es hier zu erzählen. Zuerst mal all das untechnische Zeugs, danach für die interessierten mehr Technische Dinge.
Also, der Titel sagt es eigentlich schon: NPCs können jetzt miteinander plappern. Es ist recht simpel, aber tut seinen Zweck recht gut.
Vielleicht hat ja einer schon Gothic oder Oblivion gespielt. In Gothic funktionieren die Dialoge zwischen NPCs (glaub ich zumindest) meist per Zufall. Hört man mal zwei NPCs zu, so ertönt eigentlich voll belangloses, das nichtmal zusammenpasst. Aber es steigert die Lebendigkeit der Welt, wenn man nicht genau zuhört.
Bei Oblivion ists schon etwas anders. Die Gespräche dort ergeben schon um einiges mehr Sinn, da hier auch ein bisschen von den aktuellen Geschehnissen berichtet wird. Hört man dort mal einem Gespräch zu, läuft das etwa so ab:
A: "Hallo"
B: "Guten Tag. Wusstest du schon das "... balblabla
A: "Nein"
B: "Auch gut. Schönen Tag noch."
(Jedenfalls hats für mich so angehört beim letzten Spielen)
Ich hab mich für ein statisches System entschieden. Alle Gespräche sind also schön geskriptet. Was ja nicht heisst, das man hier einige Dynamik reinbringen kann, und gewisse Dialogausschnitte nur bei gewissen Bedingungen einbringen kann.
Stimmen hab ich leider noch keine, dazu fehlen mir noch die Sprecher. Und selberaufnehmen geht wohl auch nicht, würd doch etwas komisch wirken. Desshalb hab ich das bisher erst mit so schwarzen Kästchen visualisiert.
Diese Aufnahmen zeigen auch ein bisschen den Tag - Nacht-Wechsel. Diese Bilder sind am frühen Morgen, Sonnenaufgang, gemacht. Desshalb auch dieser helle rötliche Ton in den Dingen.
Bevor ich zum technischen Hintergrund komme: Bei genauerem Hinsehen werdet ihr da allerhand Renderfehler erblicken. Beispielweise beim Haus, wo so komische schwarze Flächen zu sehen sind.
Seit kurzem ist mir aufgefallen, das es plötzlich sehr starke Fehler beim Z-Buffer-Ordnen der Objekte gibt. Wieso ist mir nach wie vor unklar, aber ich bin schon fleissig am suchen.
So, zum technischen Blabla. Wie gesagt, diese Gespräche sind geskriptet. Ich zeig euch einfach mal das Skript, zum oben abgebildeten Dialog.
Code: [AUSKLAPPEN]
void talk_test ()
{
NPC_Starttalk ($garond, $irothen, fref (diebesGut)); // Startet Dialog
};
void diebesGut()
{
NPC_Output ($this, $other, "Schon das neuste gehört?");
NPC_Output ($other, $this, "Hats was mit Oron zu tun?");
NPC_Output ($this, $other, "Ja. Asar hat mir erzählt er hat was sehr wertvolles da drin versteckt.");
NPC_Output ($other, $this, "Vermutlich das Diebesgut von Irothen.");
NPC_Output ($this, $other, "Das sagen die anderen auch. Wer weiss.");
NPC_Output ($other, $this, "Vielleicht sollten wir da mal einen vorbeischicken.");
NPC_Output ($this, $other, "Und wer traut sich denn an den Gorillas von Oron vorbei?");
NPC_Output ($other, $this, "Mit genügend Geld kriegt man immer jemanden.");
NPC_Output ($this, $other, "Das wird sich zeigen. SOlange ich keine Probleme mit seinen Gorillas kriege..");
NPC_Output ($other, $this, "Das passiert mittlerweile schneller als einem lieb ist.");
NPC_Enddialog ($this, $other);
};
Ich glaub es isst klar wie das genau funktioniert....
So, noch eine kleine Neuerung in HDSS: Statement-Referenzen. Was sich damit machen lässt ist schon interessant, und eröffnet vor allem bei dem Event-Zeugs viele neue Wege.
Nachdem HDSS-Code kompiliert wird, liegt der Code in Zahlen da. Und so befindet er sich beim Ausführen im Speicher: nämlich als Array. Beispielweise könnte aus dem Befehl print ('aaa') dieser Code entstehen: -999999, -999998, 311. Diese Zahlen würden dann PRINT STRING 311 bedeuten.
Diese erste Zahl ist die ID des Befehls PRINT, die zweite des Befehles STRING. Dieser zweite Befehl gibts im normalen Skript nicht, denn dieser Befehl liefert einfach einen String aus den externen Textressourcen zurück. Alle Texte und sonstigen Strings werden während des kompilierens in solche Textressources gepackt, und dann bevor das Skript ausgeführt wird in einen Array gelesen.
Das ist auch das "Geheimnis" hinter der recht flotten Ausführzeit: Es werden einfach ein paar Zahlen verglichen.
Desshalb hab ich eben diese Statement-Referenzen integriert. Zuerst einmal wie sie gehandhabt werden, danach wofür man sie überhaupt braucht:
Code: [AUSKLAPPEN]
var $quest = new (quest);
$quest->failed = sref ($heerfuehrer->live < 1);
$quest->suceeded = sref ($target->live < 1);
Es ist denkbar simpel, was da geschieht: Es werden zwei Bedingungen definiert, eine, die definiert, wann die Quest scheitert, und eine wann sie erfolgreich ist.
Diese Bedingungen können ohne jedwelche Speedverluste Frame für Frame überprüft werden. Spielerisch ändert das ja nichts, aber wenn man diese Quests erstellt, hat man es schön modular in der Questdefinition, und nicht in irgendwelchen NPC-Events oder was weiss ich.
Dieses SRef macht eigentlich etwas ganz simples: es liefert die Position des darauffolgenden Statements im Bytecode zurück. Wenn man die hat, kann man im sourcecode einfach
if (HDSS_ExecuteStatement (statementPosition)) machen, und schon ein Event ausführen, oder eben nicht.
Ich denk das war genug für heut.
mfG
zwar hab ich in letzter Zeit eher wenig getan, aber ich denk es ist trotzdem genug, um es hier zu erzählen. Zuerst mal all das untechnische Zeugs, danach für die interessierten mehr Technische Dinge.
Also, der Titel sagt es eigentlich schon: NPCs können jetzt miteinander plappern. Es ist recht simpel, aber tut seinen Zweck recht gut.
Vielleicht hat ja einer schon Gothic oder Oblivion gespielt. In Gothic funktionieren die Dialoge zwischen NPCs (glaub ich zumindest) meist per Zufall. Hört man mal zwei NPCs zu, so ertönt eigentlich voll belangloses, das nichtmal zusammenpasst. Aber es steigert die Lebendigkeit der Welt, wenn man nicht genau zuhört.
Bei Oblivion ists schon etwas anders. Die Gespräche dort ergeben schon um einiges mehr Sinn, da hier auch ein bisschen von den aktuellen Geschehnissen berichtet wird. Hört man dort mal einem Gespräch zu, läuft das etwa so ab:
A: "Hallo"
B: "Guten Tag. Wusstest du schon das "... balblabla
A: "Nein"
B: "Auch gut. Schönen Tag noch."
(Jedenfalls hats für mich so angehört beim letzten Spielen)
Ich hab mich für ein statisches System entschieden. Alle Gespräche sind also schön geskriptet. Was ja nicht heisst, das man hier einige Dynamik reinbringen kann, und gewisse Dialogausschnitte nur bei gewissen Bedingungen einbringen kann.
Stimmen hab ich leider noch keine, dazu fehlen mir noch die Sprecher. Und selberaufnehmen geht wohl auch nicht, würd doch etwas komisch wirken. Desshalb hab ich das bisher erst mit so schwarzen Kästchen visualisiert.
Diese Aufnahmen zeigen auch ein bisschen den Tag - Nacht-Wechsel. Diese Bilder sind am frühen Morgen, Sonnenaufgang, gemacht. Desshalb auch dieser helle rötliche Ton in den Dingen.
Bevor ich zum technischen Hintergrund komme: Bei genauerem Hinsehen werdet ihr da allerhand Renderfehler erblicken. Beispielweise beim Haus, wo so komische schwarze Flächen zu sehen sind.
Seit kurzem ist mir aufgefallen, das es plötzlich sehr starke Fehler beim Z-Buffer-Ordnen der Objekte gibt. Wieso ist mir nach wie vor unklar, aber ich bin schon fleissig am suchen.
So, zum technischen Blabla. Wie gesagt, diese Gespräche sind geskriptet. Ich zeig euch einfach mal das Skript, zum oben abgebildeten Dialog.
Code: [AUSKLAPPEN]
void talk_test ()
{
NPC_Starttalk ($garond, $irothen, fref (diebesGut)); // Startet Dialog
};
void diebesGut()
{
NPC_Output ($this, $other, "Schon das neuste gehört?");
NPC_Output ($other, $this, "Hats was mit Oron zu tun?");
NPC_Output ($this, $other, "Ja. Asar hat mir erzählt er hat was sehr wertvolles da drin versteckt.");
NPC_Output ($other, $this, "Vermutlich das Diebesgut von Irothen.");
NPC_Output ($this, $other, "Das sagen die anderen auch. Wer weiss.");
NPC_Output ($other, $this, "Vielleicht sollten wir da mal einen vorbeischicken.");
NPC_Output ($this, $other, "Und wer traut sich denn an den Gorillas von Oron vorbei?");
NPC_Output ($other, $this, "Mit genügend Geld kriegt man immer jemanden.");
NPC_Output ($this, $other, "Das wird sich zeigen. SOlange ich keine Probleme mit seinen Gorillas kriege..");
NPC_Output ($other, $this, "Das passiert mittlerweile schneller als einem lieb ist.");
NPC_Enddialog ($this, $other);
};
Ich glaub es isst klar wie das genau funktioniert....
So, noch eine kleine Neuerung in HDSS: Statement-Referenzen. Was sich damit machen lässt ist schon interessant, und eröffnet vor allem bei dem Event-Zeugs viele neue Wege.
Nachdem HDSS-Code kompiliert wird, liegt der Code in Zahlen da. Und so befindet er sich beim Ausführen im Speicher: nämlich als Array. Beispielweise könnte aus dem Befehl print ('aaa') dieser Code entstehen: -999999, -999998, 311. Diese Zahlen würden dann PRINT STRING 311 bedeuten.
Diese erste Zahl ist die ID des Befehls PRINT, die zweite des Befehles STRING. Dieser zweite Befehl gibts im normalen Skript nicht, denn dieser Befehl liefert einfach einen String aus den externen Textressourcen zurück. Alle Texte und sonstigen Strings werden während des kompilierens in solche Textressources gepackt, und dann bevor das Skript ausgeführt wird in einen Array gelesen.
Das ist auch das "Geheimnis" hinter der recht flotten Ausführzeit: Es werden einfach ein paar Zahlen verglichen.
Desshalb hab ich eben diese Statement-Referenzen integriert. Zuerst einmal wie sie gehandhabt werden, danach wofür man sie überhaupt braucht:
Code: [AUSKLAPPEN]
var $quest = new (quest);
$quest->failed = sref ($heerfuehrer->live < 1);
$quest->suceeded = sref ($target->live < 1);
Es ist denkbar simpel, was da geschieht: Es werden zwei Bedingungen definiert, eine, die definiert, wann die Quest scheitert, und eine wann sie erfolgreich ist.
Diese Bedingungen können ohne jedwelche Speedverluste Frame für Frame überprüft werden. Spielerisch ändert das ja nichts, aber wenn man diese Quests erstellt, hat man es schön modular in der Questdefinition, und nicht in irgendwelchen NPC-Events oder was weiss ich.
Dieses SRef macht eigentlich etwas ganz simples: es liefert die Position des darauffolgenden Statements im Bytecode zurück. Wenn man die hat, kann man im sourcecode einfach
if (HDSS_ExecuteStatement (statementPosition)) machen, und schon ein Event ausführen, oder eben nicht.
Ich denk das war genug für heut.
mfG
Gehe zu Seite Zurück 1, 2, 3, 4 ... 10, 11, 12 Weiter