Iliran
Neuer Mapdesigner, NPC-Editor und flexiblere Listensteuerung

Nachdem ich hier schon länger nichts mehr geschrieben habe, ist es diesmal (etwas) mehr. ^^
Zuerst einmal wollte ich vor ca. 2 Wochen mal wieder meinen Quest-Editor anschauen, weil ich ein paar Werte einer Quest ändern musste, damit diese aktuell auf meiner TestMap funktioniert. Dann bemerkte ich nur leider, dass kein Ordner "Quest-Editor" mehr auf meiner Festplatte existiert. Dachte mir dann "na toll, darfste des Ganze nochmal machen, dauert locker 1-2 Wochen". Allerdings ist mir nach ungefähr 15 Minuten eingefallen, dass ich meine ganzen Programmierdaten (alle paar Monate mal ^^) auf meinen USB-Stick speichere. Und dann hatte ich auch meinen Quest-Editor wieder. ^^ So viel dazu.
Ich habe schon vor einigen Wochen damit angefangen, die Fertigkeiten flexibler zu machen. Bis jetzt hatte ich alles manuell gespeichert. Der Spieler-Type hatte für jede Fertigkeit einen extra Field-Eintrag. Jetzt habe ich aber ein Array Fertigkeiten:TFertigkeiten[16] als eigenen Field-Eintrag. Der Type dazu sieht folgendermaßen aus:
Code: [AUSKLAPPEN]
Type TFertigkeit
Field Name:String
Field Level:Byte
Field ActExp:Float
Field NextExp:Short
End Type
Name ist die Bezeichnung der Fertigkeit, also zum Beispiel "Lange Klingen". Level ist die derzeitige Stufe der Fertigkeit (es geht von 5-100), je höher die Stufe, desto besser ist man im Umgang mit dieser Fertigkeit. ActExp (=aktuelle Experience) gibt an, wie viel Erfahrung man auf der derzeitigen Stufe des Fertigkeitslevels schon gesammelt hat. NextExp ist die Erfahrung, die man braucht, um ein Fertigkeitslevel aufzusteigen (ActExp = NextExp -> ActExp = 0; NextExp wird neu berechnet). Namen und Level schreibe ich manuell im Hauptprogrammcode, das sieht ca. so aus:
Code: [AUSKLAPPEN]
p.Fertigkeiten[1].Name = "Lange Klinge"
p.Fertigkeiten[1].Level = 20
p.Fertigkeiten[2].Name = "Axtkampf"
p.Fertigkeiten[2].Level = 25
[...]
Level bekommt dann später je nach Klasse einen individuellen Startwert.
Dann habe ich zwei weitere Arrays (außerhalb des Spieler-Types) gemacht, nämlich Hauptfertigkeiten:Byte[5] und Nebenfertigkeiten:Byte[10]. In beiden werden die Index-Nummern des Fertigkeits-Arrays gespeichert.
In den letzten 2-3 Wochen habe ich dann die Umstellung von Arrays zu Listen bei den NPCs und den Gegnern vollzogen. Außerdem werden jetzt beide aus Dateien gelesen. Dazu habe ich dann noch die Gegner-Typen "erfunden". Das ist sozusagen eine Schablone für eine gewisse Art von Gegnern. Das spart vor allem Speicher der Dateien, aus denen die Gegner gelesen werden. So ein Gegner-Typ speichert grundlegende Dinge wie zum Beispiel den Namen, die maximale Lebensenergie, den Rüstungsschutz etc. Die Dinge, die von Gegner zu Gegner (meistens) unterschiedlich sind, wie zum Beispiel die Position x/y, die Map, auf der der Gegner anzutreffen ist etc. Dazu hat der Gegner-Type einen extra Field-Eintrag "Typ:Byte". In der Funktion LoadGegner() wird dann nachdem die gegnerspezifischen Daten aus "Gegner.ild" geladen werden, noch die Datei "GegnerTyp.ild" geöffnet und nach der Schablone gesucht, der die Nummer "Gegner.Typ" hat.
Passend dazu habe ich in den letzten Tagen den "NPC- und Gegner-Editor" programmiert. Mit diesem kann man NPCs, Gegner und Gegner-Typen erstellen und bearbeiten:
Auf der rechten Leiste kann man die Attribute auswählen und bearbeiten. Wenn das Side-Menü gerade geschlossen ist, kann man einen bereits erstellten NPC oder Gegner auf der Karte auswählen und bearbeiten oder löschen. Bei einem vorhandenen Gegner-Typ muss man dessen ID kennen.
Ich hoffe, ich habe es nicht zu kompliziert ausgedrückt und ihr konntet es gut verstehen und fandet es interessant. ^^
So, zum Schluss möchte ich jetzt noch den neuen Mapdesigner von Iliran vorstellen: Cireva. Da mein alter Mapdesigner Terabite wegen mangelden Zeitgründen leider abspringen musste, übernimmt Cireva jetzt seinen Job. Auf gute Zusammenarbeit!
Zuerst einmal wollte ich vor ca. 2 Wochen mal wieder meinen Quest-Editor anschauen, weil ich ein paar Werte einer Quest ändern musste, damit diese aktuell auf meiner TestMap funktioniert. Dann bemerkte ich nur leider, dass kein Ordner "Quest-Editor" mehr auf meiner Festplatte existiert. Dachte mir dann "na toll, darfste des Ganze nochmal machen, dauert locker 1-2 Wochen". Allerdings ist mir nach ungefähr 15 Minuten eingefallen, dass ich meine ganzen Programmierdaten (alle paar Monate mal ^^) auf meinen USB-Stick speichere. Und dann hatte ich auch meinen Quest-Editor wieder. ^^ So viel dazu.
Ich habe schon vor einigen Wochen damit angefangen, die Fertigkeiten flexibler zu machen. Bis jetzt hatte ich alles manuell gespeichert. Der Spieler-Type hatte für jede Fertigkeit einen extra Field-Eintrag. Jetzt habe ich aber ein Array Fertigkeiten:TFertigkeiten[16] als eigenen Field-Eintrag. Der Type dazu sieht folgendermaßen aus:
Code: [AUSKLAPPEN]
Type TFertigkeit
Field Name:String
Field Level:Byte
Field ActExp:Float
Field NextExp:Short
End Type
Name ist die Bezeichnung der Fertigkeit, also zum Beispiel "Lange Klingen". Level ist die derzeitige Stufe der Fertigkeit (es geht von 5-100), je höher die Stufe, desto besser ist man im Umgang mit dieser Fertigkeit. ActExp (=aktuelle Experience) gibt an, wie viel Erfahrung man auf der derzeitigen Stufe des Fertigkeitslevels schon gesammelt hat. NextExp ist die Erfahrung, die man braucht, um ein Fertigkeitslevel aufzusteigen (ActExp = NextExp -> ActExp = 0; NextExp wird neu berechnet). Namen und Level schreibe ich manuell im Hauptprogrammcode, das sieht ca. so aus:
Code: [AUSKLAPPEN]
p.Fertigkeiten[1].Name = "Lange Klinge"
p.Fertigkeiten[1].Level = 20
p.Fertigkeiten[2].Name = "Axtkampf"
p.Fertigkeiten[2].Level = 25
[...]
Level bekommt dann später je nach Klasse einen individuellen Startwert.
Dann habe ich zwei weitere Arrays (außerhalb des Spieler-Types) gemacht, nämlich Hauptfertigkeiten:Byte[5] und Nebenfertigkeiten:Byte[10]. In beiden werden die Index-Nummern des Fertigkeits-Arrays gespeichert.
In den letzten 2-3 Wochen habe ich dann die Umstellung von Arrays zu Listen bei den NPCs und den Gegnern vollzogen. Außerdem werden jetzt beide aus Dateien gelesen. Dazu habe ich dann noch die Gegner-Typen "erfunden". Das ist sozusagen eine Schablone für eine gewisse Art von Gegnern. Das spart vor allem Speicher der Dateien, aus denen die Gegner gelesen werden. So ein Gegner-Typ speichert grundlegende Dinge wie zum Beispiel den Namen, die maximale Lebensenergie, den Rüstungsschutz etc. Die Dinge, die von Gegner zu Gegner (meistens) unterschiedlich sind, wie zum Beispiel die Position x/y, die Map, auf der der Gegner anzutreffen ist etc. Dazu hat der Gegner-Type einen extra Field-Eintrag "Typ:Byte". In der Funktion LoadGegner() wird dann nachdem die gegnerspezifischen Daten aus "Gegner.ild" geladen werden, noch die Datei "GegnerTyp.ild" geöffnet und nach der Schablone gesucht, der die Nummer "Gegner.Typ" hat.
Passend dazu habe ich in den letzten Tagen den "NPC- und Gegner-Editor" programmiert. Mit diesem kann man NPCs, Gegner und Gegner-Typen erstellen und bearbeiten:

Auf der rechten Leiste kann man die Attribute auswählen und bearbeiten. Wenn das Side-Menü gerade geschlossen ist, kann man einen bereits erstellten NPC oder Gegner auf der Karte auswählen und bearbeiten oder löschen. Bei einem vorhandenen Gegner-Typ muss man dessen ID kennen.
Ich hoffe, ich habe es nicht zu kompliziert ausgedrückt und ihr konntet es gut verstehen und fandet es interessant. ^^
So, zum Schluss möchte ich jetzt noch den neuen Mapdesigner von Iliran vorstellen: Cireva. Da mein alter Mapdesigner Terabite wegen mangelden Zeitgründen leider abspringen musste, übernimmt Cireva jetzt seinen Job. Auf gute Zusammenarbeit!
Codeoptimierungen und Interface-Erweiterungen

Da ich nun 3 Wochen kein Internet hatte, habe ich mich in dieser Zeit um das Aussehen meines Codes gekümmert. Ich habe zum Beispiel Tabs statt Leerzeichen benutzt und die Variablennamen teils sinnvoller benannt und vor allem groß geschrieben. Also zum Beispiel "HPMax" statt "hpmax", weil das alles einfach viel übersichtlicher macht.
Als das dann geschafft war, habe ich mich noch überwiegend um das Interface gekümmert. Vor allem waren das kleinere Verbesserungen bzw. Beseitigen von Bugs im Inventar, das Hinzufügen des Zaubermenüs (also das Zauber-Inventar) und die Hotkey-Leiste. In der Hotkeyleiste kann man Waffen und Zauber ablegen, um dann später schneller mittels Tastendruck darauf zugreifen zu können. An sich ist diese sehr simpel aufgebaut:
Code: [AUSKLAPPEN]
Image speichert den Icon der Waffe/des Zaubers. Typ kann entweder 1 (=Waffe) oder 2 (=Zauber) sein, damit das Programm später weiß, ob die Waffe aus der WaffenList oder der Zauber aus der ZauberList gesucht werden soll. ID speichert die Nummer der Waffe/des Zaubers.
Demnächst werde ich dann noch die Zauberart einbauen, dass man Monster beschwören kann und diese dann von alleine einen Gegner angreifen. Danach muss ich noch eine flexible Verwaltung der Fertigkeiten (da ja jede Klasse andere Hauptfertigkeiten hat) und Fertigkeitenaufstiege machen.
Als das dann geschafft war, habe ich mich noch überwiegend um das Interface gekümmert. Vor allem waren das kleinere Verbesserungen bzw. Beseitigen von Bugs im Inventar, das Hinzufügen des Zaubermenüs (also das Zauber-Inventar) und die Hotkey-Leiste. In der Hotkeyleiste kann man Waffen und Zauber ablegen, um dann später schneller mittels Tastendruck darauf zugreifen zu können. An sich ist diese sehr simpel aufgebaut:
Code: [AUSKLAPPEN]
Type THotkey
Field Image:TImage
Field Typ:Byte
Field ID:Short
End Type
Field Image:TImage
Field Typ:Byte
Field ID:Short
End Type
Image speichert den Icon der Waffe/des Zaubers. Typ kann entweder 1 (=Waffe) oder 2 (=Zauber) sein, damit das Programm später weiß, ob die Waffe aus der WaffenList oder der Zauber aus der ZauberList gesucht werden soll. ID speichert die Nummer der Waffe/des Zaubers.
Demnächst werde ich dann noch die Zauberart einbauen, dass man Monster beschwören kann und diese dann von alleine einen Gegner angreifen. Danach muss ich noch eine flexible Verwaltung der Fertigkeiten (da ja jede Klasse andere Hauptfertigkeiten hat) und Fertigkeitenaufstiege machen.
Einige Verbesserungen und Ingame-Video

Lange hats gedauert, aber jetzt ist mein Video doch fertig geworden! Vorher habe ich noch einige Verbesserungen für das Video vollzogen. Zum Beispiel habe ich ein paar grafische Effekte eingebaut, das heißt, wenn man getroffen wird, blinkt der Spieler rot; wenn man sich heilt, blinkt er gelb. Ebenfalls im Video sehr gut zu sehen, ist, dass Spieler und Gegner beim Angriff nun eine Schrittanimation machen. Zudem haben Spieler, NPC und Gegner nun Schichten, dadurch wird der Spieler nicht mehr immer nur über den NPCs und den Gegnern gezeichnet, sondern er passt sich seiner Lage an. Außerdem habe ich noch die Pixel-by-Pixel-Engine eingebaut. Allerdings werde ich gegen Ende der Entwicklung noch einmal Verbesserungen an den genannten Punkten vornehmen.
Das Video selbst hat keinen Ton. Ihr könnt euch entweder die Youtube- oder die MyVideo-Fassungen ansehen, oder das unkonvertierte 60FPS-Original (40 MB) herunterladen. Im Übrigen sind die Quest, die NPCs, die Items und die Welt nur Testobjekte. Vielleicht kommen sie im späteren Spiel auch vor, gewiss ist es aber nicht.
http://www.youtube.com/watch?v=7gAJsyzlsUI
http://www.myvideo.de/watch/6616714/Iliran_Ingame
http://www.fileuploadx.de/910981
Einige Dinge, die man im Video noch nicht sehen kann, werde ich noch einbauen. Zum Beispiel:
-animiertes Wasser
-verschiedene Blutflecken
-evtl. Blutspritzer
-die Leichen der Gegner in ihrem Blut
-Interface
-evtl. die Schriftgröße beim Sprechen mit den NPCs und auf jeden Fall, wie viel in einer Zeile steht
[Edit:]-animierter Zauberschuss (im Video der kleine Feuerball, der auf den Gegner geschossen wird und in einem Turm aufgeht)
Anregungen, Verbesserungsvorschläge, konstruktive Kritik und natürlich Lob sind erwünscht! Ich hoffe, das Video gefällt euch und gewährt euch einen guten Einblick in Iliran.
MFG Lador
Das Video selbst hat keinen Ton. Ihr könnt euch entweder die Youtube- oder die MyVideo-Fassungen ansehen, oder das unkonvertierte 60FPS-Original (40 MB) herunterladen. Im Übrigen sind die Quest, die NPCs, die Items und die Welt nur Testobjekte. Vielleicht kommen sie im späteren Spiel auch vor, gewiss ist es aber nicht.
http://www.youtube.com/watch?v=7gAJsyzlsUI
http://www.myvideo.de/watch/6616714/Iliran_Ingame
http://www.fileuploadx.de/910981
Einige Dinge, die man im Video noch nicht sehen kann, werde ich noch einbauen. Zum Beispiel:
-animiertes Wasser
-verschiedene Blutflecken
-evtl. Blutspritzer
-die Leichen der Gegner in ihrem Blut
-Interface
-evtl. die Schriftgröße beim Sprechen mit den NPCs und auf jeden Fall, wie viel in einer Zeile steht
[Edit:]-animierter Zauberschuss (im Video der kleine Feuerball, der auf den Gegner geschossen wird und in einem Turm aufgeht)
Anregungen, Verbesserungsvorschläge, konstruktive Kritik und natürlich Lob sind erwünscht! Ich hoffe, das Video gefällt euch und gewährt euch einen guten Einblick in Iliran.
MFG Lador
Das Quest-System, Teil 3

Wie gesagt, habe ich mich in den letzten Tagen mit dem Einbinden der Quest-Engine in mein Hauptprogramm beschäftigt. Es lief eigentlich kaum ohne große Schwierigkeiten ab, jedoch musste ich zu meinen bisherigen Types aus dem Quest-Editor einige hinzufügen. Im Hauptprogramm sehen diese nun wie folgt aus:
Code: [AUSKLAPPEN]
Wie ihr sehen könnt, haben sich lediglich die Field-Einträge "GeschafftVar:Byte" in beiden Types geändert. Diese speichern eine Zahl, die benötigt wird, um zu überprüfen, wie weit der Spieler schon mit der Quest gekommen ist und welche Effekte dann abgespielt werden. Diese Werte werden nach dem Einlesen und Speichern der Quests aus den Dateien ermittelt. Dabei lasse ich einfach einen Wert (von mir genannt "QuestGeschafft") zählen, wie viele "Aufgaben" bis jetzt erfüllt wurden. Standardwert ist natürlich 1. Den "Effekten" wird der Wert "QuestGeschafft" unter "GeschafftVar" zugeordnet. Bei den "Aufgaben" auch, nur wird zusätzlich der Wert um 1 erhöht, damit das Programm weiß, dass die folgenden Effekte erst abgespielt werden, wenn die Aufgabe erfüllt ist.
Der Field-Eintrag bei TQuest speichert, wie weit die Quest schon fortgeschritten ist. Wenn Quest.GeschafftVar = Effekt.GeschafftVar, wird der Effekt abgespielt. Wird eine Aufgabe erfüllt, wird Quest.GeschafftVar = Aufgabe.GeschafftVar. (Tut mir leid, wenn es etwas verwirrend klingt. Ich hoffe, ich habe hierbei nichts vergessen.)
Im Hauptprogramm sind schon die wesentlichsten Aufgaben und Effekte vorhanden. Die anderen werde ich in einigen Wochen (wenn das Programm etwas vollständiger ist, zum Beispiel gibt es noch kein Tagebuch, weshalb der Effekt "Tagebucheintrag" bis jetzt nutzlos ist) noch einbauen. In den nächsten Tagen/Wochen werde ich trotzdem noch etwas daran feilen.
Das war jetzt ein (im Vergleich zu den vorherigen) relativ kurzer Eintrag und wahrscheinlich auch der letzte zum Quest-System. Sollte ich noch etwas diesbezüglich einbauen, werde ich es in einem späteren Worklog schreiben. Bevor ich jedoch bald das Ingame-Video machen werde, muss ich noch ein bisschen an den wesentlichen Sachen werkeln, zum Beispiel wollte ich noch das Kampfsystem etwas verbessern, damit es für das Video auch gut rüberkommt. ^^
Code: [AUSKLAPPEN]
Type TQuest
Field ID:Short
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
Field GeschafftVar:Byte
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
Field GeschafftVar:Byte
End Type
Field ID:Short
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
Field GeschafftVar:Byte
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
Field GeschafftVar:Byte
End Type
Wie ihr sehen könnt, haben sich lediglich die Field-Einträge "GeschafftVar:Byte" in beiden Types geändert. Diese speichern eine Zahl, die benötigt wird, um zu überprüfen, wie weit der Spieler schon mit der Quest gekommen ist und welche Effekte dann abgespielt werden. Diese Werte werden nach dem Einlesen und Speichern der Quests aus den Dateien ermittelt. Dabei lasse ich einfach einen Wert (von mir genannt "QuestGeschafft") zählen, wie viele "Aufgaben" bis jetzt erfüllt wurden. Standardwert ist natürlich 1. Den "Effekten" wird der Wert "QuestGeschafft" unter "GeschafftVar" zugeordnet. Bei den "Aufgaben" auch, nur wird zusätzlich der Wert um 1 erhöht, damit das Programm weiß, dass die folgenden Effekte erst abgespielt werden, wenn die Aufgabe erfüllt ist.
Der Field-Eintrag bei TQuest speichert, wie weit die Quest schon fortgeschritten ist. Wenn Quest.GeschafftVar = Effekt.GeschafftVar, wird der Effekt abgespielt. Wird eine Aufgabe erfüllt, wird Quest.GeschafftVar = Aufgabe.GeschafftVar. (Tut mir leid, wenn es etwas verwirrend klingt. Ich hoffe, ich habe hierbei nichts vergessen.)
Im Hauptprogramm sind schon die wesentlichsten Aufgaben und Effekte vorhanden. Die anderen werde ich in einigen Wochen (wenn das Programm etwas vollständiger ist, zum Beispiel gibt es noch kein Tagebuch, weshalb der Effekt "Tagebucheintrag" bis jetzt nutzlos ist) noch einbauen. In den nächsten Tagen/Wochen werde ich trotzdem noch etwas daran feilen.
Das war jetzt ein (im Vergleich zu den vorherigen) relativ kurzer Eintrag und wahrscheinlich auch der letzte zum Quest-System. Sollte ich noch etwas diesbezüglich einbauen, werde ich es in einem späteren Worklog schreiben. Bevor ich jedoch bald das Ingame-Video machen werde, muss ich noch ein bisschen an den wesentlichen Sachen werkeln, zum Beispiel wollte ich noch das Kampfsystem etwas verbessern, damit es für das Video auch gut rüberkommt. ^^
Das Quest-System, Teil 2

Nachdem ich nun schon länger keinen Eintrag mehr geschrieben habe, weil ich viel in der Schule viel zu tun hatte, werde ich das jetzt nachholen.
In den letzten zwei Wochen habe ich mich immer noch mit dem Quest-Editor beschäftigt. Hauptsächlich eigentlich nur noch die Bedienung, ein bisschen musste ich auch noch am Quest-System feilen. An den Types hat sich eigentlich nur noch das Field "ID:Short" bei TQuest geändert, damit die Quest genau indentifizierbar ist.
Ich hatte in den letzten Tagen auch ein paar Probleme mit dem Speichern und Laden der Datei, in der die Quests gespeichert werden. Da man ja nicht genau weiß, wie viele Aufgaben bzw. Effekte in der QuestList vorhanden sind, war das etwas schwierig und mein Programm wollte nicht so, wie ich wollte. Habe das jetzt aber so gelöst, dass jede Quest in eine eigene Datei kommt. Somit können die Anzahl der Aufgaben/Effekte genau ausgelesen werden.
Auf Wunsch von Dottakopf und auch, weil ich es versprochen hatte, erkläre ich nun noch einmal, wie das Quest-System funktioniert (bzw. funktionieren soll, immerhin ist es noch nicht im Hauptprogramm eingebaut):
Es gibt zwei Types, TQuest (allgemein für die Quests) und TAufgabe (für Aufgaben und Effekte). Diese sind wie folgt aufgebaut:
Code: [AUSKLAPPEN]
Im TQuest-Type werden neben der ID und dem Namen der Quest auch noch die Startbedingung sowie deren Parameter, außerdem noch die Start- und Questliste. Die Startbedingung ist die Bedingung, die erfüllt sein muss, damit man die Quest überhaupt annehmen kann. Ich habe bis jetzt "keine" (wenn man die Quest immer annehmen kann) und "abgeschlossene Quest x" (wenn man bereits vorher eine Quest absolviert haben muss), aber wahrscheinlich fallen mir im Laufe der Entwicklung noch einige Bedingungen ein.
StartBedingungParam ist der Parameter für die Startbedingung. Bei den oberen beiden Beispielen von Bedingungen gibt es nur bei "abgeschlossene Quest" einen Parameter, nämlich "x" bzw. der Name der Quest, die man bereits erfüllt haben muss.
Der Field-Eintrag "Typ" im Type TAufgabe speichert lediglich, ob es sich bei dieser Type-Instanz um eine Aufgabe oder einen Effekt handelt (mehr dazu weiter unten).
"Art" bezeichnet die Sorte von Aufgabe bzw. Effekt, um die es sich in der jeweiligen Instanz handelt. Ich habe zum Beispiel bei Aufgabe unter anderem "rede mit NPC x Ereignis y" und bei Effekt "Tagebucheintrag x".
"ParamX" und "ParamY" sind die Parameter zur Art der Aufgabe bzw. des Effekts. Beispielsweise speichert ParamX im obigen Beispiel "rede mit NPC x Ereignis y" die ID des NPCs, ParamY speichert sich das Ereignis (ich nenne in Iliran die Situationen "Ereignisse", also zum Beispiel sagt ein NPC bei Ereignis 1 "Ich habe einen Auftrag für Euch. Es ist ...", wenn man das gelesen hat, wird das Ereignis 2 und er sagt so etwas wie "Habt Ihr den Auftrag schon erledigt? Nein? Dann solltet Ihr Euch mal beeilen!", hoffe das war verständlich erklärt...).
Bleibt noch die Frage offen, was Aufgaben sind und was Effekte. Eine Aufgabe ist eigentlich auch fast wieder so etwas wie eine Bedingung. Alles was man in der Quest machen muss, sind Aufgaben, sie sind sozusagen aktiv.
Ein Effekt geschieht passiv, nämlich wenn man eine Aufgabe erfüllt hat. Er verändert etwas am Geschehen. Zum Beispiel: Ein NPC trägt dir auf, einem Freund von ihm einen Brief zu überbringen. Nachdem du mit seinem Freund geredet hast, ist die Aufgabe (die Quest aber noch nicht) erfüllt, und einige Effekte treten ein, beispielsweise bekommst du einen Tagebucheintrag und das Ereignis des Auftraggebers (und des Briefempfängers) springt um, sonst würden sie ja wieder dasselbe sagen wie vorher.
Hierfür habe ich zwei Screenshots vom Editor gemacht, jedoch habe ich die Map weggeschnitten, da sie sowieso auf beiden Bildern gleich ist:
Hier sieht man die bisherigen Effekte des Editors.
Hier habe ich eine fertige Quest (vielleicht behalte ich sie auch in baue sie in die Version ein, mit der ich das Video machen werde ^^), damit ihr sehen könnt, wie diese in etwa im fertigen Spiel aufgebaut sein werden.
Ich hoffe, ihr habt das so in etwa verstanden, und ich hoffe, dass ich nichts vergessen habe. ^^ In den nächsten Tagen werde ich versuchen, dass Quest-System in mein Hauptprogramm einzubinden. Deswegen folgt dann demnächst der Eintrag "Das Quest-System, Teil 3" in dem ich (notfalls) noch einmal etwas erläutern könnte, sofern ich in diesem eintrag etwas vergaß.
MFG Lador
In den letzten zwei Wochen habe ich mich immer noch mit dem Quest-Editor beschäftigt. Hauptsächlich eigentlich nur noch die Bedienung, ein bisschen musste ich auch noch am Quest-System feilen. An den Types hat sich eigentlich nur noch das Field "ID:Short" bei TQuest geändert, damit die Quest genau indentifizierbar ist.
Ich hatte in den letzten Tagen auch ein paar Probleme mit dem Speichern und Laden der Datei, in der die Quests gespeichert werden. Da man ja nicht genau weiß, wie viele Aufgaben bzw. Effekte in der QuestList vorhanden sind, war das etwas schwierig und mein Programm wollte nicht so, wie ich wollte. Habe das jetzt aber so gelöst, dass jede Quest in eine eigene Datei kommt. Somit können die Anzahl der Aufgaben/Effekte genau ausgelesen werden.
Auf Wunsch von Dottakopf und auch, weil ich es versprochen hatte, erkläre ich nun noch einmal, wie das Quest-System funktioniert (bzw. funktionieren soll, immerhin ist es noch nicht im Hauptprogramm eingebaut):
Es gibt zwei Types, TQuest (allgemein für die Quests) und TAufgabe (für Aufgaben und Effekte). Diese sind wie folgt aufgebaut:
Code: [AUSKLAPPEN]
Type TQuest
Field ID:Short
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
End Type
Field ID:Short
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
End Type
Im TQuest-Type werden neben der ID und dem Namen der Quest auch noch die Startbedingung sowie deren Parameter, außerdem noch die Start- und Questliste. Die Startbedingung ist die Bedingung, die erfüllt sein muss, damit man die Quest überhaupt annehmen kann. Ich habe bis jetzt "keine" (wenn man die Quest immer annehmen kann) und "abgeschlossene Quest x" (wenn man bereits vorher eine Quest absolviert haben muss), aber wahrscheinlich fallen mir im Laufe der Entwicklung noch einige Bedingungen ein.
StartBedingungParam ist der Parameter für die Startbedingung. Bei den oberen beiden Beispielen von Bedingungen gibt es nur bei "abgeschlossene Quest" einen Parameter, nämlich "x" bzw. der Name der Quest, die man bereits erfüllt haben muss.
Der Field-Eintrag "Typ" im Type TAufgabe speichert lediglich, ob es sich bei dieser Type-Instanz um eine Aufgabe oder einen Effekt handelt (mehr dazu weiter unten).
"Art" bezeichnet die Sorte von Aufgabe bzw. Effekt, um die es sich in der jeweiligen Instanz handelt. Ich habe zum Beispiel bei Aufgabe unter anderem "rede mit NPC x Ereignis y" und bei Effekt "Tagebucheintrag x".
"ParamX" und "ParamY" sind die Parameter zur Art der Aufgabe bzw. des Effekts. Beispielsweise speichert ParamX im obigen Beispiel "rede mit NPC x Ereignis y" die ID des NPCs, ParamY speichert sich das Ereignis (ich nenne in Iliran die Situationen "Ereignisse", also zum Beispiel sagt ein NPC bei Ereignis 1 "Ich habe einen Auftrag für Euch. Es ist ...", wenn man das gelesen hat, wird das Ereignis 2 und er sagt so etwas wie "Habt Ihr den Auftrag schon erledigt? Nein? Dann solltet Ihr Euch mal beeilen!", hoffe das war verständlich erklärt...).
Bleibt noch die Frage offen, was Aufgaben sind und was Effekte. Eine Aufgabe ist eigentlich auch fast wieder so etwas wie eine Bedingung. Alles was man in der Quest machen muss, sind Aufgaben, sie sind sozusagen aktiv.
Ein Effekt geschieht passiv, nämlich wenn man eine Aufgabe erfüllt hat. Er verändert etwas am Geschehen. Zum Beispiel: Ein NPC trägt dir auf, einem Freund von ihm einen Brief zu überbringen. Nachdem du mit seinem Freund geredet hast, ist die Aufgabe (die Quest aber noch nicht) erfüllt, und einige Effekte treten ein, beispielsweise bekommst du einen Tagebucheintrag und das Ereignis des Auftraggebers (und des Briefempfängers) springt um, sonst würden sie ja wieder dasselbe sagen wie vorher.
Hierfür habe ich zwei Screenshots vom Editor gemacht, jedoch habe ich die Map weggeschnitten, da sie sowieso auf beiden Bildern gleich ist:

Hier sieht man die bisherigen Effekte des Editors.

Hier habe ich eine fertige Quest (vielleicht behalte ich sie auch in baue sie in die Version ein, mit der ich das Video machen werde ^^), damit ihr sehen könnt, wie diese in etwa im fertigen Spiel aufgebaut sein werden.
Ich hoffe, ihr habt das so in etwa verstanden, und ich hoffe, dass ich nichts vergessen habe. ^^ In den nächsten Tagen werde ich versuchen, dass Quest-System in mein Hauptprogramm einzubinden. Deswegen folgt dann demnächst der Eintrag "Das Quest-System, Teil 3" in dem ich (notfalls) noch einmal etwas erläutern könnte, sofern ich in diesem eintrag etwas vergaß.
MFG Lador
Das Quest-System, Teil 1

Heute habe ich mich mal an (meiner Meinung nach) eine der schwierigsten Engines in einem Rollenspiel gemacht: Das Quest-System.
Ich finde es sehr schwierig, da es so variabel sein muss. Immerhin will ich ja keine simplen und auf Dauer gleichen "Töte 20 hiervon, und am besten nochmal 30 davon" oder "Sammle 5 hiervon, 3 davon und 17 davon" machen, sondern innovative, motivierende und abwechslungsreiche Quests. Und dafür muss meine Engine eben sehr flexibel sein.
Auch wenn man das alles gar nicht extern, sondern auch intern lösen könnte (Hardcoding), finde ich diesen Weg sehr viel besser, wenn es auch mehr Überlegungszeit benötigt. Aber ich bin mir sicher, dass es mir im Nachhinein viel, viel Zeit gespart hat, dass ich kein Hardcoding gemacht habe.
Jedenfalls, ich hab mir schon länger mal Gedanken zum Quest-System gemacht. Damals dachte ich mir das so:
Code: [AUSKLAPPEN]
Start
Bedingung: keine; abgeschlossene Quest x
Aufgabe: rede mit NPC x
Quest (1-10)
Aufgabe: töte Gegner/Gruppe x; rede mit NPC x; benötigtes Item x Anzahl y besitzen
Naja, ist eigentlich auch fast so geblieben. Das sollte so funktionieren:
Um eine Quest annehmen zu können, gibt es entweder keine Bedingung, oder man muss schon eine andere Quest beendet haben (z.B. in einer Fraktion). Dann muss man eben mit einem NPC reden, um sie zu bekommen.
Da die Quest ja nicht immer strikt gehalten ist (also man redet mit NPC, dann macht man die Aufgabe und geht wieder zurück), dachte ich mir, man kann maximal 10 Aufgaben pro Quest machen. Also z.B. man geht erst zum NPC, der sagt, man soll die Monster aus einer Höhle vertreiben, dort findet man aber ein Amulett von jemand anderem, dann bringt man es demjenigen zurück und dann soll man wieder zum Auftraggeber.
Als ich dann aber anfing, den Quest-Editor (mitsamt System) zu coden, fiel mir auf, dass es so nicht ganz funktionieren kann. Zum einen wusste ich nicht, wie viele Aufgaben dem Spieler "dazwischen kommen" (Quest 1-10). Das hab ich jetzt halt statt mit einem Array mit einer List gelöst.
Zum anderen aber muss ja immer etwas dazwischen passieren, z.B. dass der NPC etwas anderes sagt. Deshalb dachte ich mir, dass ich "Effekte" einbaue (dabei kam mir wieder der Szenarien-Editor von Empire Earth in Erinnerung), die sowas übernehmen. Dann war das Problem nur, wie ich die variable Reihenfolge von Aufgaben und Effekten unterbringe. Dafür habe ich mich dann wieder für das Verwenden von Listen entschieden.
Ich hatte also bisher drei Types, von denen zwei dieselben Felder hatten und deshalb zu einem zusammengefasst wurden. Man kann sie durch ein extra Feld "Typ" unterscheiden.
Code: [AUSKLAPPEN]
Type TQuest
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
End Type
ParamX und ParamY sind die Parameter für die jeweilige Art der Aufgabe bzw. des Effekts, also z.B. die ID des NPC.
StartList speichert die Aufgaben und Effekte, die vor der eigentlichen Quest kommen. QuestList speichert dann logischerweise die Aufgaben und Effekte, die während der eigentlichen Quest auftreten. Ein Beispiel, das das erläutern wird, werde ich demnächst einmal posten.
Das Gute an diesem System ist, dass sich ohne Probleme die "Arten" der Aufgaben und Effekte erweitern lässt. Deshalb sollte es möglich sein, dass alle Quest-Ideen umgesetzt werden können.
Bis jetzt habe ich lediglich das System, zurzeit bin ich über dem Quest-Editor. Ob es gut in das Hauptprogramm eingebaut werden kann, wird sich erst später herausstellen. Ich habe aber ein gutes Gefühl. ^^
Ich finde es sehr schwierig, da es so variabel sein muss. Immerhin will ich ja keine simplen und auf Dauer gleichen "Töte 20 hiervon, und am besten nochmal 30 davon" oder "Sammle 5 hiervon, 3 davon und 17 davon" machen, sondern innovative, motivierende und abwechslungsreiche Quests. Und dafür muss meine Engine eben sehr flexibel sein.
Auch wenn man das alles gar nicht extern, sondern auch intern lösen könnte (Hardcoding), finde ich diesen Weg sehr viel besser, wenn es auch mehr Überlegungszeit benötigt. Aber ich bin mir sicher, dass es mir im Nachhinein viel, viel Zeit gespart hat, dass ich kein Hardcoding gemacht habe.
Jedenfalls, ich hab mir schon länger mal Gedanken zum Quest-System gemacht. Damals dachte ich mir das so:
Code: [AUSKLAPPEN]
Start
Bedingung: keine; abgeschlossene Quest x
Aufgabe: rede mit NPC x
Quest (1-10)
Aufgabe: töte Gegner/Gruppe x; rede mit NPC x; benötigtes Item x Anzahl y besitzen
Naja, ist eigentlich auch fast so geblieben. Das sollte so funktionieren:
Um eine Quest annehmen zu können, gibt es entweder keine Bedingung, oder man muss schon eine andere Quest beendet haben (z.B. in einer Fraktion). Dann muss man eben mit einem NPC reden, um sie zu bekommen.
Da die Quest ja nicht immer strikt gehalten ist (also man redet mit NPC, dann macht man die Aufgabe und geht wieder zurück), dachte ich mir, man kann maximal 10 Aufgaben pro Quest machen. Also z.B. man geht erst zum NPC, der sagt, man soll die Monster aus einer Höhle vertreiben, dort findet man aber ein Amulett von jemand anderem, dann bringt man es demjenigen zurück und dann soll man wieder zum Auftraggeber.
Als ich dann aber anfing, den Quest-Editor (mitsamt System) zu coden, fiel mir auf, dass es so nicht ganz funktionieren kann. Zum einen wusste ich nicht, wie viele Aufgaben dem Spieler "dazwischen kommen" (Quest 1-10). Das hab ich jetzt halt statt mit einem Array mit einer List gelöst.
Zum anderen aber muss ja immer etwas dazwischen passieren, z.B. dass der NPC etwas anderes sagt. Deshalb dachte ich mir, dass ich "Effekte" einbaue (dabei kam mir wieder der Szenarien-Editor von Empire Earth in Erinnerung), die sowas übernehmen. Dann war das Problem nur, wie ich die variable Reihenfolge von Aufgaben und Effekten unterbringe. Dafür habe ich mich dann wieder für das Verwenden von Listen entschieden.
Ich hatte also bisher drei Types, von denen zwei dieselben Felder hatten und deshalb zu einem zusammengefasst wurden. Man kann sie durch ein extra Feld "Typ" unterscheiden.
Code: [AUSKLAPPEN]
Type TQuest
Field Name:String
Field StartBedingung:String
Field StartBedingungParam:String
Field StartList:TList = New TList
Field QuestList:TList = New TList
End Type
Type TAufgabe
Field Typ:Byte
Field Art:String
Field ParamX:Short
Field ParamY:Short
End Type
ParamX und ParamY sind die Parameter für die jeweilige Art der Aufgabe bzw. des Effekts, also z.B. die ID des NPC.
StartList speichert die Aufgaben und Effekte, die vor der eigentlichen Quest kommen. QuestList speichert dann logischerweise die Aufgaben und Effekte, die während der eigentlichen Quest auftreten. Ein Beispiel, das das erläutern wird, werde ich demnächst einmal posten.
Das Gute an diesem System ist, dass sich ohne Probleme die "Arten" der Aufgaben und Effekte erweitern lässt. Deshalb sollte es möglich sein, dass alle Quest-Ideen umgesetzt werden können.
Bis jetzt habe ich lediglich das System, zurzeit bin ich über dem Quest-Editor. Ob es gut in das Hauptprogramm eingebaut werden kann, wird sich erst später herausstellen. Ich habe aber ein gutes Gefühl. ^^
Der Häuser-Editor

Hallo Community.
Beim letzten Eintrag habe ich nur allgemein etwas über Iliran erzählt, aber jetzt werde ich auch mal etwas genauer auf die Programmierung eingehen.
In der letzten Woche habe ich mich hauptsächlich um einen Part des Spiels gekümmert, der eigentlich sogar ziemlich wichtig ist: das Wechseln von Innen- zu Außenwelt, also das Betreten von Häusern (und Dungeons). Immerhin ist es ziemlich langweilig, die ganze Zeit in der Landschaft rumzulaufen, ohne auch mal ein die Inneneinrichtung der Bewohner Ilirans zu sehen.
Die meiste Zeit der letzten Tage hat mein "Häuser-Editor" in Anspruch genommen. Eigentlich hätte ich die Angaben für den Map-Wechsel auch einfach manuell in eine Datei schreiben können, aber ich finde den Editor trotzdem ziemlich nützlich, vor allem was die Arbeit an einem Add-On angeht, oder aber, (wenn ich die Editoren veröffentliche) das Modden. Ich wollte für alles extra Editoren machen, also auch für NPCs, Gegner etc., nicht nur aus dem Grund, dass es viel bequemer ist, sondern auch wegen der Erfahrung.
Hier erstmal ein Screenshot von meinem Häuser-Editor (da er zur Entwicklung gehört, und nicht direkt zum Spiel, wird er nicht auf der Website veröffentlicht):
(die Maus wurde von Windows entfernt ^^)
Man erkennt hierauf eigentlich sehr schön das Prinzip. Es gibt einen Type TVerbindung. Dieser sieht wie folgt aus:
Code: [AUSKLAPPEN]
Jeder Verbindung (zwischen der Außenwelt und einem Haus/Dungeon) wird eine individuelle Nummer zugewiesen. Damit wird sie später ansprechbar sein.
StartMap ist der Name der .map-Datei, auf der sich der Spieler befinden muss, um die Verbindung benutzen zu können.
X/Y bzw. StartX/Y speichert die Position (in Tiles), die der Spieler haben muss, damit er die Verbindung benutzen kann.
ZielMap ist der Name der .map-Datei, die geladen wird, wenn der Spieler die Verbindung aktiviert. Und er befindet sich dann auf der Position ZielX, ZielY der ZielMap.
Das Prinzip ist erkennbar einfach. Mit dem Häuser-Editor kann man eine neue Verbindung erstellen, eine vorhandene ansehen, löschen oder editieren. Das System ist auch schon ins Hauptprogramm eingebaut, aber ich werde des demnächst noch etwas verbessern/erweitern.
Im Hauptprogramm musste ich aber für die Map-individuellen Types, also die Types, bei denen es Objekte in der einen, aber auch in der anderen Map gibt (das betrifft fast alle ^^), noch ein eigenes Feld eintragen. Das heißt "MapName" und speichert den Namen der .map-Datei (wie StartMap und ZielMap im Verbindung-Type), und muss mit der Variable "MapName" aus dem Hauptprogramm übereinstimmen, damit sich für diese Instanz überhaupt etwas tut.
Das wars soweit von mir.
Was demnächst noch ansteht:
-den Code etwas übersichtlicher machen
-Quest-Editor (ich mache den jetzt vor dem Beschwören von Gegnern, damit ich endlich mal ein Video hochladen kann ^^)
MFG Lador
Beim letzten Eintrag habe ich nur allgemein etwas über Iliran erzählt, aber jetzt werde ich auch mal etwas genauer auf die Programmierung eingehen.
In der letzten Woche habe ich mich hauptsächlich um einen Part des Spiels gekümmert, der eigentlich sogar ziemlich wichtig ist: das Wechseln von Innen- zu Außenwelt, also das Betreten von Häusern (und Dungeons). Immerhin ist es ziemlich langweilig, die ganze Zeit in der Landschaft rumzulaufen, ohne auch mal ein die Inneneinrichtung der Bewohner Ilirans zu sehen.
Die meiste Zeit der letzten Tage hat mein "Häuser-Editor" in Anspruch genommen. Eigentlich hätte ich die Angaben für den Map-Wechsel auch einfach manuell in eine Datei schreiben können, aber ich finde den Editor trotzdem ziemlich nützlich, vor allem was die Arbeit an einem Add-On angeht, oder aber, (wenn ich die Editoren veröffentliche) das Modden. Ich wollte für alles extra Editoren machen, also auch für NPCs, Gegner etc., nicht nur aus dem Grund, dass es viel bequemer ist, sondern auch wegen der Erfahrung.
Hier erstmal ein Screenshot von meinem Häuser-Editor (da er zur Entwicklung gehört, und nicht direkt zum Spiel, wird er nicht auf der Website veröffentlicht):

(die Maus wurde von Windows entfernt ^^)
Man erkennt hierauf eigentlich sehr schön das Prinzip. Es gibt einen Type TVerbindung. Dieser sieht wie folgt aus:
Code: [AUSKLAPPEN]
Type TVerbindung
Field Nr:Short
Field StartMap:String
Field X:Short
Field Y:Short
Field ZielMap:String
Field ZielX:Short
Field ZielY:Short
End Type
Field Nr:Short
Field StartMap:String
Field X:Short
Field Y:Short
Field ZielMap:String
Field ZielX:Short
Field ZielY:Short
End Type
Jeder Verbindung (zwischen der Außenwelt und einem Haus/Dungeon) wird eine individuelle Nummer zugewiesen. Damit wird sie später ansprechbar sein.
StartMap ist der Name der .map-Datei, auf der sich der Spieler befinden muss, um die Verbindung benutzen zu können.
X/Y bzw. StartX/Y speichert die Position (in Tiles), die der Spieler haben muss, damit er die Verbindung benutzen kann.
ZielMap ist der Name der .map-Datei, die geladen wird, wenn der Spieler die Verbindung aktiviert. Und er befindet sich dann auf der Position ZielX, ZielY der ZielMap.
Das Prinzip ist erkennbar einfach. Mit dem Häuser-Editor kann man eine neue Verbindung erstellen, eine vorhandene ansehen, löschen oder editieren. Das System ist auch schon ins Hauptprogramm eingebaut, aber ich werde des demnächst noch etwas verbessern/erweitern.
Im Hauptprogramm musste ich aber für die Map-individuellen Types, also die Types, bei denen es Objekte in der einen, aber auch in der anderen Map gibt (das betrifft fast alle ^^), noch ein eigenes Feld eintragen. Das heißt "MapName" und speichert den Namen der .map-Datei (wie StartMap und ZielMap im Verbindung-Type), und muss mit der Variable "MapName" aus dem Hauptprogramm übereinstimmen, damit sich für diese Instanz überhaupt etwas tut.
Das wars soweit von mir.
Was demnächst noch ansteht:
-den Code etwas übersichtlicher machen
-Quest-Editor (ich mache den jetzt vor dem Beschwören von Gegnern, damit ich endlich mal ein Video hochladen kann ^^)
MFG Lador
Allgemein: Was ist Iliran?

Hallo Community.
Da ich schon seit fast 3 Jahren an meinem 2D-Rollenspiel Iliran arbeite, und weil in letzter Zeit immer mehr Worklogs über Rollenspiele geschrieben werden hab ich mich jetzt dazu entschlossen, auch endlich einmal einen Worklog zu schreiben und mich den anderen "anzuschließen"... ^^
Iliran ist ein 2D-Fantasy-Rollenspiel. Mein Ziel war (und ist) es, ein Spiel mit motivierenden Quests, einem einfach zu verstehenden aber doch fähigem Charaktersystem, einer abwechslungsreichen Landschaft und einfach größerer Freiheit zu erschaffen. Ich muss dabei aber zugeben, ich habe mich sehr an der ElderScrolls-Reihe orientiert (was der ein oder andere sicherlich auch noch bemerken wird) ... ^^
Auch wenn ich schon seit fast 3 Jahren an Iliran arbeite (anfangs aber nur theoretisch, da habe ich nur Sachen aufgeschrieben und überlegt), bin ich immer nur schrittweise vorangekommen. Eigentlich war ich gerade dabei, ein anderes Rollenspiel zu machen, und die Ideen für Iliran sollten für ein späteres Spiel gebraucht werden. Doch das damalige Projekt scheiterte durch mangelnde Motivation meinerseits (was meiner Meinung an der miserabel gestalteten Map und der schlechten Technik lag).
Danach verlor ich für einige Monate die Lust am Programmieren und wollte ein kleines Test-MMORPG schreiben. Ich hatte die Grundengines (Laufen, Kämpfen, mit NPCs reden, naja mehr eigentlich auch nicht) ziemlich fertig. Dann aber kam es nie zu dem besagten MMORPG, aber ich wollte die Engines für Iliran benutzen. Deshalb arbeite ich eigentlich erst seit Sommer 2007 richtig an Iliran.
Nach und nach verbesserte ich die Engines immer mehr und kann jetzt eigentlich sagen, dass ich sehr zufrieden bin. ^^ (Mehr zu der Entstehungsgeschichte werde ich wahrscheinlich irgendwann einmal auf der offiziellen Website veröffentlichen - Extra Large ^^, link unten)
Vor ziemlich genau einem Jahr fragte ich dann Terabite (der in diesem Forum als PlanetLone eher bekannt sein dürfte), ob er für mich die Mapgestaltung übernehmen wolle (weil er mir das lange Zeit vorher einmal angeboten hatte), und nur wegen ihm konnte ich den Zielpunkt "abwechslungsreiche Landschaft" abhaken. ^^
Jetzt noch einen Screenshot (vielleicht kennt ihn jemand aus der Galerie), der ist zwar schon über neun Monate alt, aber grafisch hat sich bis jetzt kaum etwas getan (außer das nun auch NPCs in der Landschaft rumlaufen, mit denen man reden kann ^^):
(https://www.blitzforum.de/gallery/1080/)
(Ich frage evtl. noch einmal Terabite, ob er nicht die Figuren entpixeln könnte.)
Ich hoffe, ich werde demnächst noch ein paar Sachen fertigstellen können (Häuser betreten, Quest-Editor + -System, Bugs ausmerzen), damit ich auch einmal ein Video hochladen kann.
Zudem hoffe ich, dass euch mein erster Worklog-Eintrag gefallen hat, und dass ich euer Interesse etwas wecken konnte.
Siehe auch:
www.iliran.de.vu <- offizielle Website
www.iliran-forum.de.vu <- Forum, bei Fragen oder Anregungen
MFG Lador
Da ich schon seit fast 3 Jahren an meinem 2D-Rollenspiel Iliran arbeite, und weil in letzter Zeit immer mehr Worklogs über Rollenspiele geschrieben werden hab ich mich jetzt dazu entschlossen, auch endlich einmal einen Worklog zu schreiben und mich den anderen "anzuschließen"... ^^
Iliran ist ein 2D-Fantasy-Rollenspiel. Mein Ziel war (und ist) es, ein Spiel mit motivierenden Quests, einem einfach zu verstehenden aber doch fähigem Charaktersystem, einer abwechslungsreichen Landschaft und einfach größerer Freiheit zu erschaffen. Ich muss dabei aber zugeben, ich habe mich sehr an der ElderScrolls-Reihe orientiert (was der ein oder andere sicherlich auch noch bemerken wird) ... ^^
Auch wenn ich schon seit fast 3 Jahren an Iliran arbeite (anfangs aber nur theoretisch, da habe ich nur Sachen aufgeschrieben und überlegt), bin ich immer nur schrittweise vorangekommen. Eigentlich war ich gerade dabei, ein anderes Rollenspiel zu machen, und die Ideen für Iliran sollten für ein späteres Spiel gebraucht werden. Doch das damalige Projekt scheiterte durch mangelnde Motivation meinerseits (was meiner Meinung an der miserabel gestalteten Map und der schlechten Technik lag).
Danach verlor ich für einige Monate die Lust am Programmieren und wollte ein kleines Test-MMORPG schreiben. Ich hatte die Grundengines (Laufen, Kämpfen, mit NPCs reden, naja mehr eigentlich auch nicht) ziemlich fertig. Dann aber kam es nie zu dem besagten MMORPG, aber ich wollte die Engines für Iliran benutzen. Deshalb arbeite ich eigentlich erst seit Sommer 2007 richtig an Iliran.
Nach und nach verbesserte ich die Engines immer mehr und kann jetzt eigentlich sagen, dass ich sehr zufrieden bin. ^^ (Mehr zu der Entstehungsgeschichte werde ich wahrscheinlich irgendwann einmal auf der offiziellen Website veröffentlichen - Extra Large ^^, link unten)
Vor ziemlich genau einem Jahr fragte ich dann Terabite (der in diesem Forum als PlanetLone eher bekannt sein dürfte), ob er für mich die Mapgestaltung übernehmen wolle (weil er mir das lange Zeit vorher einmal angeboten hatte), und nur wegen ihm konnte ich den Zielpunkt "abwechslungsreiche Landschaft" abhaken. ^^
Jetzt noch einen Screenshot (vielleicht kennt ihn jemand aus der Galerie), der ist zwar schon über neun Monate alt, aber grafisch hat sich bis jetzt kaum etwas getan (außer das nun auch NPCs in der Landschaft rumlaufen, mit denen man reden kann ^^):
(https://www.blitzforum.de/gallery/1080/)

(Ich frage evtl. noch einmal Terabite, ob er nicht die Figuren entpixeln könnte.)
Ich hoffe, ich werde demnächst noch ein paar Sachen fertigstellen können (Häuser betreten, Quest-Editor + -System, Bugs ausmerzen), damit ich auch einmal ein Video hochladen kann.
Zudem hoffe ich, dass euch mein erster Worklog-Eintrag gefallen hat, und dass ich euer Interesse etwas wecken konnte.
Siehe auch:
www.iliran.de.vu <- offizielle Website
www.iliran-forum.de.vu <- Forum, bei Fragen oder Anregungen
MFG Lador